Overview:
You can target specific players in Remote Config without listing many IDs. The recommended pattern is to tag players with a backend‑controlled attribute (for example, isBeta = true) and build a Remote Config audience that targets that attribute. This scales, avoids expression limits, and keeps your rollout easy to manage. For very small, ad‑hoc tests, you can target one or a few customUserId values directly.
Symptoms:
- You want to enable a feature for specific players (testers, VIPs, internal accounts).
- You considered listing many customUserId values in an audience rule.
- You hit JEXL expression length limits or find long ID lists hard to maintain.
- You can’t find an API to upload a list of IDs to build an audience.
Cause:
Remote Config audiences are designed for rule‑based segmentation (by attributes like app version, platform, country, or custom flags), not for large per‑ID whitelists. JEXL rules also have a character limit, so enumerating many IDs is fragile and impractical. Attribute‑based targeting aligns with the design and is easier to scale, audit, and revoke.
Resolution:
- Define a cohort attribute: Choose a simple flag (for example, isBeta = true or playerTier = "VIP") that represents “who should get this feature.”
- Tag players in your backend: Maintain the cohort in your datastore (your backend, Cloud Save, or Cloud Code). Update the flag as the cohort changes.
- Surface the attribute at fetch time: Ensure the client retrieves the player’s cohort flag from your backend before fetching Remote Config and includes it as a user attribute in the fetch call. Remote Config evaluates audience rules against the attributes you send at fetch time.
- Build an audience by rule: Create a Remote Config audience that targets your attribute (for example, isBeta == true), rather than enumerating IDs.
- Control rollout in the Dashboard: Use Game Overrides or feature flags to enable/disable features for that audience. Combine with platform/country/app version filters or percentage rollout to stage exposure safely.
- Revoke instantly: Change the attribute in your backend; the audience rule reflects it on the next fetch, no need to edit long ID lists.
Small, ad‑hoc targeting:
- For a handful of test accounts, you can target one or a few customUserId values directly in an audience rule. Keep these short to avoid expression limits and maintenance overhead.
Alternative (strict ID whitelisting):
- If you must strictly gate access by a maintained ID list, keep the whitelist in your backend and return a “featureEnabled” flag to the client. Have the game enforce that flag locally while using Remote Config for broader rule‑based segmentation.
More Information:
- Game Overrides (feature flagging and staged rollout)
- SetCustomUserID (identifying individual users for small-scale, ad‑hoc targeting)
- Cloud Save and Cloud Code (storing and serving cohort attributes)
-
Gotchas:
- Set customUserId before fetching configs.
- Audience evaluation happens at fetch time; changes apply on the next fetch.
- JEXL expressions have a character limit—use attributes instead of long ID lists.