When you build an app that includes both Firebase Remote Config and Firebase Analytics, you gain the ability to understand your app users better and to respond to their needs more quickly. You can combine the capabilities of these features to accomplish the following:
- Use Analytics user properties to customize your app for segments of your user base with flexibility and precision. To learn more, see Remote Config and user properties.
- Perform A/B testing and to validate the impact of improvements and feature changes. To learn more, see A/B test two feature variants.
To learn more about analyzing app usage with Google Analytics for Firebase, see the Analytics introduction.
Remote Config and user properties
Remote Config now lets you use Analytics user properties to create conditions, allowing you to customize your app for segments of your user base that you defined much more precisely than was previously possible.
Using Remote Config with Analytics audiences has some limitations that are not present when you use user properties. Specifically, a user is a permanent member of an audience after they are assigned to it. By comparison, you can define user properties so that they are only temporarily true for specific users.
For example, you could define the following user properties in Google Analytics for Firebase for use in an exercise app with a range of exercise activities at different durations and difficulty levels:
Then, you could create conditions that use these properties (individually, or in combination) to tailor the appearance and behavior of your app for specific users. For example, you could design your app so that users who are interested in running see an image of a jogger when your app is loading. Or, you could define segments of your user base by exercise duration and difficulty level so that casual users are first presented with a suggestion for a shorter, easier workout, whereas serious athletes are invited to start a 40-minute run when our app starts up.
If the behaviors of your users change in ways that alter their user properties, those updates are collected by Google Analytics for Firebase, which can change the behavior and appearance of their app instance after the next fetch request. A full range of operators are available so that you can create rules that include or exclude users with specific user properties or combinations of user properties.
You can also combine other Remote Config rules with rules based on user properties, to deliver customized app behaviors to audience segments like the following:
- Users who like yoga (Exercise_Interest exactly matches yoga), who use your app on an Android device (OS type == Android), located in Canada (Device in region/country == Canada).
- Users who are interested in either weight lifting or weight loss (Exercise_Interest contains weight) who use your app on an iOS device (OS type == iOS) with an English-language UI (Device language == English).
To learn more about user properties, see the following guides:
To learn more about how conditions are created by combining rules, see Remote Config Parameters and Conditions.
A/B test two feature variants
When you are creating a new feature for an application with an active user base, you want to make sure that you get it right. You might be uncertain about the following:
- The best way to implement the feature to optimize the user experience. Sometimes you have two or more competing designs for how a feature could be implemented. You could just choose your favorite approach, but wouldn't it be better if you could learn which approach a representative sample of your users prefers before rolling out the feature to all users? In this example, we show you how to A/B test two variants on your feature idea.
- Whether your users will like your new feature. Too often, app developers don't learn that their users dislike a new feature or an updated user experience until their app's rating in the app store declines. Establishing a control group for your A/B test ensures that you can measure whether your users like either of the variants on your feature idea, or whether they prefer the app as it currently exists. Plus, keeping most of your users in a control group ensures that most of your user base can continue to use your app without experiencing any changes to its behavior or appearance until the experiment has concluded.
To A/B test two feature variants with a control group, do the following:
- Set up your test in Remote Config.
- Create an Analytics user property.
- Add code to your app to support A/B testing.
The rest of this guide describes how to set up such an experiment with a simple shopping app.
Set up your experiment in Remote Config
In this hypothetical A/B test, you want to know whether your app users prefer to see a new promotional notification UI element added to the left or right side of your shopping app, ShoppingApp. In this example, the app already has an established user base and has a fairly dense UI, so adding this UI element could have a significant impact on your app's daily active users, and on revenue generated by your app.
For those reasons, you would want to include some of your user base when testing each of the feature variants, while keeping most of your users out of the experiment.
Start by creating two conditions to track both of the variants in your experiment. Let's label these conditions to note the experiment that they are part of (Experiment 1) and the variant (A and B). So, the conditions are called:
In this example, you would set up each condition with one or more User in random percentile rules to include a non-overlapping group of installed app instances for each variant:
|Experiment_1_Variant_A||User in random percentile <= 5|
|Experiment_1_Variant_B||User in random percentile > 5
User in random percentile <= 10
This results in the first 5% of app instances testing true for the condition Experiment_1_Variant_A and the next 5% of app instances testing true for the condition Experiment_1_Variant_B, with no app instances testing true for both conditions. You can also add more rules to each condition to further refine each condition.
Next, you would create one parameter, experiment1, with default and conditional values as shown below:
- Default value: None
- Experiment_1_Variant_A: variant_A
- Experiment_1_Variant_B: variant_B
experiment1 is used to identify which experiment, if any, a given user is participating in. In this example, the app also uses this parameter to change the behavior of the feature that you are experimenting with. It has a default value of None, which your app would interpret as "don't use this feature." The other two values put the new, promotional notification UI element on either the left or the right side of the screen.
In this example, we are using a single parameter to control a single feature and to manage the two groups used in this experiment. But, in most cases, you would add additional parameters to control other aspects of your app, reusing the same conditions across those parameters.
Create an Analytics user property
In Analytics, create a user property, MyExperiment, and add a description that summarizes your experiment, such as "Testing the best placement of a promotional notification UI element in MyShoppingApp."
Add code to your app to support A/B testing
If the ShoppingApp in our example is already set up to use Remote Config and Analytics, you would only need to do the following to support the A/B testing experiment described in this guide:
- When your app activates the most recently fetched set of parameter values, get the value of the experiment1 parameter.
- Set the MyExperiment user property that you created in Analytics
to the value of the experiment1 parameter:
- On iOS, use the
[FIRAnalytics setUserPropertyString: forName:]method.
- On Android, use the
On iOS and Android, you can accomplish both of these steps with just two lines of code:
NSString *experiment1_variant = [FIRRemoteConfig remoteConfig][@"experiment1"].stringValue; [FIRAnalytics setUserPropertyString:experiment1_variant forName:@"MyExperiment"];
And on Android:
String experiment1_variant = FirebaseRemoteConfig.getInstance().getString("experiment1"); FirebaseAnalytics.getInstance(context).setUserProperty("MyExperiment",experiment1_variant);
- On iOS, use the
- Use the parameter value of experiment1 to change the behavior and
appearance of your app. In this example, the following values would be
interpreted by your app as shown below:
- None: Leave the experience of the control group unchanged.
- variant_A: Place the new UI element on the left side of the screen.
- variant_B: Place the new UI element on the right side of the screen.
In a real-world scenario, you would probably use the conditions that you defined above for many different parameters used by your app.
Analytics can now record data on the two groups of app users, and on the control group. You can use Analytics to create audiences and analyze the behavior of each of these audiences, based on the different values of the MyExperiment user property. See the Analytics Overview for more information about Analytics.
You can later use those audiences to create more parameters with conditional values based on Analytics audiences, to further refine your experiment as you improve your feature. For more information, see Remote Config Parameters and Conditions.