Project: audit checkout conversion and repeat purchase

Last updated: 5 Oct 20265 min read

project

Build a product-analysis packet that reconciles event identity, ordered conversion, mature retention and transaction-ledger guardrails.

Create a controlled event stream

Prepare 83 eligible checkout entrants across web and mobile. Include duplicate event IDs, two payload conflicts, one payment attempt preceding the chosen start, a wallet order without a payment-attempt event, and entries too recent for a 48-hour outcome. Add a separate paid-order ledger with transaction IDs. Store occurrence time, known-at time, app version and schema version. The identity lesson defines the accepted stream.

Compute the ordered funnel

Count entrants, payment attempts after entry and confirmed orders within 48 hours. Show both payment-to-order and entry-to-order rates, and distinguish fully observed entries from pending entries. Inspect skipped-step paths instead of assigning them to failure. Keep user-level and session-level views separate. The sequence lesson supplies the state rules.

Build retention cohorts

Assign first-time buyers to acquisition weeks, then measure paid return in days 7 through 13. Show cohort size, mature users, returns and pending users. Compare web and mobile composition without attributing differences to platform quality. Include a deliberately recent cohort whose week-one window has not closed. The maturity rule prevents premature decline claims.

Reconcile and decide

Join confirmation events to the paid-order ledger by transaction ID. Report ledger-only and event-only orders, refunds, payment failures and support contacts as guardrails. Simulate a mobile release that drops client checkout-start events while paid orders stay stable; the analysis should flag collection drift before it reports a conversion improvement. Instrumentation checks must be visible in the decision note.

Deliver reproducible evidence

Save raw fixtures, ID-map policy, accepted-event ledger, cohort table, analysis cutoff, query or code revision, reconciliation report and assertions. A reviewer should be able to trace one buyer from checkout start through confirmed order and week-one return, then reproduce every numerator and denominator without a vendor dashboard.

Implementation

def funnel_rates(entry_count, payment_count, order_count):
    if not 0 <= order_count <= payment_count <= entry_count:
        raise ValueError("invalid closed-funnel counts")
    if entry_count == 0 or payment_count == 0:
        raise ValueError("rate denominator is empty")
    return {"payment_given_entry": payment_count / entry_count,
            "order_given_payment": order_count / payment_count,
            "order_given_entry": order_count / entry_count}

metrics = funnel_rates(83, 57, 41)
assert round(metrics["order_given_entry"], 4) == 0.4940

Performance and operating cost

The final rate arithmetic is O(1), but event deduplication and ledger reconciliation scan O(N) records with O(N) ID state; per-actor sequencing adds sorting at O(N log N) worst-case time. Reviewer effort concentrates on conflicting identity and missing-path cases.

Common Mistakes

Do not infer conversion from a funnel whose recent entries have incomplete windows.
Do not merge user-level and session-level denominators.
Do not declare a product win when the independent transaction ledger contradicts client events.