A complete GA4 tracking plan used to take me hours of clicking, screenshotting and writing. Recently I produced one with 47 events, ready for developers, while the AI did the exploration in minutes and I worked on something else.
The difference was not cutting corners. I split the work: an AI agent explored the site and wrote the first draft, and I spent my time where an engineer is actually needed, on validation and the edge cases the agent could not see.
This article walks through that process on a real (anonymized) project. You will see what AI does surprisingly well, where it fails silently, and what a tracking plan needs so a developer can implement it without a single follow-up call.
Why tracking plans are slow, and why developers hate bad ones
The tracking plan is the contract between whoever needs the data and whoever writes the code. When it is vague, the developer guesses, and you discover the guesses weeks later in GA4 reports that don't add up.
Writing a good one is slow because it is manual:
- Walk every flow on the site, on desktop and mobile, as a real user would.
- Screenshot every interaction and mark exactly where each event should fire.
- Map the site's own data (product codes, prices, store IDs) to GA4's ecommerce parameters.
- Write a
dataLayer.pushfor each event that a developer can copy and paste. - Document the rules nobody writes down: clearing the ecommerce object, number formats, deduplication, consent.
Most of these steps are repetitive. That is exactly where an AI agent with a browser earns its keep.
The case: a restaurant chain with ordering and table booking
The site belongs to an Italian restaurant chain. Its site has two conversion flows, both on a separate ordering subdomain: an Order flow for pickup and delivery, and a Book flow for table reservations. There was no GTM and no dataLayer on the ordering platform, so tracking started from zero.
I gave the agent the site, a base spreadsheet and one instruction: simulate every interaction in both flows and adapt GA4's ecommerce events wherever they fit.
What came back:
| Area | Result |
|---|---|
| Events | 47 in total: 6 global, 30 in Order, 11 in Book |
| Per event | Name, trigger moment, annotated screenshot, example URL, copy-paste dataLayer.push, parameter rules, status dropdown, developer notes |
| Real data | Product SKUs and restaurant codes read from the site's own API, so examples use real values |
| Extra sheets | Cover index, developer guide, variable dictionary, item object mapping, GTM + Consent Mode v2 setup, changelog |
The agent also adapted GA4's model to how a restaurant actually sells. Delivery hands the user off to third-party platforms, so it became a custom delivery_partner_click event. With no shipping, add_shipping_info now carries pickup mode, restaurant and time slot. In the Book flow the conversion is generate_lead.
It also found interactions I would have listed only on a second pass: a cross-sell drinks popup (shown, added, dismissed), promotions (view_promotion, select_promotion), vegan and vegetarian filters, allergen views, dish customization, promo codes, payment errors and "no slots available" in booking.
Where the AI stops and the engineer starts
The draft looked finished. It was not, and the gaps were exactly the ones a non-specialist would miss.
| What the AI handled well | What it missed or could not verify |
|---|---|
| Walking both flows and listing every interaction | The purchase and generate_lead confirmation pages: it rightly stopped before paying or booking, so they were specified blind |
| Mapping site data to GA4 item parameters | Login, registration and mobile cart: the session was already logged in and tested on desktop only |
Writing consistent, copy-paste dataLayer code | Personal data: the user's email appeared in screenshots and had to be blurred |
| Producing the developer guide and checklists | Placeholders for GTM container and GA4 property IDs |
None of these are cosmetic. A wrong purchase event breaks revenue reporting and every bidding strategy built on it. Unchecked PII in a shared document is a GDPR problem. Untested mobile flows are where most orders happen.
So my process now has two halves. The agent does the exploration and the first draft. I review every conversion event against the real confirmation flow, mark what is unverified as "to confirm with developers", check hashing and consent, and decide what is worth tracking at all. The agent saves the hours; the review is what makes the data trustworthy.
Anatomy of a developer-ready tracking plan
The test is simple: a developer opens the file and knows what to do without calling you. These are the columns every event row needs.
| Column | Why it matters |
|---|---|
| Event name | The exact GA4 name, snake_case, no ambiguity |
| Trigger | When it fires, in words ("after the item is added to the cart, not on click") |
| Screenshot | The element highlighted, so nobody tags the wrong button |
| Example URL | Where to reproduce it |
dataLayer.push | Copy-paste code with realistic values |
| Parameter rules | Types, formats, allowed values |
| Status | Dropdown: to do, in progress, implemented, validated |
| Notes | Edge cases and open questions |
Around the event sheets, a few supporting sheets save a lot of back-and-forth:
- Cover: an index of all events with links to each row.
- Developer guide: shared rules such as
ecommerce: nullbefore each push, single-page navigation, number formats, deduplication and SHA-256 hashing foruser_data. - Variable dictionary: every parameter with its allowed values.
- Item mapping: how the site's product fields become GA4 item parameters.
- GTM setup: container install with Consent Mode v2.
- Changelog: what changed and when.
The takeaway, and how to get yours
AI has turned the slowest part of a tracking project into the fastest. It has not removed the need for someone who knows what a broken purchase event costs.
