StumbleUpon Help Center

Tracking Discrepancies


Recommended Solution

Issue #1 – Default Third-Party Cookies Policy in Internet Explorer

Issue #2 – Same Origin Policy

Other Best Practices


This is a resource for those advertisers who are seeing unusually large discrepancies in their third-party reporting as compared to Paid Discovery’s statistics reporting. Discrepancies around 10-15% are par for the course when it comes to tracking on the Internet, as users are always adjusting their browser settings to block cookies or scripts, or may be using various plugins to opt out of being tracked. Many analytics packages also have difficulty recording all mobile traffic properly. If you are noticing large discrepancies between your Paid Discovery dashboard and analytics package as compared to other things you track, here are some resources to help you troubleshoot and resolve the issue.


Before you start troubleshooting, it is important to understand how StumbleUpon users arrive at your page. The traffic that we send to your site is different than the traffic you might get from other sources. A large and growing segment of the StumbleUpon users that land on your page are using our web toolbar, which embeds your page into an iframe that is hosted by Your analytics implementation may encounter technical issues with tracking through an iframe which you can mitigate by following the fixes listed below.


Recommended Solution

The best thing you can do to have more StumbleUpon traffic recorded in your analytics platform is to ensure that the tracking code is located at the very top of the page. By placing the tracking JavaScript code in the first line of your <head>, the analytics is allowed to run before any other code on the page can interfere. You should include this tracking code provided by the vendor as-is and inline with no script "src" attribute. It is also best to use asynchronous tracking so that overall the page load time is not slowed.


This should be the quickest and most effective way to close the discrepancy gap. If the discrepancy persists after implementing this fix, please see the two additional solutions listed below.


Issue #1 – Default Third-Party Cookies Policy in Internet Explorer

Internet Explorer (IE) treats your page as a “third party” page since your domain is different from the hosting domain, This is the expected behavior of IE, which is meant to protect users. You may find “Privacy in Internet Explorer” helpful to understand the concept in more detail. In this case, IE simply rejects any third-party cookies (like those from Google Analytics) and a tracking call is never sent from your page.


Potential impact of issue

25% or more


How do I know if this is happening with my site?

By default, IE is set up on a user’s computer at a default setting that blocks third-party cookies from sites without a proper P3P compact policy in place. You can check to see if your site has a P3P header and appropriate privacy policy in place by using this tool Step 2 of the tool's results page (HTTP Protocol Validation) indicates whether or not a P3P header with a compact policy is set up correctly.


How can I fix this error?

To correct this behavior of IE, Microsoft recommends that site operators deploy a P3P Privacy Policy in “Deploy P3P Privacy Policies on Your Web Site.” Please note that IE does require a “compact policy” in the HTTP header, in addition to a full policy in XML files. To see if the compact P3P headers are being sent for your site:


  • Start capturing your HTTP header by using Chrome’s inspect element (Network) or the Firefox add-on FireBug.
  • Access your site from the browser
  • Look for the response header
  • If site is responding with P3P compact header, you will see something similar to P3P: CP=”NOI DSP COR NID ADM DEV PSA OUR IND UNI PUR COM NAV INT STA”
  • The actual CP string may be different depending on your site’s specific private policy. As long as CP header is detected and provides sufficient user privacy protection, IE should be honoring the policy, and allowing third party cookies from your site.


How do I verify this fix works?


To verify that your P3P policy is correctly implemented, clear all of your cookies and then access the site through the StumbleUpon frame:



  • Clear all cookies from IE on your computer, and make sure your copy of IE doesn’t have the StumbleUpon IE toolbar extension installed.
  • In the address bar append before your URL, e.g.
  • Click “Stumble This” from the info page to load your site through our web toolbar
  • In IE, from the Tools menu or drop-down, select Internet Options
  • Under Browsing History, click Settings
  • Click View Objects or View Files to see if a tracking cookie associated with your analytics implementation has been created
  • See More


    Issue #2 – Same Origin Policy

    If you have JavaScript on your page that assumes it is the top-level frame and attempts to access the top-level frame (which is hosted on StumbleUpon’s servers), it encounters a security error. Once this security error occurs, execution of JavaScript can halt on that page, including any tracking calls for Google Analytics or Omniture. That means when such an error is encountered, no tracking occurs for that page view, and as far as your tracking package is concerned, there was no page view. The nature of this behavior is dependent on browser type, version, etc. In some cases, some or all of the JavaScript may continue to execute.


    Potential impact of issue

    40% or more


    How do I know if this is happening with my site?

    It's important to see what kind of JavaScript errors are occuring on your page:


    • Open a new incognito window in Chrome. Doing so temporarily removes the installed SU toolbar (in the event that you are a dedicated stumbler yourself) from your browser so that you can load the page through the web toolbar for testing purposes.
    • In the address bar append before your URL, e.g.
    • In Chrome, go to View -> Developer -> JavaScript Console to see if there are JS errors occurring on the page.
    • Click “Stumble This” from the info page to load your site through our web toolbar.
    • Look for the error similar to: Unsafe JavaScript attempt to access frame with URL from frame with URL Domains, protocols and ports must match.


    It’s not always the case that a JavaScript error will halt execution. The conditions differ by browsers, versions, exception type, etc. Most security errors do result in JavaScript execution halting, but you should check your page to be sure. One way to be sure whether JavaScript errors are halting execution and preventing tracking from occurring is to check whether the tracking ping occurs when your page is framed by another domain’s page. Follow the steps above, and then:


    • Click the Network tab, and refresh the page.
    • For Google Analytics, you should see a request for a file called “_utm.gif.” That is the tracking ping you want.
    • Make sure it isn’t some other site/frame’s tracking request by clicking on that entry, and looking at its headers. Verify that it is associated with your GA account.


    How can I fix this error?

    There are JavaScript calls within your page that are attempting to access higher-level DOM variables. Normally, when not framed, this issue isn’t apparent; therefore, when fixing, make sure you are framed appropriately to reproduce and find the errors. Then, try using hierarchical DOM references (like “parent”) rather than strict ones (like “top”) when attempting to access higher-level variables. Often these calls are nested inside your third-party JavaScript libraries, so make sure your vendors are practicing proper access hygiene. Correcting this situation removes such errors, and allows for continued execution of JavaScript, including the tracking call. It may be the case that unsafe calls are made by other JavaScript libraries but tracking calls are still able to execute independently. Remember: the security error you receive could be occurring in the JavaScript for the tracking code itself!


    See More
    • Same origin policy:
    • Example for JavaScript:


      Code example

      Here’s a snippet of code that, when embedded as an iframe on a page hosted by another domain, shows how this issue occurs.





      // An example of trying to get the current URL for use in tracking, etc.

      alert(“Attempting to make calls…”);

      alert(“Accessing location by document: ” + document.location.href); // This executes properly

      alert(“Non-halting exception: ” + document.location.wrong); // This results in an exception,

                                                                                                             //but doesn’t halt execution

      alert(“Accessing location by parent: ” + parent.document.location.href); // This results in an exception,

                                                                                                                      // and halts execution

      alert(“Accessing location by top: ” + top.document.location.href); // This results in an exception

                                                                                                               // and halts execution

      alert(“Done, execution continuing…”); // This never happens because

                                                                       // execution halts!






      Other Best Practices
seconds ago
a minute ago
minutes ago
an hour ago
hours ago
a day ago
days ago
Invalid characters found