Is there a way to create an audience of developer builds?

Question

I've tried to make an audience in Firebase Analytics, with "App Version" set to "contains 'debug'". The debug version of my app appends "-debug" on the end of the Version Name string.

When I run the app, though, while Firebase records data for my sessions, it does not record any for the "debug audience."

What I ultimately hope to get to is a world where I can use Remote Config, creating config items that I can use in testing, but I wouldn't have to worry about accidentally leaving config active in some test mode when I push the app live. Right now, my solution is to wrap all calls to apply Remote Config with "if (!BuildConfig.DEBUG)", but I'm sure to forget once, and push an app live with "isPremiumUser" set to true for all users, or something dumb like that :).

Is there a way to create an audience of developer builds, whether by version name, or any other method?

Thanks!

Zapata

You can tag your users created from debug build with "debug" and then filter them by setting up the right audience. – Osithe

When you say "tag your users" - what do you mean? Audience lets you set conditions based on predefined events or user properties, and "tag" is not on of them – Zapata

Sorry, wrong term probably, I was doing it on MS platform where it is called tagging. It is setting a custom property on the user in Firebase. Just set debug = true on those users, so later on you can filter this audience and either include or leave out depending on what you are about to do. Here is a link too, in case you are not familiar with the concept: firebase.google.com/docs/analytics/android/… – Osithe

Answer 1

You could use Firebase Analytics user properties for this (Android docs, iOS docs).

Android example:

if (BuildConfig.DEBUG) {
    mFirebaseAnalytics.setUserProperty("debug_build", "true");
}

You will also need to go to the Firebase console and do two things:

1. Analytics -> User Properties -> New User Property -> "debug_build"
2. Analytics -> Audiences -> New Audience -> name your audience and set condition to user property where debug_build = "true"

Now in Remote Config you can set up conditions based on the newly created audience.

A few things to note:

• Once a user is in an audience, they will forever be in that audience, so even if you stop setting that property the user will still be part of the debug audience
• There is a limit of 50 audiences and 25 user properties so you are sacrificing some of these numbers for debug builds

Griddlecake

That's great info, thanks! Now, a couple questions: If a user is in an audience, but they get an updated value for that custom property, do they join a second audience (presuming an audience was set up for the second value), or switch audiences, or just stick in the first? I just finished the Firebase Hangouts, and there was a suggestion made that the "best" way to handle debug vs prod is separate projects. Would you agree with that? – Zapata

Once a user is in an audience they will never be removed again regardless of if they qualify (or stop qualifying) for those conditions. So to answer your question, yes they would end up joining the second audience while also staying in the first. In terms of best way to handle debug/prod, IMO it really depends on what you're trying to achieve. I do think debug builds are not the most appropriate place to use audiences/user properties because for debug builds you can usually work something into your build process to handle it for you. – Griddlecake

OK, thanks. The reason I'm thinking of using remote config specific to debug builds is that I have 3 variants of user - demo, ad-supported, and premium, which get set based on if IAB is supported (more than 1/2 of my audience comes from users in countries that Google doesn't support with IAB) or if they've done an IAP for upgrade. I can do flavors, but then I have 5 flavors, at least (3 for testing + 2 legit flavors), and I don't like that. So I'm playing with using remote config to set my user-type, and it's been working like a charm so far. Best solution I've found so far. – Zapata

If it's working then I say continue doing it :) I think the hesitation in using Analytics for debug type stuff is that you don't want production data being mixed with data from debug build usage if at all possible. As per the Firebase Hangouts response, you could just have a different package name for debug builds and that would cleanly separate things out on the Firebase side as well. – Griddlecake

I have a follow-up question, @Griddlecake - you mention "Once a user is in an audience, they will forever be in that audience". I'm curious how long is "forever," in the context of a user? For instance, if a user changes phones, or uninstalls the app and then re-installs later, does the user persist across those transitions, or is each of those a separate user? And if I have multiple apps in one Firebase project, does the user appear in the same audience in all apps within that project? – Zapata

I think that depends on what Firebase Analytics considers a unique/new user and unfortunately I'm not sure on exactly how that works. It might be worth filing a new question on stackoverflow to see if someone else from the team can answer. I would think that for multiple apps in one Firebase project a "user" would be of that specific app so they would not appear in the same audience across apps. – Griddlecake

I've asked a new SO question @ #37517560. – Zapata

Answer 2

One thing to keep in mind is that audience user counts are thresholded below 10 users for privacy reasons. And so if you're just testing your "debug" audience yourself, then your audience has < 10 users and "0" will be shown. This will be clarified in the future.

Antonelli

Now THAT is good info that makes it an easy decision. I'll be creating multiple projects. Thanks! – Zapata

If anyone from Firebase is reading the dashboard should really make this clearer. – Dissension

Answer 3

If you are mostly using Analytics you can also register two independent Firebase Projects one for development and one for production. This will allow you to experiment in development w/o interfering with the production data. Just don't forget to switch the project id before releasing the app. You might be able to do this with Gradle targets as well.

Witmer