Event flow — empirical Markov chain from real logs
What actually happens vs what the invariants say should happen

Three observations that pop out of the graph:

1. Massive self-loops on the two dominant events. page.dwell → page.dwell at 100% and element.impression → element.impression at 88%. Both are legitimate — the page-dwell one fires on every visibilitychange (many tabs backgrounding + returning) and the impression self-loop is the observer walking through a viewport of ten trackable elements in sequence. But visually they dominate, which is why filtering to P ≥ 3% still leaves them front and centre. A third self-loop has emerged today: sponsored.timeout → sponsored.timeout at 79%. The sponsored.timeout event class did not exist in yesterday's snapshot — 61 events fired today, and nearly all of them chain into another timeout on the same slot.
2. pageview → page.dwell at 64%. Nearly two-thirds of sessions leave the first page fast enough that no other event fires between the initial pageview and the terminal page.dwell — up from 55% yesterday. The shallow-bot majority tightened over the day, consistent with the operator's note that most sessions are shallow bot traffic — humans usually trigger at least one impression before pagehide.
3. element.click → element.dwell at 34%. A click is often followed by the click target scrolling out of view, firing dwell on the item that was clicked. Useful signal — it says "the user's attention moved past the clicked element rather than staying on it." Higher than dwell after hover (23% total across the three hover edges) which suggests clicks are less exploratory. Rate unchanged from yesterday — the click-follow behaviour is stable across the day.

34,874 tracker events across 11,688 sessions = 3.0 events per session average. Median is much lower (dominated by long-tail crawler sessions with 1-2 events each — 90.7% of sessions today fired exactly two events, see §5.5) — the operator's own sessions run 60+ events. See bb scripts/tracker-intent.clj --group session --format counts for the per-session bucket distribution.

By event type (from the 2026-08-18 snapshot):

sponsored.timeout is new since the 2026-08-17 snapshot — the tracker is now emitting a distinct timeout signal when a sponsored slot fails to fill within the auction window, which shows up in the graph as a heavy self-loop (79%) on the same slot as the retry mechanism attempts to refill.

The most striking shift versus 2026-08-17: page.dwell share climbed from 24.5% to 64.3% of all events. This is the shallow-bot signal from §5.5 amplifying — more sessions today fired the visibility/pagehide pair without any impression in between.

form.submit fired zero times today. All 18 form.focus events are on /search. There is one form in the wal.sh HTML — the search input — and it does not submit; the pocket-es UI syncs the URL on each keystroke and re-runs the search live. The submit handler on the form is a no-op that returns false.

So the empirical form.focus → form.submit transition is correctly zero, and would remain zero even at min-p = 0. The invariant permits the transition; the site has nothing to submit.

The divergence is a site fact, not a tracker bug. The tracker's form.submit listener is correctly wired (on-submit in browser.cljs); it has nothing to observe.

What it says. The invariant machine (§3) is drawn from the observer vocabulary, not from the site's deployment. A site-specific invariant machine would remove form.submit from the reachable states entirely, and would probably remove form.focus too — it fires 18 times / day, all on one search input, and the signal is dominated by dev iteration.

Follow-on. If we ever add a real form (contact / subscribe / comment), the empirical rate will move above 0. Today's rate is a useful baseline for that future comparison.

Empirical: 34%. Invariant: allowed. This one matches — it belongs in the "not-a-divergence" list, and I kept it in the table for transparency about what the empirical model does say about a transition the invariant permits.

The mechanism: a click on an element scrolls the target briefly into a new viewport position, and the IntersectionObserver fires element.dwell as the clicked element exits its old ratio bucket. This is a legitimate second-order signal — "the user's attention moved past the thing they clicked, rather than staying on it" — and it's part of the rage-click vs considered-click distinction the auditor's tag bag captures.

What it says. The observer's dwell math (§9.4) is correctly paired with the click handler (§9.2). Nothing to change.

The same 6 clicks as yesterday, still split 2 vs 4 across two uids (no new sponsored clicks landed in the 2026-08-18 log window):

Two of the six are the operator dev-testing the sy-001 sponsored unit (recent iteration on the sponsored render). The remaining four are one user clicking the same sponsored event page four times. Four repeats on the same slot from one uid within one day is rage-click territory in the LLM auditor's tag vocabulary — the observer spec §17 R69 lists it explicitly.

Retail-media benchmark context. Native ad CTR benchmarks vary by placement but 0.1-0.5% is typical for programmatic sponsored content; the IAB's 2024 report puts in-feed native at ~0.25% median. wal.sh's empirical 0.99% is ~4× that (was 5× yesterday before impressions grew). But 6 events is a n too small to defend — remove the operator's 2 self-clicks and the 4 remaining clicks from one repeating user leave 0 independent third-party interactions.

True external-user CTR today: 0% on n = 4 external users. The 0.99% is an artefact of dev traffic + one confused-or-persistent user. A retail-media auditor looking at this data would flag both the rage-click (u-6im…) and the sponsored-blind tag (605 impressions across 11,688 sessions, 0 real clicks). Denominator grew by 28% over the day while the numerator held constant — the CTR is trending toward the benchmark from above.

What it says. Sponsored slots on wal.sh currently monetise nothing because there IS no counterparty (§8 of the retrospective: A closed ecosystem hollows the market parts and leaves the rest). The auction reserve applies to a single bidder; ACOS is Infinity. This diagram is the empirical version of that argument.

Follow-on. If we wire the observer-spec's rage-click tag into stuffing-detectors.core and run against the same log, we should flag u-6im… automatically. Trivial to implement — a ~10-line bb script over the tracker-intent output.

The 26% suggests a quarter of clicks lead directly to pagehide. Two candidates: (a) external navigations (sponsored redirects, outbound links), (b) UI actions that reload the page.

The click-href breakdown reveals it's mostly neither:

elKind confirms: of the 172 element.clicks today, roughly the same 32 ui-sort / 13 ui-filter share persists, landing on search-UI chrome rather than on content or external links.

What actually happens on click → page.dwell. When a user clicks a sort chip on /search, the pocket-es UI does an in-place re-render (no navigation), but the URL updates via pushState (§10 of the observer spec — SPA navigation hook fires page.dwell for the outgoing "page" and pageview for the new one). The pushState handler is triggering page.dwell even though no real navigation happened.

This is a bug. The SPA hook is over-firing page.dwell on in-place UI updates. The 26% rate is inflated by pushState-driven "navigations" that are actually just facet changes. Real navigate-away clicks are ≤5% of the total.

Follow-on. Two options:

1. Suppress page.dwell on pushState when location.pathname is unchanged (only the query string moved). Preserves the signal for real SPA route changes.
2. Emit a new event filter.change for facet-only URL updates, distinct from page transitions.

Option 1 is the smaller change and matches user intent: someone who stays on /search and clicks three sort chips fires one pageview and one page.dwell, not four of each.

Session-length distribution across today's 11,688 unique sessions:

Ninety-one percent of sessions fire exactly two tracker events — almost certainly the pageview + page.dwell pair. That's the signal behind the pageview → page.dwell 64% edge: for the modal session, no impression / hover / scroll fires between init and exit. Compared to yesterday's snapshot the distribution shape flipped (single-event sessions dropped from 90.5% to 5.3% as two-event sessions climbed from 3.1% to 90.7%) — the shift is consistent with the tracker's page.dwell handler now firing reliably on pagehide/visibilitychange for shallow sessions where yesterday it was often being lost.

So the empirical claim: ~10,600 sessions today fired exactly the pageview / page.dwell pair and nothing else observable. Not one impression, not one scroll, not one hover. Two ways to read this:

1. Crawler majority. HeadlessChrome / Playwright / Puppeteer passes the bot? filter (R32) as false — they set neither navigator.webdriver nor an obvious UA. Their JS runs, fires pageview, exits before any IntersectionObserver settles.
2. Real users on ephemeral / news-feed impressions. Someone opens a link, sees it's not what they wanted, closes the tab within ~1s. Real but shallow.

The bot-shaped tag in the auditor vocabulary is designed for exactly this. Threshold: session with 1-2 events, sub-2-second span, and referer pattern matching known aggregators (Hacker News, Lobsters, r/programming). The tracker has ref in the envelope already; the classifier is another 20-line bb script.

The visualisation exposes this because the 64% pageview → page.dwell edge is drawn with the same visual weight as element.impression → element.impression at 88%. The graph's LR layout puts them side-by-side and the eye reads "these two things are equally important". The pageview → page.dwell edge is in fact the dominant real-world signal — the site is mostly observed by crawlers and one-glance visitors.

What it says about the tracker. R47 (both pagehide AND visibilitychange) is doing its job — otherwise many of these page.dwell events would be lost when the tab backgrounds instead of unloads. The pixel transport (R6-R8, R31) is also doing its job — the events land even for sub-second sessions.

What it says about wal.sh. Real interaction is thin. Any observability claim ("our tracker sees the user do X") applies to <10% of sessions. Everything else is a shallow view. This isn't a bug; it's the honest denominator.

Zero consent.overlay.impression, zero consent.decision, zero consent.abandon. The observer spec's §12 proposes these; the wal.sh tracker (src/wal_sh/site/tracker/) does not implement them.

Why they'd normally fire. The observer scans for [id*=consent], .cookie-notice, .cc-banner, etc. on init. Present → emit impression. Button click → classify + emit decision. 1s pagehide gate → emit abandon.

Why they don't fire on wal.sh. Two reasons, both structural:

1. No consent overlay exists on the wal.sh HTML. The homepage HTML contains no elements matching the consent-marker selectors (verified: curl -s https://wal.sh/ | grep -Ei "cookie|consent" returns no relevant hits). The site's /privacy URL is a 404.
2. The tracker code has no consent path. Even if we added an overlay tomorrow, src/wal_sh/site/tracker/browser.cljs has no attach-consent! (observer spec §12). Adding it would land the listeners; adding it without an overlay would be dead code.

Do we need one? Depends on obligations:

• GDPR: wal.sh serves EU users but collects no PII in the tracker envelope (R4 boundary — uid is opaque, no email/IP/name). PECR cookie-consent applies to cookies not localStorage, but the _ab_uid key in localStorage has been argued both ways. Defensive posture: add a banner + honour reject.
• CCPA: wal.sh has no California business nexus; likely exempt.
• ePrivacy directive: applies to "electronic communications" metadata; the pixel GET is arguably in scope.

The observer spec was written for arbitrary third-party sites where compliance is the operator's problem. On wal.sh the answer is: legal opinion needed before implementation. Not a technical-blocker.

What it says. The invariant machine's consent.* states are present because they're in the vocabulary. The empirical machine shows them absent because they're not in the deployment. Neither is wrong; they're describing different layers.

Follow-on. Add a "site-configuration" invariant machine that excludes vocabulary states the site's HTML cannot produce. That would drop consent.*, form.submit, sponsored.click (as an independent state since it collapses to 0 with real users), and result.dwell (search-mount specific — only fires on /search) into greyed-out "vocabulary allows but site never fires" boxes. Makes the gap between contract and deployment visually first-class.

Four of the six divergences (D1, D3-external-users, D4-UI-clicks, D5, D6) point at the same underlying fact: the wal.sh tracker is observing an empty room most of the time. Real interactive traffic is dominated by the operator; real third-party interaction is almost nil; sponsored monetisation is theatre because there's no counterparty; consent is unimplemented because there's nobody to consent for.

This is the parody-as-research argument from the retrospective's §3.8, made visible in the graph rather than in prose. The observer's mechanisms are correct and structural (the D2 dwell math works; the D5 dual-event pagehide/visibility handler works; the D4 SPA hook fires — even too eagerly). The mechanisms are running against traffic that doesn't have much to observe.

The one real bug the deep dive surfaced is D4's over-eager pushState → page.dwell on facet-only URL changes. That's the one to fix.