Skip to content

Remote Evaluation

Remote evaluation involves making a request to Amplitude Experiment's evaluation servers to fetch variants for a user. Remote evaluation is the default way to evaluate users on client-side apps, but may also be used from a server-side environment.

Client-side

Client-side experimentation diagram.

Server-side

Server-side remote evaluation experimentation diagram.

Targeting Capabilities

Remote evaluation targeting and identity resolution is powered by Amplitude Analytics' historical user data. Remote evaluation enables advanced features such as Amplitude ID resolution, IP geolocation, property canonicalization, targeting behavioral cohorts, and historical user properties.

Feature
Remote Evaluation Local Evaluation
Consistent bucketing
Individual inclusions
Targeting segments
Amplitude ID resolution
User enrichment
Sticky bucketing

Implementation

Remote evaluation resolves the user within amplitude and appends additional information to the user before passing the enriched user to the evaluation implementation.

Diagram of remote evaluation, specifically amplitude ID resolution and user enrichment

Amplitude ID resolution

Amplitude ID resolution happens before additional user enrichment, and is required if bucketing by Amplitude ID.

User enrichment

Geolocation

If you use location based targeting in your flags, remote evaluation will automatically resolve location based on the client's IP and use a canonical Country user property to make targeting consistent and easy.

The following fields are resolved via IP geolocation:

  • Country
  • City
  • Region
  • DMA

Canonicalization

Remote evaluation canonicalizes inputs to make it easier to segment users by platform, OS, language, country, etc, even if the devices report slightly different values. Canonicalization transforms various known device, language, and country inputs into canonical values which remain consistent even if the client reports different values.

The following fields are canonicalized on remote evaluation:

  • Platform
  • Device Family
  • Device Type
  • Language
  • Country

User properties

Race Conditions

Targeting a recently set user property may cause a race between Amplitude Analytics ingesting and applying the user property, and Experiment accessing the user property. To avoid any races between a user property being set, and a remote evaluation accessing the user's properties, the user property should be sent explicitly in the remote fetch request.

The resolved Amplitude ID is used to access the user's current user properties based on historical analytics data. These user properties are merged with any user properties sent explicitly in the fetch request and which are then passed in for evaluation.

User Property Merge Priority

User properties sent explicitly in a remote fetch request are prioritized over user properties accessed from analytics.

Cohort membership

Remote evaluation gets the user's cohort membership from analytics which enables targeting by cohorts in targeting segments.

Hourly Cohort Sync

Dynamic cohorts are synced hourly. Therefore, only use cohort targeting if the bucketing isn't time sensitive. Time sensitive user targeting should use user properties passed explicitly to the remote fetch request.

SDKs

Remote evaluation is supported by all SDKs, client-side and server-side.

Client-side

Server-side

APIs


Was this page helpful?