Conversion Definition

Defining what counts as a conversion —the boundary between interest and commitment —so every funnel, experiment, and revenue number rests on a shared, unambiguous event.

Why

Conversion is the moment a user crosses from evaluating to committing, and every downstream metric —funnel rate, CAC, LTV, payback period —is computed from this boundary. If the boundary is fuzzy, every number derived from it is fuzzy. A SaaS that counts a conversion as signup will report a 60% conversion rate and wonder why revenue is low; a SaaS that counts it as first payment will report 3% and know exactly how many paying users it has. The definition must specify the event, the deduplication rule (a user who converts twice counts once), the time window (first conversion only, or any conversion), and the exclusion set (test accounts, refunds, chargebacks). Without this specification, the marketing team reports 1,000 conversions, the finance team reports 600 paying customers, and nobody can reconcile the gap because they are counting different things. A written conversion definition is the contract between product, marketing, and finance.

When

Before building any conversion funnel or reporting conversion rate to stakeholders. Re-define when the business model changes (free-to-paid, self-serve-to-sales, one-time-to-subscription).

How

1. Name the conversion event in plain language: "first successful payment" not "conversion", "deployed first project" not "activated"
2. Specify the trigger precisely: the Stripe invoice.paid event with amount > 0, not the checkout.session.completed event (which fires before payment succeeds)
3. Define deduplication: a user who upgrades, downgrades, and upgrades again counts as 1 conversion (first paid), not 3
4. Define the time window: first-ever conversion only (cohort entry), or any conversion in the period (revenue counting)
5. List exclusions: test accounts (email domain test.dev), internal employees (user_id < 1000), refunded orders, chargebacks, $0 plans
6. Write the SQL that computes it and pin it in the metrics dictionary alongside the metric definition
7. Reconcile with finance: the conversion count from analytics must match the paying-customer count from Stripe within 1%; if not, the definition or the exclusion set is wrong
8. Add a unit test on a fixed dataset so the conversion count is regression-proof
9. Document the definition in a single place (metrics dictionary) and link it from every dashboard that shows conversion

Example

# Conversion definition: "First Paying Customer"
Owner: @growth-lead  Version: 1.4  Last reviewed: 2026-09-20

Event: stripe.invoice.paid where amount_due > 0 AND status = "paid"
Deduplication: one conversion per user_id (first paid invoice only)
Time window: first-ever paid invoice (cohort entry date = first paid date)
Exclusions:
  - email_domain IN ('test.dev', 'example.com', 'internal.ez4code.com')
  - user_id < 1000 (internal/seed accounts)
  - plan_id = 'free' or amount_due = 0
  - refunded: invoice.refunded_at IS NOT NULL
  - chargeback: dispute.status = 'won' (we keep) or 'lost' (we exclude)

SQL:
  SELECT
    user_id,
    MIN(paid_at) AS first_conversion_at
  FROM stripe_invoices
  WHERE amount_due > 0
    AND status = 'paid'
    AND user_id >= 1000
    AND email_domain NOT IN ('test.dev','example.com','internal.ez4code.com')
    AND refunded_at IS NULL
  GROUP BY user_id

Reconciliation (2026-09):
  Analytics: 4,827 first-time paying users
  Stripe:    4,839 active subscriptions (diff 12 = upgrades within month)
  Match: 99.75% —within 1% threshold

Unit test: fixtures/conversion.sql asserts 4,827 on Sep snapshot

Common Problems

⚠Counting signup as conversion —a user who signs up and never pays is not a conversion; reporting 60% conversion when 3% pay hides the real funnel and misleads acquisition spend.
⚠Using checkout.session.completed instead of invoice.paid —the checkout event fires when the user submits the form, before the payment succeeds; counting it inflates conversion by the failure rate (typically 2-5%).
⚠Not deduplicating —a user who upgrades, downgrades, and upgrades again generates 3 payment events; counting all 3 inflates conversion and breaks the cohort entry logic.
⚠Not reconciling with finance —analytics reports 1,000 conversions, Stripe shows 600 active subscriptions, and the 400 gap is never investigated because nobody owns the reconciliation.
⚠Excluding refunds from the conversion count but not from the revenue count —the conversion happened (the user paid), but the revenue should be net of the refund; mixing the two definitions corrupts both metrics.

Best Practices

✓Define conversion as the first successful payment (invoice.paid with amount > 0), not signup —this is the boundary between evaluating and committing, and every downstream metric (CAC, LTV, payback) is only meaningful when computed from paying users.
✓Reconcile the analytics conversion count with the Stripe/billing customer count every month —a > 1% gap means the definition, the exclusion set, or the event trigger is wrong, and the gap must be closed before reporting any conversion number.
✓Deduplicate by user_id (first conversion only) for cohort analysis, and count all conversions for revenue —these are two different definitions serving two different purposes, and both must be documented in the metrics dictionary.
✓Pin the SQL in a versioned metrics dictionary and link it from every dashboard —when the definition changes, the version bumps, the SQL updates, and every dashboard shows the new version, so nobody reports a stale number.