The useful half of a tracking plan is the list of things you decided not to measure, with the date and the reason. Without it, the document only grows, because adding an event always feels cheaper than defending its absence.
The costs of collection are real and they arrive later: cardinality you cannot undo, a hard cap on parameters, reports that will not display, and a larger surface for arguments about numbers nobody uses.
This page sets out the documented constraints that bound any plan, and a test for whether an event belongs in it.
Cardinality is permanent
Of all the mistakes available, this is the one you cannot fix afterwards.
The mechanism. The number of values assigned to a dimension is its cardinality. Any dimension with more than 500 values is considered high cardinality by the vendor, which describes 500 as guidance rather than a limit.
What happens past the table row limit. Values are condensed into an (other) row. The product surfaces the most common values and hides the rest inside it.
Why it is permanent. Cardinality is created at the moment of collection. You can stop sending the offending values today, but the historical data keeps them, and reports spanning that period keep the (other) row.
What creates it in practice. Query strings in page paths. Session identifiers. Order numbers. Product codes. Campaign names containing dates or unique strings. Anything that is different for every user or every visit.
The specific B2B version. Tracking a form submission with a parameter carrying the submitted email address or company name. It feels informative. It permanently degrades every report using that dimension, and the useful analysis is a count anyway.
The rule that prevents all of it. A dimension is for grouping. If a value will be nearly unique, it belongs in your CRM, not in your analytics dimension.
The constraints you are designing against
Four documented limits, worth knowing before the plan is written rather than after.
Parameters per event: 25. A hard cap, which forces a decision about what each event carries rather than attaching everything to hand.
Thresholding on demographic reports. System defined, not adjustable, with no published numeric threshold. Any report including demographic dimensions may simply not display its rows, and B2B audiences are small enough to hit this regularly.
Retention for explorations: 14 months maximum on a standard property. Standard aggregated reports are unaffected, but any exploration is capped there, and many B2B sales cycles are longer than that.
Attribution windows that differ by platform. One search platform defaults to a 30-day click window. One professional network defaults to 90-day click and 90-day view. The same conversion will be attributed differently by each, before any question of tracking quality arises.
And modelled conversions inside the same column. Advertising platforms report modelled and observed conversions together, with no separate label. Your tracking cannot fix that because it is not a tracking problem.
What all of this means for the plan. Some things you want to measure are not measurable at your tier, at your audience size, or across systems. Writing that down is more useful than attempting them and quietly failing.
Two of these cannot be worked around at all. Knowing which is the difference between a plan and a wish list. Source : Analytics and platform documentation (2026)
The test for whether an event belongs
One question, two parts, and it disposes of most proposals in under a minute.
Name the person who will look at it. Not a role. A person, who exists, whose job includes opening that report.
Name the decision that changes. Specifically: what would they do differently if the number were high, and what if it were low.
If either answer is missing, refuse the event. Write it on the refusal list with today’s date and the reason, so the same proposal does not return in six months as a new idea.
What this eliminates immediately. Scroll depth on pages nobody will redesign. Video plays on videos nobody will re-edit. Outbound link clicks nobody investigates. Every micro-interaction added because it was available.
What it keeps in a B2B account. Form submissions, split by form. Meeting bookings. Document downloads, if someone follows up on them. Pricing page views, if the sales team uses them in call preparation. Usually fewer than ten events.
Why fewer than ten is a feature. Every event you keep gets reviewed, understood and trusted. Every event you add dilutes attention across a larger surface, and the ones nobody looks at are exactly the ones that break silently.
The uncomfortable consequence. Most tracking plans should shrink. If yours has forty events and your business closes fifteen deals a quarter, the plan is measuring the website rather than the business.
Tracking breaks silently, and always has
The argument for a small plan is not tidiness. It is that broken tracking does not announce itself.
What a broken event looks like. Nothing. No error, no alert, no red row. The number simply stops rising, or starts rising from a different denominator, and the report continues to render.
When it happens. A website release changes a button class. A form vendor updates its embed. A consent banner changes category names. A developer renames a template. None of these are analytics changes, and none of them will be communicated to you.
Why plan size makes this worse. With eight events, somebody notices when one goes flat, because somebody looks at all eight. With forty, nobody looks at all forty, and the broken ones are by definition the ones nobody was watching.
The compounding version. A key event breaks, so conversions fall. The advertising platform optimising toward that event now receives fewer signals, and delivery degrades for a real reason caused by a fake one.
The cheap detection you can build today. A weekly check on the count of each key event against the previous four weeks. Not a dashboard, a list. Anything at zero, or down more than half, gets looked at.
And the cheapest of all. Submit your own form once a week and confirm the event fired. It takes two minutes and it catches the failure that costs the most.
No error, no alert. The report renders perfectly with a number that stopped meaning anything. Source : Method (2026)
What to refuse, specifically
A starting refusal list, which you should adapt rather than copy.
Anything with a unique value going into a dimension. Emails, company names, order references, session identifiers. Permanent cardinality damage in exchange for information your CRM already holds.
Demographic segmentation on a small audience. It will be thresholded, the rows will not display, and you will spend an afternoon deciding whether the tracking broke. It did not.
Micro-engagement on pages you will not change. If there is no redesign budget, scroll depth on that page is a number you will look at and do nothing about.
Anything measured only to prove a channel’s value internally. That is a political requirement, not a measurement one, and it produces metrics designed to win arguments rather than inform decisions.
Cross-system reconciliation to the unit. Your platforms use different attribution windows by default and include modelled conversions in the same column as observed ones. Reconciling them exactly is not achievable; agreeing on which system is the system of record is.
Anything whose owner has left. Every tracking plan contains events set up by someone who is gone, still firing, still in reports, trusted by nobody. Delete them or claim them.
Six sections, and the last one is the one nobody writes.
The system of record, named. One system whose number is the number when systems disagree. In B2B this is almost always the CRM, because that is where a deal either exists or does not.
The events, with owners. Each event, the person who reads it, and the decision it informs. If the owner changes, the event is reviewed.
The dimensions, with their expected cardinality. For each, roughly how many distinct values you expect. Anything approaching 500 gets challenged before it ships, not after.
The attribution settings you chose. Which window on each platform, and whether you aligned them. If you did not align them, say so, so nobody spends a day discovering it.
The known limits. What cannot be measured at your tier: explorations beyond fourteen months, demographic breakdowns that will threshold, cross-system reconciliation to the unit.
The refusal list. Every event proposed and declined, with the date and the reason. This is the section that keeps the plan finite, and it is the only part that saves time in year two.
The refusal list is the only section that gets more valuable with age. Source : Method (2026)
The refusal list is the useful half of a tracking plan, because adding an event always feels cheaper than defending its absence.
Cardinality is permanent. It is created at collection, dimensions above 500 values are high cardinality, and the excess is condensed into an (other) row for good.
Never put a unique value in a dimension. Emails, order references, session identifiers. Your CRM already holds them.
Events cap at 25 parameters, which forces a choice about what each one carries.
Thresholding has no published number and cannot be adjusted, so demographic reports on small B2B audiences may simply not display.
Explorations cap at 14 months on a standard property, which is shorter than many B2B sales cycles.
Attribution windows differ by default, 30 days on one search platform against 90 on one professional network, so systems will disagree regardless of tracking quality.
The test is two questions: who looks at it, and what decision changes. Most proposals fail the second.
Write the refusal list first, and name your system of record. Book a diagnostic, or see how we approach B2B websites.
Frequently asked questions
What should a tracking plan contain?
The events you will act on, the person who acts on each, and an explicit list of what you decided not to track and why. The refusals are the part that stops the document growing forever.
Why not just track everything?
Because collection has costs that fall due later: cardinality that cannot be undone, a twenty-five parameter cap per event, review time, and a larger surface for disputes about numbers nobody uses.
What is the single most damaging tracking mistake?
Putting a unique identifier into a dimension. Cardinality is created at collection, so once a dimension exceeds the row limit the excess is condensed into an (other) row and every report using it is permanently degraded.
How many parameters can an event carry?
Twenty-five. That cap forces a decision about what matters on each event rather than attaching everything available.
Should I track demographics?
Only if you will act on them. Reports containing demographic dimensions are subject to thresholding, which is system defined, cannot be adjusted and publishes no numeric threshold, so small B2B audiences may simply not display.
Can I measure my full sales cycle in explorations?
Not on a standard property if your cycle exceeds fourteen months, because that is the maximum retention for explorations and funnel reports. Standard aggregated reports are unaffected.
Why will my numbers never match across systems?
Because platform attribution windows differ by default, and because advertising platforms include modelled conversions in the same column as observed ones. Neither is a tracking fault.
How do I know an event is worth tracking?
Name the person who will look at it and the decision that changes because of it. If you cannot do both, write it on the refusal list with today's date.