How to design a conversion tracking plan before a website or campaign launches

Why the plan has to exist before launch

Most website projects treat tracking as a line item near the end: “install GA4 and pixels.” The developer pastes in a tag the week of launch, someone marks the contact form as a key event, and the site goes live. Three months later the lead count does not match the CRM, the booking engine is taking credit for every sale and nobody can say which campaign worked.

None of that is a software failure. It is a planning failure. The decisions that determine whether tracking works (how forms confirm success, whether the booking step happens on your domain, what the consent banner controls, who owns the accounts) are made during design and development. If nobody writes measurement requirements at that stage, those decisions get made by default, and defaults rarely favour measurement.

A conversion tracking plan sits between two other documents. Above it is the marketing measurement plan, which decides what the business needs to know and which KPIs matter. Below it is the configuration itself, covered in our GA4 setup and audit checklist. The tracking plan translates the first into instructions for the second, for one specific launch. If you have no measurement plan yet, write a short one first. If you do, this is the document your developer or agency builds from.

Start with an inventory of business events

Begin with a plain list of every way a visitor can become a customer, or take a meaningful step toward it, on the new site. Not every click: every action the business would care about if it doubled or disappeared.

Walk the sitemap and the wireframes with marketing and sales in the room, and ask at each page what a visitor can do there. A typical inventory for a service business includes:

• Each distinct form: quote request, contact, careers application, event registration, newsletter signup.
• Phone number and email address clicks, on mobile and desktop.
• Bookings or purchases, including any step that leaves your domain for a third-party engine or payment page.
• Chat conversations started, if a chat tool is planned.
• Downloads of anything gated or valuable, such as a capabilities statement or a rate sheet.
• Clicks to directions or to a location page, for businesses with physical sites.

Then classify each one. Which are primary conversions that represent real business, which are secondary signals of intent, and which are diagnostic only? If you need a framework for that call, our piece on what should count as a marketing conversion lays out the tiers. The classification matters for launch because primary conversions get the strictest specifications, the most testing and the right to be sent to ad platforms.

The inventory also exposes gaps early. If the new booking flow sends people to a vendor’s domain and never brings them back, you will find out in discovery, when the fix is a conversation with the vendor, rather than in the first monthly report.

Write a specification for each event

For every event in the inventory, write a short entry that a developer can build from and a tester can check against. It does not need special software. A shared document or spreadsheet is fine. Each entry should answer:

• Name. One name, used everywhere: GA4, Tag Manager, the ad platforms and the CRM field that records it. Where Google’s recommended event names fit (generate_lead is the common one for forms), use them.
• Trigger. Exactly when it fires. “On successful submission, confirmed by the form platform’s success response or the thank-you page, once per submission.” Not “on click of the submit button”, which counts failed validation and impatient double clicks.
• Parameters. The context it carries: form name, service requested, location, language, booking type. Decide now which of these must appear in reports, because some need to be registered before they show up.
• Destinations. Which platforms receive it: GA4 only, or also Google Ads, Meta and LinkedIn. And whether the CRM record should store the source data that came with it.
• Priority. Primary, secondary or diagnostic.
• Consent category. Which consent choice governs each destination (analytics, advertising, or neither).
• Personal information. A flat rule that names, emails and phone numbers are never sent to GA4 in event parameters or URLs, with a note on any platform that will receive hashed data through an approved integration.

An illustrative entry. Say a regional engineering firm is launching a new site with a project inquiry form in English and French. The specification might read: event generate_lead, fires once on the form tool’s success callback, carries form_name, service_line, office and language, goes to GA4 as a key event and to Google Ads and LinkedIn as the primary conversion, requires analytics consent for GA4 and advertising consent for the ad platforms, and writes source, medium, campaign and click ID into hidden fields so the CRM record carries them. Six lines, and every argument about that form for the next two years has an answer.

For bilingual sites, decide early that both language versions fire the same event with a language parameter. Separate events for French and English pages double the testing and halve the clarity of every report.

Assign ownership, by role

Tracking breaks at the boundaries between people. The developer assumes the agency is testing it. The agency assumes the developer will tell them about a form change. Nobody owns the GA4 property, because it was set up under a former employee’s personal login. The plan should name, by role so it survives turnover:

• Account owner. The organization owns GA4, Tag Manager, the ad accounts and the consent platform, under a company account, with suppliers added as users. This is decided before anything is created.
• Builder. Who implements each part: the web developer for form callbacks and the data layer, the agency or analyst for tags, the CRM administrator for hidden fields and source mapping.
• Approver. Who signs off that the specification matches the business’s definitions. Usually the marketing lead, with sales confirming anything that lands in the CRM.
• Tester. Who runs the acceptance tests, and who checks their work. Ideally not the person who built it.
• Maintainer. Who is responsible for tracking integrity after launch, and who must be told before any form, page template or plugin changes.

Third-party systems need their own line. If bookings, payments or applications happen in a vendor’s tool, record who at the vendor can confirm what tracking their system supports, and get that answer in writing during discovery. Atlantic Canadian tourism and recreation operators run into this more than most, because the booking engine is almost never part of the website build.

Set consent requirements before the build

Consent is a design requirement, not a plugin you add at the end. The plan should record:

• Which consent platform will be used and which tags it controls.
• For each tag, which consent category it belongs to, and what it is allowed to do before a choice is made.
• How Google consent mode will be configured, and whether the organization has chosen the basic approach (tags wait for consent) or the advanced one (limited cookieless signals before consent). That choice should be made with counsel, not by the developer on launch day.
• Whether the banner behaves differently for some audiences, for example visitors from Quebec, where provincial law sets stricter expectations for tracking technologies.
• Where the privacy policy describes what is collected, and who updates it when tags change.

What your obligations are is a legal question, and our article on privacy-conscious marketing measurement in Canada covers the principles to bring to that conversation. The tracking plan’s job is narrower: to turn whatever was decided into requirements that can be built and tested. It should also warn leadership, in writing, that properly configured consent reduces what analytics reports. Better that they read it in the plan than discover it in the first quarterly review.

Define the tests and the sign-off

A tracking plan without acceptance tests is a wish list. For each primary conversion, write the test that proves it works, and make passing it a condition of launch.

1. Complete the action on desktop and on a phone, in each language, with debugging tools open. Confirm the event fires once, on success, with the specified parameters.
2. Trigger a validation error and confirm nothing fires.
3. Repeat with consent declined, then accepted, and confirm each tag follows the choice.
4. Follow any handoff to a third-party domain and back, and confirm the session and source survive.
5. Check that a test submission reaches the CRM with its source fields filled.
6. Confirm that test traffic is excluded or labelled, so launch-week testing does not pollute the numbers.

Run the tests on the staging site, then again on the live site within hours of launch, because staging and production rarely behave identically. Our guide to testing whether website tracking is working sets out the full scenarios. Record what was tested, by whom and on what date. The next person to touch the site will need to know what “working” looked like.

The first month after launch

Launch is when tracking gets its first real workout. Build three things into the plan for the weeks that follow:

• A reconciliation check. After the first two weeks, compare key events in GA4 against form submissions in the form tool and the CRM. They will not match exactly, and our article on why GA4 and your CRM report different lead numbers explains why. What you are looking for is a gap you can explain.
• Redirect and migration checks. If the launch replaced an old site, campaign links and ad destinations pointing at old URLs should be updated, not left to redirects that strip campaign parameters.
• Change control. A rule that any change to forms, templates, the consent banner or the tag container is followed by a rerun of the relevant tests.

Our guide to the weeks after launching a new website covers the wider checklist this sits inside.

Red flags in a website or campaign proposal

If you are buying a website or a campaign, the proposal tells you whether tracking will be planned or improvised. Be wary of:

• “Analytics installation” as a single line, with no mention of events, testing or consent.
• No question, anywhere in discovery, about how leads reach your CRM.
• Accounts to be created “by us” with no statement that you will own them.
• Consent described as a banner rather than as tag behaviour.
• No acceptance criteria for tracking, which means no way to say it is not done.

In our own analytics and measurement work, the tracking plan is written during discovery and travels with the website scope, so measurement is designed alongside the forms and pages it depends on. It is a few pages long. It saves the conversation, months later, about why nobody can trust the numbers.