Evaluation & Exposure
Follow a single user from assignment to exposure. Explore three evaluation paths, inspect the JSON travelling between services, and see why fetching a recommendation is different from seeing it.
Opening your workspace…
Follow a single user from assignment to exposure. Explore three evaluation paths, inspect the JSON travelling between services, and see why fetching a recommendation is different from seeing it.
The mobile SDK asks Amplitude for variants, caches the result, then records exposure at visibility.
Press Play journey. Requests, replies and local SDK operations will appear in order.
Variants are fetched before the user opens the page containing the widget.
The widget has not been seen.Start the journey to see where evaluation happens and how the result reaches the app.
Recorded when the user is evaluated, subject to SDK tracking / deduplication.
Waiting for ≥50% visibility for 1000 ms.
Frontend setup This journey disables automaticExposureTracking at SDK initialization. fetch() fills the cache; variant(flagKey) reads it. At qualified visibility, exposure(flagKey) uses the configured analytics integration.
{
"message": "Press Play or Step to inspect a request and its response.",
"experiment": "biller-widget-layout",
"user": "user-1042"
}Remote fetch retrieves variants; variant reads the client cache. Exposure needs an analytics integration or tracking provider.
Mobile SDK documentationCMS/BFF/XP endpoints and track_exposure are illustrative. Assignment stays on. The proposed XP exposure default is on; this visibility scenario explicitly turns it off. Amplitude REST itself defaults to no-track. Engineering must confirm the XP parameter.
Assignment tracking is configured. One exposure is recorded per demo journey. The sample variant selection and animation timing do not reproduce Amplitude's bucketing or network latency.