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]](https://webanalyticsfordevelopers.files.wordpress.com/2017/03/170321-blablabla-data-layer-404.png)
![[screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2017/03/170321-blablabla-tracking-call.png){kind=tracking}
![[screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2017/03/170321-blablabla-pages-not-found-report.png)
![[screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2017/03/170321-blablabla-plr.png)
![[screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2017/03/170321-blablabla-custom-code.png)
httpErrorCode Data Element, too? Sure:
![[screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2017/03/170321-blablabla-hecde.png)
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.
Web Analytics for Developers 
Sometimes (pretty often in fact) we use just Image pixel tracking, because IT DEV OPS want error pages on lower network nodes (i.e. Proxy) to be independent from other resources (no DTM and preferrably no external scripts).
i.e.
We mostly add some other custom variables to have status codes, in case that we want dynamic stuff from DOM – i.e. location.pathname, we use inline script to create the image.
This way you don’t have to worry about library updates.
LikeLiked by 1 person
Hi Lukáš,
Very good points indeed!
Cheers,
Jan
LikeLike
In you page there is a section
digitalData.page.attributes = digitalData.page.attributes || {};
digitalData.page.attributes.errorPage = “404”;
digitalData.page.pageInfo.pageName = “404:” + window.location.href;
Is this rendered by Adobe or you have put it in there? It looks like a very strange that Adobe has put it there. If you did it, your tutorial is incomplete.
If this is actually what s.pageType=”errorPage” does what is missing then to have it rendered since I do not get it and have to write the above lines myself.
LikeLike
Hi Aleksandar,
The attributes are part of the data layer in my page, and as such, they are the responsibility of the developer, not Analytics or the tool (Adobe).
Are you implementing using DTM or pure Javascript?
LikeLike
We set through DTM as you explained, but it did not work out of the box, so I looked into your solution and those lines where apparently missing but you are saying now that they are your custom attributes so they are not going to help directly although we can use them.
It should track at least one way now since we added custom attribute type ourselves, but it must be some configuration that is missing that does not allow DTM solution directly. Is there any specific DTM requirement, like linking to some file or something? It would be nice to see the page as real 404. Both solutions require s object. What file needs to be linked to get this s object for Javascript and DTM solution?
We will dig this out I guess, but maybe “read this first” would help if some settings from DTM Javascript are assumed. Thanks.
LikeLike
Hi Aleksandar,
You need nothing specific to make this work, except a 404 page.
On that 404 page, DTM must be loaded, and the page must also contain something in the data layer that you can use to identify it as the 404 page.
Can you give me a pointer to your setup? This should be pretty easy, so I’d like to see for myself.
Cheers,
Jan
LikeLike
I believe I had the same issue with your DTM solution as Alexandar: the s object not being available for the page rule calling it. Why not, I didn’t investigate. At least my page load rule was set to trigger at Bottom of Page like yours.
Luckily that very issue has been addressed in https://stackoverflow.com/a/27320309/1057869 (for me in scenario 1.a, to be precise).
LikeLike
Hi ennaj,
That is strange! The Custom Code in the Analytics part of a DTM PLR should _always_ have access to the s object!
I’m guessing there is no way we can reproduce?
LikeLike
My bad! I had mistakenly added the s.pageType = “errorPage” line to the “Javascript / Third Party Tags” section of the page load rule. There it doesn’t work, but in “Adobe Analytics → Custom Page Code” it does. You even have a screenshot of the correct location, I just failed to notice it. Thanks for this article!
LikeLiked by 1 person
Have you successfully implemented erroPage reporting using Adobe Launch? I’m migrated over from DTM, but the errorPage is firing even when network assets (GET) is throwing a 404. For example, if an image on the page is throwing a 404, it’s reporting to Adobe. Never did that before. Don’t need to make those extra image calls. Thanks!
LikeLike
Not yet, but it is on the list.
LikeLike