Optimizely Data in Adobe Analytics

[croPro]

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 solution]

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.

[croPro]

Thank you @Jennifer_Dungan for this info. I'll check implementation on s.products.

also wanted to ask does s.tl calls (non page view) also increases the server calls ? I had this impression that only s.t calls does increase

[Jennifer_Dungan]

Every request is considered a billable server call... s.t increments your page views, s.tl increments your occurrences / page events... but they are both requests and definitely count towards server calls on your contract.

This is one of the reasons that Adobe create Activity Map, to pass information about clicks on the next page view, so that people could reduce their server call usage (combine it with the page view, instead of trying to track every single link having a separate s.tl tracking beacon).

[Vinay_Chauhan]

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!