Quantcast
Channel: s_code.js – Web Analytics for Developers
Viewing all articles
Browse latest Browse all 46

Tracking 404 Error Pages

$
0
0

There are tools out there that find bogus links on your site, and some even try to find links outside your site that point to nirvana. But your friendly marketer likely wants to have better data than that, so she asks you to build tracking for 404 pages.

Now what?

Let me explain, both for Javascript-only (“legacy”) and DTM-based deployments.

Javascript-only

If your site is not yet using a TMS, or if your TMS wants you to write Javascript code for Analytics, then you should read this part.

What we need:

  • a 404 error handler page
  • the Analytics library loaded on that page (either s_code.js or AppMeasurement.js)
  • a limited data layer on the 404 handler page
    1. stating it is the 404 handler page
    2. carrying the original URL that failed
  • a little Javascript block at the bottom of the page

There is a special report for pages that do not exist, aptly called the “Pages not Found” report. For a not-found page to show up in this report, its URL has to be tracked, and the system has to be told that this URL was bad.

Here’s what that would look like:

	s.pageName = "404:" + window.location.href;
	s.pageType = "errorPage"; // this makes it a call for the Pages not Found report
	s.t();

The two things to note here are:

  1. Setting s.pageType = "errorPage" is what makes this call special. By setting this, you tell Analytics that the page name should be treated like a URL for the Pages not Found report.
  2. Setting s.pageName, you should include the original URL. That’ll help you figure out where the problem is. Whether you use window.location.href, window.location.pathname, or something else, is entirely up to you.

Note that the s.pageType Variable is not used anywhere else! The above is the only use case and the only allowed value for that variable!

DTM-based

This will be pretty easy, too (so I wrote it first). We need:

  • a 404 error handler page
  • a limited data layer on the 404 handler page
    1. stating it is the 404 handler page
    2. carrying the original URL that failed
  • one Page Load Rule
  • a little bit of custom Javascript inside that rule

To show you an example, here’s what happens if you go to — say — https://www.jan-exner.de/blablabla:

[screenshot]

Data Layer on the 404 handler page

The resulting tracking call looks like this:

[screenshot]

Analytics tracking call on 404 page

And in Analytics, you’ll later see this:

[screenshot]

Analytics Pages not Found report

How did I do that? Easy. Here is the PLR:

[screenshot]

Page Load Rule for 404 page

And the custom code is actually a single line:

[screenshot]

Custom Code inside the PLR

Want to see the httpErrorCode Data Element, too? Sure:

[screenshot]

Data Element for 404 error tracking

Any questions?

Note that my 404 handler page is good in that it leaves the URL untouched, making it easy to create the pageName for tracking. Other content management systems redirect the browser. If yours does that, make sure the original URL is available somewhere in the page, so that it can be read and used for tracking.

Does it make sense to go one step further and track the referrer into a prop? I guess it does.


Filed under: AppMeasurement, DTM, Javascript, Page Code, Principles Tagged: analytics, appmeasurement.js, DTM, implementation, javascript, s_code.js, tag manager

Viewing all articles
Browse latest Browse all 46

Trending Articles