> ## Documentation Index
> Fetch the complete documentation index at: https://recurr.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Measurement

> Analytics, attribution, and revenue recognition on Recurr's web rails. Server-side events, MMP integration, GAAP/IFRS schedules.

When subscribers move to web rails, the measurement stack continues — and gets cleaner. Conversion events fire server-side, attribution survives post-ATT, and revenue recognition runs from a single billing source of truth that GAAP and IFRS schedules can pull from directly.

## What stays measurable

| Concern                          | App-store rails                                               | Recurr's web rails                                                               |
| -------------------------------- | ------------------------------------------------------------- | -------------------------------------------------------------------------------- |
| Per-subscriber conversion events | Limited; bundled aggregate via App Store Server Notifications | Per-subscriber webhooks (`subscription.activated`, `subscription.renewed`, etc.) |
| Cohort-level A/B testing         | Constrained by store mechanics                                | Per-subscriber experiment assignment via subscription metadata                   |
| Attribution (post-ATT)           | Aggregated, modelled                                          | Server-side events with the install attribution token                            |
| Revenue recognition              | Backed out from store reports                                 | GAAP / IFRS schedule generated from billing source of truth                      |

## Per-subscriber experiments

Experiments assign a variant at subscription creation time and write it into Recurr-managed subscriber metadata. The variant rides every downstream event (renewal, upgrade, cancellation), so cohort-level performance attribution doesn't depend on a separate experiment-tracking layer maintained alongside billing.

Common patterns:

* Pricing experiments — different price points within the same plan
* Trial-length experiments — 7-day vs. 14-day vs. no-trial
* Welcome-sequence experiments — cohorts split on onboarding email cadence
* Plan-mix experiments — monthly vs. annual default surfacing

The customer sets the experiment shape; Recurr emits the variant assignment plus the conversion outcome on every event. Downstream warehouses join the two.

## Attribution

Conversion events fire from Recurr's server, not the user's browser. The attribution token (idfa, gaid, or the equivalent MMP-supplied identifier) attaches to each subscription record at creation, and every subsequent conversion event carries the same token forward.

The benefits:

* **Post-ATT compatible** — server-side events don't require ATT consent for delivery to the MMP. Attribution survives even when the user's iOS device denies tracking permission.
* **Reliable delivery** — server-side events aren't blocked by client-side ad-blockers, browser tracking-prevention, or network failures the way pixel-based attribution is.
* **Same view across platforms** — web sub conversions land in the MMP alongside in-app conversions, so the marketing team sees one view of the user.

### MMP integration

Recurr emits the standard conversion events that mobile measurement platforms expect. The MMP wiring happens during onboarding — Recurr's team configures the specific MMP endpoint plus the event mapping for your stack.

For destinations beyond the major MMPs, Recurr emits the same event schema to any HTTPS endpoint via signed webhooks.

[See destinations →](/api-reference/destinations)

## Revenue recognition

Subscription revenue lands in your Stripe account at settlement. From there, Recurr produces a GAAP- and IFRS-compatible deferred-revenue schedule:

* **Earned revenue** for the period — the portion of a subscription's billing that's been delivered as service
* **Deferred revenue** balance — the portion still to deliver against future periods
* **Period roll-forward** — monthly close-out math for finance teams handling rev rec manually

The schedule generates on the same period boundary your finance team uses (calendar-month default; fiscal-month configurable). Output formats include CSV for spreadsheet import plus the underlying webhook events for ETL into your warehouse.

[Finance role guide →](/for-your-role/finance)

## Multi-source reconciliation during migration

During an active migration, both Apple/Google store events and Recurr events fire for the same subscriber as state changes happen. Your warehouse will land:

1. **App Store Server Notifications** (existing pipeline) — Apple/Google fire `DID_CANCEL`, `DID_RENEW`, etc. for subscribers still on store rails plus historical state changes
2. **Recurr webhooks** (new pipeline) — `subscription.activated`, `subscription.renewed`, `subscription.cancelled` for subscribers on web rails

**Recommended source of truth**: Recurr's events (or your entitlement system if it consolidates both sources). Reasons:

* Recurr's webhooks consolidate state across both rails post-migration — once a subscriber is migrated, Recurr is the authoritative record for their subscription state
* App Store / Google Play events fire for the cancelled app-store subscription during migration (because the store subscription cancels as part of the migration flow); treating them as authoritative state-change events double-counts the churn
* Your entitlement system (RevenueCat, Adapty, custom) is typically already designed to consolidate both sources — leverage that

**Practical pattern**: pipe both event streams into your warehouse, but build your subscription-state model against Recurr's events (or the entitlement system) as source of truth. Store events become reference data for pre-migration history, not authoritative state for active subscribers.

## Webhook event stream

Every measurement-relevant event flows out via signed webhook delivery. Your warehouse (BigQuery, Snowflake, Redshift), product analytics (Mixpanel, Amplitude, PostHog), CDP (Segment, Rudderstack), or any custom pipeline subscribes to the same event stream:

* HMAC-signed delivery — verify origin per request
* Idempotent retries — stable event IDs make downstream dedup trivial
* Versioned schemas — additive changes ship without a version bump; breaking changes ship with 90-day lead time

[API reference →](/api-reference/overview)

[Event catalog →](/api-reference/events)