Costs
Part of How to think about digital product funnels
Digital product funnels checklist: the first 14 days live
A digital product funnels checklist for the first 14 days live: what to check on day one, in week one and in week two, with a daily log and a closing record.
What to take away
- Split the first 14 days into three phasesfollow real orders by hand on day one, match records daily in week one, then check refunds and cohorts in week two.
- A mismatch is a record with no partner. Log it with an owner and a recovery route the day it appears.
- Clean event data comes before any reportfix names, traffic filters and duplicates first.
- Stop work when a mandatory privacy, security, data-quality, accessibility, or correction condition fails, even if the score looks favorable.
Day one: follow the first real orders
On day one, follow the first real orders from payment to access by hand, before any report exists. For each one, confirm the order record, the access the buyer received and the price they saw at the start.
A digital product funnels checklist should be attached to a named product version, owner, review date and release. The checklist covers the buying journey from first click to repeat purchase, so day one walks that whole path once.
- Same product, plan, currency and term from the first click to the receipt
- A failed or pending payment creates no order
- A purchase event test row exists, with event name, timestamp, order ID and the matching payment record
Price continuity is the first check to fail quietly, because each screen can look right while the receipt shows a different plan or term.
Days 2 to 7: the daily match
From the second day, run the same match every day. Compare payment, order, access and refund records against each other, and write down every record that has no partner.
- Pull the day's payments, split into accepted, failed, pending and reversed.
- Match each accepted payment to an order record.
- Match each order to an entitlement, so the buyer has the right access.
- Match each refund to its payment and to the access record.
- Log every mismatch with an owner and a recovery route.
The table lists the transitions that break most visibly after launch, the mismatch each one produces and the evidence that shows it is fixed.
| Transition | Mismatch to look for | Pass evidence |
|---|---|---|
| Payment to order | An accepted payment with no order | Matching order ID on the payment record |
| Order to access | An order with no entitlement, or the wrong one | Correct access and recovery |
| Refund to access | A refund with access left unchanged | Refund and access records agree |
| Failed or pending payment | An order created anyway | Accepted, failed, pending and reversed tests |
Keep the event data clean
The daily match is only as good as the events behind it. Document event names and firing rules, exclude test and staff traffic, and control retries and duplicate callbacks, so one purchase is not counted twice.
- Event names and firing rules are documented
- Test and staff traffic are excluded
- Retries and duplicate callbacks are controlled
- Raw counts appear beside percentages
- Privacy purpose, retention and access are approved
Retention follows purpose. The FTC's guide to protecting personal information tells businesses to keep only what they need for their business, so each event field needs a stated reason.
Days 8 to 14: refunds and cohorts
In the second week the question changes from "did each order land" to "what happened after it". Refunds and reversals can arrive after the first purchase, so match each one to its payment and to the access record.
Read the results through digital product analytics rather than a single conversion figure. State how mature each cohort is, and the time limit it covers, before drawing a conclusion from it.
A cohort that is only a few days old cannot show repeat purchase. Say so in the log instead of filling the gap with a forecast.
When a mismatch traces back to the buyer's step
Many daily mismatches are a symptom of a step the buyer could not complete. Run each critical payment path at least twice on the live site, not only on a preview, and use only a keyboard on the second run.
ADA.gov guidance says people with disabilities who cannot use a mouse or trackpad will not be able to access web content if they cannot navigate a website using a keyboard. A funnel step that traps focus therefore costs those buyers the sale.
The daily log
Keep one row per day, written the same way each time, so day nine can be compared with day three.
Field / What to enter
- Date and day number
- Day 1 to day 14
- Payments by state
- Accepted, failed, pending, reversed
- Unmatched records
- Payment without order, order without access, refund without access change
- Owner and recovery route
- Name, and the fix the owner will apply
- End-of-day status
- Open, resolved or accepted exception
Day 14: hand the record over
Close the run only after monitoring is active and the responsible teams know how to investigate. Hand over the open mismatches, the accepted exceptions and the date of the next review.
Reopen the log when price, product, checkout, identity, analytics or policy changes. Gates that apply before payment sit with the launch stages and release gates, so this log starts where those end.
Common questions
What if no mismatch appears for several days?
Keep running the match. A clean day is still a record, and a quiet stretch can hide a path no buyer has used yet.
Who owns a mismatch?
One named person, assigned when the row is written. The row also states the recovery route, so the buyer's problem does not wait for a meeting.
Does a clean fortnight prove conversion will improve?
No. It proves the records agreed over those days; commercial results still require responsible measurement.
When does the log reopen after day 14?
When price, product, checkout, identity, analytics or policy changes, and after any incident.
