By Mehdi HassanMost analytics problems on marketing sites aren't tool problems. They're planning problems: events added ad hoc, named three different ways, and owned by nobody. A tracking plan fixes that with one shared document. This template is designed to sit alongside our GA4 setup guide for marketing websites, and it's deliberately small.
What should a website tracking plan include?
A website tracking plan should include, for each event, its name, the user action that triggers it, its parameters, the question it answers, whether it's a key event, where it's implemented and who owns it. Add a status column so you can see what's live, broken or planned.
Column | What goes in it | Example |
|---|---|---|
Event name | object_action, lowercase snake_case | demo_request_submit |
Trigger | The exact user action | Demo form submits successfully |
Parameters | Extra detail sent with the event | form_location, plan_interest |
Question it answers | The decision this data supports | Which pages drive demo requests? |
Key event | Yes if it's a conversion in GA4 | Yes |
Implementation | GTM tag, site code or platform | dataLayer push from the form handler |
Owner | One named person or role | Growth lead |
Status | Planned, live, broken, retired | Live |
Last tested | Date of the last QA check | After the last release |
Keep the plan in a shared spreadsheet with one tab for events, one for parameters and one for a change log. That's enough structure to be useful and light enough that people actually update it.
How many events does a marketing website need?
In our builds, a marketing website needs 10 to 15 custom events on top of what GA4 collects automatically. That covers conversions, the steps just before conversions and a few engagement signals tied to real decisions. Plans with hundreds of events tend to produce reports nobody opens.
GA4's enhanced measurement already records page views, scrolls, outbound clicks, site search, file downloads and video engagement on YouTube embeds. Don't duplicate those with custom events unless you need a parameter they don't send. The value you add is in the business events GA4 can't infer: which form, which plan, which CTA.
What does a lean tracking plan template look like?
A lean tracking plan for a SaaS or B2B marketing site has three groups: conversions, intent signals and engagement. Here's the set we start from, then trim or extend per project.
Event | Group | Key event | Main parameters |
|---|---|---|---|
demo_request_submit | Conversion | Yes | form_location, company_size |
signup_start | Conversion | Yes | plan, cta_location |
contact_form_submit | Conversion | Yes | form_location, topic |
meeting_booked | Conversion | Yes | booking_tool, source_page |
newsletter_signup | Conversion | Optional | form_location |
pricing_plan_select | Intent | No | plan, billing_period |
cta_click | Intent | No | cta_text, cta_location |
form_start | Intent | No | form_name |
case_study_view | Engagement | No | industry |
video_play | Engagement | No | video_title |
That's ten events. Add a few for your own model, such as integration_page_view for a product with many integrations or calculator_complete for a pricing calculator, and stop there. Pricing, booking and form events are the ones our conversion tracking guide for lead-gen websites explains in detail.
What naming convention should events use?
Events should use object_action names in lowercase snake_case, such as demo_request_submit, so they sort together and read the same in every tool. GA4 is case-sensitive, so Demo_Request and demo_request become two different events with split data.
- Object first, action second: form_start and form_submit sit next to each other in reports.
- Lowercase only: never mix cases, in event names or in parameter values you'll filter on.
- Name the action, not the button: cta_click with a cta_text parameter beats one event per button.
- No personal data: never send emails, names or phone numbers as parameters.
- Reuse GA4's recommended names where they fit, such as sign_up and generate_lead, if your team prefers Google's vocabulary. Pick one style and stick to it.
Who should own the tracking plan?
One person should own the tracking plan as a whole, usually the growth or marketing lead, and each event should have a named owner who decides whether it stays. Developers implement events, but they shouldn't be the ones deciding what gets measured.
Ownership means three things: approving new events before they're built, checking the data after releases and retiring events nobody uses. Put a quarterly review in the calendar. If an event's owner can't name a decision it informed, archive it in the change log and remove the tag.
For example, suppose a team adds a pricing calculator
For example, suppose your team ships a pricing calculator on the pricing page. Before any code is written, the growth lead adds two rows to the plan: calculator_start and calculator_complete, with parameters for seats and plan. The question it answers is whether people who complete the calculator request demos more often than people who don't.
The developer pushes both events to the dataLayer, GTM sends them to GA4, and the owner tests them in DebugView before launch. Three months later, if nobody has looked at the comparison, calculator_start is cut and only calculator_complete stays.
How do you keep a tracking plan up to date?
You keep a tracking plan current by changing the plan before the code, testing every row after each release and logging every change with a date. The plan is only useful while it matches what the site actually sends.
Plan first
Any new form, CTA or page type gets its events added to the plan before development starts.
Implement through one layer
Send events through the dataLayer and GTM, as covered in our Google Tag Manager setup guide, so there's one place to look.
Test in DebugView
Before release, trigger each new event and check its name and parameters in GA4 DebugView.
Re-test after releases
After each deploy, run through the key events and update the last-tested column.
Review quarterly
Retire events without a decision attached and record the change in the log.
Migrations are where plans most often break, because templates and form handlers get rebuilt. Keep this sheet as the checklist in your analytics continuity plan, and if events go missing, use our GA4 conversions troubleshooting guide.
