Website tracking often goes wrong without anyone making a big mistake. Tags are added one request at a time, by different people, with different names, until nobody can say what a "conversion" in the report actually counts.
A tracking plan helps prevent that. It is a short, shared document that says what you measure, why, how it is named, where it is sent and who owns it. Marketing and developers agree on it before anyone opens Google Tag Manager. This guide explains how to write one for a B2B lead-generation website, and ends with a template you can copy.
Five terms come up throughout:
Event: a signal your website sends to analytics when something happens, such as a form being submitted.
Parameter: an extra detail sent with an event, such as which form it was.
Key event: an event GA4 treats as a business outcome, such as a new lead. GA4 used to call these conversions.
Tag manager: a tool, usually Google Tag Manager, that receives events from your website and forwards them to analytics and ad platforms.
Data layer: the named events your website announces for the tag manager to pick up, so it doesn't have to guess from buttons and page elements.
What a tracking plan is, and isn't
A tracking plan is a table. Each row is one thing you want to measure, with:
the business question it answers,
the event name the website sends,
when it fires,
its parameters, the extra details sent with it,
the destinations it goes to, such as GA4 or an ad platform,
whether it is a key event,
an owner, and
how to test it.
It isn't a list of every click on the site. In our experience, ten to twenty events cover what most B2B websites need. A plan with a hundred events usually means most of them will never be looked at.
Start from questions, not tags
Begin with the questions marketing and sales actually need answered:
Which channels and campaigns produce qualified inquiries, not just visits?
Which pages do people visit before they request a demo?
Where do people abandon a form?
Which content is read by people who later become leads?
Do people click through to our service pages from articles?
Every event in the plan should help answer one of these. If an event doesn't, leave it out.
The core events for a B2B lead-generation website
Most B2B lead-generation sites can start from the same core set. Where Google Analytics has a recommended event for the action, use its name. GA4's recommended lead events include generate_lead for a submitted lead, qualify_lead when the lead is qualified, and close_convert_lead when it becomes a customer. Using these names fills GA4's lead acquisition reports.
Event | When it fires | Key parameters | Key event? |
|---|---|---|---|
| A form is submitted successfully, after validation | Form name, lead type (such as demo or contact) | Yes |
| A meeting is booked through your booking tool | Booking type | Yes |
| A visitor first interacts with a form | Form name | No |
| A submission fails validation | Form name, field | No |
| A primary call to action is clicked | Placement, link text, destination | No |
| A link to a service page is clicked | Placement, service | No |
| A guide or whitepaper is downloaded | File name | Sometimes |
| Sales marks the lead as qualified in the CRM | Lead type | Yes, if you send it back from the CRM |
GA4's enhanced measurement, a set of events it collects without any extra setup, can already send form_start, form_submit and file_download automatically. Either use those, or turn the matching options off before adding your own, so each action is counted once. Its form_submit fires when someone submits a form, not when your server accepts it, so don't use it as your lead key event in place of generate_lead.
The last row is worth planning even if you don't build it yet. Sending a qualification from your CRM back to analytics and ad platforms, through GA4's Measurement Protocol (a way to send events from your own server), an offline import or your CRM's own integration, is what eventually lets you optimize for pipeline rather than form fills.
Names and parameters
Consistency is what makes the data usable. Agree on a few rules:
One naming style, for example lowercase with underscores (
form_start, notForm StartorformStarted).The same parameter names everywhere. If one event calls it
placementand another calls itlocation, you can't compare them.Fire on success, not on click. A lead event should fire when the form was accepted, not when the submit button was pressed.
Never send personal data. Google's policies prohibit sending information such as email addresses or names to Analytics, including in URLs and parameters. See Google's guidance on avoiding personal information.
Name events after what happened, not after the tool that sent them. generate_lead still makes sense after you switch form providers; hubspot_form_submit doesn't.
On makersden.io, for example, every click toward a service page, the contact page or a guide is sent to the data layer as one of three named events (service_link_click, click_contact or content_link_click), each with a link_placement parameter that says where on the page it happened: main navigation, footer, an in-content link or a call-to-action button. Because every event shares the same names and parameters, a single tag manager trigger can forward all of them to GA4, and adding a new placement doesn't need a new tag.
The same principle works at a larger scale: when Perk consolidated its websites, every page and language got the same form events and parameters.
GA4 key events and conversion tracking
In GA4, actions that matter to your business are called key events. The word "conversion" is now reserved for events you use to measure and optimize ad campaigns.
Mark only real outcomes as key events: a submitted lead, a booked meeting and, later, a qualified lead. Clicks on calls to action are useful for understanding behavior, but if they count as key events, your reports will look better than your pipeline.
Plan for consent
Where analytics and advertising cookies need consent, as they generally do in the EU and UK, visitors who decline are measured differently or not at all, depending on how your tags and Google's consent mode are set up. Your plan should say:
which events fire only with consent, and which tags they feed,
how your consent banner tells the tag manager about the visitor's choice,
that you will test every key event with consent both accepted and declined.
Expect your analytics to show fewer leads than your CRM, because of declined consent and blocked scripts. Treat the CRM as the source of truth for leads, and analytics as the place to see patterns. If you use HubSpot, HubSpot forms and lead routing on any website shows how to make sure every lead arrives there with its source.
Tracking plan template
Copy this table into a spreadsheet and fill one row per event. The first rows are examples for a typical B2B site.
Question | Event | Fires when | Parameters | Destinations | Key event | Owner | How to test |
|---|---|---|---|---|---|---|---|
Which campaigns produce inquiries? |
| Form accepted by the server |
| GA4, Google Ads, LinkedIn | Yes | Marketing ops | Submit each form; check GA4 DebugView and each ad platform |
How many meetings does the site book? |
| Booking confirmed |
| GA4, Google Ads | Yes | Marketing ops | Book a test meeting; check GA4 and the CRM |
Where do people abandon forms? |
| First interaction; failed validation |
| GA4 | No | Web team | Start a form and leave; submit with an empty field |
Which pages lead to service pages? |
| Link to a service page clicked |
| GA4 | No | Web team | Click links in the menu, footer and articles |
Which content attracts future leads? |
| Guide downloaded |
| GA4 | No | Content | Download each file |
Rolling it out
Agree on the plan with marketing, sales and the developers, and give every row an owner.
Have developers add the events to the website's data layer.
Map the events in your tag manager to GA4 and the ad platforms.
Test every row in the tag manager's preview mode and GA4 DebugView, which shows events as they arrive, with consent accepted and declined.
Mark the key events in GA4.
Write it down where people will find it, and review it every quarter and before every redesign.
Steps two to four are where a plan becomes the data layer and tags behind your reports. If no one in your team owns that work, this is where tracking can quietly fall apart.