Remote evaluation

Remote evaluation sends a request to Amplitude Experiment's evaluation servers to fetch variants for a user. Remote evaluation is the default way to evaluate users in client-side apps, and also works from a server-side environment.

Client-side

Diagram of client-side remote evaluation request flow

Server-side

Diagram of server-side remote evaluation request flow

Targeting capabilities

Remote evaluation targeting and identity resolution both use 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	✅	❌
Transformed properties	✅	❌
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 enriching the user before variant assignment

Amplitude ID resolution

Amplitude ID resolution happens before additional user enrichment, and Experiment requires it when bucketing by Amplitude ID.Learn more about Amplitude's advanced identity resolution.

User enrichment

Geolocation

If you use location-based targeting in your flags, remote evaluation resolves location from the client's IP and uses a canonical Country user property to keep targeting consistent.

Remote evaluation resolves the following fields with IP geolocation:

Country
City
Region
DMA

Canonicalization

Remote evaluation canonicalizes inputs so you can segment users by platform, OS, language, or country even when devices report slightly different values. Canonicalization transforms known device, language, and country inputs into canonical values that stay consistent across clients.

Remote evaluation canonicalizes the following fields:

Platform
Device Family
Device Type
Language
Country

User properties

Race conditions

Targeting a recently set user property can cause a race between Amplitude Analytics applying the user property and Experiment accessing it. To avoid this race, set the user property explicitly in the remote fetch request.

When you pass user properties to the remote fetch request, those user properties don't update on associated analytics events.

The resolved Amplitude ID accesses the user's current user properties from historical analytics data. Amplitude merges these properties with any user properties sent explicitly in the fetch request, then passes the merged set to evaluation.

User property merge priority

Amplitude prioritizes user properties sent explicitly in a remote fetch request over user properties accessed from analytics.

First Seen

Remote evaluation enriches users with a built-in First Seen user property from the Amplitude ID table. The value is the timestamp when Amplitude first saw the user, in epoch milliseconds UTC.

Use First Seen to target new users without creating or syncing behavioral cohorts. Compare the property against a timestamp to define windows such as users who joined in the last 7 or 30 days.

First-session timing

During a user's first session, First Seen may not be available yet for targeting. Avoid relying on First Seen for flags or experiments that must evaluate on the very first page load or event in a new user's session.

Cohort membership

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

Hourly cohort sync

Dynamic cohorts sync hourly. Use cohort targeting only when bucketing isn't time-sensitive. For time-sensitive targeting, pass user properties explicitly to the remote fetch request.

Transformed properties

Remote evaluation applies your project's transformation configuration to user properties before evaluating targeting rules. Amplitude fetches the transformation config, applies the configured merge and rename rules, then evaluates targeting against the transformed values. The transformed values match what Analytics uses in charts and cohorts.

The Target Segment property picker surfaces transformed user properties alongside standard user properties. You can build targeting rules on the same canonical values your analytics already use.

Consistency with Analytics

Targeting on transformed properties ensures your experiment and feature flag segments match the same population in Analytics charts and cohorts, because both use the same transformation rules.

Was this helpful?