Search
Clear search
Close search
Google apps
Main menu

Activation events

Activate an experiment with a custom event.

Dynamic pages and single page web apps typically load additional data after the page has finished its initial load. Optimize supports these implementations via a feature called Activation events.

In this article:

How it works

Activation Events enables Optimize experiments to work on dynamic pages including dynamic subsections of single page applications. Optimize supports late state activation, re-activation and de-activation of a change list.

Activation Events in Optimize allows you to target experiments to events that you’ve pushed into the dataLayer on your site. An event name can be used sitewide in conjunction with additional Optimize targeting rules to target specific actions.

Activate an experiment on a custom event

Optimize allows you to continuously instrument new experiments by leveraging a combination of events and additional targeting rules without having to repeatedly change your site’s client side code.

The targeting tab of an experiment details page in Optimize.

The targeting tab of an experiment details page provides the option of activating an experiment on a custom event.

When this happens the experiment will not run until a dataLayer event with the provided event name is fired. You may fire such an event at the point that the page is at the correct state, by running the following javascript from the page:

dataLayer.push({'event': 'optimize.activate'});

Once the targeted event is fired, any additional targeting conditions will be evaluated and the experiment will move to active state (change list will be applied) only if all of the conditions are true.

Example

If you have multiple AJAX calls that all need to return before your page is ready for the experiment, you could fire an event after each AJAX call and also include an additional JavaScript targeting rule that checks a certain variable value. The experiment would not fire until the additional JavaScript targeting rule is true and an AJAX call has returned.

Reactivate a change list

It’s possible to configure an experiment so that all of the targeting conditions are fulfilled and the targeted event is fired multiple times.

If you fire the targeted event multiple times and the other targeting conditions are all fulfilled, the change list will be reactivated. When that happens, Optimize will check the page to see if the page has loaded any additional elements that should be changed according to the experiment’s change list. Optimize will update the newly loaded elements accordingly. Existing elements will not be altered.

Example

Consider a page that includes a dynamic shopping cart where a user can click on products to add them to the cart. Then consider an experiment that:

  • Inserts an image after each product in the cart, and...
  • Inserts a global offer message on the top of the body when the user has at least one product in the cart

The page fires the activation event (e.g. shoppingCartChanged) every time that a user adds or removes something from the cart. Both the page condition and the applied changes can be part of the experiment.

In the example above the targeting condition would include: "Are there any products in the cart?"

The first time that the user adds a product, the change list is activated and Optimize will:

  • Add an image after the single product in the cart
  • Add the global offer message to the top of the page

The second time that the user adds a product to the cart, the change list is re-activated and will:

  • Add an image after the second product in the cart

The second time that the user adds a product to the cart, Optimize doesn’t add a second offer message to the page, nor does Optimize add another image after the first product. The only changed element is the newly added product that was not present when the experiment’s change list was applied the first time.

Deactivate a change list

Activation Events can be used to revert an experiment’s change list. For example, in the shopping cart scenario above, we may not want to show an offer code to a user that no longer meets the experiment’s targeting condition. Likewise, many single page web apps share components across multiple sections of the site, but experiment changes may need to be restricted to a single section.

If an event is fired after a given experiment has been activated and the targeting conditions are no longer satisfied, Optimize will revert the previously applied changes associated with the experiment. In this way, the page is put back into the state it was in before the experiment was activated and the change list was applied.

In the example above, removing the last item from the cart means that the global offer message will be also removed.

JavaScript changes can’t be reverted automatically.

Single page applications and virtual pages

Targeting criteria can be used to define virtual pages for single page web apps. The right condition to use is dependent on the site’s underlying framework, but most single page web app developers will find that URL fragments are the easiest option for their sites.

There are cases where web apps do not map a virtual page to a URL fragment. For example, some sites use newsletter signup interstitials that are excellent candidates for A/B testing. These interstitials (and other similar elements) can be experimented on by adding additional targeting conditions to the Optimize experiment. JavaScript variable targeting can be used to check for the existence of specific content or elements.

Deactivation is very useful for single page apps that use CSS Rules to make style changes to components that are reused across multiple pages. The <STYLE> tags of a virtual page will be cleaned up from the <HEAD> when the app transitions to a different virtual page.

Firing activation in a single page application

Reactivating a change list does not require an additional round trip to the Optimize server. As such, a simple and effective approach to Activation Events is to fire an event after anything on the page changes.

For example, an AngularJS app could implement Activation Events in seven lines of code by firing an event after every digest loop.

The following example code snippet fires an event after every digest loop in an AngularJS app:

myapp.run(function($rootScope, $timeout) {
   $rootScope.$watch(function(){
     $timeout(function(){
       dataLayer.push({'event': 'optimize.activate'});
     },0,false);
   })
})
Was this article helpful?
How can we improve it?