experimentKey, then renders the returned variant payload.
1. Plan the hypothesis
Write down:- the exact app surface you are testing
- the primary metric you expect to move
- the control behavior
- the treatment behavior
- the minimum runtime or traffic needed before you decide
2. Configure variants
Create one control variant and one or more treatment variants. Each variant should carry the values your app needs to render that treatment. Those values can look like Remote Config payloads, but the user receives them through experiment assignment. Before an experiment can start, AppActor expects:- draft status
- at least two variants
- exactly one control variant
- variant weights that sum to
10000
3. Test before launch
AppActor does not currently expose a public SDK method for manually pinning one user to one experiment variant. Test with a QA app, narrow app version, country, or entitlement rule instead of shipping manual variant override code. Fetch the assignment from the SDK:- the assignment is stable for the same user
- the payload renders the expected UI
- identity changes do not leak the previous customer’s variant
- fallback behavior is safe when the assignment is unavailable
4. Set traffic and launch
SettrafficAllocationBp in basis points. 1000 means 10% of eligible users, 5000 means 50%, and 10000 means 100%.
Start with a small traffic level when the UI or pricing path is risky. Increase traffic only after you verify diagnostics, purchase flow, and entitlement refresh behavior.
5. Keep analysis separate
Do not call a winner from one local conversion event. Use the experiment result view, subscription lifecycle, refund behavior, and revenue impact together.Assignment and Payloads
Understand SDK assignment fields and fallback behavior.
Analyze Experiments
Review the result before rolling a treatment into Remote Config or app defaults.