- Optimizely Web Experimentation
This topic describes how to:
Check that events in a live experiment or campaign fire when you expect.
This article is relevant for Optimizely Web Experimentation projects which have been configured to use
/events logging endpoint. Follow these instructions to identify the logging endpoint used by your snippet.
The network panel is a log in your browser that records the events that occur as you interact with a page. When you trigger an event in Optimizely Web Experimentation, the event is queued and sent in a batch with other events every second for the first 10 seconds of the page load. You can see these batches of events in the network traffic.
Network traffic information is useful when:
You see few or no metrics on your Results page and want to check whether events are firing.
You want to test a custom event that requires the visitor to take an action beyond just a click (like a revenue event).
This article shows you how to use the console to check whether an event is firing in a live experiment or campaign.
Want to check event firing in a draft experiment or campaign? Use the Preview tool.
An origin is a combination of a specific hostname, protocol, and port on your site. By default, events you track in Optimizely Web Experimentation 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:
http://shop.example.com(different security protocol)
Before you can use Optimizely Web Experimentation to track events across domains, you will have to enable the feature. Check out our article on enabling cross-origin targeting to track events across domains to learn more.
Confirm your events are firing
To determine whether your events are firing in a live experiment or campaign, use your browser’s console:
- Right-click on the page. From the dropdown menu, select Inspect in Chrome or Inspect Element in Firefox.
- Select the Network tab.
- Click the filter icon.
- Select XHR.
- Trigger the event you'd like to test. See how to quickly access the developer console for more details.
- In the Filter field, enter events to filter your results.
- Look for a Method of POST with a status of 204. This means that Optimizely Web Experimentation has logged a collection of events in its counting infrastructure.
- Select one of these POST events.
- Click the Headers tab and scroll to the Request Payload section.
- Click Request Payload to expand it to see more detail.
A snapshot contains arrays of decisions and events triggered for the experiment. Decisions and events are objects. The decision array is a list of bucketing determinations made for the visitor (that is, which experiments and variations the visitor was exposed to) for the duration of the session thus far. The event array is a collection of all events that will be logged in a given batch request. Event objects may contain one or all of the following keys:
key – For click and custom events, the api_name is returned. For pageview events, the page ID is returned.
timestamp – Timestamp at which the event was generated, time since the epoch in milliseconds.
uuid – A unique identifier for this event. This may be generated by the client with a typical UUID-generating method. Used by Optimizely Web Experimentation's backend to de-duplicate requests that are accidentally or erroneously replayed.
tags – An object containing all event tags attached to the event.
entity_id – The id of the entity corresponding to this event.