Handle user ids
Describes what User IDs are and how to handle them in your application for Optimizely Feature Experimentation.
User IDs are used to identify the participants in your experiments or flag deliveries uniquely. Supply any string you want for user IDs, depending on your test design. UserIDs ensure that a single user is not randomly re-bucketed every time they see your experiment. In other words: a user always gets the same flag variation or flag on/off experience.
For example, if you are running experiments on anonymous users, you can use a first-party cookie or device ID to identify each participant. If you're running 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 are running 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.
Tips for using user IDs:
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, we recommend 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.
Quickly conduct a vendor bake-off or test performance by using a request ID as a user ID. For an example of how Optimizely Feature Experimentation implements this approach, see Using experimentation to measure and validate backend performance improvements.
iOS 14 IDFA & Disclosure Updates
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.
We recommend reviewing Apple's full requirements and guidance, other identifier options and your data use in detail to determine the correct path forward for your application and usage.
Users and billing
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 What are monthly active users.
Updated about 2 months ago