11
votes

I'm exploring using Firebase's "User in random percentile" condition to target different segments of a customer-base for A/B testing and have a few questions after reviewing the Firebase Remote Config Parameters and Conditions documentation:

Each app instance is persistently mapped to a random whole or fractional number, according to a key defined in that project.

  1. Assuming that like setUserProperty this value persists for all generated percentiles (i.e. those without keys and with keys) until the app in uninstalled. Is this a correct assumption?

  2. If a condition maps to a random percentile that is <= 50 and I then change that condition to only target <= 10 (but do not modify the key associated with the random percentile), I expect the 11-50 percentile to now match on the next condition (could be the default) but the original 0 to 10 percentile should still match on the condition. Are the these assumptions correct?

  3. Once a random percentile is created for a user, does that value persist across any mutations to conditions so long as the key for that percentile does not change? For example, for key "firebase_test" user A's percentile value is 47%. So long as user A does not uninstall the app that user's percentile value will always be 47% for "firebase_test".

  4. Is the FirebaseRemoteConfig singleton doing any persistence of values? I'm assuming a fetch after the cache expires will ignore any values returned previously by getValue methods and simply return the latest value configured.

  5. Is there any way to print out the percentile value a user is assigned for given keys (and no key as well)? For example calling mFirebaseRemoteConfig.getPercentile("firebase_test") would return 1.234.

Thank you!

1

1 Answers

8
votes
  1. That's true on iOS. I believe on Android, this value will persist even if you uninstall/reinstall your app.

  2. Yes, that assumption is correct. (This is how you can do gradual rollouts of feature with remote config)

  3. I believe so, although if you have specific concerns, I'd be happy to hear 'em

  4. That's true, assuming you also remember to call applyFetched after getting those new values.

  5. Nope, there's no way to do this currently.