The Marketing Data Dictionary: Define Metrics Once So Meetings Stop Relitigating Them

The recurring meeting scene where marketing's lead count differs from sales' lead count is almost never a data quality problem, it is a definition problem. One dashboard counts form submissions, another counts CRM records created, a third counts records that passed qualification, and all three present their number under the label leads. Each is internally correct, mutually contradictory, and the meeting burns twenty minutes relitigating a question that should have been settled once in writing.

The tell that you need a dictionary is exactly this repetition: the same definitional dispute resurfacing across meetings with slightly different combatants. Every hour spent arguing about what counts as an MQL, whether pipeline means created or open, or which conversion rate is the conversion rate, is an hour the dictionary would have refunded.

A dictionary entry that actually settles arguments has more than a name and a sentence. It states the formula in operational terms, the exact system and field the inputs come from, the filters applied, such as excluding internal domains or test records, the time basis, meaning whether events are counted by created date or closed date, and known limitations someone will otherwise rediscover in a meeting. It also names an owner, the single person with authority to change the definition, because a definition nobody owns is a definition everyone quietly forks.

Write entries at the altitude of the disputes. The metrics worth defining first are not the exotic ones but the load-bearing common words: lead, MQL, SQL, opportunity, pipeline created, win rate, CAC, and the conversion rates between stages. In most organizations fewer than two dozen entries cover the surface area of ninety percent of the arguments, which is why this is an achievable document and not a boil-the-ocean project.

A dictionary in a forgotten folder changes nothing; adoption comes from placing definitions at the point of consumption. Link the entry from the dashboard tile, the report header, and the spreadsheet column, so the person about to dispute a number is one click from its formula, filters, and known caveats. Teams running a warehouse and BI layer can go further by encoding definitions directly into a shared metrics or semantic layer so every downstream tool computes the same figure from the same logic, but the linked document alone captures most of the value at a fraction of the effort.

Adoption also needs one social rule with teeth: dashboards and decks that display a defined metric must use the defined version or visibly label the variant. The moment leadership starts asking is this the dictionary definition in reviews, the dictionary stops being documentation and becomes the terrain.

Definitions legitimately evolve, and the dictionary must make evolution safe rather than pretending it will not happen. When a definition changes, version it: record the old and new definitions, the change date, the reason, and whether historical values were restated or left as-is, because a silent mid-year definition change manufactures a fake trend break that someone will later analyze as a real one. The owner communicates the change to everyone consuming affected reports before dashboards flip, not after.

Review the dictionary on a light cadence, quarterly is plenty, to catch definitions that drifted from practice and disputes that reveal a missing entry. The maintenance burden is genuinely small, a few hours a quarter, which buys back the meeting hours currently spent relitigating settled questions and, more valuably, restores the default assumption that when two numbers differ, one of them is wrong rather than both being right in different languages.