Family Sharing and Subscription Attribution

You open your attribution dashboard on Monday morning and realize your reported subscriber count is higher than the actual cash sitting in your bank account. When you run a consumer subscription app and allow household plan sharing, a single paid checkout can generate multiple premium access grants across a home. If your backend or client code treats every unlocked entitlement as a paid conversion, your campaign ROAS inflates and you end up scaling ad creatives that are not actually bringing in new payers. Understanding how shared household transactions are structured—and how to pipe clean revenue events into your attribution reports—keeps your ad budget tied to real money.

Shared Access Mechanics

Multiple people in a household can share access to an eligible auto-renewable subscription once you enable family access in your subscription settings. One person initiates the checkout and pays the bill, while additional household members can install your app on their own mobile devices and unlock the same premium tier without paying an extra cent.

From your backend's perspective, the billing system does not simply copy a single receipt file across multiple devices. Instead, the store generates an independent transaction record for every family member who opens your app and claims the shared benefit. Each person signs in with their own account, restores or automatically receives the entitlement, and triggers their own receipt validation and server notifications. Because each family member shows up as an active premium user with a valid signed payload, any attribution pipeline that blindly equates "valid subscription receipt" with "paid conversion" will log multiple conversions for a single charge.

Unique Member IDs

The store billing system assigns a separate, unique original_transaction_id to each family member who accesses a shared subscription. If User A buys an annual plan and shares it with User B and User C, User B and User C do not inherit User A's original_transaction_id.

When User B opens your app and syncs their entitlement, the store creates a distinct transaction_id and a distinct original_transaction_id tied to User B's personal account. On future billing cycles, when User A's card is charged for a renewal, User B's subscription state also renews under User B's own original_transaction_id.

Because these identifiers are not shared across the family group, you cannot deduplicate family members simply by grouping transactions by original_transaction_id in your database. Instead, the signed transaction payload (inAppOwnershipType) and receipt info (in_app_ownership_type) include an explicit ownership field. For Family Sharing, the two values to check are:

• PURCHASED: The transaction belongs to the family member who actually paid for the subscription.
• FAMILY_SHARED: The transaction belongs to a family member who received access through the purchaser's shared plan.

Separating Payers and Users

How you count a shared subscription depends on whether you are measuring product engagement or paid user acquisition. In product analytics, a family beneficiary with in_app_ownership_type set to FAMILY_SHARED is a real active user consuming server resources and features. Counting them in your daily active users or feature adoption cohorts makes complete sense.

For ad attribution and campaign optimization, however, only the PURCHASED transaction represents real revenue. Imagine User A installs your app organically and buys an annual plan with household sharing enabled. The next day, User B—who lives in the same house—sees one of your video ads, clicks it, installs the app, and immediately receives premium access via User A's shared plan.

If your app fires a paid subscription event for User B, your attribution report will credit that ad campaign with a paid subscriber, even though the click generated no new billing. To prevent your ad spend from chasing non-paying beneficiaries, inspect in_app_ownership_type before sending conversion events downstream. Trigger paid trial and revenue events strictly when in_app_ownership_type equals PURCHASED, or pass zero revenue for shared access if you track household onboarding separately.

Preventing Duplicate Revenue

Once you isolate the actual purchaser, the next step is making sure that single transaction is not logged twice between your client app and your server integrations. In Airbridge, subscription lifecycle tracking relies on three standard events: Start Trial, Subscribe, and Unsubscribe. The Connect trials and subscriptions to the click setup triggers the Subscribe event at three moments: on the initial purchase, when a trial converts to paid, and on every subsequent renewal. To calculate subscription revenue in your reports, you pass the transaction amount and currency along with the Subscribe event and flag the event as revenue so the dashboard sums those values automatically.

When you connect Subscription Attribution, the integration pairs user and device identifiers so the same subscription event is not collected twice. Whenever you import subscription-related events into Airbridge from a third-party solution, disable subscription-related event collection inside the Airbridge SDK to avoid double counting.

Verifying Attribution Reports

After configuring your events so only paying purchasers trigger revenue from a single source, you can verify campaign performance inside your Airbridge reports. The Airbridge Core Plan includes subscription revenue aggregation and up to two third-party integrations, such as RevenueCat, Adapty, or Superwall.

With clean identifiers flowing in, use two core reports to audit your ad spend:

• In the Actuals report, group your installs, trial starts, Subscribe events, and subscription revenue across Campaign, Ad Group, and Ad Creative levels to see which ads bring in paying subscribers.
• In the Funnel report, track the step-by-step progression from install to trial start to subscription per campaign so you can compare trial-to-paid conversion rates across different creators.