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
Server-side
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.
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.
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?