A word of warning. This is not a developers’ post, a guide, or a thought experiment. This is a bona fide rant. Sometimes we just need to vent.

A couple of weeks ago, I checked one of our (inactive) client’s Google Analytics accounts I still had access to. What I saw in the acquisition report was this:

Splash page affect on Google Analytics

See how direct traffic gobbles up a great big share of organic traffic in late October?

As my fingers tingled with the anticipation of yet another web analytics mystery (the fuel that keeps my engines going), I was overcome with a feeling of dread. I knew for a fact that there had been a site redesign at the time (which is part of the reason I checked the account), and I had originally had some concerns with the technical implementation.

Anyway, when one metric falls and another rises with an observable correlation, there’s usually something very wrong with site tracking. On top of that, if the fluctuation involves direct traffic, the problem is usually related to referral data being overwritten for some reason.

When I went to take a look at their site, the problem became too apparent. A splash page was present. And, to make matters worse, some shoddy JavaScript reared its ugly head.

X

The Simmer Newsletter

Subscribe to the Simmer newsletter to get the latest news and content from Simo Ahava into your email inbox!

The problem with the splash

A splash page is a screen that the visitor sees prior to entering the website. It’s been a pain for SEO and usability for a long time (see e.g. this splash page rant from 2010, or this more recent one). It introduces an unnecessary step into the conversion path, it usually caters to the wrong crowd for all the wrong reasons, and if there’s any kind of variable visibility involved (like checking for cookies or language settings), the JavaScript redirection might just be done in the wrong way.

I know this rant is about the splash page, but I just can’t help myself. Why is JavaScript a free-for-all programming ride, where there really are no consequences for shoddy workmanship? What’s wrong with quality assurance even with major companies, where the code that gets published is riddled with performance problems, security issues, and over-complicated syntax? Global variables are being overwritten with abandon, errors are not caught and handled, references are outdated, and pushing all this crap into a library just makes the issue exponentially worse when the library is pushed to public repositories.

In the case of the client’s account, the splash page was used as a country / language selector. Now, I consider that to be a moderately acceptable reason for hijacking the visit, but I’m willing to bet there’s a better way to do it. Instead of imposing a selection screen, which in itself is a turn-off for anyone who just wants to get to the site, why not do an IP redirection based on geolocation, with a visible but unobtrusive way of indicating why the visitor was transported to the version they’re seeing? Maybe a small banner at the top of the page, which can be closed with a click. Of course, the banner should also have a quick link menu, with which the visitor can go to the correct version, if they were redirected wrong.

So what was wrong with the example?

Why yes, I sidetracked a little. The problem was that upon entering the main page of the global site, a JavaScript function checked whether or not the user had a country cookie in their browser. This cookie is downloaded once the user chooses a country from the country selector, or visits a local site directly. If the cookie is not in place, they are redirected (with JavaScript again) to the splash page.

That’s right. A JavaScript redirection. Anyone with even the slightest knowledge of SEO and web analytics best practices is now permitted to shudder. Here’s the kicker:

If you do a JavaScript redirection before GA has a time to write the visit cookie, you lose the original referral information.

You see, because the GA tracking code doesn’t have time to load before the redirection is fired, the referral information is not written to the session cookie. This means that the first time the referral information is recorded is after the redirection, when the user enters the splash page (if it has tracking enabled). Because the original referral information is lost, the session is recorded as originating from direct traffic. Direct traffic is notorious for being the dumping ground for all sorts of undefined traffic sources. In essence, a JavaScript redirection which does not include the referral information throws away a key ingredient of understanding how your traffic channels perform.

How to avoid the problem

If you want the redirection, your best bet is to let Google write the session cookie on the front page before the redirection. Note! If the redirection is to another domain, you will need to implement cross-domain decoration for the redirect URL!

The best solution, by far, is to redesign your site structure so that a splash page is not needed. Here are some ideas:

  1. IP redirection based on geolocation. Just remember to help those out who are redirected wrongly, or you’ll have an even bigger problem on your hands
  2. Integrate the country selector into the flow of your main site without a splash page
  3. Optimize your country sites so that people find them without having to go through your global site