Fixes – Too many Visits on Pages with Links

On the German blog, I used to run a series about frequent mishaps, and how to detect and fix them. Those articles were often about data, rather than implementation, so I never translated them to this blog. But here is one that is pretty technical, so it should clearly live here.

Friendly marketer says that she can see additional Visits on the homepage.

You sit down, and she explains:

On the homepage, there is a banner. The clicks on that banner are tracked, because clicking on the banner transports visitors to a microsite that, so far, is not tracked with Adobe Analytics.

Looking at the “Pagename” eVar, your friendly marketer sees more Visits than when she looks at the built-in “Pages” report.

The problem started when the banner was added to the homepage.

How come?

eVars or Page

First things first: there are different types of dimensions in Analytics, props and eVars. They do not work the same way. On top of that, the “Page” dimension works slightly differently, again.

Without going into details, when visitors come to the site, a Page View should be tracked, and a Visit be counted. When the visitors then click the banner, an Exit Link should be tracked, and that Exit Link should be part of the same Visit.

If you look at this scenario using the “Pagename” eVar as a dimension, you can see 1 Page View, 1 Exit Link, and 1 Visit against that page.

If you look at the same thing using “Page” as a dimension, you will see 1 Page View and 1 Visit, but not the Exit Link.

So far, so good.

Note that Page Views and Visits should be the same for this simple scenario.

In the case mentioned by your friendly marketer, the Visits metric is not the same. Instead, it looks like some of the Exit Links count as a separate Visit.

Hmm…

Reasons

There are a bunch of reasons why she would see more Visits on the eVar, both technical and “well, because that’s how it works” reasons.

First — a Visit expires after 30 minutes of inactivity.

If a visitor loads the home page, goes to lunch, comes back, and then clicks the banner, she will have had 2 Visits. The first one would only include the Page View, i.e. when the page was first loaded, while the second one would only include the Exit Link, when she clicked the banner.

Second — timing matters.

If the visitor clicks the banner before page load tracking had a chance to happen, it might not happen at all.

It is possible that the click came before the tracking call, and because the banner is really a link, the browser would likely not execute any tracking after the link handling is finished. It would simply move to the next page.

Third — timing matters.

For new visitors (who do not have a Visitor ID when they first load the page), there could be a race condition.

If the visitor clicks the banner at around the same time as the page load tracking happens, it is possible that the cookie handshake for new visitor hasn’t finished yet with the Analytics servers, and the click tracking would therefore initiate a second cookie handshake.

The visitor would have a valid Visitor ID at the end, but either the Page View, or the Exit Link might have a different Visitor ID.

Note that this is pretty much impossible if you are using the Experience Cloud ID Service (fka Marketing Cloud ID Service fka Visitor ID Service fka Visitor API), but I have seen it happen on an Analytics-only deployment.

Also note that this is fiendishly hard to find.

Fix

Your friendly marketer works with you for a reason: she really just wants reliable data, and she wants you to provide/suggest/deploy a fix.

The scope of the fix includes 2 & 3 above, not 1.

I don’t think 1 should really be a big problem, in the sense that some people might do that, but I don’t think it’ll seriously change your numbers.

But for 2 & 3 we can make a fix, so we should.

In principle, 2 can be fixed by delaying the attachment of the click handler, and/or some sort of a semaphore.

As usual, more than just one way lead to Rome. Here is the one I think is the easiest.

Semaphore

Event-based Rules can have conditions, and the easiest fix for this is to check for the existence of some Javascript variable, which will only be created after the standard page load tracking has happened.

We need three things for this:

1. a Data Element (“First tracking call has happened”) that returns “yes” or “no”,
2. a condition in the EBR, that checks aforementioned DE,
3. code that sets a JS variable after the first tracking call (think postTrackCallback)

Here is an example:

Let’s make a Data Element, Custom Code, as follows:

var weHadFirstTrackingCall = 'no';
if ('undefined' !== typeof _satellite.__je && _satellite.__je && 'undefined' !== _satellite.__je.firstTrackHasHappened && _satellite.__je.firstTrackHasHappened) {
  weHadFirstTrackingCall = 'yes'
}
return weHadFirstTrackingCall;

The DE returns ‘no’ by default, but it returns ‘yes’ when it finds our Javascript variable.

(Note that I return “yes”/”no” rather than true/false. I am not a developer, and this ambiguity with false and false-y in Javascript spooks me. Feel free to do this differently.)

Next we define the callback, as follow. Do this wherever you customise your Analytics code.

s.registerPostTrackCallback(function(requestUrl, hanger) {
  hanger.__je = hanger.__je || {};
  hanger.__je.firstTrackHasHappened = true;
}, _satellite);

With those two in place, the DE will return ‘no’ on any page up until the moment the first tracking call has successfully gone through, and then it’ll return ‘yes’.

Now in your EBRs, you can use this DE as a condition, and that means EBRs will only fire after the page has been tracked.

Bingo, problem solved!

Funny enough, this fixes 3, as well.

So we’re done.

Notes

If you don’t like semaphores, you could use the postTrackCallback to attach click handlers, rather than using EBRs. You would attach handlers which would likely call DCRs. This would probably be more complex, but if you’re using DCRs anyway, it might be an easier way (and, with DTM, the only way).

Sometimes, the easiest fix could be to move tracking of the page to the top of the page, in the hope that it’ll have happened by the time anyone clicks anything.

I would wager that postTrackCallback is heavily underrated.