Revenue attribution built on verified payment events
Connect acquisition and product journeys to Dodo Payments, Stripe, Lemon Squeezy and other gateways without trusting browser purchase events.
Revenue attribution asks which acquisition touch and product journey contributed to a verified commercial outcome. The word verified is essential. A browser can report that a pricing button was clicked or that a checkout page opened. It cannot prove a payment settled, a subscription renewed, a refund completed or an entitlement should remain active.
A durable attribution system joins a short-lived visit context with a server-side payment event. It retains the source evidence needed for a commercial decision while avoiding a permanent anonymous advertising profile.
The browser-to-webhook handoff
MetricFold's attribution design uses a bounded token:
- The collector creates first-touch and last-touch context from permitted source, campaign and landing-page fields.
- The product requests an opaque attribution token for the current visit.
- The product adds that token to checkout metadata supported by its payment gateway.
- A signed webhook confirms the payment or subscription outcome.
- The trusted server adapter redeems the token once and writes an idempotent revenue event.
The token contains no payment authority. Guessing or replaying it cannot grant access. It expires, is stored hashed and resolves only inside the correct analytics site and workspace.
Gateway adapters need a common contract
Dodo Payments, Stripe, Lemon Squeezy, Paddle, Chargebee and PayPal use different event names and payload shapes. The reporting layer should not copy those differences into every chart. Normalize them into a small commercial vocabulary while preserving provider identity and raw reconciliation references outside analytics.
The normalized contract should include provider event id, account scope, external subject hash, event type, amount, currency, occurred time, product or plan key and optional attribution token. Webhook signatures must be checked against the raw request body. Duplicate delivery must converge through a unique provider-event key. Foreign product IDs in a shared merchant account must be acknowledged and ignored.
MetricFold's native contract covers paid, renewed, failed, recovered, refunded, disputed, cancelled and resumed outcomes. Dodo is used for MetricFold's own billing, with product-scoped IDs and signed webhook processing. Product integrations can use the same trusted recorder for Dodo, Stripe, Lemon Squeezy and other adapters.
First touch, last touch and journeys answer different questions
First touch is useful for understanding how demand begins. Last touch is useful for understanding which interaction preceded conversion. A journey view shows the meaningful actions between them. None is universally “correct.” A founder deciding which educational content creates future customers may prefer first touch. A campaign operator optimizing this week's spend may prefer last non-direct touch. A product manager investigating checkout friction needs the complete path.
Reports should name the model and keep direct traffic rules explicit. They should also show unattributed revenue instead of silently dropping it. A payment may lack a valid token because checkout happened on another device, a link expired, the customer returned much later or an integration was installed incorrectly. The unattributed share is an operational metric of its own.
Recurring revenue needs continuing attribution
Renewals should not be treated as new acquisition conversions. They are outcomes of retained value and payment health. Preserve the original acquisition context and distinguish initial, renewal, expansion, contraction and recovery revenue. A subscription upgraded after a product capability was adopted may support a product-led expansion analysis, but the report should not claim that capability caused the upgrade without an experiment.
Payment recovery deserves a dedicated rate: recovered payments divided by eligible failures in a defined window. Pair it with time to recovery, involuntary churn and the product actions around the failure. This exposes cases where customers want to continue but cannot repair a mandate or payment method.
Currency, refunds and net revenue
Never add USD, EUR and ZAR as though they were the same unit. A workspace can report one currency directly, segment by currency or use an explicit conversion service whose rate and time are recorded. Refunds and disputes should reduce net revenue in the correct period according to the product's accounting definition. Tax-inclusive and tax-exclusive amounts must not be mixed.
MetricFold keeps amounts in precise micro or minor units and labels the currency. Dashboard views default to one workspace currency and do not invent a cross-currency total.
Advertising destinations are a separate policy boundary
Teams often need to send qualified leads or purchases to Google Ads, Meta, LinkedIn, TikTok or another destination. This resembles server-side tag management, but it should not be coupled to core analytics. Each destination connection needs its own purpose, consent requirement, event mapping, allowed fields, retry policy and delivery log.
MetricFold's destination model separates the source event from the destination event. A rule can allow only specific properties and can require an advertising consent purpose. Delivery is idempotent by source event and rule. Turning on privacy analytics never turns on an ad destination.
A good attribution report leaves an audit trail. It can explain which definition produced a number, which payments were included and which outcomes remain unattributed. That makes it useful for budget and product decisions rather than only attractive in a chart.
Reconcile provider truth before reading attribution
Verify intake and state transitions
Use each provider's current signature procedure and raw request body. Stripe's webhook guide and Dodo Payments' subscription webhook documentation illustrate provider-specific contracts; an adapter must not assume one provider's headers, retry behavior or event ordering apply to another.
Test duplicate delivery, delayed failure after success, unknown product ids, foreign merchant products, refund after renewal and events arriving out of order. A late event cannot regress paid or delivered state. An unknown timeout outcome remains pending reconciliation unless an idempotent retry proves the result.
Reconcile money and attribution separately
First reconcile provider event ids, payment state, currency, gross, refunds, disputes and net amount. Then measure which reconciled outcomes have a valid attribution token. This prevents an attribution bug from making revenue itself look missing. Display unattributed paid outcomes and expired/invalid token counts as installation evidence.
The SaaS analytics lifecycle uses the same trusted states for renewal, churn and recovery. The customer journey model connects those outcomes to prior product actions without claiming the path caused the payment.
Use a provider acceptance matrix
| Case | Money result | Attribution result | Required evidence |
|---|---|---|---|
| First paid webhook with valid token | Record once | Join first/last touch | Valid signature, product scope and unused token |
| Duplicate webhook | No additional money | No additional conversion | Provider event id uniqueness |
| Paid webhook without token | Record once | Unattributed | Valid provider truth still wins |
| Browser purchase event | No money truth | Intent only | Public collector cannot create revenue |
| Refund after payment | Reduce net according to policy | Preserve original acquisition context | Verified refund event and currency |
| Foreign product in shared account | Acknowledge and ignore | None | Explicit product-id scope |
Frequently asked questions
Should revenue be attributed to first touch or last touch?
Show both when the evidence exists and name the model. First touch supports demand creation; last non-direct touch supports the interaction nearest conversion. Neither proves causation.
What happens when checkout completes on another device?
The outcome remains trusted revenue but may be unattributed. Do not invent a cross-device match from fingerprinting. A product-owned authenticated account flow may provide an approved join where policy permits.
Can browser JavaScript send a payment amount?
It can report checkout intent for a funnel, but it cannot establish paid, refund or entitlement state. Money comes from a verified provider webhook or an equivalent authoritative server transition.
Which gateways should be supported?
Native adapters should prioritize gateways used by the target market and map them to one tested contract. MetricFold currently models Dodo Payments, Stripe, Lemon Squeezy, Paddle, Polar and a signed generic webhook; every production connection still requires provider credentials and test reconciliation.
Keep a gateway-specific contract test that signs the exact raw payload, replays it, reorders lifecycle events and verifies the normalized money record. This protects the shared report from a provider API or webhook-version change.
Production smoke should use the provider's supported test mode, reconcile the result in MetricFold and confirm no secret, raw payload or customer identity appears in logs, screenshots or client responses.