> ## Documentation Index
> Fetch the complete documentation index at: https://docs.snowdoughnut.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Marketing reporting data dictionary
> The single fill-in document that defines what your business measures, how each metric is calculated, where every number comes from, and where every report and dashboard lives. Fill it in once, keep it current, and link to it from every report.
*Fill in each section below. Every section has a "Concept review" dropdown explaining what the section is for and why it exists; you can complete the whole page without opening one, or expand any of them for the reasoning first. Examples throughout use Doughnut Labs, an invented company that sells Doughnut Technology, so you can see one filled-in dictionary rather than scattered fragments. Replace the greyed* `E.g. `*lines with your own answers.*
Fill in Setup, North star metric, and KPI tiers first, ideally with the people who tend to argue about numbers in the same room for 90 minutes. Attribution, source of truth, and ownership come next. Metric formulas can be added gradually, starting with your north star and tier 1 metrics. Everything is a living document: expect to update it as questions come up, and review it on a schedule rather than only when something breaks.
Fill in Setup, the north star metric, and the KPI tiers. This is the part worth doing live, with whoever ends up arguing about numbers later, rather than as individual homework.
Attribution, source of truth, and ownership. These sections are what keep two people from getting two different answers to the same question.
One block per metric, starting with the north star and tier 1. The worked example with real numbers is where a broken definition reveals itself, so don't skip it.
Link your flat file, dashboards, and reports so this page becomes the one place anyone can find any of them.
Log decisions and changes as they happen, and review the whole dictionary on a set schedule.
## Setup
**The basics that identify this dictionary and who's accountable for it:**
| Field | Fill in |
| :-------------------- | :--------------------------------- |
| Organization or brand | *E.g. Doughnut Labs* |
| Business model | *E.g. Ecommerce* |
| Completed by | *E.g. Priya Desai, Head of Growth* |
| Date completed | *E.g. 2026-02-03* |
| Last reviewed | *E.g. 2026-05-01* |
| Next review | *E.g. 2026-08-01* |
**What this business gets paid for, in one sentence:**
*E.g. Doughnut Labs sells a direct-to-consumer subscription box of small-batch doughnut kits.*
These fields exist so anyone opening the dictionary can place it in seconds: whose numbers these are, what kind of business they run, and when the definitions were last checked. The one-sentence business description matters more than it looks. A metric like "conversion" or "customer" means something different for a business selling one-time purchases than one selling subscriptions, and writing the model down up front keeps that distinction visible everywhere else in the document.
## North star metric
**The tiebreaker metric: the one you optimize for when two reasonable options conflict.**
| Field | Fill in |
| :------------------------ | :----------------------------------------------------------------------------------------------- |
| North star metric | *E.g. Contribution margin after marketing* |
| Plain-language definition | *E.g. What's left from sales after every cost that scales with an order, including advertising.* |
| Why this one | *E.g. Revenue alone can be bought at a loss; this can't be improved by spending recklessly.* |
| Counter-metric | *E.g. New customer count* |
| Who owns it | *E.g. Finance lead* |
**Common starting points, if you want a reference rather than a blank page:**
| Business type | Common north star | Counter-metric |
| :-------------- | :---------------------------------- | :----------------- |
| Ecommerce | Contribution margin after marketing | New customer count |
| Subscription | Net new recurring revenue | Churn rate |
| Lead generation | Cost per closed-won customer | Pipeline volume |
| Marketplace | Completed transactions | Take rate |
The north star is the tiebreaker, not the most important KPI on the list. A team can have several well-defined KPIs and still disagree constantly, because KPIs conflict with each other in ordinary ways: volume up and margin down, lead count up and lead quality down. The north star is the one number that settles which side wins. There can be many KPIs. There's exactly one north star.
A counter-metric belongs beside it always, in the same report, because any single metric can be improved by doing something that quietly damages the business elsewhere. The counter-metric doesn't need its own target; it needs to be visible every time the north star is, so the tradeoff shows up in the routine report rather than in a postmortem months later. See [reporting framework concepts](/reporting-framework-concepts) for the four tests a good north star has to pass.
## KPI tiers
**Keep the total list under 15. A metric earns a place here only if a 20% move, in either direction, would change what you do.**
### Tier 1, outcomes
Three to five metrics the business is directly accountable for.
| Metric | Definition in one line | Target | Floor | Owner |
| :------------------------- | :------------------------------------------------------------ | :------------------------ | :----------------- | :------------------ |
| *E.g. Contribution margin* | *E.g. Net revenue minus every cost that scales with an order* | *E.g. 24% of net revenue* | *E.g. 18%* | *E.g. Finance lead* |
| *E.g. New customer count* | *E.g. First-ever purchasers in the period* | *E.g. 2,400/month* | *E.g. 1,800/month* | *E.g. Growth lead* |
| \[add tier 1 metric] | | | | |
**Floor** is the level that triggers an actual phone call rather than a note in a report.
### Tier 2, drivers
Five to ten metrics: the levers that move tier 1.
| Metric | Which tier 1 metric it moves | Owner |
| :--------------------------------------- | :--------------------------- | :--------------------- |
| *E.g. Marketing efficiency ratio* | *E.g. Contribution margin* | *E.g. Paid media lead* |
| *E.g. Blended customer acquisition cost* | *E.g. New customer count* | *E.g. Paid media lead* |
| \[add tier 2 metric] | | |
### Tier 3, diagnostics
Listed, not tabled. These explain why a tier 2 driver moved: cost per click by channel, add-to-cart rate, checkout abandonment, whatever your team checks first when something looks off.
*E.g. Cost per click by channel, add-to-cart rate, checkout abandonment rate*
\[add diagnostic]
### Deliberately not tracking
Write these down. It saves the same conversation from repeating every quarter.
| Not tracking | Why not |
| :--------------------------------- | :-------------------------------------------------------------------------- |
| *E.g. Social media follower count* | *E.g. Doesn't move with revenue or margin; vanity metric for this business* |
| \[add item] | |
A KPI is a metric that changes what you do. If it moved 20% and nobody would act differently, it's context, not a KPI, and it belongs in tier 3 or off the list. Starting from decisions rather than from whatever a dashboard happens to surface is what keeps this list short and useful rather than long and decorative.
The three tiers exist so a report can explain, not just state. When a tier 1 outcome moves, tier 2 says why; when a tier 2 driver moves, tier 3 says why that happened. A report built on this chain reads as cause and effect instead of a list of unrelated facts. See [reporting framework concepts](/reporting-framework-concepts) for how this plays out differently in a business with a long sales cycle, where tier 1 outcomes lag the activity that produced them.
## Attribution
**The rule for deciding which touch gets credit for a result. Every model is wrong differently; pick one, write down where it's wrong, and apply it consistently.**
| Field | Fill in |
| :---------------------------------------------- | :-------------------------------------------------------- |
| Primary model | *E.g. 7-day click, multi-touch* |
| Applied to | *E.g. All paid channels* |
| Click window | *E.g. 7 days* |
| View window | *E.g. Excluded* |
| Lookback window | *E.g. 7 days* |
| Secondary model, if any | *E.g. Marketing efficiency ratio (blended, unattributed)* |
| Used for | *E.g. Sanity check against the primary model* |
| Do platform-reported numbers appear in reports? | *E.g. No* |
| If yes, how labeled | *E.g. N/A* |
**Where the model is known to be wrong, written down honestly:**
| Question | Answer |
| :---------------------- | :------------------------------------------------------------------------------------------------------------------------- |
| This model overcredits | *E.g. Retargeting and branded search, since they're often the last click before a purchase someone had already decided on* |
| This model undercredits | *E.g. Top-of-funnel video, which rarely gets the last click* |
| Not measured at all | *E.g. Podcast sponsorships and word of mouth* |
**How the model gets checked:**
| Field | Fill in |
| :---------------- | :------------------------------------------------------------------------ |
| Validation method | *E.g. Quarterly geo holdout test on paid social* |
| How often | *E.g. Quarterly* |
| Last validated | *E.g. 2026-04-15* |
| What we found | *E.g. Model undercredited paid social by roughly 12% against the holdout* |
Add up what every ad platform reports and the total will exceed actual orders, because each platform claims every conversion it touched under its own window. This is normal, not a tracking bug, and it's exactly why platform numbers can't be summed and why the business needs one model of its own, applied the same way every time.
Which model fits depends on how long the path to purchase runs, how much spend goes to channels that can't be clicked (audio, connected TV, sponsorships), and how fast the team needs to act on the answer. See [reporting framework concepts](/reporting-framework-concepts) for how those three questions point toward different models, and why validating the model at least once a year, rather than just trusting it, is what keeps an attribution setup from quietly drifting out of line with reality.
## Source of truth
**One approved system per metric. When two systems disagree, the approved one wins.**
| Metric | Approved source | Exact field or report | Refresh | Who owns the pipeline |
| :------------------- | :---------------------- | :--------------------------- | :------------- | :--------------------- |
| *E.g. Total revenue* | *E.g. Shopify* | *E.g. Net sales* | *E.g. Daily* | *E.g. Data lead* |
| *E.g. Ad spend* | *E.g. Each ad platform* | *E.g. Amount spent* | *E.g. Daily* | *E.g. Paid media lead* |
| *E.g. Cost of goods* | *E.g. Finance export* | *E.g. Standard cost per SKU* | *E.g. Monthly* | *E.g. Finance lead* |
| \[add metric] | | | | |
Name the exact field, not just the system. "Revenue from the ecommerce platform" is ambiguous; gross sales, net sales, and total sales are three different numbers in the same admin panel.
### Expected discrepancies
Systems will disagree. Recording the normal gap turns a change in that gap into a signal instead of a monthly crisis.
| Comparison | Normal gap | Why | Investigate when |
| :-------------------------------------------- | :------------------------- | :------------------------------------ | :-------------------------- |
| *E.g. Analytics revenue vs. platform revenue* | *E.g. 3 to 6%* | *E.g. Ad blockers, consent rejection* | *E.g. Gap exceeds 10%* |
| Sum of platform conversions vs. actual orders | *(usually higher, always)* | Platforms claim shared conversions | Never; this gap is expected |
### Data lag
| Field | Fill in |
| :---------------------------------------------- | :------------------------------------------------------- |
| Earliest date a weekly report can cover through | *E.g. 2 days before send* |
| Earliest business day a monthly report can send | *E.g. 4th business day* |
| When finance closes | *E.g. 10th business day* |
| Are monthly reports sent before close? | *E.g. Yes* |
| If yes, how estimates are labeled | *E.g. Cost of goods marked "estimated" until reconciled* |
When two systems produce different numbers for the same metric, the useful question is "which one is approved," not "which one seems more trustworthy right now." Naming the source ahead of time turns that moment from a debate into a lookup.
The most common mistake is treating an analytics platform as the source for revenue. Analytics tools miss sales lost to ad blockers or consent rejection and don't know about refunds after the fact; revenue belongs to whichever system actually took the money. See [reporting framework concepts](/reporting-framework-concepts) for how to assign a source by which system owns the underlying event, and how a metric that spans several systems, like contribution margin, needs a join rule recorded alongside its source.
## Ownership
**No role can be blank. One person can hold several roles.**
| Role | Name | What they decide |
| :-------------------- | :-------------------- | :-------------------------------------------------- |
| Metric owner | *E.g. Priya Desai* | *E.g. What a metric should measure* |
| Data owner | *E.g. Sam Okafor* | *E.g. Where the number comes from; fixes pipelines* |
| Report owner, weekly | *E.g. Marco Silva* | *E.g. Writes and sends the weekly report* |
| Report owner, monthly | *E.g. Priya Desai* | *E.g. Writes and sends the monthly report* |
| Decision owner | *E.g. Head of Growth* | *E.g. Acts on what the report says* |
Every metric needs one name attached, not a team. A metric with shared ownership tends to drift silently, since someone adjusts a filter, someone else changes a date range, and eventually two views of the same number disagree with no record of why. One owner doesn't mean one person does all the work; it means there's one person to ask when the definition needs a decision.
A definition should only change when its owner approves the change, and the change gets logged with an effective date below in Part 4, so old reports don't quietly stop matching new ones. See [reporting framework concepts](/reporting-framework-concepts) for what breaks when a definition changes silently instead.
## Metric formulas
**One block per tier 1 and tier 2 metric. Copy the block as many times as you need. Start with your north star and tier 1 metrics; you don't need every metric defined before you start reporting.**
```text theme={null}
METRIC: _________________________________________
TIER: ______ OWNER: ____________________________
PLAIN DEFINITION (one sentence, no jargon):
_________________________________________________
FORMULA:
_________________________________________________
INPUTS:
Input Source system Exact field
________________ __________________ ____________
________________ __________________ ____________
INCLUDES: _______________________________________
EXCLUDES: _______________________________________
GRAIN (what one row represents): ________________
DATE ATTRIBUTED TO: _____________________________
ATTRIBUTION APPLIED: ____________________________
TARGET: __________ FLOOR: __________
NORMAL RANGE: ___________________________________
WORKED EXAMPLE (real numbers, one recent period):
_________________________________________________
MISLEADS WHEN: __________________________________
READ ALONGSIDE: _________________________________
```
**A block filled in, for reference:**
```text theme={null}
METRIC: Contribution margin after marketing
TIER: 1 OWNER: Finance lead
PLAIN DEFINITION:
What's left from sales after every cost that scales with an
order, including advertising.
FORMULA:
Net revenue − cost of goods − shipping − payment fees
− discounts − ad spend
INPUTS:
Input Source Exact field
Net revenue Shopify Net sales
Cost of goods Finance export Standard cost per SKU
Shipping Fulfilment provider Actual cost per shipment
Payment fees Payment processor Fee per transaction
Discounts Shopify Discount applied
Ad spend Ad platforms Amount spent
INCLUDES: all direct-to-consumer orders, all paid channel spend
EXCLUDES: wholesale orders, flagged test orders, salaries, software
GRAIN: one order, rolled up to week and channel
DATE ATTRIBUTED TO: order date, account time zone
ATTRIBUTION APPLIED: ad spend allocated by 7-day click, multi-touch
TARGET: 24% of net revenue FLOOR: 18%
NORMAL RANGE: 21 to 27%
WORKED EXAMPLE (week of June 8, 2026):
Net revenue $103,000
Cost of goods $ 37,100
Shipping $ 9,950
Payment fees $ 2,975
Discounts $ 5,600
Ad spend $ 23,150
103,000 − 37,100 − 9,950 − 2,975 − 5,600 − 23,150 = $24,225
Margin % = 24,225 / 103,000 = 23.5%
MISLEADS WHEN: standard rather than actual cost of goods delays
the effect of a supplier price change by a month. A shift in
product mix can move the percentage with nothing else changing.
READ ALONGSIDE: new customer count, which catches margin
improving because the business is quietly shrinking.
```
**Calls worth making explicit, since this is where two people's numbers usually diverge:**
| Question | Your answer |
| :----------------------------------- | :---------------------------- |
| Test and internal orders | *E.g. Excluded* |
| Refunds | *E.g. Deducted when refunded* |
| Cancelled orders | *E.g. Excluded* |
| Tax | *E.g. Excluded* |
| Shipping revenue charged to customer | *E.g. Included* |
| Discounts | *E.g. Net* |
| Time zone | *E.g. Account local time* |
The worked example is the part most templates skip and the part that matters most. Calculate it with real numbers before adopting a metric; if the answer doesn't roughly match what people already expect, the definition has a problem, and it's far cheaper to find that now than in a meeting where two people are holding different numbers.
This block is also where the ambiguity in a metric name actually gets resolved. "Revenue" sounds like one number until you write down whether it includes tax, whether a refund gets deducted the day it happens or the day the original order shipped, and which time zone a date belongs to. None of those calls has a universally right answer; what matters is making the call once and writing it down, so it doesn't get made differently by whoever happens to be pulling the number that week.
## Where everything lives
**Update this whenever you build something. This section is what makes the dictionary a portal instead of just a form.**
### The flat file
| Field | Fill in |
| :----------------- | :------------------------------------------------------- |
| Location | *E.g. Google Sheet: "Doughnut Labs Reporting Flat File"* |
| Owner | *E.g. Sam Okafor* |
| Channels included | *E.g. Meta, Google Search, Email, blended* |
| Refresh schedule | *E.g. Every Monday for the prior week* |
| Restatement window | *E.g. 14 days* |
| Last validated | *E.g. 2026-06-09* |
Metric names in the flat file must match the metric formulas above. Channel and source names must match Source of truth. See the [flat file template](/flat-file-template) for the schema.
### Dashboards
| Name | What question it answers | Audience | Link | Owner | Refresh |
| :--------------------------- | :------------------------------------------------- | :----------------- | :------------- | :---------------- | :----------- |
| *E.g. Live pacing dashboard* | *E.g. Are we on track to hit this month's target?* | *E.g. Growth team* | *E.g. \[link]* | *E.g. Sam Okafor* | *E.g. Daily* |
| \[add dashboard] | | | | | |
### Reports
| Report | Send day | Period covered | Audience | Owner | Template |
| :-------- | :--------------------------------- | :-------------------------- | :----------------------- | :----------------- | :------------------------------------------------------ |
| Weekly | *E.g. Every Tuesday* | *E.g. Prior Mon to Sun* | *E.g. Growth team* | *E.g. Marco Silva* | [Weekly report template](/weekly-report-template) |
| Monthly | *E.g. 4th business day* | *E.g. Prior calendar month* | *E.g. Leadership* | *E.g. Priya Desai* | [Monthly report template](/monthly-report-template) |
| Quarterly | *E.g. 2 weeks after quarter end* | *E.g. Prior quarter* | *E.g. Leadership, board* | *E.g. Priya Desai* | [Quarterly report template](/quarterly-report-template) |
| Annual | *E.g. Before next year's planning* | *E.g. Prior year* | *E.g. Leadership, board* | *E.g. Priya Desai* | [Annual report template](/annual-report-template) |
Leave a row's fields blank for a cadence you don't yet produce. Most brands start with a dashboard plus a monthly report and add weekly once spend justifies it.
### Report archive
Every sent report gets logged, by cadence, in the [weekly](/weekly-report-archive), [monthly](/monthly-report-archive), [quarterly](/quarterly-report-archive), and [annual](/annual-report-archive) report archives.
A dictionary that only defines metrics, without saying where the flat file, dashboards, and reports actually live, leaves a reader with the definitions but not the destination. This section is what turns the dictionary into the front door for the whole reporting system: anyone with a question about a number can start here and reach the actual file, dashboard, or report without asking around for a link.
Metric and channel names have to match exactly between this section, the formulas above, and the flat file itself. A metric that's spelled one way in the dictionary and another way in the flat file is the same ambiguity the dictionary exists to prevent, just moved one level down.
## Decisions and changes
### Why we decided what we decided
One entry per significant choice. The "rejected because" field is what stops the same debate from reopening every few months.
```text theme={null}
DATE: ___________________________________________
DECISION: _______________________________________
CONTEXT: ________________________________________
OPTIONS CONSIDERED: _____________________________
WHY WE CHOSE THIS: ______________________________
REJECTED BECAUSE: _______________________________
DECIDED BY: _____________________________________
EFFECTIVE DATE: _________________________________
AFFECTS: ________________________________________
```
**Filled in, for reference:**
```text theme={null}
DATE: 2026-02-10
DECISION: Use a 7-day click, multi-touch model for all channel
numbers.
CONTEXT: Platform-reported conversions summed to well over our
actual order count.
OPTIONS CONSIDERED: Last touch, platform-reported, 7-day
multi-touch, media mix modeling.
WHY WE CHOSE THIS: Median first-touch-to-purchase is 4 days, so
a 7-day window covers most real paths.
REJECTED BECAUSE: Last touch overcredited branded search by
roughly 30% against a January holdout test. Mix modeling needs
more history than we have.
DECIDED BY: Head of Growth, with finance present.
EFFECTIVE DATE: 2026-03-01
AFFECTS: All channel-level conversion and revenue numbers.
Reports before this date used last touch.
```
**Effective date matters.** When a definition changes, every report before that date used the old one; without the date, old numbers look wrong instead of just different.
### What changed and when
Anything that could change how a number should be read. Log it the day it happens, not at report time.
| Date | What changed | Expected effect | Duration | Logged by |
| :---------------- | :----------------------------------- | :----------------------------- | :-------------------- | :----------------- |
| *E.g. 2026-06-03* | *E.g. Summer sale, 20% off sitewide* | *E.g. Revenue up, margin down* | *E.g. 06-03 to 06-10* | *E.g. Marco Silva* |
| \[add change] | | | | |
Log campaign launches, promotions, price changes, site deploys, outages, stockouts, tracking changes, definition changes, and competitor moves. Skip routine bid adjustments and normal creative rotation; log what would actually break a comparison, not everyday tuning.
### Open questions
Anything unresolved. Each needs a name and a date, or it becomes permanent.
| Question | Owner | Needed by | Blocking |
| :-------------- | :---- | :-------- | :------- |
| \[add question] | | | |
The decision log exists because the same debate tends to resurface every few months if the reasoning behind a choice isn't written down anywhere. Recording what was considered and why it was rejected is what lets a future conversation start from "we already looked at that" instead of relitigating it from zero.
The change log answers a different, more immediate question: why did this number move on that date. Without it, an unusual spike or dip in a report becomes a small investigation every time, even when the cause was a known promotion or a tracking change logged weeks earlier and simply forgotten.
## Sign-off
Everyone agrees these are the numbers, calculated this way, from these systems, until the decisions and changes section says otherwise.
| Role | Name | Date |
| :--------------------------------- | :--- | :--- |
| Marketing | | |
| Finance | | |
| Agency or analytics, if applicable | | |
## Related resources
* [**Reporting framework concepts**](/reporting-framework-concepts) The reasoning behind every section on this page.
* [**Flat file template**](/flat-file-template) Where the raw numbers this dictionary defines actually get stored.
* [**Ecommerce metrics starter pack**](/ecommerce-metrics-starter-pack) and [**Sales-led metrics starter pack**](/sales-led-metrics-starter-pack) Pre-researched metric definitions if you'd rather start from a reference than a blank page.
* [**Weekly**](/weekly-report-template), [**monthly**](/monthly-report-template), [**quarterly**](/quarterly-report-template), and [**annual**](/annual-report-template) report templates The reports this dictionary's definitions feed.