Tracking Plan Template for a Lead Business

A tracking plan is a document that lists every event you measure, where it fires, what each tool calls it, who owns it and how you prove it still works. For a lead business that means five rows (form submit, call, booking, qualified lead and sale), each tied to a GA4 event and a Google Ads conversion action, as in the template below, checked against the vendors' help pages on October 3, 2026.

The tracking plan template

One row per lead event, one column per question someone asks when a number looks wrong.

Replace each cell with your own pages, actions and people, and write "none" rather than leave a cell blank, so the gap reads as known. Categories and call action names are Google's labels (conversion categories, call setup).

Which GA4 events and parameters belong in it?

Google's recommended lead events, not invented names: generate_lead when someone submits a form online or information offline, qualify_lead when a lead is marked as qualified, close_convert_lead when it becomes a customer. Sending them populates GA4's Lead acquisition report (recommended events). Each takes value and currency, and currency is required whenever value is set (event reference). A custom parameter such as lead_type needs a custom dimension, created on the Custom definitions page in Admin, before you can report on it, and Google says that takes 24 to 48 hours (custom dimensions). Event and parameter names stay within 40 characters (collection limits).

The qualified and sale rows happen in a CRM, so they reach GA4 only if you send them: a server job through the Measurement Protocol, or an events upload through Data Import. The browser-side event is covered in GA4 key events for leads.

Which Google Ads actions should be primary?

Primary actions count in the Conversions column and drive bidding when their goal is used for bidding; secondary actions show in All conversions, for observation only (primary and secondary actions). You set it under Goals > Conversions > Summary, Edit goal, in the Conversion action optimization section: Primary or Secondary (observe only).

The column exists so one lead never counts twice for bidding. Google sets actions built from GA4 key events to secondary when the account already has goals from Analytics, for exactly that reason (GA4 key event conversions). If someone flips an imported generate_lead to primary while the Ads tag counts the same form, the form row lists two primary actions for one lead. My rule: no lead counts in two primary actions, and imported stages stay secondary until their uploads arrive on schedule. Creating each action is covered in how to set up conversion tracking in Google Ads.

What value and count go in each row?

Google Ads lets an action measure the same value for each conversion or different values, the second needing dynamic values in your tracking code (conversion values). Each uploaded conversion can carry its own value, and a blank one falls back to the action's default (import fields). Count One records one conversion per ad click, which Google suggests when you care whether a lead was generated; Every records each one, its suggestion for sales (count settings). So the lead rows get a fixed value with One, and the sale row the real amount with Every. Which number goes in the value cell is its own decision: what value to send.

How do you write the test column?

As a check someone else can run without asking you: the action, the tool and what they should see. That means Preview in Tag Manager before a publish, DebugView for events as GA4 collects them, Tag Assistant for Google Ads website actions, and offline data diagnostics for imports. Calls differ: Google swaps in its forwarding number only for users who clicked an ad (call conversion types), so a plain test visit never shows it.

Write down where the test runs from, too. When agents audited public pages of practices I researched for outreach, headless Chrome captured what each site sent (gtm.js, the gtag config, conversion requests), read-only, never submitting a form. One finding, consent denied on a Wix site with no banner, held only because the check ran from Bulgaria, and I withdrew it. Wix sends no data to Google Analytics from visitors in countries that require consent when a site has no cookie banner (Wix help), so a test from the EU sees a different site than a US visitor.

Why is the plan the first file an agent reads?

In a recorded talk, Lauren Tan, an engineer at Cursor, describes a feature map file in a skill that lets her agent run and inspect the app. Before the map, the agent could launch the app but flailed, searching the code for where a feature lived and how to reach it. The map tells it how to reach each feature, down to the attributes used to select it, so even a vague report or a bare screenshot maps to something it can open.

A tracking plan is that map for measurement. "Google Ads shows fewer leads this week" becomes a row, the tag or upload behind it, its owner and its test, whether the reader is an agent or a new hire. In Claude Code, CLAUDE.md loads at the start of every session and can import other files with @path/to/import syntax (memory docs), so one import line puts the plan in front of the agent every time. It is context, not enforced configuration; blocking an action takes a hook.

How do you keep the plan current?

The plugin Tan describes ships a skill that maintains the map next to the one that creates it; a plan needs the same habit. Update the row in the same change as the tag, form or action it describes. In Tag Manager, put the row's name in the Version Name and Version Description you enter at publish; the publish history shows when each version was live and who published it (versions).

Where the plan stops

A plan with every row filled still ends at the form, the call and the booking unless something sends the qualified and sale rows. Getting those CRM stages back to the ad click is closed-loop attribution, the part I build.