Firebase A/B Testing for Mobile Apps: What It Covers and How to Read Results by Acquisition Channel

A paywall experiment can declare a winner while subscription revenue stays flat. One common reason is that organic and paid users land in the same experiment groups, and high-intent organic traffic hides how paid traffic behaves. Reading results by acquisition source shows whether a variant actually turns paid clicks into paying subscribers.

Supported Platforms and Scopes

Native mobile apps on iOS and Android can run experiments across three distinct surfaces: in-app parameters, push notifications, and in-app messaging prompts. When you set up an experiment, you choose which surface to test based on where the user friction lives. If you are testing onboarding flows or paywall layouts, parameter-based experiments handle the logic directly inside the app code. If you are trying to bring inactive trial users back before day seven, messaging and notification experiments let you test copy and timing without shipping a binary update. Because each experiment runs against your analytics events, every variant is evaluated against the primary conversion metric you define, such as trial starts or initial purchases, alongside secondary metrics like daily engagement or crash-free users.

Remote Config Experiments

Parameter experiments work by overriding default in-app values with server-side keys. Instead of hardcoding a single paywall layout or trial length, your app fetches a parameter value on launch and renders the corresponding screen. You assign a percentage of your eligible user base to the experiment, split equally by default across your baseline control group and one or more variants. When a user opens the app, they receive a variant assignment that sticks with them across sessions, ensuring they do not see a $49 annual plan in the morning and a $69 plan at night. You can change feature flags, pricing strings, or onboarding step orders on the fly, and once a variant shows a clear lead on your primary goal, you can roll that parameter value out to everyone with a single click.

User Property Targeting

Dumping all new installs into a single experiment skews your readout whenever your paid budget fluctuates. Paid traffic arriving from an ad creative has different expectations than someone who typed your app name into the store. By targeting experiments with custom user properties, you can restrict a test to a specific segment—such as users from a single country, a minimum app version, or a specific acquisition source. A user property acts as a sticky label attached to the user's profile before the experiment evaluates eligibility. If you set an experiment condition to only include users whose acquisition property matches a specific campaign or ad group, your baseline and variant buckets will only collect data from that exact paid cohort.

Passing Deep Link Data

To obtain deep link callbacks on the device, follow the DeepLink - SDK Quickstart. When the app launches via an Airbridge deep link, isAirbridgeDeeplink is true and the configured deep link is passed as the callback's URI. After installation, when the user installs and launches the app, the app can call handleDeferredDeeplink to obtain the deep link set in the tracking link and use it to redirect the user to the intended in-app location.

Reading Results by Channel

Inside Airbridge's Marketing Analytics, you can configure funnel steps to analyze converted users, conversion rates, drop-offs, and average conversion time, with results broken down by supported acquisition dimensions.

In the Airbridge Core Plan, the Actuals Report shows installs, trials, subscriptions, revenue, and ROAS side by side for every campaign. It groups installs, trial starts, Subscribe events, and subscription revenue across three levels: Campaign, Ad Group, and Ad Creative. Sorting by revenue instead of installs can change the campaign ranking.