This article will help you:
  • Write custom code in Optimizely Personalization
  • Understand timing differences for custom code in A/B Testing versus Personalization
  • Implement behavioral targeting across different origins (subdomains or protocols) of your site
 
Note:

Please note that this article is about custom code in Optimizely Personalization. If you'd like to learn about the Code Editor in Optimizely A/B Testing, check out this resource.

Custom code

In Optimizely Testing, every change you make in the Visual Editor turns immediately into jQuery in the Edit Code box. For example, if you change a headline’s text using the Visual Editor, you’ll see code like $(‘h1’).text(‘New Headline’); in the Edit Code box. In Personalization, we’ve changed this behavior.

Now, the visual changes that you make aren’t instantly translated to code. Instead, we store the full structure of what you change in the Visual Editor and simply list out a summary of those changes in the left sidebar. These changes will NOT show up in the custom code box the way they did before.

However, you can still add your own jQuery. The only big difference is timing. In Optimizely Testing, we would delay running code until the element you changed was ready on the page. However, we received many requests to give developers more control over timing. So in Personalization, custom code executes immediately, and you can also write code to specify when things should run.

Please note this means that some code that works in Optimizely Testing does not work in Personalization. For example, the following code won't work in Personalization, because the body element doesn't exist at the time when the code runs (and remember, custom code runs immediately): 

$(‘body’).css(‘background-color’, ‘red’);


To delay running the code until the whole page is loaded, you can use jQuery’s document.ready function:

$(document).ready(function() { 
$(‘body’).css(‘background-color’, ‘red’);
}); 

Cross-origin behavioral targeting

An “origin” is a combination of a specific hostname, protocol, and port on your site. By default, events that you track in Optimizely can only be used to target changes on the same origin. So when the snippet is running on https://shop.example.com, it can access events that were generated on https://shop.example.com, but it cannot access events that were generated on:

What if you want to run an experiment on the secure origin https://shop.example.com, targeting browsing behavior on the unsecure origin http://shop.example.com? Or what if you want to target based on reading activity on http://blog.example.com?  

You can enable this by navigating to Personalization Settings and clicking on the Implementation tab. There, you can specify origins whose events Optimizely is allowed to pool together.  There are several ways to specify origins:

You can find more information in this article on URL match types.

Note:

Want to learn more about origins and the "same-origin policy"? See this Wikipedia article for more examples.

Events are shared asynchronously across origins, so events from http://blog.example.com are not available when Optimizely first begins to execute on https://shop.example.com.  As a result, behavioral targeting may not succeed until the second page load on https://shop.example.com.

Cross-domain behavioral targeting

Events are targetable across origins only for the current Optimizely User ID, which is stored in the optimizelyEndUserId cookie. Since browsers prevent sharing cookies across domains (e.g. example.com, anotherexample.com) and across top-level domains (e.g. example.com, example.net), Optimizely is unable to set consistent user IDs across such domains.

You will need to manually sync the optimizelyEndUserId cookie across domains, using other means, in order for cross-domain targeting to work.