A/B Testing troubleshooting and FAQ

How many experiments can I create and run?

You are allowed up to 300 experiments per project (including rollouts), which could consist of up to 24 running experiments and rollouts, with the rest as completed experiments. If you reach this limit, you'll need to delete draft or completed experiments before creating new ones.

Why can't I view my experiments after unlinking and relinking my project to Google Analytics?

Linking to a different Google Analytics property will cause you to lose access to experiments created beforehand. To regain access to a previous experiment, re-link your project to the Google Analytics property that was linked when the experiment was created.

Why do I receive a "Project not linked to Google Analytics" message when creating a Remote Config experiment?

If you've already enabled Google Analytics in your project and linked your apps, but you're still seeing a message that Google Analytics is not linked, then make sure that an Analytics stream exists for all apps in your project. Currently, to use A/B Testing, all apps in a project must be linked to Analytics.

Here's how to verify the list of all active streams for your Google Analytics integration:

1. In the Firebase console, go to the settings Settings > Integrations page.
2. In the Google Analytics card, click Manage.

Creating a Google Analytics stream for any app that does not have one should resolve the issue. There are a few ways to create streams for missing apps:

• If you only have one or two apps missing an associated Google Analytics stream, you can choose one of the following methods to add a Google Analytics stream:
  • In the Firebase console, delete and re-add any app without an active stream.
  • From the Google Analytics console, select Admin, click Data Streams, then click Add stream, add the missing app's details, and click Register app.
• If you have more than a few missing app streams, unlinking and relinking your Google Analytics property is the fastest and most efficient way to create the missing app streams:
  1. In the Firebase console, go to the settings Settings > Integrations page.
  2. In the Google Analytics card, click Manage.
  3. Make a note of the Google Analytics Property ID and the Linked Google Analytics account.
  4. Click more_vert More and select Unlink Analytics from this project.
  5. Review the warning that appears (don't worry here; you will relink the same property in the next step), then click Unlink Google Analytics.
     
     When unlinking is complete, you'll be redirected to the Integrations page.
  6. In the Google Analytics card, click Enable to begin the relinking process.
  7. Select your Analytics account from the Select account list.
  8. Next to Automatically create a new property in this account, click edit Edit and, from the Analytics property list that appears, select your property ID.
     
     A list of all apps in your project appears. Existing stream mappings for each app are listed, and apps that do not have a stream will have one created for them.
  9. Click Enable Google Analytics to relink the property.
  10. Click Finish.

If you still receive an error creating A/B Tests with Remote Config after performing these steps, contact Firebase Support.

What are the key features of the new A/B Testing workflow?

• Creation within Remote Config: You now create experiments directly from the Remote Config section of the Firebase console. For example, from the Parameters page, click Create Experiment which opens a sidebar-based creation flow.
• Richer Targeting & Condition Reuse: Experiments use Remote Config's native condition builder, enabling you to reuse existing conditions and target users with rich criteria (such as Analytics audiences, user properties, app versions, device language, and country/region) evaluated in predictable sequential order.
• Unified Architecture: Experiments are part of the Remote Config template. This means changes to experiments (targeting, variants, stopping) are bundled with other Remote Config changes and take effect when the template is published.
• Real-Time Updates: Leveraging the Remote Config fetch mechanism, experiment value updates can be propagated to your mobile users in real-time.
• Staging Tab: Experiments that are in create or update states are held in a "Staging" sub-tab within Remote Config. These are local to the active console session.
• Deprecation of Old Drafts: The old standalone Drafts tab in A/B Testing is deprecated. Existing drafts in this tab are view-only (can be duplicated or deleted) and cannot be started or edited. This tab is scheduled to be permanently removed on October 31st, 2026.
• Test Devices Removal: The Manage test devices functionality is no longer available in the new workflow. To target specific internal test devices, you can add one or more Firebase Installation IDs (FIDs) to the experiment's conditions during creation.

How many experiments can I create and run?

You are allowed up to 300 experiments per project (including rollouts), which could consist of up to 24 running experiments and rollouts, with the rest as completed experiments. If you reach this limit, you'll need to delete draft or completed experiments before creating new ones.

How do I create an experiment?

You can create experiments directly from the Remote Config section. For example, to create an experiment from the Parameters page, navigate to Remote Config > Parameters and click Create Experiment. This opens a sidebar-based creation flow similar to how Remote Config rollouts are created.

How can I test or review an experiment internally before exposing it to all users?

In most cases when you want to validate and test an experiment before rolling it out, you're likely more interested in testing the experiment values and the app behavior rather than testing the experiment distribution itself. For such cases, we recommend creating a test experiment that you can target to a limited testing group. After creating the test experiment and verifying that the experiment variants work as intended, you can duplicate the experiment and change the conditions to target your external users, and apply any other conditions based on which users you want to target.

You can also target specific internal test devices to validate experiment behavior before exposing the experiment to any end-users. To do this, add one or more Firebase installation IDs (FIDs) to the experiment's conditions during experiment creation.

Where can I find my temporary experiment drafts, and what is the "Staging" tab?

With this workflow, temporary experiment drafts (includes experiments that are currently in create or update states) are available in a sub-tab called Staging within Remote Config. The drafts in this sub-tab are not persisted beyond the current session.

How do I stop a running experiment?

Stopping an experiment now requires publishing the Remote Config template. When you click Stop Experiment, a publish confirmation pop-up will appear. This pop-up lists all changes that will go into effect, including the experiment stoppage. Publishing the template is necessary to finalize the stopping action.

Why did my running A/B Test experiment stop unexpectedly?

Experiments can stop automatically due to changes in the Remote Config template:

• Template rollback: Rolling back your Remote Config template to a version where the experiment did not exist will stop the experiment. Rolling back to a version where an experiment was already stopped will not restart it. You can make a duplicate of the stopped experiment and re-publish it if you'd want to recreate and run the experiment.
• Parameter unlinking: If an experiment is linked to only one parameter, unlinking the condition associated with that parameter will cause the experiment to stop.

Will rolling back to an older Remote Config template version reactivate an experiment that was previously stopped or deleted?

No. Rolling back a Remote Config template will not restart any experiment that was already stopped, expired, or deleted, even if that experiment was active in the rolled-back version. You can make a duplicate of the experiment and re-publish it if you want to recreate and run the experiment.

What happens when an experiment expires, and what steps should I take?

A/B Testing experiments automatically expire after running for 90 days. When an experiment reaches expiration:

• Data collection stops: The experiment stops collecting new data and calculating metrics. Historical results and metrics collected during the 90-day window remain available in the Firebase console for review.
• The experiment is no longer active: The experiment stops running, and its condition logic no longer actively filters users for experiment variants.
• The expired experiment must be removed: You must remove the expired experiment from the Remote Config parameter. If the expired experiment is not removed, you won't be able to create a new experiment using the same parameter until the expired experiment is cleaned up.

Recommended actions:

• Review experiment results in the Firebase console to examine final metrics and determine if there is a winning variant.
• Apply changes and clean up the expired experiment:
  • If there is a winning variant, roll out the winning variant to apply the value to your users. Note that rolling out a variant does not automatically remove the expired experiment.
  • If you do not want to roll out a variant, remove the experiment from the parameter to return to the default parameter value.
  In either case, explicitly remove the expired experiment from the parameter and publish the Remote Config template to finalize the cleanup.
• Duplicate the experiment or create a new experiment from the parameter if you need to continue testing or collect more data.

Key things to keep in mind:

• Rollouts do not automatically remove expired experiments: Rolling out a winning variant does not automatically clean up the expired experiment. You must still explicitly remove the expired experiment from the Remote Config parameter and publish the template.
• Expired experiments cannot be revived: Once an experiment expires, it cannot be restarted or reactivated—even if you roll back your Remote Config template to a version where the experiment was active.
• The 90-day timer starts on publish: The expiration clock begins as soon as the experiment is published to the template, even if user exposure is initially set to 0%.

Is real-time support available for A/B Testing experiments?

Yes, real-time updates are now supported for A/B Testing experiments. Ensure your application uses the latest required SDK versions (Firebase Android SDK version 34.13.0, Firebase iOS SDK version 12.13.0 and Firebase JavaScript SDK version 12.15.0 to leverage this feature.

If I edit a running experiment's targeting conditions to exclude certain users, why are those users still included in the experiment's measurement data?

A/B Testing uses sticky buckets for measurement.

Once a user is assigned to an experiment and begins being measured, they will continue to be included in the experiment's metrics, even if subsequent edits to the targeting conditions would normally exclude them. However, these users will stop receiving the experiment's variant values if they no longer meet the updated conditions. More details available in the Remote Config variant assignment logic.

I see an error message Link an app to this Condition or select another when configuring targeting for an experiment.

This error means the selected targeting condition requires an explicit Firebase app to be targeted, but the current setup does not include one. Ensure that the condition contains a rule that targets at least one of your Firebase apps.

Why are my conditions not targeting any users?

Conditions in the Remote Config template are evaluated sequentially from top to bottom using the "first match" logic. If a broad, general condition is positioned above a more specific experiment condition, the broader condition captures the user first, and the experiment is ignored. To fix this, consider doing one of following under the Conditions tab:

• Reorder Conditions: Ensure more specific (least inclusive) experiment conditions are placed higher in the evaluation list so they are checked before broader, more general conditions.
• Use Dedicated Parameters: If you have complex targeting needs, consider creating a unique Remote Config parameter specifically for your experiment to avoid condition conflicts.

I cannot delete a condition from the Conditions tab.

Conditions cannot be deleted if they are linked to any active/running experiments. You must first stop the experiment and remove the condition.

I cannot remove a rule from a condition if that rule links to a specific app.

If a condition contains a rule that explicitly targets a Firebase app, that specific app-linking rule cannot be removed while editing the condition.

I see a warning about using multiple percentage conditions in my experiment targeting. Should I be concerned?

This is a non-blocking warning. It appears to make you aware when an experiment's targeting combines multiple percentage-based conditions, as their compounded effect, combined with the experiment's exposure percentage, can sometimes lead to unexpected user distribution. You can proceed, but be mindful of how these conditions interact.

Where can I find and manage Draft experiments or Test Devices?

With the new A/B Testing workflow, here are some of the changes related to old drafts and test devices:

• Draft tab deprecation: The Drafts tab and existing draft experiments are no longer editable. You can only view, duplicate or delete existing draft experiments. The Drafts tab will be permanently removed from the console on October 31st, 2026.
• Test devices removal: The Manage test devices functionality is no longer available in the new workflow. To target specific internal test devices, you can add one or more Firebase installation IDs (FIDs) to the experiment's conditions during creation. For testing experimental for QA apps, assign the experiment to a specific app ID and set exposure to 100%. To review the experiment before rolling it out, set the exposure to 0%. Note that the 90-day experiment expiry period begins upon publishing, even at 0% exposure. After reviewing the experiment, you can increase the exposure percentage to begin the full rollout.

Can I create parameters when creating an experiment?

No, you cannot create a Remote Config parameter directly within the experiment creation sidebar. You need to create the parameter in Remote Config before setting up an experiment that uses it.

How can I mitigate fetch issues (that occurred in May 2026) with the new workflow?

An issue prevented Firebase A/B Testing experiments created between 13 May 2026 and 22 May 2026 from reaching client SDKs. This means your end-users did not receive experiment variants, and metrics are not available for these experiments. Note that experiment delivery to your end-users are now automatically restored, and metrics collection will begin from the next fetch. If you need to extend your experiment's measurement window due to this interruption or have further questions on the new workflow, please contact Firebase Support.