Check event firing in a live experiment or campaign
- Optimizely Web Experimentation
Note
This article is relevant for Optimizely Web Experimentation projects that are configured to use /events logging endpoint, and shows how to use the console to check whether an event is firing in a live experiment or campaign.
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).
Note
Want to check event firing in a draft experiment or campaign? See Preview and publish your experiment.
Cross-origin settings
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 be used only 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 (because of a different security protocol) nor https://example.com (which has a different subdomain).
Note
Before you can use Optimizely Web Experimentation to track events across domains, enable the feature. See Cross-origin tracking.
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 and select Inspect in Chrome (or Inspect Element in Firefox) from the drop-down menu,.
- Select the Network tab.
- Click Filter (icon).
- Select XHR.
- Trigger the event you want to test. See Open the developer console.
- 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 the 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 pageId 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.