Diagnostics makes regular, periodic evaluations of your Analytics implementation, and provides notifications as a gentle reminder of how to keep Analytics tuned to ensure the best data, performance, and analysis.
In this article:Overview
Analytics regularly attempts to find pages on a website that do not have properly installed tracking code. The system looks at results of the Google-search crawl on websites associated with Analytics accounts. A subset of those pages are crawled with JavaScript enabled, and the execution results are examined to confirm the expected hits would have been sent. Note that the hits are not actually sent to Analytics and therefore do not inflate your traffic numbers.
If it appears that pages aren’t sending tracking data, a notification appears to alert you of the problem:
Limitations
Diagnostics does not check pages that are not publicly crawlable, either because of a login wall or robots.txt exclusions. For those pages, you should use Google Tag Assistant to check tagging health yourself. In general, it is not feasible to crawl all possible pages due to sheer volume. Furthermore, the system may decide to exclude certain pages based on execution cost, but it does attempt to prioritize those pages that receive significant traffic.
Crawl frequency varies from a few days up to several weeks in the worst case, so keep in mind that recent tracking code changes or fixes may not be reflected in the results until the page is re-examined.
The crawler must be able to execute JavaScript without error, which means that it cannot continue in cases where necessary script files have been blocked by robots.txt. This mostly applies to non-standard tracking code installations implemented with custom JavaScript code or some third-party tag managers.
Investigate and fix
After you receive the missing-tracking-code notification, first verify whether the tracking code is installed properly on those pages, based on these instructions. If you confirm that the tracking code is missing, go ahead and set up the web tracking code on those pages. The notification you received only reports a sample of pages and should not be considered an exhaustive list, so be sure to check other pages on your site.
If the pages belong to another website or the tracking code is actually installed correctly, see the sections below.
Reported pages do not belong to the website
If the pages belong to a domain that you do not recognize, that website likely specified your Analytics account in its tracking code by accident. First, you should create a filter to exclude the unwanted traffic data from that domain as soon as possible. Then try contacting their webmaster to correct the problem.
If the pages belong to a recognizable or related domain, but should not be considered a part of the website, you probably have multiple websites under the same domain, with unclear site boundaries.
Our systems can handle simple multisite setups where the top-level paths correspond to different sites. For example, if the paths http://www.example.com/glass/ and http://www.example.com/fiber/ map to separate sites and have different Analytics accounts installed in each, then the site boundaries would be clear to our algorithms.
For more complex path-to-site mappings where site boundaries are at deeper level paths or don’t follow a predictable pattern, there is a chance that pages from other sites are mistakenly included in the results. We advise you set the notification to “Ignore” to stop being notified of these problems.
Tracking code is actually correct
A reported URL can turn out to be a false alarm: the tracking code is in fact installed properly and sending data. Occasional false positives are to be expected, as there is a small amount of error introduced by any network and system anomalies or JavaScript-execution timeouts. Also, recent fixes or changes may take several weeks to be crawled and processed, so that should be taken into account. However if the majority of results are false positives, then the website most likely has inconsistent tracking code implementations. For example, a website might be partially tracked with the standard, recommended Analytics code, while its other pages use a custom implementation.
The tracking-code verifier cannot support non-standard implementations where necessary JavaScript files are blocked to crawlers by robots.txt. If the verifier does not find any evidence of installation on the entire site, it simply gives up, assuming that a non-standard implementation is in place. However, when there is a mix of supported and unsupported tracking codes, the verifier expects to be able to proceed because it found Analytics on some pages. In that case, all pages with the unsupported implementation wrongly show up as missing the tracking code.
In general, it is a strongly recommended best practice to use a consistent approach to tracking codes, and to stick with one implementation throughout the entire site. If fixing the inconsistencies is not possible, you can set the notification to “Ignore” to stop being notified of these problems.
