Optimizely Data in Adobe Analytics

Question

Hi Team,

We are using Optimizely as a CRO Tool but we have Adobe Analytics implemented on the website for tracking purpose.

We have one CRO experiment and want to send its Original and Variant data in Adobe Analytics. I am using below code in Original and variant so that I can use the custom link item to identify the user behaviour of both original and variant in Adobe Analytics.

if (window.s != undefined && typeof s.tl === "function") {

s.tl(true, 'o', 'defaultOffersLayout');

} else {

console.warn('Adobe Analytics is not initialized: window.s is undefined');

}

So wanted to ask if I use this code on the load of original and variant experience, would be there any issue since custom links are used for click tracking but here we are using them for page load.

Jennifer_Dungan · Accepted Answer

Technically no, it shouldn't hurt anything... "Click Tracking" is more akin to "Custom Action" tracking now, the naming just hasn't changed to reflect that....This is however preferable to tracking each test as a page view on top of your existing page view (that would cause inflation in your data)

However, you might find this starts to inflate your server call (sending all these additional tracking requests on your page). Especially if you have multiple tests running at the same time... you would have 1 PV tracking request, and additional s.tl calls for each active test.

We also use third-party A/B Testing solutions, we used to use Visual Website Optimizer and now we use WebTrends Optimize... and we also collect data into Adobe Analytics to support our testing...

We do things a little out of the box... but here is how we track our A/B tests....

Since we have a potential to have multiple tests running on a page at any given time, and there is information associated to each test (identifiers and which variant, etc), we actually use our s.products variable for multiple purposes beyond just our payment flows.... this way we can leverage Merchandising eVars and events for different uses.

So the products has the following syntax:

category;product id;quantity;price;events;evars

So we use category to identify "ab-test"
product id to identify the test (using the test alias)
we completely ignore quantity and price which have no relevance in this context
then we have an event for "test impression" (used on our PV call) and an event for Goal (used when the test goal is complete)
Finally, we have multiple merchandising eVars to add addition data about the test (Project and Test Ids; Variant Identification like "control", "variant1", "variant2", etc; and even short descriptions of what the variant is doing)

When a page loads with a test enabled, the product string is populated with the test information and the impression event... when the goal is reached, the products string is used to pass the goal complete event for that specific test.

This solution is not without its challenges, since the s.products variable becomes more complex to use... but it reduces server calls by attaching all tests running in parallel to our existing server calls without the data for each test corrupting one another.

Vinay_Chauhan · Answer

Hi @cropro

You're right to be cautious about using s.tl() on page load. Technically, it will work, you can use it to capture which variant a user saw but it does count as a billable server call, just likes.tl(), and if multiple experiments run at once, you could quickly inflate your server call volume.

While s.tl() is typically used for interactions like clicks, Adobe doesn’t restrict how you use it. That said, firing custom links on load (especially across multiple experiments) can clutter your reporting and drive up costs if not managed carefully.

A more scalable approach is to pass experiment info (test name, variant, etc.) into an eVar or prop on the mains.tl() pageview call. That way, no extra hits are generated, and you still get a clean way to segment user behavior by test variant.

If you want to go one step further, especially with multiple experiments running at once, consider leveraging the s.products string with merchandising eVars. This lets you bundle all test data into a single hit using structured logic. It's more complex to implement, but very efficient long-term.

So short answer: yes, your approach works, but look out for unnecessary server call volume. If possible, push variant data into your main pageview beacon instead, it'll keep your data clean and your costs lower.

Hope that helps!

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded