Tracking 404 Error Pages

~ Jan Exner

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.

Published by Jan Exner

German expat living in Switzerland (formerly UK and France). Consultant and member of the Multi-Solutions Group at Adobe, working with the Digital Marketing Suite. Father of 4 girls.

11 thoughts on “Tracking 404 Error Pages”

  1. 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.

    Liked by 1 person

    Reply

  2. 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.

    Like

    Reply

    1. 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?

      Like

      Reply

      1. 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.

        Like

      2. 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

        Like

  3. 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).

    Like

    Reply

    1. 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?

      Like

      Reply

  4. 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!

    Liked by 1 person

    Reply

  5. 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!

    Like

    Reply

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.