This article will help you:
  • Figure out why you aren't seeing conversions for a certain goal
  • Figure out why you're seeing a higher or lower number of conversions than expected
  • Check that you've set your goal tracking correctly

Are you experiencing any of the following issues? Then this article will help you get to the root of the issue:

  • You see no conversions at all for a certain goal on the Results page
  • You see a higher or lower number of conversions than expected for a certain goal

Here’s when this article may not be for you:

  • Your conversions on a goal do not match when compared to another analytics platform. See our article on analytics troubleshooting for that.
  • You don't see any goals tracking at all on the Results page. That is more likely an experiment activation issue.

Want to see how to troubleshoot goals using your browser's developer tools? Watch this short video on goals troubleshooting.

Before you start: check whether your goal is firing

If you've noticed that results aren't coming in for a goal, then first check whether the goal is firing on your page. Follow the instructions in our pre-launch checklist to test your goals:

  1. Optionally, first open Optimizely's Preview Mode to the Events tab and right-click the goal you want to QA. Check whether that goal appears in the log below.
     
  2. In your browser, go to the page you want to check, then open your browser's console (this example uses Google Chrome).
     
  3. Go to the Network tab of the console. Filter by optimizely, as seen below.
     
  4. Trigger your goal on the page, and see if it appears in the network traffic below. It will start with the word event.


     
  5. Click each of the events to investigate them further. You'll see some parameters beginning with x, which are the experiment and variations that you're currently bucketed into. If you need to switch variations, use Optimizely's force parameter technique.
     
  6. You'll also see a parameter beginning with n, which is the goal name. If it's a URL, you're looking at a pageview goal. If it has a different name, you're looking at a click goal or custom event.


     
  7. Don't see your goal in this list? Then it's not firing on the page (or you failed to trigger it). This will help you dig into the troubleshooting issue further.

    If you're more technical, this is what's going on: Every tracking event is an HTTP GET request to Optimizely’s log servers. Each event can be thought of as a URL. The URL’s components are the pieces of information Optimizely needs to understand the event being tracked and where that tracked event should be counted. Learn more about each parameter in our offline conversion article.

1. Check the snippet on the page

Before you begin this troubleshooting process, make sure that the Optimizely Snippet is on your page, as high as possible in the <head> tag, and that there is only one Optimizely Snippet on the page.

Optimizely works best when installed directly in the <head> tag of every page where you would like to track a goal. Having more than one Optimizely Snippet on the page, even it’s for a different project, can create complications.

You can also check your Diagnostic Report to make sure your snippet is installed and your experiment is live.

2. Make sure your experiment is running on the page, and you're bucketed into the variation

Your goals may not be tracking correctly because the experiment isn’t active on the page. Here’s how to check for that:

  1. Make sure that your experiment is in Running status on your Home page.
     
  2. Optimizely provides an easy way for determining whether an experiment is running. Go to the URL where you’re running the experiment, and then open your browser's console.
     
  3. Now, we’ll need to ask Optimizely, “Which experiments are active on this page?“ To do this, examine the Optimizely data object in the next two steps.
     
  4. Type optimizely.activeExperiments into the console. This will return a list of all experiments currently running on the page for you.


     
    1. If you see your current experiment ID, you are bucketed into the experiment. You can find an experiment ID by going to your Home page > Overview > Experiments, then click that experiment and scroll down in the right-hand panel).
    2. If you see an empty array ‘[ ]’ then your experiment isn’t active on the page. See our experiment activation article for more information.
       
  5. Type optimizely.variationNamesMap into the console. This will return a mapping of experiment IDs to variation names for all experiments on the page into which you are currently cookied, both active and inactive.


     
    1. If this returns the “Original” variation for your experiment, then your experiment is running, but you’re simply looking at the Original variation.
    2. Use the force parameter to toggle to another variation, and see whether it appears.
 
Note:

If there are multiple active experiments, make sure they are not colliding (in other words, making different changes to the same element on the page). If there is interference, you can make simultaneous experiments mutually exclusive.

If you see the correct Experiment ID in activeExperiments AND the correct variation name in variationNamesMap, but this hasn’t resolved your issue, continue below by choosing the type of goal that isn’t tracking correctly.

Click Goals

After you have set up your Click Goals by following the steps in this article and they don't fire as expected then the most common reasons that Click Goals do not work are:

  • You are tracking clicks on a redirect page, or a page outside of your experiment’s URL Targeting conditions
  • The wrong selector is tracked
  • The element is loaded only after Optimizely has run
  • Dynamic content overwrites the click goal
  • You're tracking clicks on an element within an iFrame
  • The selectors for your click goal aren't defined correctly

You are tracking clicks on a redirect page, or a page outside of your experiment’s URL Targeting conditions

This will apply to you if:

  • You’re tracking clicks in a redirect experiment
  • You’re tracking clicks on a different page than the one you’re using for your experiment’s URL Targeting (for example, you’re running an experiment on your homepage but tracking clicks in your shopping cart)

If the page you are redirecting to falls outside the URL Targeting of the Optimizely experiment, you will need to manually specify that your click goal should be tracked on this page. See details about this in our article on goal targeting.

Tracking the wrong selector

This will apply to you if:

  • You click Options > Element Tracking in the Editor, and you don’t see the correct goals highlighted
  • You’re using dynamic selectors (or a click-tracking service that uses dynamic IDs)

Optimizely uses CSS selectors to identify which element should be tracked. When you click Options > Element Tracking in the Editor, you will see all tracked elements highlighted in red. Switch between each variation to verify that the correct elements are being tracked. To manually check which elements are being tracked on your page, see our article on manually finding selectors.

If you do not use IDs/classes on your website and you know that your site implements dynamic IDs, the risk is increased that the wrong selector may be tracked. If you are using dynamic selectors, use the following workaround to remove them temporarily while working in the Editor. For more information, see our article on dynamic selectors.

/* _optimizely_evaluate=editor_only */
$('[id^="selector"]').each(function(){
   $(this).attr("id","");
});
/* _optimizely_evaluate=end_editor_only */
 
Note:

In the above code, change selector to a string of characters that your dynamic IDs have in common. For example, if all your IDs begin with 'abc', change selector to 'abc'.

The element is loaded only after Optimizely has run

This will apply to you if:

  • You’re tracking clicks on an element that appears after a visitor takes a certain action
  • You’re tracking clicks on a modal or pop-up

As our article on Optimizely's order of execution shows, Optimizely will execute any remaining code upon the “document ready” event, which means the moment at which the full HTML of your page has been parsed by your browser. This condition is sometimes called "dom ready." 

If the element you are tracking is loaded in after document ready, Optimizely may execute the code to attach your click goal before the element is available. This may be the case for elements such as modals or pop-ups, which are only triggered after a visitor takes a certain action.

If this is the case, we recommend switching to a custom event goal, which will fire correctly even if the element to be tracked is loaded in dynamically.

Unsure if your element is available at document ready? You can use this code in your variation code or Experiment Javascript to print out whether the element is available or not at "dom ready":

$(document).ready(function () {
   if ($('selector').length > 0) {
       console.log('Element available');
   } else {
       console.log('Element not available');
   }
});
 
Note:

Replace “selector” with the ID or class of the element you’re looking for.

Dynamic content overwrites the click goal

Some websites that load in dynamic content can end up overwriting a click goal that was previously tied to an element. If this turns out to be the case, try implementing a custom event goal rather than a click goal.

You’re tracking clicks on an element within an iFrame

Tracking clicks on an iFrame is generally impossible due to cross-domain tracking limitations. However, if the iFramed element is hosted on the same domain where you are running the experiment, you can try the following:

  • Set up your goal so that it will fire on the iFramed page as well as the top-level page
  • Place the Optimizely snippet on the iFramed page

If you’re trying to track clicks on social media buttons, such as a Facebook Like button or a Twitter Follow button, please follow the method outlined in this article instead.

The selectors for your click goal aren't defined correctly

If you open up your click goal and look under Advanced > Selectors, you will see the CSS Selectors which are being tracked for this goal.

  • CSS class selectors should be preceded by a period (for example: .myClass) and CSS IDs should be preceded by a hash (for example: #myID).
  • Multiple selectors should be separated by a comma.
  • If you are formatting your selector as a jQuery selector (for example: $(‘.myElement’), remove the dollar sign, brackets and quotation marks when inputting this in the goal Selector field.

Pageview goals

After you have set up your Pageview Goals by following the steps in this article and they don't fire as expected then the most common reasons that Pageview Goals do not work are:

  • The URL for the pageview goal doesn’t match the exact set of pages you want to track
  • The URL being tracked isn’t reachable
  • The pageview goal isn’t on the same domain as the experiment

The URL for the pageview goal doesn’t match the exact set of pages you want to track

Check using our URL Match Validator to check whether the goal page is a match for the pageview goal. To do this:

  1. Go to the URL where you wish the pageview goal to fire.
  2. Copy the URL, and paste it into the URL Match Validator. Matching URLs will show up as green; non-matching URLs will show up as red.

If the URL for the page you want to track shows up as red, you’ll need to change the URL or match type for the goal.

The URL being tracked isn’t reachable

If visitors cannot reach a URL for any reason, no conversions will be tracked. This may occur is a site is temporarily unavailable or is gated.

This may also occur if your pageview goal is placed on a URL which triggers a redirect and where visitors may be redirected away from the page before the goal can fire.

The pageview goal isn't on the same domain as the experiment

If the page you’re trying to track is on a separate domain than the domain on which the experiment is running, you may run into issues with cross-domain tracking. Please take a look at our article on cross-domain tracking to resolve these.

Custom event goals

For implementation advice, check our custom event goals support article.

Custom event goals can be modified to fire under any number of conditions. A common cause of issues with custom event goals is that:

  • The custom event goal code is not applied to the page
  • The conditions to fire the goal are not correctly fulfilled

The custom event goal code is not applied to the page

Custom event goals require custom code to be added to the pages where you’d like the goal to fire. There are many ways to install this code, such as by hard-coding it to the page, injecting the code via tag manager, or including the code in the Experiment JavaScript of your experiment.

The conditions to fire the goal are not correctly fulfilled

A handy way of finding out which condition is not evaluating as true is to add one or more console logs to your custom event goal code. Let’s take the following custom event goal as an example:

$("#ButtonID").bind("mousedown", function () {
   window.optimizely.push(["trackEvent", "eventName"]);
});

If we add in a console log (line 2) to the custom event goal code, we can look at our browser console to see if the console log has been printed in order check to see whether the code is triggered:

$("#ButtonID").bind("mousedown", function () {
   console.log(‘button clicked’);
   window.optimizely.push(["trackEvent", "eventName"]);
});

If you have multiple conditional clauses in your custom event goal, try adding a console log at each step, like so:

$("#ButtonID").bind("mousedown", function () {
   console.log(‘button clicked’);
   if (someCondition === true) {
     console.log(‘condition true!’);
     window.optimizely.push(["trackEvent", "eventName"]);
   }
});

If you do not the console log for a certain step printed out to the console, your code may not be evaluating as expected.

Revenue goals

To find out how to set up the revenue tracking goal, please see our support article on revenue tracking goals. As a quick refresher, the revenue goal code looks like this:

window.optimizely = window.optimizely || [];
window.optimizely.push(['trackEvent', 'eventName', {'revenue': valueInCents}]);

Common issues with the revenue tracking goal are:

  • The variable which stores the order price (in the above example, valueInCents) is defined below the revenue goal code on the page
  • The revenue goal code fires multiple times per order instead of just once, resulting in duplicate conversions
  • Visitors are taken to a different domain during the payment flow
  • Multiple currencies are converted incorrectly

The variable which stores the order price is defined *below* the revenue goal code

In the revenue goal code, ‘valueInCents’ represents the order total value in cents. For Optimizely to correctly pass this value onto the Results page, the price of the order must be defined on your site prior to the revenue goal code.

For example, if you’re storing the value of an order in cents in a variable called “price,” you’d need to modify the code as follows:

window.optimizely = window.optimizely || [];
window.optimizely.push(['trackEvent', 'eventName', {'revenue': price}]);

Make sure that the price variable is defined prior to the revenue goal code, and that the price variable is an integer rather than a string. Otherwise, Optimizely may pass an undefined value and no revenue values will appear on the Results page.

The revenue goal code fires multiple times per order instead of just once, resulting in duplicate conversions

Unlike all other goal types, which de-duplicate multiple conversions by the same visitor, the revenue goal is cumulative. This can result in duplicate orders being passed through to Optimizely if the goal is not correctly implemented.

Make sure that your revenue goal is implemented in such a way that it can only fire once for every successfully placed order. You might choose to do this by looking at successful form submissions or by verifying the order number, but there are many ways to achieve this.

See our Revenue implementation article for tips on how to remove large outlier conversions, which may look similar to this spike on your Results page:

If you’ve already seen an abnormal spike in revenue on the results page (likely caused by a large outlier conversion), you can fix this by sending Optimizely an offline conversion event for a negative dollar amount. This will essentially tell Optimizely to subtract an amount from the Results page.

If you don’t know how to pass an offline conversion event, work with your technical team. In this example, we’ll show you how the offline event would be set up in a REST client like Postman. Send an API call containing the relevant details for the experiment and variation where you want to remove the outlier:

  • Project ID (a)
  • Experiment and variation IDs (x)
  • Event name, such as “cancel_purchase” (n)
  • Negative revenue value in cents (v)

Visitors are taken to a different domain during the payment flow

If you are seeing lower revenue values than expected, make sure that visitors who choose certain payment types (such as PayPal) are not taken away from your site during the payment flow.

Due to cross-domain tracking restrictions, conversions on a separate domain would not fire consistently. If you are unable to prevent visitors from leaving your site, you can circumvent this issue by making sure they are returned to an order confirmation page on your site once the payment is complete. You can then place the revenue goal on this confirmation page.

Multiple currencies are not being converted correctly

Do you offer multi-currency sales and are you seeing unusual numbers across all variations of your experiment? If so, check that you are either tracking one single currency or that your logic to convert currencies is correct.