Attribution and paywall optimization are different problems
A paywall's job is to convert: the right price, the right copy, the right offer for this user. Attribution's job is to record which affiliate earned the sale. They are easy to conflate because both care about the referral, but they resolve at different layers. Optimizing a paywall does not attribute a sale, and attributing a sale does not require changing your paywall design.
The clean approach is to let the referral context inform what the paywall shows, while the deterministic attribution key rides the purchase itself. That way a paywall experiment never breaks who gets paid.
Passing referral context safely
When your app binds a referred user, Attribloom returns an appAccountToken and, when a campaign configures one, an optional offer code. The token is the attribution key you set on the StoreKit 2 purchase. The offer code is what you present as the referred-user discount.
Use an Apple-approved subscription offer code for the discount rather than inventing a client-side coupon. Offer codes are Apple's supported mechanism for a discounted introductory price, and they keep the reward attached to a paid action. Under Apple 3.2.2 the reward must attach to subscribing, never to the install itself.
- Read the bind response: appAccountToken for attribution, offerCode for the offer.
- Show the offer only to referred users, as a paywall variant.
- Set the appAccountToken on the purchase regardless of which paywall variant renders.
- Never fingerprint the device to infer the referral. Since iOS 14.5 that is against Apple's rules.
Why this keeps experiments honest
Because attribution is carried by the token and confirmed by App Store Server Notifications v2, you can restyle, reprice, or A/B test the paywall freely. The affiliate is credited from Apple's signed transaction, not from anything the paywall renders. A refund later reverses the commission through the same notification stream, independent of paywall design.