The worst kind of reporting meeting goes like this. The agency reports 63 leads for the month. The client's ops person opens the same CRM, runs what she believes is the same report, and gets 41. Twenty minutes disappear into screen sharing. Eventually someone notices that her filter drops contacts with no phone number and the agency's doesn't, and everyone agrees to align offline.
Nobody was wrong. There were two definitions of a lead in the room and one word for both.
I've sat through versions of that meeting more than once. It gets read as a data quality problem, so people go shopping for a better dashboard. The dashboard was fine. What was missing was a page saying what each number means and who decides when the meaning changes.
This article is that page: the structure I use for a KPI dictionary, then filled-in entries for the metrics agencies argue about most.
Why does a definition problem look like a data problem?
Because the symptoms are identical. Two numbers disagree, and disagreeing numbers feel like broken plumbing.
Sometimes they are. Systems genuinely count different things on different clocks, which I've diagnosed in why your GoHighLevel numbers don't match GA4. That piece is about gaps between systems. This one is about the gap inside a single system, where the same table gives two answers because two people applied two rules to it. The tell is easy: if both numbers came from the same source and still disagree, your problem is definitions.
Definitions also rot quietly. Someone adds a chatbot in March and nobody decides whether a chat transcript is a lead. That never shows up as an error. It shows up nine months later as a trend line that bends for no reason anyone can explain.
What does a KPI dictionary entry need?
Seven fields. Fewer than seven and the arguments come back.
Name. The exact label as it appears on the report. If the dashboard says "New Leads" and the dictionary says "Leads," someone will assume they're different metrics.
Plain-language definition. One sentence a client could read aloud without a follow-up question. If you can't write it, the metric isn't agreed yet.
System of record. The system whose value wins when systems disagree. That field alone settles more disputes than the other six together.
Formula. How it's calculated, naming exact fields. "Contacts created in the period where source is not internal" is a formula. "Leads from marketing" is not.
Inclusion and exclusion rules. The edge cases: duplicates, test records, internal submissions, spam. Most people skip this field. It's the one doing the work.
Owner. A named person who approves changes. One person, not a department.
Refresh cadence. How often the number updates and when it stops moving. A metric still changing after you've reported it needs a settle date.
How should you define a lead and a qualified lead?
Start here, because most downstream metrics inherit this definition. Everything below is an illustration, drafted the way I would for an agency running inbound forms and calls into a CRM. Your rules will differ.
Lead
- Plain-language definition
- A person who gave us their contact details through a tracked channel for the first time.
- System of record
- The CRM. Not the ad platform, not GA4.
- Formula
- Count of contacts created in the period where the source is a tracked marketing channel.
- Includes
- Form fills, inbound calls over 30 seconds, booked-call requests, chats where details were captured.
- Excludes
- Duplicates matched on email or phone within 90 days, internal and test submissions, bulk imports, spam.
- Owner
- Agency account lead.
- Refresh
- Daily, settles 3 days after month end so call records and spam review can land.
- Argument it settles
- Is a duplicate form fill a second lead? No. One person filling in two forms is one lead and two form submissions. If you want the second number, give it its own name.
That 90-day window is a judgment call, not a standard. Pick one and record why. Leave it undecided and the count depends on whichever report someone happened to run.
Qualified lead
- Plain-language definition
- A lead a human has reviewed and confirmed fits the criteria we agreed with the client.
- System of record
- The CRM.
- Formula
- Count of contacts set to Qualified during the period, counted on the qualification date.
- Includes
- Leads qualified in the period, whenever they were created.
- Excludes
- Leads awaiting review, and leads disqualified then requalified within 30 days (counted once).
- Owner
- Client sales lead, because the client owns the criteria.
- Refresh
- Daily, settles 5 working days after month end.
- Argument it settles
- A lead created in March and qualified in April counts in which month? April. Two dates sit on that record and the entry names which one wins.
Look at who owns that entry. Agencies take the blame for lead quality against a standard they never agreed to, and the owner field is where that stops.
Where does the pipeline get argued over?
At two points: when a lead becomes an opportunity, and what number sits on it.
Opportunity
- Plain-language definition
- A qualified lead with a real chance of buying, actively being worked by a salesperson.
- System of record
- The CRM pipeline.
- Formula
- Count of opportunity records created in the period.
- Includes
- Opportunities created manually and by automation, each flagged with its creation method.
- Excludes
- Renewals, which run in a separate pipeline, and duplicates raised from re-engaged old leads.
- Owner
- Client sales lead.
- Refresh
- Daily.
- Argument it settles
- Does every qualified lead become an opportunity automatically? Decide once. Auto-creation gives a clean funnel and an inflated pipeline. Manual creation gives a realistic pipeline and a conversion rate that measures how diligently reps click.
Pipeline value
- Plain-language definition
- The total value of open deals not yet won or lost.
- System of record
- The CRM pipeline.
- Formula
- Sum of opportunity value across open stages, as of the report run date.
- Includes
- Open opportunities with a value entered.
- Excludes
- Opportunities with no activity in 60 days, which move to a Stale stage and out of the headline number.
- Owner
- Client sales lead.
- Refresh
- Daily, and it never settles.
- Argument it settles
- Is pipeline value a forecast or a fact? A forecast. It's a number a human typed in before the deal closed and rarely corrected afterwards. Report it beside collected revenue, never instead of it.
It carries a second trap. Pipeline value is a snapshot, and most CRMs overwrite the previous state instead of keeping it, which I've written about in what GoHighLevel overwrites when a deal changes stage. Ask what the pipeline looked like sixty days ago and often the answer exists nowhere. Name where that history is stored, or accept that the metric only describes today.
Booked or collected: which revenue goes on the report?
Both, as two metrics with two names. Revenue is the one number a client can check against her own bank statement, so this is where reporting arguments turn into invoicing arguments.
Revenue (booked)
- Plain-language definition
- The value of deals marked won in the period, whether or not the money has arrived.
- System of record
- The CRM.
- Formula
- Sum of opportunity value for deals moved to Won in the period, counted on the date of the stage change.
- Includes
- Deals won in the period, at the value recorded when they were won.
- Excludes
- Renewals and upsells, reported separately, and deals won then reversed inside the same period.
- Owner
- Client sales lead.
- Refresh
- Daily, settles 5 working days after month end.
- Argument it settles
- Is a signed deal revenue? For this metric, yes. For the next one, no. Nobody has to guess which is on the slide.
Revenue (collected)
- Plain-language definition
- Money that actually arrived in the period, net of refunds.
- System of record
- The payment processor or the accounting system. Never the CRM.
- Formula
- Successful payments received in the period, minus refunds and chargebacks processed in the same period.
- Includes
- Deposits and instalments, counted when received rather than when the deal was signed.
- Excludes
- Failed payments awaiting retry, and payouts not yet cleared.
- Owner
- Client finance contact.
- Refresh
- Daily, settles at month-end close.
- Argument it settles
- Does a refund reduce last month's revenue? Not under this definition. It reduces collected revenue in the month it was processed, and the original month stands as reported. Restating prior months is defensible too. Deciding case by case is not, because then no report you've sent matches the current version of itself.
Report the gap between the two as its own line. When it widens, something real is happening to deal values or collections.
How should cost per lead, ROAS, and show rate be defined?
Calculated metrics carry every ambiguity of their inputs plus a few of their own.
Cost per lead
- Plain-language definition
- What we paid in media for each new lead.
- System of record
- Ad platforms for spend, the CRM for the lead count. The metric lives in neither, which is why it needs a written definition.
- Formula
- Total media spend in the period, divided by the Lead count defined above.
- Includes
- Media spend across every paid channel for that client.
- Excludes
- Agency fees, creative production, tooling. A client who wants the fully loaded figure gets a second metric with its own name.
- Owner
- Agency account lead.
- Refresh
- Daily, settles with the lead count.
- Argument it settles
- Does our fee count? Not in this number, and the entry says so before anyone asks. It handles a second argument too: spend reports by click date and leads by creation date, so a click on the 30th converting on the 2nd splits the pair across two months.
ROAS
- Plain-language definition
- Revenue earned for every currency unit of media spend.
- System of record
- Payment processor for revenue, ad platforms for spend.
- Formula
- Collected revenue attributed to paid channels, divided by media spend, both in the same period.
- Includes
- Revenue from customers whose first touch was a tracked paid channel.
- Excludes
- Platform-reported conversion value, which uses each platform's own model and window.
- Owner
- Agency account lead.
- Refresh
- Weekly.
- Argument it settles
- Whose revenue goes in the numerator? The one that matches the bank. Use platform-reported values instead, say so in the entry, and expect your total to exceed collected revenue, because two platforms will claim the same sale. The attribution rule underneath belongs in a data model rather than a definition.
Show rate
- Plain-language definition
- The share of booked appointments where the prospect turned up.
- System of record
- The calendar or CRM appointment object.
- Formula
- Appointments marked Showed, divided by all appointments scheduled to occur in the period.
- Includes
- Appointments scheduled to occur in the period, whenever they were booked.
- Excludes
- Appointments cancelled more than 24 hours ahead, removed from the denominator.
- Owner
- Client sales lead, because their team marks the outcome.
- Refresh
- Daily, settles 2 working days after month end.
- Argument it settles
- Does a reschedule count as a no-show? No. It moves to its new date and counts once. Without that rule, one indecisive prospect produces three no-shows.
- Known caveat
- If nobody marks outcomes, this measures admin discipline rather than prospect behaviour. Say so on the report.
How do you get a dictionary people actually use?
Writing it is the easy half. Three habits decide whether it survives a busy month.
Publish it next to the report rather than in a folder, linked at the bottom of every dashboard. Definitions people have to go and find get re-litigated. I'd rather a client read the entry uninvited than ask me about it in a meeting.
Version it and date the change. When a definition changes, and it will, record the old rule, the new rule, the effective date, and who approved it. Then anyone comparing March to October can tell whether the trend is real or whether the rule moved underneath it. Skip that and an innocent change to duplicate handling reads as a performance collapse.
Give every metric one named owner. Not a shared inbox, not "the reporting team." Unowned definitions drift and nobody notices for six months.
Then check that the reports agree with the dictionary: every filter, every calculated field, every spreadsheet column. Across the CRM, UTM, and GA4 field mapping work I do, a written definition that no longer matches the query behind the dashboard turns up often enough that I now assume it until proven otherwise. Inconsistent metric definitions are one of three structural weaknesses in "Your GHL Reporting Is Lying to You," and the only one entirely within your control. The reporting audit checklist runs those checks in order.
Frequently asked questions
What is a marketing reporting data dictionary?
One document defining every metric on your reports: what each means in plain language, which system owns it, how it's calculated, what it includes and excludes, who approves changes, and how often it refreshes. It's written for the person reading the report.
How do I define a lead so everyone counts the same number?
Name the system of record first, then write the inclusion and exclusion rules before the formula. Most disagreements live in the exclusions: duplicates, test records, internal submissions, spam. Set the deduplication window explicitly and count the lead on contact creation date unless the entry says otherwise.
Should the dictionary be shared with clients?
Yes, and it works better shared than internal. A client who can read the definition of cost per lead before the meeting doesn't open the meeting by challenging it. Publishing it commits you to consistency, which is also the entire benefit.
Does a KPI dictionary fix numbers that disagree across systems?
Partly. It removes the disagreements caused by two people applying different rules to the same data, which is a large share of them. It won't close the structural gaps between platforms measuring different things on different clocks. Those need their own diagnosis, though a dictionary isolates them: once the rules are written down, anything still off has to be structural.
Get your definitions reviewed
If your reports and your client's disagree and nobody can say which rule produced which number, that's a diagnosable problem with a finite answer.
I run an agency CRM and reporting diagnostic: a structured review of your CRM setup, attribution capture, and reporting definitions. The definitions half is the work above, done against your actual reports rather than a template, including the places where the query behind a dashboard stopped matching the definition on the page. You get the written dictionary and a prioritized fix list, whether or not you do the remediation with me.
Get your reporting definitions reviewed, or see how I work with performance-marketing agencies on CRM and reporting data.
About the author. Ahmed Abdelkhalek is a Data Automation and Reporting Consultant and the founder of ChromiumData, a founder-led consultancy building reliable reporting and connected data workflows for performance-marketing agencies. He works with clients directly from diagnosis through delivery, mostly at the unglamorous end: CRM data that won't reconcile, reports that take hours to assemble by hand, metric definitions that two people read two ways. More at chromiumdata.com/author/ahmed-abdelkhalek.