Troubleshooting

Logging

You can tell Optimizely to output its log to the browser's console log by using the query parameter optimizely_log={level}. For example, you can follow the high-level execution by adding ?optimizely_log=info. The following levels are supported, and the default is off:

Campaign Activation

You can use the logging output to see which campaigns are activating for a given a visitor, and which experience they will see.

First, enable logging by adding ?optimizely_log=info to a URL on your site. Then, open your browser's console to see the logging output. To make the log more readable, it may help to filter within the console log to "Optly /" so that other messages are hidden.

The first few lines cover the initialization of the Optimizely client, including data like the active campaigns, events, and pages. You can use this section to confirm that the right data is being compiled into the snippet. Some of the terminology is slightly different from the user interface:

To debug a specific campaign, you can search within the console (Cmd-F) for that campaign's ID. You can find the ID in the URL of the Optimizely interface. A campaign with the URL https://app.optimizely.com/p13n/3563611614/layers/3558430129 has the ID 3558430129. Searching for this ID will show all log events related to that campaign. For example:

In this example, the output is telling us that the visitor did not match any of the audiences in the campaign. Therefore, they weren't eligible for any experiences and no changes were applied.

Now let's add the visitor to a campaign audience to apply a change:

In this example, the output tells us that the visitor was in the Campaign "Homepage Offers". Let's take a closer look at some of the entries in the log:

If we click on the Objects in the log to inspect them, we can see some of the details about the "decision ticket" (the information Optimizely uses in order to make a decision of which experience to show, if any) on the left of the arrow "->" and the "decision" (the selected experiment/variation, if any, and whether the visitor is in the layer holdback) on the right hand side. In particular note the "audienceIds" property of the decision ticket which shows the IDs of the audiences the visitor was in at the time of the decision (in this case "4055203664").

Next we can see that Optimizely created a log event to track the decision. By inspecting the log event we can see that it has properties "decisionTicket" and "decision" corresponding to the objects we inspected above, as well as information about the client version, a guid and timestamp to track the event in Optimizely's logs, and others (event properties subject to change).

In addition to recording and tracking the decision, Optimizely applies the actions (changes) corresponding to the current view. By clicking on the Object to inspect, we can see that the action is associated with the current campaign (layerId) and selected experiment/variation (from the decision), and consists of a "changeSet" (list of changes), each of which describes a change to apply. The change detail above shows that the first change in the set is an "attribute" change which changes the "html" (innerHTML) of the ".hero__title" element to the string "Stylish new looks for p13n-ers". If there is an error applying this change, it will be logged here as well.

Events and Tags

The process to debug event tracking and visual tags differs depending on the logging endpoint used by your snippet. Learn more about how to determine which logging endpoint your snippet has been configured to use.

Snippets using the /events endpoint

To debug event tracking and visual tags, you can use the network tab to observe requests to Optimizely's log endpoint. For example, in Google Chrome, you can open the Developer Tools and then reload the page. When you click on the Network tab, you'll see all the network requests on that page. You can filter these requests to show only those made by Optimizely for tracking purposes by filtering to logx. When you trigger an event, e.g. by clicking a button, you'll see it fire here. For example:

In this example, we've triggered the Add to Cart button on the Product Detail Page (contained in the array of events included in this batch request). The key shows the API name of the event.

The tags object contains tag values that were captured at the time the event was triggered. This object is contained within each event object, and tag values can vary between the events in the request. In this case, we can see tags picking up the product's category, subcategory, and price. Finally, the decisions array shows which decisions have been made so far for the visitor this session, and which campaigns the event will be attributed to.

For more information on the structure of this request, please see the Event API documentation.

Snippets using the /event endpoint

To debug event tracking and visual tags, you can use the network tab to observe requests to Optimizely's log endpoint. For example, in Google Chrome, you can open the Developer Tools and then reload the page. When you click on the Network tab, you'll see all the network requests on that page. You can filter these requests to show only those made by Optimizely for tracking purposes by filtering to logx. When you trigger an event, e.g. by clicking a button, you'll see it fire here. For example:

In this example, we've triggered the Add to Cart button on the Product Detail Page. The eventName shows the API name of the event, and the type corresponds to the category in the Optimizely interface. For pages, eventType = 'view-activated' and the eventName will be the ID of the page.

The eventFeatures show tags that were captured on the page. In this case, we can see tags picking up the product's category, subcategory, and price. eventMetrics show tags that are used as metrics on the results page, like revenue for a custom event. Finally, the layerStates show which campaigns the event will be attributed to.