Links not tracked in some browsers as jquery click event exits before tracking code finishes

See #1057914: Custom outbound link tracking with outdated link targets or javascript is broken. I tried this and it caused several regressions. Suxxx google docs.

I just want to be sure that the full context of this is correctly documented, so please allow me to open this once again just long enough to confirm a couple things (in the hope that this can be a reference for others and prevent new issues on this from being opened).

From what I can tell, adding an outbound click delay was attempted in 6.x-3.2 (see the bottom of googleanalytics.js in the git repository for 6.x-3.2). However, this lead to issues with links that contain target values, and needed to be rolled back in 6.x-3.3 (see #1057914: Custom outbound link tracking with outdated link targets or javascript is broken specifically comment #12). As a result, it would appear that the outbound click delay (as suggested by Google) is currently not implemented.

So I think it would be useful to confirm the following:

1. Is the summary above correct?
2. If the click delay is not implemented, does this pose any concern for the effectiveness of outbound link tracking (i.e is it safe to assume that the absence of a click delay has a negligible impact on the accuracy of Analytics event data)?

As said in the linked case I'm not aware of any technical way that allow us to fix it.

I'm posting another note here not to contend with the conclusion that there is no known technical way to fix this, but rather to suggest that this issue be better clarified, both in the issue queues and hopefully in the docs/readme.

I believe the bottom line is that outbound/file link tracking is simply not supported across all browsers. The attempt to address this in 6.x-3.2, and the subsequent complete rollback of that attempt (to address other issues it introduced) in 6.x-3.3, may have lead to some confusion.

I may also be able to add to the issue description a bit as I've been trying to do some of my own testing on this matter. Basically I've been using tcpdump to track all GET requests for __utm.gif across a number of scenarios and browsers (I believe this gif file should be requested whenever a click event is recorded, and thus should indicate whenever my client browser is reporting something to Analytics). Anyway, it's starting to look like no click events (outbound links, files, etc.) are ever recorded in both Safari and Chrome (and perhaps other webkit browsers). IE and Firefox don't seem to show any issues. Given the increasing popularity of Chrome this may be a fairly significant data-tracking issue.

The above was also true for 6.x-3.2 in my tests. It just seems like the .click event in googleanalytics.js always finishes too soon, even when settimeout is used.

I'm just wondering if we could look at one or both of the following:

1. Update the readme, and possibly the text near the related admin conf options, to note that outbound/file link tracking may not be supported across all browsers (I'd be happy to submit this kind of change as a patch).
2. Leave this, or whatever related issue best captures all this, marked as "active" or at least "postponed" so that there is an existing place to go for anyone who wants to continue to pursue a solution, or is just looking for an open summary of all this.

I'm just hoping that someone has some comments on these ideas.

The more I look into this, the more it seems like there are few solid options, as it's nearly impossible to implement a delay on the click event without "hijacking" the execution of the link itself (such as changing document.location, etc.). Obviously the maintainers understand this well, but for anyone else interested, this article helped me a lot:

http://www.ravelrumba.com/blog/tracking-links-with-javascript

However, I did stumble upon a surprisingly simply solution that does seem rather promising. I read that a mousedown event on a link tends to introduce a 50-200ms delay between firing and the link being followed. So this could give us an extra 50ms to 200ms delay for _gaq.push to run, which might be plenty for most cases. I did some tests with this change, and suddenly saw pretty consistent indications that __utm.gif requests were indeed getting sent from both Chrome and Safari on outbound links.

So I'm wondering if there are any strong reasons why:

$(document.body).click(function(event) { ... }

could not become:

$(document.body).mousedown(function(event) { ... }

Don't the conditional checks in googleanalytics.js pretty much filter out any odd cases where mousedown would cause issues?

Title typo

I've been testing the change I noted in #7 on a production site that receives notable outbound traffic (part of the site serves as an index for some digitized media content that's hosted on a separate domain). I'm now comparing Analytics for a week before this change to the week after, and though the overall in-site traffic has stayed the same (including the overall browser usage breakdown), the outbound link click events have changed significantly:

• Outbound clicks with Safari up 600%
• Outbound clicks with Chrome up 340%
• Outbound clicks with IE up 50%
• Outbound clicks with Firefox held steady (no increase)

Of course this is just one case specific test, but it really helps confirm the idea that clicks from Chrome and Safari were indeed being missed.

I'm going ahead and rolling this as a patch, which also includes additions to the README about link tracking.

Sound interesting, but I don't think that there is any loss with file or mailto links. With these two you have no time limits. The problem can only be with outbound links.

Yes, that is a good point. For the changes I noted in #9 I was only looking at "Outbound Link" events.

However, I don't think it is safe to say that all file links are immune to this problem. Any file type that a browser can handle on its own will cause the page/window to close as soon as the link is followed, which may also shut down the tracking code before it's finished. For example, all browsers will natively display txt files and some (such as Safari and Chrome) will also natively display pdf files.

I had a look at the "Download" events in our Analytics and I see that pdf type downloads have jumped up (between 3-6 fold) in Safari and Chrome since I made the change outlined in #7 (while IE and Firefox have remained pretty steady). So for the specific case of pdf downloads, the results seem pretty consistent with the results from Outbound Links.

Ok, thats a good point i missed. My main trouble here is that we have no clue why a mouse down gives us a delay ond the click event not. It could be a jquery caused delay or a browser delay. Maybe in a few weeks or with a later jquery version or newer browser version this delay get's removed. You may know that js performance has been optimized in past 2 years extremly in all browsers. This discussion may make someone to review why a browser "hang" with mouse down andvstarts optimizing this... It may work now, but it sounds not like a reliable solution that we or google analytics controls. This may make us running every few weeks after a browser or jquery lib version... If this may has not already changed in a newer jquery version... The one in core is far old compared to the latest available version as example.

Actually I was under the impression that the delay was due to the physical time it takes someone to tap-and-release their mouse/trackpad/whatever when clicking on a link. So the delay would not be related to jquery at all. Still, if this is the case, I do agree that this feels like a very ad-hoc solution, but it seems to at least be an improvement.

However, one thing that I did not give much thought to yet is how such a change would play out on touch devices. I'm guessing that proper "mousedown" support on touch devices is mixed at best, but I personally have no idea. So ad-hoc or not, it's certainly not a real fix. Still, I should note that we will continue with this patch in production as it does help us make better sense out of our Analytics (our interest in this problem started as we were seeing inexplicable mismatches in some of our Analytics data).

Anyway, the details about how this problem differs across browsers is indeed interesting, and it does help put some "scale" to what clicks might be missing in Analytics.

From what I can see with a quick bit of research (just anecdotal, not exhaustive), it seems as though most touch devices should support mousedown events, though they will simply fire at the same time as a click event. I suppose this could be good as it would mean that using mousedown instead of click would not introduce any loss of data going to analytics for touch devices, though it would not add a delay either (we would only get the delay with traditional mouse-like devices).

In the case of Apple devices see (specifically figure 6-4): http://developer.apple.com/library/safari/#documentation/AppleApplicatio...

Unfortunately we don't have enough mobile usage data coming in to our sites to do any meaningful comparison on this.

http://forum.jquery.com/topic/how-to-remove-the-300ms-delay-when-clickin...

Maybe we can add a delay the same way?

I have found an critical issue with this change. If you need event.preventDefault(); the click event is not prevented as the event that is blocked is only the mousedown than and then #1608310: Cross-domain link tracking fails because it does not return false would fail.

We should take a look into Piwik source code how they implemented the delay.

Changing the Pause Timer

When a user clicks to download a file, or clicks on an outbound link, Piwik records it. In order to do so, it adds a small delay before the user is redirected to the requested file or link. The default value is 500ms, but you can set it to a shorter length of time. It should be noted, however, that doing so results in the risk that this period of time is not long enough for the data to be recorded in Piwik.

[...]
piwikTracker.setLinkTrackingTimer( 250 ); // 250 milliseconds

I just had a look at this out of curiosity.

It seems piwiki sets an "expireDateTime" variable equal to the current time + the configured delay. It then uses this variable in a beforeunload event by starting a loop that runs until expireDateTime is readched:

        /*
         * Handle beforeunload event
         *
         * Subject to Safari's "Runaway JavaScript Timer" and
         * Chrome V8 extension that terminates JS that exhibits
         * "slow unload", i.e., calling getTime() > 1000 times
         */
        function beforeUnloadHandler() {
            var now;

            executePluginMethod('unload');

            /*
             * Delay/pause (blocks UI)
             */
            if (expireDateTime) {
                // the things we do for backwards compatibility...
                // in ECMA-262 5th ed., we could simply use:
                //     while (Date.now() < expireDateTime) { }
                do {
                    now = new Date();
                } while (now.getTimeAlias() < expireDateTime);
            }
        }

Is this considered good practice (doing thousands of iterations of an empty loop just to kill time)?

I don't know... but who cares, if it works and solve our "unsolveable" issues? :-)

I only ask as I was under the impression that this kind of thing might somewhat "monopolize" the user's CPU by locking the browser in a momentary loop. Though that may work, it might also be frowned upon (and it seems that some browsers, such as Chrome, may even implement mechanisms to prohibit it). This also looks like the same practice that a tracking script called "Clicky" uses, as referenced in this article (see the heading "Lock up the browser UI thread"):

http://www.ravelrumba.com/blog/tracking-links-with-javascript/

Really, it was just the article linked above that led me to believe this may be bad practice, but I'm personally no expert. The fact that this is what others do to solve this problem may indicate that it's the only way. I'd just hate for the approach to be implemented and then cause a new issue to be opened in the future when someone says "hey, you should not be doing this". If others think this is the way to go, I'm certainly not one to naysay.

More troubles #1836370: Link clicks (example downloads) not beïng tracked

Marked #1836370: Link clicks (example downloads) not beïng tracked as duplicate.

Tested Firefox with TXT and PDF (both are not tracked). Tested with MSI download (works). It looks like, if the browser is able to open the download itself internally - tracking fails. If a download/save dialog appears - tracking works.

16.0.2
16.0.1
15.0.1
14.0.1
13.0.1
12.0

Your change to A element is invalid and will cause slow unbinding issues, see #336924: Massive page rendering slowdown with many links. Additional it also does not help anything here.

Marked #1943220: Outbound links not reported correctly (in-page analytics also not reported correctly) as duplicate.

Let's see if this works for us.

Patch seems not blocking the default browser action.

Per Cross Domain Auto Linking, Google adds the linker stuff on mousedown. So we cannot use mousedown from my point of view.

Would it work to delay outbound links only if the current window's location is changing (i.e. the link isn't being opened in a new tab/window)?
And then if the link being followed isn't changing the location of the current window (i.e. the link is being opened in a new tab/window), then you don't need the delay because the page from which the tracking gif is being sent isn't changing.

Something like:

_gaq.push(['_trackEvent', category, action, label]);

if (event.metaKey || event.ctrlKey || hrefTarget == "_blank"){
	var newTab = true;
}

if (!newTab){
	event.preventDefault();
  	setTimeout('location.href = "'+href+'"', 200); 
}

They do similar things here and here.

This was already tried earlier and cause a lot of issues. See #1057890: Prevent browsers default behavior if monitored links are clicked and #807320: Rollback: Track outgoing links as targets / Disable event tracking optionally for outgoing links

Like Google does for auto linking I'm binding the mousedown keyup touchstart events and no longer a click event.

Let's see if we can get some reviews in production.

Patch should apply to GA7.1, GA7.2 and GA8.2, but was made for 8.2. The changed line is the same in all branches.

Committed these changes to the DEV branches:
7.x-2.x: http://drupalcode.org/project/google_analytics.git/commit/f0f27ea
8.x-2.x: http://drupalcode.org/project/google_analytics.git/commit/f8d15f8

Additional here is a patch for 7.x-1.x for testing. Please provided some feedback.

Looks like nobody is interested and 1.x has reached end of live.

It looks like we can make this tracking more reliable now. See #2355091: Add {'transport': 'beacon'} for more reliable tracking with very fast browsers exiting before tracking code finishes