An event tracking plan is a shared document listing every action you measure, what each event is called, what details it carries, when it fires and who owns it. A data layer is a structured object on your site or app that passes those clean details to analytics and tag tools. Together they keep analytics consistent, trustworthy and easy to change.
Key takeaways
- A tracking plan is the contract between marketing, product and engineering. Without one, analytics decays into inconsistent names and gaps.
- A data layer separates what happened from how it is reported, so tags do not depend on fragile page markup.
- Use consistent naming: lowercase, one verb and one object pattern, and no personal data in event names.
- Track the few events that map to business decisions, not everything that can be tracked.
- Respect consent and collect only the personal data you need. Requirements vary by country and sector.
- Test before release, version your changes and give every event an owner.
What is an event tracking plan?
A tracking plan is a living reference, usually a spreadsheet or document, that answers the same questions about every event:
- What is it called?
- What does it mean in business terms?
- What triggers it?
- What properties does it carry?
- Which tools receive it?
- Who owns it and when was it last changed?
It is written before the code and updated whenever the product changes.
Why do tracking plans prevent messy analytics?
Without a plan, each person adds tracking in their own style. One developer sends "signup", another "sign_up", a marketer adds "Registration Complete" in a tag tool. Reports then split one behaviour into three, filters miss data, and nobody trusts the numbers.
A plan prevents this by:
- Creating one name for one thing. Everyone looks up the event instead of inventing it.
- Making gaps visible. You see what is not yet measured before a decision depends on it.
- Speeding up onboarding. A new analyst or developer can read the plan instead of reverse-engineering tags.
- Supporting audits. You can show what data is collected and why, which helps with privacy reviews. Our guide to data governance basics covers the wider picture.
What is a data layer in plain words?
A data layer is a structured piece of data that your website or app publishes with the facts of what is happening: which page type is open, which product was viewed, what the basket contains, what stage the user has reached. Analytics and tag tools read from it instead of scraping the page for text or button labels.
The benefit is stability. If a designer renames a button or restructures a page, tags that read from the page may break silently. Tags that read from the data layer keep working, because engineering maintains that data as part of the product.
On mobile apps the same idea applies: the app sends structured events to the analytics software development kit.
What naming conventions should you use?
Pick a convention once and write it at the top of the plan.
- Lowercase with underscores or another single style, applied everywhere.
- Object then action, or action then object, but not both. For example, always "product_viewed" and "cart_updated", or always "view_product" and "update_cart".
- Past tense for things that have happened, if you choose that style, applied consistently.
- Specific but not too specific. "form_submitted" with a property for the form name is better than a separate event for every form.
- No personal data in names or values that are not needed. Never put an email address, phone number or name into an event name, page address or property by accident.
How do event properties and user properties differ?
Event properties describe the thing that happened: the product category, the form name, the plan viewed, the page type. User properties describe the person or account across events: customer type, sign-up source, plan tier. Keep both lists short and defined. Each property should have a name, a description, an allowed set of values or format, and an example. Free-text values invite inconsistency, so use fixed lists wherever possible.
Which key events matter for each business model?
Choose events that connect to decisions. Starting points by model:
- Lead generation: form started, form submitted, phone number tapped, booking requested, brochure downloaded.
- E-commerce: product viewed, added to basket, checkout started, shipping chosen, payment attempted, order completed, return requested.
- SaaS: sign-up completed, onboarding step completed, key feature used for the first time, invitation sent, upgrade started, cancellation requested.
- Content and media: article read to the end, newsletter sign-up, search used, video played, share clicked.
For more on what to measure and why, see website analytics setup: what to track and why and, for apps, mobile app analytics: what to track and how to act.
How do consent and privacy affect tracking?
Tracking should follow your privacy commitments and local rules. In practice:
- Fire analytics and advertising tags only after the required consent has been given, where consent is required in your market.
- Collect the minimum personal data needed. If an analysis does not need an identifier, do not send one.
- Keep sensitive details, such as health or financial information, out of analytics tools altogether.
- Link the plan to your cookie and privacy notices so they stay accurate.
Rules differ by country and sector and change over time, so ask a qualified adviser to confirm what applies. Our article on cookie consent and privacy policy for business websites gives a practical overview.
What does a tag management tool add?
A tag management tool is a control panel that loads and configures tags, such as analytics and advertising scripts, without a new code release each time. Used well, it listens to events pushed into the data layer and decides which tools receive them, subject to consent rules. Used badly, it becomes a place where untracked, undocumented tags pile up. The plan should list every tag and the event that triggers it, so the tool reflects the plan and not the other way around.
How do you QA and debug tracking?
Test before release, not after the numbers look odd.
- Use preview and debug modes offered by your tag and analytics tools to watch events fire in real time.
- Test in a staging environment with test data kept out of production reports, or filter internal traffic.
- Walk each key journey on desktop and mobile, checking that each event fires once, at the right moment, with the right properties.
- Test consent states, confirming that nothing fires before consent where required.
- Check edge cases, such as double clicks, back buttons, failed payments and slow connections.
- Schedule recurring checks, since site changes silently break tracking.
How should you handle versioning and ownership?
Treat the plan like code. Keep a change log with the date, the change, the reason and who approved it. When an event's meaning changes, create a new event or note the date, so trends are not misread. Assign roles clearly:
- Marketing owns the questions and the reports.
- Product owns the behavioural events and their definitions.
- Engineering owns the implementation and the data layer.
- One named person owns the plan itself and approves changes.
A plan template as an outline
A simple template for each event:
- Event name
- Business question it answers
- Trigger (what exactly causes it to fire)
- Platforms (web, iOS, Android)
- Properties, each with a name, description, type and allowed values
- Consent category
- Destinations (analytics, advertising, other)
- Owner
- Status (planned, in test, live, retired)
- Date of last change and notes
A short worked example
Imagine a small online training company with a website and a booking form. The team lists four business questions: which pages bring enquiries, where visitors drop out of the form, which courses attract interest and whether enquiries become bookings. They define five events: course_viewed, enquiry_form_started, enquiry_form_submitted, call_back_requested and booking_confirmed, each with properties for course name and page type. The developers push these into the data layer, the tag tool forwards them only after consent, and a quick staging test shows that the submitted event was firing twice on slow connections. Because the plan existed, the bug was caught before launch.
What mistakes should you avoid?
- Tracking everything, then drowning in unused events.
- Inconsistent names across teams and platforms.
- Putting personal data into event names, page addresses or free-text properties.
FAQ
What is an event tracking plan?
It is a shared document that lists each event you measure, its name, what triggers it, the properties it carries, where it is sent and who owns it. It gives marketing, product and engineering one reference so data stays consistent and trustworthy.
What is a data layer in analytics?
A data layer is a structured object on your website or app that holds clean information about what is happening, such as page type, product and basket contents. Analytics and tag tools read from it instead of scraping the page, which makes tracking more stable and consistent across tools.
How many events should I track?
Track only what supports a decision, which for most small businesses is a short list of key journey events rather than every click. You can add more when a real question needs it. A smaller set that is well defined and tested beats a large set nobody trusts.
Do I need consent before tracking events?
In many countries you need consent before using certain analytics or advertising tracking, but rules vary by country and sector and change over time. Design your tags to respect consent states, collect only necessary personal data and ask a qualified adviser what applies to you.
Related reading
- Website Analytics Setup: What to Track and Why It Matters
- Mobile App Analytics: What to Track and How to Act
- Data Governance Basics for Small and Growing Businesses
Next steps
Write down the five business questions you most want your analytics to answer, then list the events needed to answer them and fill in a plan entry for each one. Share it with the person who builds your site or app and agree the naming rules before anything is coded. If you would like help drafting a plan, setting up a data layer or auditing existing tags, contact us and we will help you get it into shape.
