User profile service in Optimizely Feature Experimentation

After starting an experiment, you can increase total traffic while ensuring that users experience consistent variations. However, decreasing traffic or reconfiguring a running experiment can cause users to be reassigned to different variations. To prevent this, implement a user profile service that persists variation assignments (also called sticky bucketing). You may need this in the following scenarios:

Reconfiguring a running experiment to troubleshoot.
Enabling Stats Accelerator.

The primary reason you would decrease traffic is to address errors. Instead of reducing traffic to 0%, you can pause the experiment rule while investigating the issue.

How users are bucketed

Optimizely Feature Experimentation uses a deterministic hashing method that combines the user ID and experiment ID to assign ("bucket") users to experiment variations. As long as your systems consistently share user IDs and attributes, you can consistently bucket users across different channels, languages, and experiments, even in environments with poor network connectivity.

However, if you add variations or change traffic allocation while an experiment is running, users without user profiles may get rebucketed. For instance, if you reduce the traffic from 50% to 0% and then increase it back to 50%, Optimizely resets the bucketing for that experiment. Additionally, reducing and then increasing traffic allocation could lead to a sample ratio mismatch (SRM). For information, see Optimizely's automatic sample ratio mismatch detection.

Implement a user profile service for consistent bucket assignments

For instructions on configuring a user profile service, see the SDK documentation for your platform:

Android
C#
Go
Java
JavaScript – SDK versions 6.0.0 and later.
JavaScript (Browser) – SDK versions 5.3.5 and earlier.
JavaScript (Node) – SDK versions 5.3.5 and earlier.
PHP
React
React Native
Ruby
Python
Swift