Version 7.1.0 of the Firebase Unity and C++ SDKs did a lot to improve Firebase Remote Config and better aligned it with the iOS and Android SDKs. In the process, however, there were some minor changes to the API that may require some action on your part.
First, in the Unity/C# SDK, the static methods you’ve been using have been removed from FirebaseRemoteConfig and moved into FirebaseRemoteConfigDeprecated. For technical reasons, we could not deprecate these functions and leave them in place. If you want a fast and easy way to update Firebase in your game, change FirebaseRemoteConfig to FirebaseRemoteConfigDeprecated. This will let your existing code work without any additional changes, but you won't be able to take advantage of the newer features.
FirebaseRemoteConfig
FirebaseRemoteConfigDeprecated
Also worth noting is that IsDeveloperMode no longer has any effect and can be omitted. You likely paired this with a change to MinimumFetchInterfaclInMilliseconds or by passing a TimeSpan into FetchAsync when debugging Remote Config. Shorter fetch intervals now function without IsDeveloperMode making RemoteConfig an even stronger tool in your LiveOps toolbox!
IsDeveloperMode
MinimumFetchInterfaclInMilliseconds
TimeSpan
FetchAsync
C++ developers can leave their code as is, although you will be warned about deprecation.
Developers wishing to future proof their code and take advantage of new features as they become available should switch to using a Remote Config instance rather than using static functions.
Unity/C#
var remoteConfig = FirebaseRemoteConfig.DefaultInstance;
C++
auto remoteConfig = ::firebase::remote_config::RemoteConfig::GetInstance(app);
SetDefaults is now asynchronous. This is probably a good thing for game developers hoping to move logic off of the main thread, but you do have to be a little more cautious when building your app logic.
remoteConfig.SetDefaultsAsync(new Dictionary<string, object> { {"starting_player_lives", 3}, {"theme", "dark"} }).ContinueWithOnMainThread(task => { // it's now safe to Fetch });
std::vector<remote_config::ConfigKeyValueVariant> defaultConfig = { {"starting_player_lives", 3}, {"theme", "dark"}, }; remoteConfig->SetDefaults(defaultConfig.data(), defaultConfig.size()) .OnCompletion([](const ::firebase::Future<void>&){ // it's now safe to Fetch });
It’s now possible to Fetch and Activate Remote Config changes in a single call.
remoteConfig.FetchAndActivateAsync().ContinueWithOnMainThread(task => { // handle completion });
remoteConfig->FetchAndActivate().OnCompletion([](const ::firebase::Future<bool>& future) { // handle completion });
And when you are ready to read your configuration, it’s now possible to retrieve all of the keys and values in a single language-specific native collection. No more getting a list of keys and looking up each value individually!
IDictionary<string, ConfigValue> values = remoteConfig.AllValues;
std::map<std::string, ::firebase::Variant> values = remoteConfig->GetAll();
Finally, if you would like to debug your Remote Config settings, you may want to reduce the interval between fetches.
var configSettings = new ConfigSettings(); if (Debug.isDebugBuild) { // refresh immediately when debugging configSettings.MinimumFetchInternalInMilliseconds = 0; } FirebaseRemoteConfig.DefaultInstance.SetConfigSettingsAsync(configSettings).ContinueWithOnMainThread(task => { // handle completion });
::firebase::remote_config::ConfigSettings settings; settings.minimum_fetch_interval_in_milliseconds = 0; // caution, only do this in debug mode! remoteConfig->SetConfigSettings(settings);
These changes are part of an ongoing effort to improve Remote Config, including some exciting new features you'll be hearing about in the future. Updating your games now will ensure that you can continue to take the advantage of the latest advances in Remote Config.
Even if your mobile app has been downloaded by millions of users worldwide, making it profitable in the long run is a tricky science. Most apps rely on a mix of ads and in-app purchases (IAP) to make money. The challenge is finding the right balance to maximize both revenue streams while ensuring an engaging experience for every user.
But determining your overall ad monetization strategy without negatively impacting in-app purchases isn’t a one-time effort. Between competition from other apps, changing user behavior, and evolving ad formats, you need to continually assess and experiment with your strategy to find an optimal mix. Doing so can keep users from dropping off from your app and even drive a 25% bump in total ads revenue, as mobile games publisher Pomelo Games discovered.
To tackle this challenge, you need a simple way to test and validate changes to your ads strategy in one place. And ideally, you'll want to gauge the impact of any changes on a small subset of users before rolling them out to your entire user base.
Linking AdMob, Firebase, and Google Analytics provides a streamlined solution to experiment with ads, and make smarter decisions based on app and ad performance insights. Here’s what each tool brings to the table:
Firebase Remote Config allows you to change the appearance and behavior of your app dynamically for any target audience — with no need to release an app update. For instance, you could design a new branding style for users in a certain country or region or change your app's color theme to match a seasonal promotion. You can also provide different app ad experiences, customized to different users in your app.
From there, you can use Firebase A/B Testing with Remote Config to run product and marketing experiments with variants of your app and analyze the results. This helps you make informed decisions about what’s working and whether your changes should be rolled out to more users.
Let’s say you launched a hit space shooter game and want to figure out what type of gameplay keeps users engaged — an easier version with fewer aliens to fight, or a more challenging version with fewer power-ups and a lot more monsters.
Using Remote Config, you build in the framework that enables you to add more challenging elements to your game without having to re-code and publish an entirely new version. Then, you can set up an A/B test that deploys these challenging elements to a small group of users, like your expert-level gaming audience. As part of setting up the A/B test, you choose primary and secondary metrics to optimize for, such as retention rate or total estimated revenue, and then you watch how the more challenging variant performs compared to the easier version.
And thanks to Firebase’s integration with Google Analytics, the actions that users are taking inside the app as a result of your experiments are factored into determining how well a variant performs.
Applied to your ads strategy, this testing framework using Firebase allows you to optimize for goals, like total ads revenue, while also tracking the impact on secondary metrics, like overall app monetization and user retention.
For instance, you might want to figure out if you can earn more ads revenue by adjusting the frequency capping without a drop in user retention. Using AdMob, you can create two ad units that vary in how often they’re shown to the user — say, one ad every 20 minutes versus one ad every five minutes. You can then use Remote Config and A/B testing to evaluate how these two different ad frequencies impact your ad revenue. You can also add secondary metrics to watch during the A/B test, like user retention and IAP revenue.
Or perhaps you’ve noticed a steady drop in ad clicks as people spend more time in your game and suspect it’s related to ad formats. For this case, you can experiment with the various ad formats in AdMob and A/B test these variants on a small number of users who spend more time in your game (an audience determined by Google Analytics). Then, when your A/B test determines which ad format increases ad clicks, you can roll out the new format more widely.
Whether you want to experiment with frequency capping to increase revenue or serve ads to a specific audience, linking AdMob with Firebase and Google Analytics leads to smarter, data-driven decisions. With insights about which users are most likely to spend money in your app, you can even fine-tune who sees an ad versus who’s encouraged to make a purchase instead.
Mobile game publishers around the world have successfully used these tools to optimize their ads and in-app purchases strategies without hindering the player experience. After hearing plenty of positive user feedback — including about the ads themselves — Four Thirty Three Inc. and Pomelo Games (mentioned earlier) were inspired to transform their entire business model, with Firebase tools at the core.
You can watch this session from Firebase Summit and learn more about features you can unlock by linking Firebase, Google Analytics, and AdMob.
Firebase Remote Config allows developers to control the appearance and the behaviour of their apps without having to publish an app update. You can build your app with in-app default configurations and later change those configurations by updating your project’s Remote Config template.
We are happy to announce that you can now manage your Remote Config templates directly from the Admin Node.js SDK.
Typically, you would use the Firebase console to specify and update Remote Config templates manually. However, sometimes you need more automation and server-side control of these settings, such as scheduling Remote Config updates or importing configurations from your own proprietary systems and other Firebase projects. Until now the Remote Config REST API was the only way to implement such use cases, which at times could be cumbersome.
As of version 8.13.0, the Admin SDK introduced a Remote Config API that simplifies the process of creating, accessing, and updating your Remote Config templates from your own backend servers and also from managed Cloud environments like Google Cloud Functions.
Let’s go through some examples on how to use the Firebase Admin Node.js SDK to manage your projects’ templates. You can start by creating a fresh Remote Config template for your project, or you can get the current active template and make changes to it. Here's how you can get the current active template in Node.js:
const admin = require('firebase-admin'); admin.initializeApp(); const template = await admin.remoteConfig().getTemplate(); console.log('ETag from server: ' + template.etag);
Each Remote Config template version is associated with an entity tag (ETag) for version control purposes. The Remote Config API uses this ETag to prevent race conditions and concurrent updates to resources. To learn more about ETags, see ETag - HTTP.
Once you have obtained your current active Remote Config template you can start making modifications. Here are some of the operations you can perform using the Admin Node.js SDK:
Let’s go through an example on adding a new Remote Config condition and a parameter to your template.
// add a new condition template.conditions.push({ name: 'android_en', expression: "device.os == 'android' " + "&& device.country in ['us','uk']", tagColor: 'BLUE' as admin.remoteConfig.TagColor, }); // add a new parameter, that references the above condition template.parameters['header_text'] = { defaultValue: { value: 'A Gryffindor must be brave, talented and helpful.' }, conditionalValues: { 'android_en': { value: 'A Droid must be brave, talented and helpful.' }, }, };
The above example creates a new condition named android_en and uses it in a conditional value of the parameter named header_text. Checkout the documentation to learn more about conditional expressions. Keep in mind that the conditions in a template are listed in descending order by priority. A parameter might have several conditional values associated with it. If multiple conditions evaluate to true, the first condition in the list takes precedence.
android_en
header_text
Once you make updates to your template you must publish it to make the new changes effective. After you publish a Remote Config template using the Firebase Admin Node.js SDK, that template becomes the current active version of your project. Before you publish a template you can always validate it to check for any errors.
try { const validatedTemplate = admin.remoteConfig() .validateTemplate(template); const publishedTemplate = admin.remoteConfig() .publishTemplate(validatedTemplate); } catch(err) { console.log('Error publishing the template:', error); }
For more details and code samples on programmatically modifying Remote Config templates, check out the detailed documentation.
In addition to the API for modifying Remote Config templates, the Firebase Admin Node.js SDK provides an API to manage Remote Config template versions. This API supports the following operations.
The listVersions operation allows you to retrieve a list of metadata for all stored versions of your project, sorted in reverse chronological order. Note that the last 300 versions are stored. All versions that correspond to non-active Remote Config templates (that is, all except the template that is being fetched by clients) are also deleted if they are more than 90 days old. Here’s a sample code to fetch a list of template versions.
listVersions
// list all the Remote Config template Versions // Only the last 300 versions are stored. const listVersionsResult = admin.remoteConfig().listVersions(); listVersionsResult.versions.forEach((version) => { console.log('version', JSON.stringify(version)); });
For a complete list of available operations and examples, check out the documentation on programmatically managing Remote Config template versions.
We hope this new addition of the Remote Config API in the Admin Node.js SDK helps with your backend development tasks. Stay tuned for the Remote Config API to be added across other Firebase Admin SDK platforms. We are excited to see how you use the new APIs in your projects! Hop over to our Github Repo to check out the implementation. Help us further improve our SDKs by providing your valuable feedback, reporting issues, and contributions to our codebase.
