Get Variation
This topic describes the Get Variation method which returns a variation where the visitor will be bucketed, without triggering an impression.
Returns a variation where the visitor will be bucketed, without triggering an impression.
Version
SDK v3.0, v3.1
Description
Takes the same arguments and returns the same values as Activate, but without sending an impression network request. The behavior of the two methods is identical otherwise.
Use Get Variation if Activate has been called and the current variation assignment is needed for a given experiment and user. This method bypasses redundant network requests to Optimizely.
See Decisions and impressions for guidance on when to use each method.
Parameters
This table lists the required and optional parameters for the Swift SDK.
Parameter | Type | Description |
---|---|---|
experimentKey required | string | The key of the experiment. Note: If you call Get Variation in the context of a feature test, be sure to pass the experiment key, not the feature flag key. If you pass the flag key, then the method tries to find an experiment key with that value. |
userId required | string | The ID of the user. |
attributes optional | map | A map of custom key-value string pairs specifying attributes for the user that are used for audience targeting and results segmentation. Non-string values are only supported in the 3.0 SDK and above. |
Returns
The variation into which the user was bucketed. It throws an OptimizelyError
if the user does not qualify for the experiment or other error is detected.
Example
let attributes = [
"device": "iPhone",
"lifetime": 24738388,
"is_logged_in": true,
]
let variationKey = try? optimizely.getVariationKey(experimentKey: "my_experiment_key",
userId: "user_123",
attributes: attributes)
NSDictionary *attributes = @{
@"device": @"iPhone",
@"lifetime": @24738388,
@"is_logged_in": @true
};
NSString *variationKey = [optimizely getVariationKeyWithExperimentKey: @"my_experiment_key"
userId:@"user_123"
attributes:attributes
error:nil];
Notes
Activate versus Get Variation
Use Activate or Is Feature Enabled when the visitor actually sees the experiment. Use Get Variation when you need to know which bucket a visitor is in without showing the visitor the experiment.
For example, use Get Variation in the following circumstances:
-
To pre-bucket users (for example, in order to render a page correctly) before actually exposing them to the experiment. This way, you avoid triggering redundant impressions that might skew experiment results.
For example, suppose you want your web server to show a visitor variation_1 but do not want the visitor to count until they open a flag that isn't visible when the variation loads, like a modal. In this case, use Get Variation in the backend to specify that your web server should respond with variation_1, and use Activate or Get Feature Enabled in the front end when the visitor sees the experiment. -
To align your third-party analytics and your Optimizely results.
For example, suppose you use client-side third-party analytics. Use Get Variation to retrieve the variation, and even show it to the visitor, but only call Activate when the analytics call goes out. This way, your Optimizely results and your 3rd-party analytics stay aligned. -
To avoid redundant network requests. For example, if you called Activate or is Feature Enabled already, you can use Get Variation if you need the current variation assignment for a given experiment and user.
Important
Conversion events can only be attributed to experiments with previously tracked impressions. Impressions are tracked by Activate, not by Get Variation. As a general rule, Optimizely impressions are required for experiment results.
Source files
The language/platform source files containing the implementation for Swift is OptimizelyClient.swift.
Updated over 2 years ago