One of my favorite features of Firebase Remote Config is its ability to deliver different content to different groups of users. For instance, you can change the look and feel of your storefront for people who have spent a lot of money in your app. Or you could emphasize one part of your fitness app for runners and another for weightlifters.

Ever since Remote Config first launched, you could accomplish some pretty sophisticated user targeting by delivering different content to people who were in different Firebase Analytics audiences.

But more recently, Remote Config added the ability for you to send different sets of data to people with different user properties, which has made this feature even more useful.

“Wait a second,” you might be saying. “I can already target users with audiences, which allow more sophisticated targeting than just a user property. Why is this any better?”

And it’s true; audiences give you some very powerful and very specific user targeting by enabling you to create groups of users who can be defined by a number of different events and user properties. For instance, you could create an audience of “Left-handed Canadians who have completed level 5 in my game.”1

But audiences have two limitations that can make them more difficult to use within Remote Config:

First off, you’re limited to 50 audiences, and they’re shared among people who might be using these same audiences for other targeting features within Firebase, such as running Analytics reports, or building remarketing campaigns via Google AdWords. This makes it more difficult to create several smaller ad hoc user groups, or to edit existing audiences that other people in your organization might be using.

Second, with the way audiences currently work, once a user joins an audience, they can never leave. To your average marketer who uses audiences for remarketing campaigns, this might be exactly what they’re expecting, but for Remote Config purposes, this can sometimes be problematic.

Imagine you wanted to create a “Newbies” audience of people who have started your game but not yet completed level 10. If you tried creating an audience out of this group, everybody who started your game would be placed into this audience. But then they would remain in this audience even if they reach level 15 or 20, essentially turning this into an “All players” audience.

And that’s why, when I’m targeting users in Remote Config, I prefer to use User Properties as a way to personalize my content. They allow me to create lots of smaller one-off targeting groups, and let me be little more dynamic than with traditional audiences.

For instance, let’s say you have a fitness app and wanted to deliver a different front page image based on the user’s favorite fitness activity. If you have that favorite exercise stored as a user property, you can easily set that up by creating a new condition based on that property.

Then you can show a different front page image based on each one of those conditions.

In this way, you could easily create a half dozen different conditions and not worry about “using up” those Firebase Analytics audiences.2

Or imagine you have a game and you want to change aspects your game’s behavior based on what level the user is at. You can do that by storing that level as a user property and then creating a number of different conditions based on these tiers. For instance, I can create a “intermediate” tier of players who are in between levels 4 and 10…

…and give a different daily bonus to those players.

As users progress in level, Remote Config will automatically start delivering them different values based on their level as their user property places them in different tiers. And I don’t need to create new audiences for each one.

It’s also simple to change these groupings later. If, in the future, I decide that my intermediate tier should really start at level 6, I can make that change within the Firebase control panel, and those changes are pushed out immediately to Remote Config.

Heck I could even add in a fourth tier if I suddenly decide I need to change my game’s behavior for the the extra special players.

By default, user properties are stored as strings, which means you can run string comparisons like “exactly matches” or “contains” against them. If you stored your user’s top 3 fitness activities as a pipe separated string (e.g. **yoga|interval_training|running**) you could create an “All runners” condition by targeting anybody whose fitness activities contained the string “running.”

But you can also run numeric comparisons against them, as we did in the playerLevel example above. Remote Config will translate strings to numbers as you might expect; **"42"** evaluates to 42, **"3.14159"** evaluates to 3.14159, and so on. Numeric comparisons with user property strings that don’t translate to integers or floats (e.g. **"Level_42"**) will always fail, however.

Being able to target user properties is a relatively new feature, so if you haven’t played with it yet, I encourage you to give it a try. Head on over to the Remote Config panel and try making a minor change based on a user property you’re already storing. Once you have that working, stop and think what parts of your app could really benefit from personalization, and considering adding another user property or two to support that.

And if you end up building something cool, let us know! We’d be excited to hear about it.

Footnotes

[1] Assuming you targeted “handedness” as a user property, that is.

[2] To be fair, there is also a limit to the number of Remote Config conditions you can create, but it’s 100, which gives you a lot more room to experiment.