Growth Tracking Verify

Prove the pipe flows. Three different layers can each look healthy while tracking is broken: the code calls trackEvent (page layer), the property is configured to receive it (measurement layer — the growth-measurement-audit skill), and yet nothing arrives — tag not loaded, gated out by environment, blocked, pointed at the wrong measurement ID. The only proof is firing the real flow and watching the event arrive.

A real case that motivates the method: a server started cleanly, reported healthy, and was silently running on template defaults — wrong port, wrong name, feature disabled. Its config file was never loaded. "It deployed and nothing errored" is not verification; observed arrival is.

Which property to verify (target resolution)

Resolve the target in this order, and say which rule applied before firing anything:

1. Named target wins. If the request names a site, property, or deploy, verify that.
2. Otherwise, default to the manifest in data/. Each real data/checklist-<property>.md describes one property this skill instance covers. Exactly one real manifest → that property is the default; state it and proceed. Several → ask which. Two files never bind this rule: anything named data/example-* (fictional documentation, never a target) and a manifest whose content says it is scrubbed / describes no property (treat as absent).
3. No real manifest? Ask the user which property/site to verify, then build its manifest first — verifying without one tests whatever you happened to remember.

Working copies, clones, and publishing

data/ is per-account state, not part of the runbook. The intended model:

• The published/master skill carries only data/example-* files — fictional, clearly marked, safe to be public.
• To use the skill on a real property, clone it and build the real manifest on first use; from then on the clone defaults to its own property.
• Never publish real state. A manifest is a complete event taxonomy — event names, expected params, and the measurement target — which is exactly the kit needed to inject plausible fake events into a property (GA4's collect endpoint is unauthenticated). If a clone with a real manifest must be shared, share it tenant-scoped, never publicly.

Prerequisites

• The google-search MCP connector — ga4_run_realtime, ga4_run_report, ga4_key_events.
• A browser on the target site (Claude in Chrome, or a human following the checklist). The browser must not run an ad-blocker — a blocked tag fails the test without telling you anything about the site.

Method

1. Read the manifest. It lists each flow to fire, the expected event name, the expected parameters, and whether the event should be a key event (format: data/example-checklist.md). Also read references/procedure.md for polling cadence and the failure-signature table.

2. Snapshot realtime BEFORE firing. ga4_run_realtime(property, dimensions: [eventName]) — record current counts. An event already streaming at volume can mask your single test firing; the before/after delta is the evidence, not presence alone.

3. Fire the real flow in the browser. Click the actual CTA, submit the actual form, walk the actual signup. Never inject events directly (gtag calls from the console, Measurement Protocol test hits) as a substitute — an injected event proves the property accepts data, not that the site sends it. Injection is a diagnostic for isolating WHICH half is broken, never a pass.

4. Poll realtime for arrival. Every ~30s, up to 10 minutes. Realtime typically shows events within a minute; the window covers the last 30.

   • Verify the event name appears / increments.
   • Verify the property: if the site's host matters (multi-host streams), confirm via a realtime or next-day report that traffic carries the expected hostName — arrival in the wrong property is a distinct failure with a distinct fix.

5. Verify parameters the honest way. Realtime dimension support is limited; do not conclude params are missing from a realtime blind spot. Event-scoped custom dimensions (customEvent:<param>) are authoritative in the standard report the NEXT day — schedule that follow-up check and say it is pending rather than passing it on faith. For same-day param evidence, GA4 DebugView (with debug_mode) is the manual fallback; references/procedure.md describes it.

6. Diagnose non-arrival by signature, not guesswork — the table in references/procedure.md maps symptoms (nothing arrives / name without params / wrong property / no session source / dev-host pollution) to causes and to the check that confirms each.

Report format

For each manifest line, one verdict (see data/example-verify-log.md for a complete fictional run):

| Flow | Event | Arrived | Params verified | Notes |
|---|---|---|---|---|
| toolbar signup CTA | signup_click | YES (+1 in 40s) | pending next-day report | — |

Verdicts are exactly: YES (observed delta), NO (fired, absent after 10 min — include the diagnosed signature), BLOCKED (could not fire the flow; say why), PENDING (param check awaiting next-day data). Never mark YES on faith, code reading, or an injected event.

After the run: write state back

• Append the run's results table to data/verify-log.md with date, deploy or change being verified, and browser used.
• Update the manifest if flows were added/removed on the site.

Use save_skill_resource; draft reads are immediate, no publish needed.

Honesty rules

• Absence is "not observed in N minutes", never "the event doesn't fire". State N.
• Realtime counts are not final counts; never quote them as traffic.
• If the testing browser might have blocked the tag, the whole run is invalid — say so and rerun clean, don't caveat individual rows.
• A verification you didn't run is PENDING, not passed. Silent scope reduction is how "we verified tracking" becomes false.