The last link in the chain
b7 taught you to ship the numbers; b8 teaches you to protect them. A pack is only as trustworthy as the definitions under it, and definitions only hold when they are written, owned, and change-controlled. This is the governance session of the analyst track - the computing-side twin of the leader track's a6, where leaders learn to ask "whose definition is this?" and you learn to be the person with the answer.
Seven fields that end metric arguments 10 min live
Recall a6's Monday fight: marketing reports CR 3.9%, the trading team reports 2.7%, both are honest, and the meeting burns twenty minutes discovering they divided by different things. A metric spec makes that fight impossible, because everything arguable is written down. Seven fields per metric: name, definition (one sentence), formula, denominator (declared!), source event(s), owner, and alert threshold. Here is one filled in - the course's own default metric.
LiveWhy each field earns its place4 min▶
- Name + one-sentence definition - so the metric can be said out loud without a formula.
- Formula + denominator - the denominator gets its own field because it is where every metric fight actually lives: sessions vs visitors (CR), of-PDP vs of-all-sessions (add-to-cart), gross vs net (GMV).
- Source events - ties the number to the b1 event trail, so anyone can re-derive it from raw data.
- Owner - a metric nobody answers for drifts. One name, not a committee.
- Alert threshold - turns "someone should watch this" into a number with a promise attached (Part 3).
The one-sentence test: hand a spec row to a colleague who has never seen the metric and ask them to compute it from raw events. If they come back with your number, the spec is done. If they come back with a question, that question is a missing field - most often the denominator or a quiet exclusion (bots, gift cards, test orders) living only in someone's head.
Self-studyWhere the spec sheet lives2 min read▶
A spec sheet in a forgotten folder governs nothing. Three placement rules:
- One canonical copy - a wiki page or repo file, never a spreadsheet attachment that forks every time it is emailed.
- Linked from every dashboard - the metric's name on the dashboard links to its spec row. The moment of confusion is the moment of reading.
- Referenced by the weekly pack - b7's pages footnote "definitions per the metric spec sheet, v-dated". The pack and the sheet vouch for each other.
The course's full spec sheet ★ 18 min · everyone works
Eight rows - every metric this course taught, specced with the canonical definitions, the GA4/Shopify source events, a sensible owner, and a simple percentage alert band. Write it once and every dashboard, pack page, and Monday meeting inherits it.
LiveEight metrics, seven fields each14 min▶
| Metric | Definition + formula | Denominator | Source event(s) | Owner | Alert |
|---|---|---|---|---|---|
| UV (unique visitors) | Distinct people who visited in the period. Count of users. Mango Lane: 240,000/mo | None - a count | GA4 users (Active users by default) · any event | Analytics | +/-20% WoW |
| Sessions | Visits; a session ends after 30 min inactivity. Count of sessions. 360,000/mo | None - a count | GA4 session_start · Shopify sessions | Analytics | +/-20% WoW |
| Session CR | Share of sessions ending in purchase. purchase sessions / sessions = 2.7% | Sessions (not visitors) | session_start + purchase | Analytics | +/-10% WoW |
| AOV | Average order value. GMV / orders = $68. Shopify excludes gift cards + post-order adjustments | Orders | purchase (revenue + order id) | Merchandising | +/-8% WoW |
| GMV | Order value before costs. orders x AOV = $660,960. Spec MUST state what is netted out (a2's ladder) | None - a total | purchase (item-level revenue) | Ecommerce lead | +/-10% WoW |
| PDP penetration | Share of sessions viewing at least one product. PDP sessions / sessions = 40% | All sessions | session_start + view_item | Product / UX | +/-10% WoW |
| Add-to-cart rate | Two honest framings - declare which: of PDP sessions (36,000 / 144,000 = 25%, course default) or of all sessions (36,000 / 360,000 = 10%, how Shopify and Littledata report it) | PDP sessions OR all sessions - say which | view_item + add_to_cart | Product / UX | +/-10% WoW |
| Checkout completion | Share of started checkouts that finish. purchase sessions / checkout sessions = 60% | Checkout-start sessions | begin_checkout + purchase | Checkout eng | +/-10% WoW |
LiveThe two rows people always get wrong4 min▶
Add-to-cart rate is the sheet's only row with two denominators in the definition on purpose. Both framings are honest and both are in the wild, so the spec documents both and names a default:
| Framing | Formula (Mango Lane) | Value | Who reports it this way |
|---|---|---|---|
| Of PDP sessions (course default) | 36,000 / 144,000 | 25% | This course's gate math (b4) - gates multiply to CR |
| Of all sessions | 36,000 / 360,000 | 10% | Shopify's funnel report; Littledata's 4.6% benchmark |
GMV is the other trap: there is no universal standard for what it nets out. Shopify's own ladder runs gross sales, minus discounts and returns to net sales, plus tax and shipping to total sales. The spec row does not settle the industry debate - it settles your definition, in writing, so "GMV" means one thing in your building. Always ask what is netted out (a2).
Self-studyReading the sheet as a system3 min read▶
Notice three things about the finished sheet. First, every rate names two events - a numerator event and a denominator event - which is b1's "every metric is a count or a ratio" made official. Second, the two-denominator metrics (CR, add-to-cart) carry the warning inside the definition, so the trap is documented where the next analyst will actually read it. Third, owners follow the funnel: analytics owns the counting, product owns the browsing gates, checkout engineering owns the paying gate, merchandising owns basket value. When a threshold fires, the sheet already knows who picks up.
Self-studySpec sheet vs data dictionary vs semantic layer3 min read▶
Three names you will meet for overlapping ideas - worth keeping straight:
- Data dictionary - documents the raw material: tables, columns, event properties. "The purchase event carries order_id, items, and value." It describes data, not metrics.
- Metric spec sheet (today) - documents the numbers people argue about: definition, formula, denominator, owner, threshold. It sits on top of the dictionary and points at its events.
- Semantic layer - the spec sheet turned into code: metric definitions written once in a tool so every dashboard computes them identically instead of each analyst re-implementing the formula.
The order matters: teams that jump straight to tooling encode their ambiguities at scale. Write the eight rows by hand first - the arguments you settle on paper are the ones the tool then enforces for free.
Alerting basics - a threshold is a promise 8 min live
Three rules make thresholds useful instead of noisy. One: a threshold is a promise to look, not a diagnosis. "CR moved 12% WoW" means the owner investigates - it does not mean anything is broken; the b5 playbook decides that. Two: page the owner, not the channel. An alert into a group chat is an alert to nobody; the spec sheet's owner field exists so the alert has a name on it. Three: every alert names its spec row. The message says "Session CR (spec row 3, sessions denominator) moved -12% WoW" - so the first ten minutes are not spent re-litigating the definition.
LiveThe changelog discipline4 min▶
Definitions will change - a replatform, a new gift-card policy, a fix to bot filtering. The rule that keeps trust: definitions change only with a dated changelog entry, and every dashboard showing the affected metric carries a footnote for one quarter - long enough for every WoW and YoY comparison that straddles the change to be read correctly.
The classic failure: a team quietly starts excluding app-only sessions from the CR denominator in March. CR "improves" 8%. In June someone builds a YoY chart, sees a March step-change, and spends two days hunting a growth miracle that was actually a definition edit. A one-line dated changelog entry would have cost thirty seconds.
Self-studyAnatomy of a good alert message3 min read▶
| Bad alert | Good alert | |
|---|---|---|
| Recipient | #analytics-alerts channel (74 members, 0 readers) | Checkout eng lead, by name |
| Message | "Conversion looks off??" | "Checkout completion (spec row 8: purchase sessions / checkout sessions) 60% to 52%, -13% WoW, crossed +/-10% band" |
| Next step | Implied: someone should probably look | Stated: owner runs the b5 drop playbook, findings in Friday's pack |
The good alert is longer to write and ten times faster to act on: the definition is settled (spec row named), the size is quantified, the owner is a person, and the deadline already exists because b7's pack ships Friday whether or not the mystery is solved.
Self-studyTuning the bands - too noisy vs too quiet2 min read▶
A band that fires weekly gets muted; a band that never fires protects nothing. The working rule: a well-tuned threshold fires roughly once or twice a quarter per metric. Firing more often means the band is inside the metric's normal weekly wobble - widen it, or the metric genuinely is unstable and belongs in the pack's narrative, not in alerts. Never firing across two quarters means it is decorative - tighten it. And review the bands at the same quarterly boundary where b7 allows format changes: seasonality (a5) moves what "normal wobble" means, which is exactly the craft the anomaly-detection sibling course takes further.
What you can now do 5 min live
Eight sessions ago Mango Lane was a stranger. Here is the skill chain you built, one session per link:
b1 · Know the store - the five-event trail, visitor vs session vs pageview, the baseline scorecard.
b2 · Compute - the core four (sessions, CR, AOV, GMV) by hand, denominators declared.
b3 · Tree - GMV decomposed into its drivers in the live simulator; changes multiply.
b4 · Gates - PDP penetration, add-to-cart, checkout start, completion; gates multiply to CR.
b5 · Diagnose - a real drop traced to its gate and its slice with the drop playbook.
b6 · Cut - every metric by channel, device, cohort; averages hide, cuts reveal.
b7 · Narrate - four fixed pages and one paragraph that answers the room's questions first.
b8 · Govern - the spec sheet, alert thresholds, and the changelog that keep it all honest.
Self-studyWhere the series goes next2 min read▶
Course 2 of this series maps the in-app user journey step by step - what shoppers actually do between the events you have been counting - coming to the same hub. And three siblings deepen individual muscles from this track:
- learn-metric-decomposition-with-phoebe ↗ - the driver-tree craft from b3, across six industries.
- learn-sql-with-phoebe ↗ - compute all of this from raw tables instead of dashboards.
- learn-marketing-attribution-with-phoebe ↗ - who really gets credit for b7's channel page.
Self-studyKeeping the habit after the course2 min read▶
The track's skills decay in a predictable order if unused: narration first, then diagnosis, then the arithmetic instincts. Three small rituals keep them alive:
- Cross-foot one real report a week. Any report - yours or someone else's. Multiply the factors, sum the segments. Thirty seconds, and it keeps b2-b3 sharp.
- Ask for the denominator once a meeting. Whenever a rate is quoted, ask "divided by what?" out loud. It keeps b1 sharp and quietly trains the room.
- Re-derive one Mango Lane number from memory each month. If you can still get from 360,000 sessions to 9,720 orders through the four gates, the whole chain is intact.
Try it yourself - this week ◐ 30-40 min total
- Write spec rows for your top 5 metrics - all seven fields, denominator declared, using today's sheet as the template.
- Get the owner named in each row to agree in writing - a one-line reply is enough. An owner who never said yes is not an owner.
- Ship the sheet to wherever your team will actually read it - the wiki page linked from every dashboard beats the beautiful doc nobody opens.
Sources this session draws on
The spec sheet's definitions are the platforms' own; the sheet format and the alert bands are this course's working craft. This page draws on:
Three questions before you go 🎯 ◐ 90 seconds
1 · Marketing says CR is 3.9%, trading says 2.7%, both are honest. Which spec field cures this fight?
Both numbers are correct answers to different questions: buying visitors / visitors vs purchase sessions / sessions. The declared-denominator field makes the difference visible in writing, so the meeting never has to rediscover it.
2 · Session CR moves -12% WoW and crosses its +/-10% alert band. What does that mean?
A threshold firing means one thing: the named owner looks, before Friday's pack, starting from the spec row the alert names. Whether it is a platform change, a tracking bug, or real trouble is what the investigation decides.
3 · The team wants to exclude bot sessions from the CR denominator starting next month. What does the changelog rule require?
Definitions change only with a dated entry, and affected dashboards carry a footnote for a quarter - long enough that every WoW and YoY comparison straddling the change gets read correctly instead of being mistaken for a step-change in the business.