Google Play External Content Links in the US: Attribution Outside Play Billing
See how Airbridge connects US Android installs to web checkouts, then compare campaign and creator performance for installs, trial starts, and subscriptions.

Key Takeaway
- Routing US Android checkouts to the web splits your conversion path across two environments, requiring you to connect app sessions with browser transactions.
- Airbridge provides cross-platform attribution in a single dashboard, and the Core Plan includes web-to-app attribution, the S2S API, and the Web SDK for web-to-app tracking.
- Actuals and Funnel reports break down installs, trial starts, and subscriptions by campaign and creator.
Google Play's external content links program lets enrolled developers link US users to purchases outside Play Billing. When a subscriber pays in a browser instead of through Play, the purchase leaves the Play Billing flow: your payment processor shows new subscribers, but the revenue column in your ad reports stays empty. Unless the app session and the web checkout are linked, you cannot tell which campaign brought in the paying user.
Directing US Users Outside Play Billing
Before changing your checkout flow, review the current requirements on the Play Console Help page for the external content links program: you must enroll, integrate the external links APIs, report transactions, and pay the applicable Play service fees. From a tracking perspective, the core decision is straightforward: the moment you send a user out of the app to complete a transaction, you take on the responsibility of connecting that external payment back to the original install source.
Where the Native Checkout Trail Breaks
In a standard in-app purchase flow, the entire conversion happens inside one environment. A user clicks an ad on TikTok, installs your app from the Play Store, opens it, and starts a trial or subscription on the spot. The app SDK observes the install and the billing event on the same device.
External content links split that path across two surfaces:
- The user installs and opens your Android app, generating a mobile session with device-level identifiers.
- When the user taps your external content link, the purchase opens in a browser or webview outside the app.
- If the browser session does not know who the app user is, the purchase registers as an isolated web event rather than a conversion driven by your mobile ad campaign.
For a small team running lean monthly ad budgets on channels like Google or Meta, losing that connection means flying blind. You might pause a campaign that is quietly generating your best web subscribers, or keep funding an ad group that only drives free app sign-ups.
Connecting App Installs to Web Checkouts
Keeping attribution intact across an app-to-web jump requires a measurement setup that spans both surfaces. Airbridge provides cross-platform attribution, analytics, and deep linking across mobile and web in a single dashboard, measuring ad, campaign, and channel performance across installs, sign-ups, and purchases.
If you are on the Core Plan, your workspace already includes web-to-app attribution, the S2S API, and the Web SDK. On the Core Plan, the Web SDK supports web-to-app tracking only. A purchase completed in the browser can be sent to Airbridge from your server through the S2S API. Within these Core Plan tools and integrations:
- The Web SDK's listed JavaScript methods include
setUserIDandclearUserID. - Subscription revenue from RevenueCat, Adapty, or Superwall flows in through subscription revenue aggregation.
Passing the Right Events and Identifiers
To make sure your external web checkout maps to the right Android install, your app and server payloads need matching identifiers and standardized event names.
On the device side, Airbridge uses platform-supported UUIDs as Airbridge Device IDs for attribution and performance measurement. When you Send In-app Events via the S2S API, the request example includes device fields such as deviceUUID, gaid, ifa, appSetID, and ifv, alongside user fields like externalUserID (for example, 19443), externalUserEmail (for example, example@ab180.co), and externalUserPhone (for example, 821012341234).
For the events themselves, developers install the Core Plan SDK to record predefined events and verify the setup in the Test Console. While 25 standard events come pre-configured in the Core Plan, the subscription-specific events are Start Trial, Subscribe, and Unsubscribe.
Verifying Campaign Performance in Reports
Start with the Actuals report, which groups installs, trial starts, Subscribe events, and subscription revenue across three hierarchy levels: campaign, ad group, and ad creative.
Next, open the Funnel report to see the step-by-step progression from install to trial start to subscription for each campaign. Because it lays out each stage, you can compare conversion rates across different creators.
FAQS
FAQ
How much does it cost to set up cross-platform attribution on the Core Plan?
As of November 2026, the Core Plan starts with a 30-day free trial and then costs $40+/mo with no annual contract or lock-in. The plan includes 500,000 data points per month, and any additional usage is billed at $0.0001 per extra data point.
Which platforms does Airbridge cover in a single dashboard?
Airbridge provides cross-platform attribution, analytics, and deep linking across mobile, web, PC, console, and CTV in a single dashboard. PC, console, and CTV attribution are not included in the Core Plan.
Link your web checkouts
Send web checkout events to Airbridge through the S2S API on the Core Plan.


