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.jsorAppMeasurement.js) - a limited data layer on the 404 handler page
- stating it is the 404 handler page
- 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:
- 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. - Setting
s.pageName, you should include the original URL. That’ll help you figure out where the problem is. Whether you usewindow.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
- stating it is the 404 handler page
- 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]](http://webanalyticsfordevelopers.files.wordpress.com/2017/03/170321-blablabla-data-layer-404.png?w=605&h=471)
Data Layer on the 404 handler page
![[screenshot]](http://webanalyticsfordevelopers.files.wordpress.com/2017/03/170321-blablabla-tracking-call.png?w=605&h=456){kind=tracking}
Analytics tracking call on 404 page
![[screenshot]](http://webanalyticsfordevelopers.files.wordpress.com/2017/03/170321-blablabla-pages-not-found-report.png?w=605&h=327)
Analytics Pages not Found report
![[screenshot]](http://webanalyticsfordevelopers.files.wordpress.com/2017/03/170321-blablabla-plr.png?w=605&h=781)
Page Load Rule for 404 page
![[screenshot]](http://webanalyticsfordevelopers.files.wordpress.com/2017/03/170321-blablabla-custom-code.png?w=605&h=393)
Custom Code inside the PLR
httpErrorCode Data Element, too? Sure:
![[screenshot]](http://webanalyticsfordevelopers.files.wordpress.com/2017/03/170321-blablabla-hecde.png?w=605&h=752)
Data Element for 404 error tracking
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
