06Measurement · 2 metrics need no analytics access
What would prove this worked — and what would prove it didn't.
Two of the five metrics are counts the team can own on day one. The rest need a join that does not exist yet, and the number that would price the cart disclaimer lives inside the ordering platform. This page says which is which.
How to read this page — counted versus modelled, and why they are never mixed
Two kinds of number, kept apart. Counted figures are computed right now from the 28 offers and 63 sample records in this case study. They are true statements about this dataset and nothing more. Modelled figures come from a seeded session stream of 1,500 sessions, generated deterministically so the workbook and this page never disagree.
What is not here. No uplift. No "before and after". No probability dressed up as a score. The modelled stream exists so the formulas can be inspected; a formula you cannot inspect is a number you have to believe.
What a real engagement would replace. Every modelled figure has a stated internal source that would replace it — search logs, cart subtotals before and after adjustment, order lines. Those are listed in the metric table, not hidden.
The controls change the model, and say so. The filters below genuinely recompute the funnel from the session stream. They do not simulate a business outcome, and changing one does not change any counted figure on the page.
The numbers that need no analytics at all.
These are recomputed every time the page loads, from the same objects the deal checker and the reconciliation workspace read. They reconcile by construction, because they are not copies.
92.9%
26 of 28 offers clear every blocking check
85.7%
24 of 28 offers resolve to at least one product
0.0%
0 of 28 — the field is the blocker
0.0%
none publish a start or end date
Read this correctly"Promotion readiness" is a statement about whether a publication is complete, not about whether the business is performing. A low value here does not mean sales are bad. It means a launch gate would currently stop most offers — which is exactly what a launch gate is for.
Change a filter. Read the modelled behaviour.
The funnel recomputes from the seed. Nothing here is Puff traffic and nothing here is a forecast. The behaviour in the model is an assumption written down in one place — that a deal which resolves to products carries a visitor further than one that does not — so you can disagree with it explicitly rather than implicitly.
POPULATION FUNNEL · one denominator
DEAL BRANCH · only sessions that saw a deal
Two series, two bases, kept apart on purpose. An earlier draft ran them as one funnel and the deal-conditional step made a later stage exceed an earlier one — which means the percentages were not comparable. The bases are now stated on every row.
WHAT THE MODEL ASSUMES
- Deal resolves → product
- 74% continue to a product when the deal resolves vs 41%
- Deal does not resolve
- 41% reach a product anyway; the deal page did not help assumed
- Product → cart
- 44% when the deal resolved, 29% when it did not assumed
- Cart → order
- 61% when the deal resolved, 47% when it did not assumed
These four numbers are the entire model. Nothing else is assumed, and any of them can be replaced with a real measurement without changing the code that computes the funnel.
Every metric, with its formula and its missing source.
| Metric | Formula | Window | Source field | Origin | Note |
|---|---|---|---|---|---|
| Deal-page resolve rate | deals with at least one eligible product ÷ deals published | Point-in-time, on the current promotion set | promotion.eligible_products[] (does not exist yet) | derived | The only metric on this page that needs no new analytics. It is computable the moment promotions become records, and it can be reported by store. |
| Deal-to-product continuation | sessions that reached a product from a resolved deal ÷ sessions that viewed a deal | 7-day rolling | deal_page_view, product_view, session_id | Modeled demonstration data | Modelled here. The real version needs deal-page and product-view events joined on a session id, which requires the analytics tag to fire on both templates. |
| Cart-price adjustment rate | orders whose cart subtotal changed at payment ÷ orders containing a deal item | 28-day rolling | pos.order_lines, cart.subtotal_before, cart.subtotal_after | Requires company data | This is the number that would prove or disprove the cost of the disclaimer on the deal pages. It exists inside the ordering platform and cannot be seen from outside. |
| Zero-result rate on deal-linked searches | searches with no result ÷ searches within 60 seconds of a deal page view | 7-day rolling | search.term, search.result_count, deal_page_view.session_id | Requires company data | A high value here points at the same join problem from the customer's side: they saw a deal, searched for the product, and the menu did not answer. |
| Promotion readiness | promotions passing every blocking check ÷ promotions published | Weekly, at publication | promotion checks (this case study's rule set) | derived | The metric an e-commerce coordinator can own without any analytics access. It is a launch gate, not a performance claim. |
If a deal page lists the products it covers, the stores it covers and the effective unit price, then more of the sessions that view a deal will reach a product and place an order.
Written before the result, with the guardrails fixed in advance so the read cannot be chosen after the fact.
- Unit
- store, then offer type
- Allocation
- Alternate weeks by store, so no offer is half treated inside one store
- Primary metric
- Deal-to-product continuation (m2)
- Guardrails
- Cart-price adjustment rate (m3) must not rise · Order value must not fall · Promotion readiness (m5) must not fall
- Duration
- Four weeks, then read; two weeks minimum before any call
- Stop rule
- Stop if cart-price adjustment rate rises in the treated group, because the change is not doing what it was meant to do.
What would have to exist first
- Deal-page and product-view events joined on a session id
- Order lines with cart subtotal before and after adjustment
- The promotions table, once promotions are records
Until those exist, this test cannot run. Saying so is more useful than designing it further.
The workbook.
A 12-sheet Excel workbook built from the same records this page renders: the disclosure sheet, the source register, the offer set, the rule definitions, the product sample, the check matrix and its explanations, the rollup, the modelled sessions with their summary, and the implementation queue. Real formulas wherever a calculation is claimed — and the disclosure sheet names every modelled value.
View only. The workbook is generated from the same modules this site renders from, so it and the pages cannot drift apart. An empty cell means not published, not derivable, or not applicable to that offer type. It never means zero.