Your Tracking Plan Was Written for Product Analytics. Marketing Needs a Different One.
Every tracking plan template you can download specifies event names and properties, because they were all written for product teams instrumenting a feature. A team buying media and attributing revenue has to specify four more things, and none of them appear on those templates.
Your Tracking Plan Was Written for Product Analytics. Marketing Needs a Different One.
Search for a tracking plan template and you will find a dozen good ones. Every one of them is a table of event names, event properties, types, and an owner - the artefact a product team writes before an engineer instruments a feature. That document is genuinely useful and it is not sufficient for marketing, because it answers "what will we record" and marketing's hard questions are all about what the recorded values mean once revenue and media spend are attached to them.
Key takeaways
- Product tracking plans specify events and properties; a marketing measurement plan has to additionally specify meaning - which values link records, which are measured, and in what unit.
- The field most likely to be forgotten is the one that exists only to join records to a person, because nothing on a dashboard ever displays it.
- Every metric needs its time semantics declared up front - as-of-now or within-a-window - or two reports will legitimately disagree later.
- Revenue needs a named layer and a currency, not just a field; "revenue" without those is four different numbers.
- Normalisation rules belong in the plan, not in the implementation, because the rule decides whether two records about one person ever match.
Teams that adopt a product-analytics template unchanged ship a plan that passes review and still leaves every cross-channel reporting question unanswered six months later.
Measurement plan: the document that defines, before anything is instrumented, what each field means, which concept it maps to, and how it will be compared or aggregated.
Canonical field: the standard concept an incoming field is mapped onto - the revenue, the event time, the customer identifier - as distinct from whatever the sending system happens to call it.
What a product plan omits: fields that exist only to be compared
The operational pain this creates for marketing teams reusing a product template: the template has a column for what the property is called and what type it holds, and no column for what the value is for. That distinction turns out to be load-bearing. Some fields exist to be shown or summed - a deal value, a session count. Others exist only to be compared against other records, and are never displayed or aggregated at all: an email address or a phone number used to recognise a returning person.
Those comparison-only fields are the ones that get dropped, and they get dropped for a structural reason rather than carelessness. If you audit which fields anything on a dashboard actually reads, a joining field has no reader by definition - the thing that would read it is the matching logic, which cannot be built until the field is already being retained. So a plan that justifies each field by "which report uses it" will systematically discard exactly the fields the reports depend on. A marketing measurement plan has to list them in their own section, with a stated reason, and accept that each one carries a privacy cost since the value is then retained for every contact. Which keys you choose determines how much of your contact base can be matched at all.
Run marketing on one source of truth
Every source in one brief, so the team stops reconciling exports.
14-day trial after the call · no card required
What a product plan omits: time semantics and the revenue layer
The ICP problem this creates for anyone who will later be asked to reconcile two reports: product plans record events, and an event has one timestamp, so time semantics feel like a solved problem. They are not solved at the metric level. A metric built from those events is either a count of things that happened inside a date range or a state as of the moment you ask, and the plan has to say which - because the same name applied to both produces disagreements that look like data problems and are not.
Revenue needs the same treatment and rarely gets it. "Revenue" is not a field, it is a choice between layers: what a payment system charged, what a CRM marked closed-won on a date a human picked, what a purchase event fired in a browser, or what an ad platform claims it caused. The last of those is the weakest, because each platform credits itself as much as its attribution window allows and the windows overlap. The plan should name one layer as the reporting truth, name the currency and the unit - minor units and major units are a classic silent factor-of-one-hundred error - and state that the layers are reported separately rather than summed.
What a product plan omits: normalisation rules
The ICP problem this creates for teams who get the field list right and still cannot match anything: a plan that names a phone number as a matching key has not finished the job, because the same number written two ways is two keys. Whether the international prefix is kept, whether spaces and brackets are stripped, what happens to a local-format number with no country code - those decisions determine whether matching works, and if they are left to whoever implements the field, each system will decide differently.
The rule worth writing into the plan explicitly: an ambiguous value stays unmatched. A number with no country code should produce no key rather than a guessed one, because a confident false match corrupts reporting in a way a gap does not. This is the same exploratory discipline applied one stage earlier - checking that a value is even possible before interpreting it. A 2025 Gartner survey found 73% of enterprise data leaders rank data quality as the top barrier to AI success, ahead of model accuracy and compute cost, and normalisation rules written down before instrumentation are the cheapest point at which that barrier can be removed. The same reasoning governs what to do when there is no connector and you are mapping an inbound payload yourself.
Prooflytics makes most of this explicit rather than optional. Incoming fields are mapped onto standard concepts you choose per source, so the question "which of your fields is the revenue, the event time, the identifier" is answered in configuration instead of in a document that drifts. Every metric declares whether it is a snapshot, a period figure, or a trend, and carries a one-line definition shown where you select it. Revenue source is one explicit setting per organisation with four named options, and the layers stay separate under their own labels rather than being combined. Matching keys are a short declared list with a stated reason for each, which is the section a product-analytics template has no place for.
Bottom line
- Product tracking plans specify what gets recorded; marketing plans also have to specify what the recorded values mean.
- Give comparison-only fields their own section - a plan that justifies fields by "which report reads this" will always discard them.
- Declare each metric as as-of-now or within-a-window before anything is built, not during the first disagreement.
- Name the revenue layer, the currency, and the unit; state that layers are reported separately rather than summed.
- Book a walkthrough to see how Prooflytics turns field meaning, metric semantics, and revenue source into explicit settings.
Frequently asked questions
Can I just extend a product tracking plan with a few extra columns?+
You can, and it is a reasonable starting point - but the additions are sections, not columns. Matching keys with their normalisation rules, metric time semantics, and the revenue layer each need their own block, because they describe relationships between fields rather than attributes of a single field.
Who should write the marketing measurement plan?+
Whoever will be held to the numbers, drafted with whoever will implement them. A plan written only by engineering specifies what is easy to emit; a plan written only by marketing specifies things no system can supply. The useful version is negotiated.
How detailed should it be before instrumentation starts?+
Detailed enough that two people reading it would build the same thing. The specific test: can someone tell from the plan alone whether a given metric is as-of-now or within-a-window, and which field carries revenue in which currency? If not, it is not ready.
What if we already instrumented everything without a plan?+
Write the plan against what exists rather than against what you wish existed, then list the gaps separately. Documenting the current meaning of each field is valuable on its own, and it turns "our data is a mess" into a finite list of decisions.
You can read independent reviews of Prooflytics on G2 and compare it to other marketing intelligence platforms in the category.
Run marketing on one source of truth
Every source in one brief, so the team stops reconciling exports.
14-day trial after the call · no card required
Continue reading
Marketing Analytics Guide: From Scattered Data to a Unified View
Marketing analytics means joining data from all your channels - paid, email, CRM, and revenue - into a single view. This guide covers what it includes, where most stacks break down, and how to build one that gives reliable answers.
Two Teams, One Metric Name, Two Numbers: Where the Gap Actually Comes From
When two people report different figures for the same named metric, the instinct is to look for a broken integration. Usually nothing is broken. There are three specific definitional gaps that produce this, and each one needs a different fix.
End-to-End Marketing Analytics: Connecting Ad Spend to Revenue
End-to-end marketing analytics closes the loop between your paid channels and actual revenue events in your CRM or payment processor. This guide explains the full-funnel stack, why most B2B SaaS teams are still stuck at the reporting layer, and how to move to the intelligence layer where decisions happen.
What Is Marketing Attribution? Models, Limitations, and How to Choose the Right One
Marketing attribution assigns credit for conversions to the touchpoints that contributed to them - but every model makes different assumptions. Here is the full breakdown of six models, when to use each, and why the sum of platform ROAS always exceeds actual revenue.