AI 生成的應用程式演示正常，註冊事件真的送達 GA4 嗎？

You vibe-coded a landing page with a lead form over a weekend. The demo works: you submit, you see the success toast, you move on. Two weeks later you open GA4 and there are three events for a form that was submitted forty times — or worse, zero.

This keeps happening to AI-built apps for a structural reason, not a careless one. The AI generates the UI and the tracking code in one pass, nobody writes a test for an event that "fires" (the page loads fine either way), and analytics bugs are silent by design: a broken button shows an error, a broken generate_lead event shows nothing at all. Your funnel just becomes quietly unmeasurable.

Here is the manual verification process that actually works today, before any tooling — learned the hard way from debugging duplicate conversions and dead DebugViews in production properties.

1. DebugView proves almost nothing. Use it anyway — correctly.

GA4 DebugView is the first place everyone looks, and the first place that lies to you. DebugView only shows events from browsers/devices running in debug mode (GTM Preview, debug_mode: true in gtag, or the GA Debugger extension). Three failure modes bite everyone:

• Events appear in DebugView but never in standard reports — often consent mode defaulting to denied, or a duplicate property/measurement ID (events going to a test property).
• DebugView shows nothing while events flow fine — your debug flag never got set on the environment you're testing.
• DebugView works in GTM Preview but not from the live site — your trigger conditions differ between preview and production (consent, data layer timing).

So: use DebugView to confirm the event structure (name, parameters), never to confirm it arrives in production conditions.

2. Inspect the actual network request

The ground truth is the request itself. Open DevTools → Network, filter for google-analytics.com/g/collect, submit your form, and read the request:

• en= — the event name. Typos here are the #1 silent killer: generate_leads never matches the generate_lead you built reports on.
• cid= / _ga cookie — the client ID. If it changes between page loads, every submission looks like a brand new user.
• ep.* — custom parameters. Verify the lead's value/label actually travels.
• gtm= — confirms which GTM container version served the tag.

For SPAs, do this twice: once on a cold load, once after client-side navigation. Route-change page_views and duplicated listeners show up only in the second pass.

3. The duplicate-event check (the one that costs real money)

A generate_lead firing twice per submission inflates conversions and corrupts every downstream bid strategy. The reliable way to count duplicates is not eyeballing DebugView — it's counting per client ID over a window:

• With BigQuery export (free tier of GA4 exports): query events_* for the last day, group by user_pseudo_id, event_name, and a 60-second timestamp bucket, and count events per bucket. Any bucket > 1 for a conversion event is a duplicate candidate.
• Without BigQuery: GA4 Explorations → open a single session → check whether one session shows twice the conversion events you expect. Crude, but it catches the common React StrictMode / double-render / retry duplicates.

Do this once per tracking release, not once ever. GTM container versions change.

4. The 10-point release checklist

Before you call tracking "done" on an AI-built app:

1. Every planned event fires with the exact documented name (en=).
2. Parameters arrive (ep.*), with correct types (revenue as number, not string).
3. The client ID is stable across a full journey (landing → form → thank-you).
4. No duplicates on double-click, no duplicates on SPA route re-entry.
5. Consent state actually gates what you think it gates.
6. Events fire in production, not only in preview/debug.
7. The thank-you page fires its conversion exactly once, on the server-confirmed outcome if possible.
8. Cross-domain links (checkout, docs) preserve the session.
9. No events fire on bot/preview/admin paths.
10. You can reproduce steps 1–9 from scratch in under 10 minutes — otherwise it will never be repeated, and it will rot.

The part I'm building

I went through this often enough — including auditing a live commerce deployment where configuration drift produced measurably wrong discount behavior, silent failures again — that I've started building an open-source tool around step 10: you define a user journey once, it drives a real browser through it (Playwright-based), asserts the analytics events that should fire — names, parameters, duplicates, consent state — alongside API and database state checks, and emits an evidence bundle you can attach to a PR or a release.

It's early — no public release yet, so there's nothing to link and nothing to oversell. If steps 2–3 above describe your week, I'd genuinely like to know which part hurts most: duplicate detection, parameter assertions, or consent-mode verification. That decides what gets built first. Comments or DM.