- Optimizely Web Experimentation
- Optimizely Performance Edge
- Identify visitors using your own IDs (BYOID), rather than using the IDs Optimizely automatically provides
You can configure Optimizely to use visitor IDs that you provide, rather than using the cookie that Optimizely automatically generates for Web Experimentation and Performance Edge projects. For more information on the built-in visitor identification, see Cookies and localStorage in the Optimizely snippet.
Why bring your own visitor ID (BYOID)?
Bringing your own visitor ID (BYOID) lets you:
- Have more fine-grained control over your ID persistence strategy (for example, as part of your mitigation of Intelligent Tracking Prevention. See also Intelligent Tracking Prevention and Optimizely).
- Reduce cookie bloat in the browser by consolidating identifiers.
- If you use both Optimizely Web and Optimizely Full Stack, you can supply a known ID so you can use the same identifier across both Web and Full Stack.
- Avoid complicated joins between Optimizely data exports and your own first-party data source.
Configure visitor IDs per snippet
To ensure granular control over visitor identifiers, you configure visitor IDs on a per-snippet basis. To enable using your own visitor ID, rather than using the default
optimizelyEndUserId, for a given snippet:
1. In your project, navigate to Settings. On the Implementation tab, select your snippet.
2. In the Visitor ID section, select the Identifier Type from the dropdown and the Identifier Name.
You can select from the following options for identifier type:
|Identifier Type||Web||Performance Edge||Comment|
You can select an existing cookie as a visitor ID.
For example, if you have a unique Google Analytics cookie identifier, you can choose Cookie for the identifier type from the dropdown menu, with identifier name (cookie name), _ga.
Note: If you implement Performance Edge using the CDN proxy method, ensure you forward the selected cookie in requests to Optimizely's Edge Decider.
|Page Query Parameter||✔||✔||
You can select a query parameter as a visitor ID.
For example, if you pass a visitor's unique identifier in a query parameter as part of a URL, as in: www.yourwebsite.com/?visitorId=myuniqueid, you can select Page Query Parameter from the identifier type dropdown, with identifier name (query parameter name), visitorId.
You can select a LocalStorage key as a visitor ID.
For example, if you store a unique visitor value to the localStorage key visitorId, you can choose Local Storage from the identifier type dropdown, with identifier name (localStorage key), visitorId.
For example, if you store a unique visitor value to the variable
When you save the snippet with a specified identifier type and name, subsequent activations of this snippet result in the following:
optimizelyEndUserIdis NOT created on snippet activation.
- Any data in
localStorageunder the previously set unique identifier is erased. For example, if an
optimizelyEndUserIdonce identified a visitor, the initialization of the snippet with a new identifier type and value erases any previously stored data. All events and bucketing use the unique identifier.
- The snippet stops executing if Optimizely cannot locate the identifier you select in your snippet settings. This means that visitors aren't activated for any experiments or trigger any Optimizely instrumented events.
Optimizely does not stop or pause experiments while you configure this setting. Changing the visitor ID settings while experiments are still running may inflate visitor counts for those experiments and/or cause a visitor to see a different experience than they did previously. We recommend pausing all experiments before changing visitor ID settings.
What kind of ID should I choose?
Optimizely recommends selecting a static ID such as the same ID you primarily use to conduct data analysis, typically that of your first-party analytics provider (for example, a Google Analytics ID or Segment ID). Doing so simplifies your downstream data analysis by avoiding complicated joins with your own proprietary data set. Changing what you use as the ID often may cause strange behavior in your experiment data.
Note that regardless of which ID you choose, you must ensure that the ID is set and available for visitors before the Optimizely snippet runs.
What happens if Optimizely cannot locate my specified ID?
The snippet stops executing if Optimizely cannot locate the identifier you selected in your snippet settings. This means that visitors aren't activated for any experiments or trigger any Optimizely instrumented events.
To avoid this, we recommend ensuring that IDs are set and available before Optimizely running. For example, if you rely on another cookie, we recommend creating your cookies at the CDN level instead of via document. cookie to ensure availability. This approach is also recommended given Safari ITP, which limits the lifetime of all client-side generated cookies to 7 days.
Is BYOID bucketing deterministic?
Yes. The same variant is guaranteed for the same user ID (in the same project) across devices/browsers. For example, a user visiting your site on desktop is assigned ID=123 and bucketed into variation A. Then that same user visits your site on mobile, where BYOID also sets ID=123 for that user. This user will still see variation A on mobile, just as they did on desktop.
Will you be deprecating
We anticipate that most customers will move away from
optimizelyEndUserId over time given the benefits of post-experiment analysis and the constraints of more restrictive browser changes; however, we don't plan to deprecate
optimizelyEndUserId in the immediate future.
Is creating your own visitor IDs in Beta?
No, it is fully released on our Optimizely Web Experimentation and Optimizely Performance Edge products.
Can I use the default
optimizelyEndUserId for some projects and another identifier type/name for others?
Yes, visitor ID settings are snippet-specific. You can configure a different identifier type/name per snippet if needed.
What if I want to change my IDs often?
We recommend that you select an ID for BYOID that will be somewhat static and unchanging. Changing the ID often can cause errors or other discrepancies in your experimentation data.
Does enabling this setting affect page performance when using Web or Performance Edge?
No, performance testing indicates that enabling an alternate ID in Web/performance Edge does not significantly impact page speed/performance.
What happens to existing behavioral targeting information that I have pre-migration?
When you configure a new ID, Optimizely creates a new visitor profile for each visitor. This means that you will not be able to access store behavioral/visitor profile data collected under the previously set
How does this migration affect DCP usage?
The Optimizely data source is mapped to
optimizelyEndUserId; we sync the
optimizelyEndUserId to the IDs designated in each uploaded data source. When you configure your snippet to look for another ID, you can expect the following, depending on your DCP
- If DCP
customerIdis the same as the newly provided identifier and is available on each page load: No changes are needed. Everything should operate as expected. The first-party user ID will be sent to the DCP backend on any given page load.
- If the DCP
customerIddiffers from the newly provided identifier but is generally available on every page load, everything should work as expected. The DCP
customerIdwill be sent to the DCP backend on any given page load.
- If the DCP
customerIdis different from the newly provided identifier, it is not available on every page load. The customer thus relies on DCP's "aliasing" feature: It may be difficult to target previously-seen visitors after switching to a new identifier (since the DCP
customerIdwas aliased to an
optimizelyEndUserIdand not to the new ID). Talk to your Optimizely account contact for help.
How will this affect any list attributes I am currently using?
List attributes should not be an issue unless your attributes are targeting extant
How will this affect my existing analytics integrations?
The migration should not affect existing analytics integrations. Current integrations attach experiment and variation information to events. These can continue to exist even with the replacement of the
optimizelyEndUserID. In fact, this should simplify custom integration if you currently pass through the
optimizelyEndUserId as a property/trait/attribute in your existing custom analytics integrations to help join Optimizely results export data to your internal data. You should remove that code with this feature since a common key will already be available for those joins.
How will this affect my existing audience integrations?
There shouldn’t be any existing integration code that would be dependent on the existence of any particular visitor identity.
How will this affect data exports?
This migration should not affect exports. Once a customer turns on this feature, visitor ID values will reflect the customer passed user id and not the previous Optimizely-generated
optimizelyEndUserId. Your data export during this transitional period may contain both references to the
optimizelyEndUserId and the new identifier because of caching behavior.
What happens if I migrate my snippet to use a different Id while experiments are still running?
If migration happens while experiments are still running, return visitors who were previously identified with their randomly assigned
optimizelyEndUserId will be identified with the newly designated identifier. This will lead to visitor count inflation in your results. We recommend that all experiments are paused before changing the visitor ID settings.