Skip to main content
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

ConcernApp-store railsRecurr’s web rails
Per-subscriber conversion eventsLimited; bundled aggregate via App Store Server NotificationsPer-subscriber webhooks (subscription.activated, subscription.renewed, etc.)
Cohort-level A/B testingConstrained by store mechanicsPer-subscriber experiment assignment via subscription metadata
Attribution (post-ATT)Aggregated, modelledServer-side events with the install attribution token
Revenue recognitionBacked out from store reportsGAAP / 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 →

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 →

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 → Event catalog →