User IDs are used to uniquely identify the participants in your experiments or flag deliveries. Supply any string you want for user IDs, depending on your test design. UserIDs ensure a single user is not randomly re-bucketed whenever they see your experiment. In other words, a user gets the same flag variation or flag on or off experience.
For example, if you run experiments on anonymous users, you can use a first-party cookie or device ID to identify each participant. If you run experiments on known users, you can use a universal user identifier (UUID) to identify each participant. If you are using UUIDs, you can run tests that span multiple devices or applications and ensure that users have a consistent treatment.
User IDs do not necessarily need to correspond to individual users. If you run tests in a business application, you may want to pass account IDs to the SDK to ensure that every user in a given account has the same treatment. Alternatively, you can use bucketing IDs to ensure these users get a consistent experience.
Ensure user IDs are unique – User IDs must be unique among the population you are using for tests. Optimizely Feature Experimentation buckets users and provides test metrics based on the user IDs that you provide.
Anonymize user IDs – The user IDs you provide are sent to Optimizely Feature Experimentation servers exactly as you provide them. You are responsible for anonymizing any personally identifiable data such as email addresses in accordance with your company's policies.
Use IDs from third-party platforms – If you are measuring the impact of your tests in a third-party analytics platform, Optimizely recommends leveraging the same user ID from that platform. This helps ensure data consistency and makes it easier to reconcile events between systems.
Use one namespace per project – Optimizely Feature Experimentation generally assumes a single namespace of user IDs for each project. If you are using multiple different conventions for user IDs in a single project (for example, anonymous visitor IDs for some tests and UUIDs for others), Optimizely will be unable to enforce rules such as mutual exclusivity between tests.
Use either logged-out or logged-in IDs – Optimizely Feature Experimentation does not currently provide a mechanism to alias logged-out IDs with logged-in IDs. If you are running tests that span both logged-out and logged-in states (for example, test on a signup funnel and track conversions after the user has logged in), you must persist logged-out IDs for the lifetime of the test.
Use a request ID as a user ID – If you are conducting a vendor bake-off or testing backend performance, Optimizely recommends using the request ID as the user ID. For an example of how Optimizely Feature Experimentation implements this approach, see Using experimentation to measure and validate backend performance improvements.
Optimizely Feature Experimentation SDKs do not access any user data or identifiers that are not explicitly passed in via instrumented API calls.
As a result, we do not have any direct dependency on SDK changes planned to accommodate Apple's upcoming changes to its privacy disclosure and opt-in policy related to their ID for Advertisers (IDFA).
Optimizely Feature Experimentation does not link user data with third-party data for advertising or advertising measurement purposes or share data with data brokers.
Starting September 2020, Optimizely Feature Experimentation offers monthly active users MAU pricing as an alternative to impressions pricing. This plan includes a number of MAUs whose unique user IDs appear in calls to Optimizely Feature Experimentation SDKs in a given month. Optimizely counts a monthly active user each time one of the following occurs for a unique user ID:
- When a Decide method is called, and a decision event (aka impression) is triggered
- When the Track Event method is called, and a conversion event is triggered
The MAU count includes unique anonymous IDs. If you use both Optimizely Web Experimentation and Optimizely Feature Experimentation, you can override anonymous Optimizely Web Experimentation user IDs with known Feature Experimentation user IDs to avoid overcounting. For more information, see Bring your own ID.
Users are counted even if they receive a disabled flag as a result of a Decide method because a decision event was still sent.
For more information, see the end user documentation on Monthly active users (MAUs).
Updated 2 days ago