Hi, is there a valid reason to track clicks on outbound links with "mousedown keyup touchstart"? Using touchstart actually logs every swipe across a link as a click, which makes statistics quite inaccurate. Many people will swipe across a page, maybe "touchstart" over a link, but won't click the link.

I have read other discussions (e. g. https://www.drupal.org/node/2498727 and https://www.drupal.org/node/1580144), but I still don't see justification for using touchstart. I understand that there used to be some problems with using "click", but with browsers regularly updated it probably doesn't affect stats nearly as much as touchstart does.

If I'm not missing something obvious, this method of tracking clicks on outbound links is a major problem.

Steps to reproduce:

1. Create a link on a page.

2. Open the page that contains that link (e. g. in Android's mobile browser).

3. Swipe down, with your finger touching the link when you swipe down, i. e. that link is the point that your finger touches when you swipe down.

4. A click is registered, although you didn't really click on the link and you never even intended to do it.

You can also see collect gif being loaded in network tab when you do that.

CommentFileSizeAuthor
#28 google_analytics-8.x-3.x-link-click-bug-2649834-28.patch1.22 KBchrisolof
#26 touchstart_event_logging_non_existent_clicks-2649834-26.patch449 bytesguardiola86
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jp20 created an issue. See original summary.

hass’s picture

hass CreditAttribution: hass commented
Version: 7.x-2.1 » 7.x-2.x-dev
hass’s picture

hass CreditAttribution: hass commented

Google has documented in past that Google use mousedown keyup touchstart events to trigger tracking on cross domain auto link tracking. This was just overtaken.

jp20’s picture

jp20 CreditAttribution: jp20 commented

OK, it might have been fitting to use it then, but mobile phones take so much traffic now that this approach probably doesn't make sense anymore.

Is it possible that using just "click" instead of "mousedown keyup touchstart" misses some clicks? If not or if that number is small, wouldn't it be more accurate to switch current binding to "click"?

hass’s picture

hass CreditAttribution: hass commented

No, because the browser will exit too early and than the cross domain tracking will stop working.

jp20’s picture

jp20 CreditAttribution: jp20 commented

I have investigated it more thoroughly and here are my findings (based on the assumption that only "click" is used):

1. If you use a mouse and open a link with left click:

- click is registered properly if the link is opened in new window/tab
- click might not be registered if the link is opened in the same window

2. If you use a mouse and open a link with scroll wheel:

- although this way you force the browser to open a new window, some browsers will recognize a click (e. g. Chrome) and some will not (e. g. Firefox)

3. If you use a mouse and open a link with right-click contextual menu:

- click is not logged

4. If you use a phone and open a link with "regular" click:

- click is registered properly if the link is opened in new window/tab
- click might not be registered if the link is opened in the same window

5. If you use a phone and open a link by "pressing/holding" the link and then selecting to open it in a new window/tab:

- click is not logged

Considering all of this, it makes sense to use mousedown and probably keyup (I didn't test that one), but touchstart is a tricky one. Touchstart does prevent clicks described in case #5 from being lost, but the question is are there more people who open links that way or the ones who "touch" the link accidentaly when scrolling. Considering that everyone scrolls/swipes with their phones and only a fraction of users click on any links (and then a fraction of them open them as described in #5), I suppose that using "touchstart" for mobile users messes up data much more than "click".

Is there another event listener for mobile phones now that would be more appropriate?

hass’s picture

hass CreditAttribution: hass commented

Again, click does not work. The browser will not track the outbound links in this case as the browser kills the tracking hit before the request is send/completed. We already discussed this in #1580144: Links not tracked in some browsers as jquery click event exits before tracking code finishes. You may better read this and all linked cases and docs very first. It has tons of ideas we tried already.

Site internal clicks on links are never tracked. Only pageviews will be.

jp20’s picture

jp20 CreditAttribution: jp20 commented

Sure, I have already read all of it. I'm not opposed to using other methods, the thing I'm pointing to is that touchstart can completely mess the stats if you have many mobile users.

Imagine that you have a link close to the top of the page, maybe a lengthy link that spans in two rows on smaller screens. How many people will touch the link when swiping down, without any intention to click on the link?

hass’s picture

hass CreditAttribution: hass commented

What type of link is this? What is the destination and in what url is it embedded?

jp20’s picture

jp20 CreditAttribution: jp20 commented

It's an external link, tests I was describing were all about external links. It happens on regular links, nothing special there. Example of such a link:

<a href="http://www.example.com">Example</a>

jp20’s picture

jp20 CreditAttribution: jp20 commented

It's an external link, tests I was describing were all about external links. It happens on regular links, nothing special there. Href with an external url, with anchor text inside.

hass’s picture

hass CreditAttribution: hass commented

I found some discussions how to detect a swipe, but they save the touchstart position and on touchend they compare the touchend position and if the positions are nearly the same it is not a swipe.

The problem here is touchend is too late like click.

If we remove touchstart binding we may loose some tracking. However most / all modern browsers support web beacons. I never tested it in that detail, but it is possible that the old issue no longer exists and the limited time is enough to issue this web beacon request.

We need to seriously test this. I have no idea if we change from a intermittend double tracking to missing tracking. Not sure what is a more win situation.

jp20’s picture

jp20 CreditAttribution: jp20 commented

It has to be tested thoroughly, of course. It's a big change, but IMHO it would result in more accurate reporting. The problem is that touchstart doesn't only introduce double tracking (not always though), but it logs non-existent clicks, which is, as described, a serious issue if long links or linked images are used.

It seems to me that there is no perfect solution for all situations, so maybe some new options should be introduced. For example, if someone doesn't use _blank at all, it might be forced if they select such an option. That would remove one of the obstacles for proper tracking.

When it comes to touchend - would that solution work for a "short" touch? Some people hold their finger on screen for a while and release it when they reach the part of the page they need. However, some of them touch the screen only briefly, release the finger and let the page scroll down "itself". In that second case, touchend is almost the same as touchstart, isn't it?

hass’s picture

hass CreditAttribution: hass commented
Parent issue: » #2671716: Use Autotrack

We should check out if this case may solve this issue for us as Google may implemented all the magic.

philipwalton’s picture

philipwalton CreditAttribution: philipwalton commented

Hello, I am the creator of autotrack for Google Analytics.

Autotrack does not currently try to address the issues of clicks via context menu or long pressing on mobile to open in a new tab. Neither does Google Tag Manager. The problem with tracking these instances as definite "clicks" is you'll get a lot of false positives.

As I mention in this issue on Github, I'd be open to extending the functionality to include tracking these additional events, but I think it only makes sense to do so in a way that can be filtered out at reporting time later (e.g. using a different event action).

hass’s picture

hass CreditAttribution: hass commented

@Philip: Many thanks for your feedbacks. I think I was wrong with some assumptions after my not so deep review first. I need to think about it a bit more and try some things next week and check what is left now.

I think you build something that could replace most of the many years old drupal ga js code.

Since Drupal 8 no longer fully supports IE8 or older I may be able to replace current code with autotrack.

What I really do not like in autotrack is the custom domain handling coding. It requires custom coding where you could make it a lot easier if you would take over the settings from the ga params. The domain array or wildcard setting is already there - why not reusing it?

cato’s picture

cato CreditAttribution: cato commented

Chiming in here with another bug related to the event handlers...

Found a nasty bug in the module that will generate extra clicks in Analytics.

Steps to reproduce on a clean D7 install:
1. Install Google Analytics, Wysiwyg, CKEditor (to change link target)
2. Create an article with a link in the text. Set the link target to new window (_blank).
3. Save the article.
4. On line 55 in googleanalytics.js insert the following code: console.log('clicked '+this.href);
5. Using Chrome or Firefox, visit the article in your browser.
6. Open the console.
7. Click the link
8. Close the new tab that was opened.
9. Without clicking on anything, start typing on your keyboard.
10. Look at the console. You should see that the clicked 'whatever href you set the link to' message is repeated many times.
11. Click on something in the window. Start typing. You should see in the console that the message doesn't repeat anymore

hass’s picture

hass CreditAttribution: hass commented

Can you share why this happens? It looks totally unrelated. See #2384595: Inconsistent multi-domain behavior

cato’s picture

cato CreditAttribution: cato commented

Yes, it's unrelated but you closed the issue I created and asked me to join this issue instead.

Another example, try using your tab key to select a link on the page. Now start typing, every keyup will register a new click in GA.
Great for your statistics but a bit hard to explain to customers that you're driving traffic to when they can't match their stats with yours :)

Basically, the focus gets stuck on whatever element triggered the click the first time. Every keyup after that will trigger the same click.

hass’s picture

hass CreditAttribution: hass commented

Are you using multidomain feature?

cato’s picture

cato CreditAttribution: cato commented

Nope. You can try it out for yourself, I set up a clean install to verify the bug: http://dgabuggverifiering.minimedia.se/node/1
Only change I made was to add a console.log('clicked '+this.href); on line 53 of the js file.
If there's some blatant misconfiguration on my part feel free to point it out.

cato’s picture

cato CreditAttribution: cato commented

Hey @hass, could you verify that this happens for you too?

hass’s picture

hass CreditAttribution: hass commented

Not yet, sorry. Maybe next weekend.

halth’s picture

halth
Primary language Portuguese, Brazil
Location Brazil
CreditAttribution: halth commented

Hi everyone after a long sleep for this issue.

Going back to the original topic...
@jp20 and @hass after all this time, considering your learnings since then, can you point me (and other landing here) in any direction towards solving this "thouchstart registering clicks" problem?

benqwerty’s picture

benqwerty CreditAttribution: benqwerty as a volunteer commented

Could different event actions be set for mousedown, keyup and touchstart? That way the same number of events would appear in Google Analytics but they would be divided into three different actions.

guardiola86’s picture

guardiola86 CreditAttribution: guardiola86 commented
FileSize
touchstart_event_logging_non_existent_clicks-2649834-26.patch449 bytes

Patch attached to fix event.key Tab. Made by https://github.com/donttellmywife

ixismark’s picture

ixismark CreditAttribution: ixismark commented

Thanks for the patch. Tested successfully!

chrisolof’s picture

chrisolof CreditAttribution: chrisolof at Greentech Renewables commented
Version: 7.x-2.x-dev » 8.x-3.x-dev
Status: Active » Needs review
Related issues: +#3191122: Outbound/mailto/download link click events sent multiple times in Chrome
FileSize
google_analytics-8.x-3.x-link-click-bug-2649834-28.patch1.22 KB

Coming in from #3191122: Outbound/mailto/download link click events sent multiple times in Chrome.

Current GA docs on outbound link click tracking seem to suggest utilizing the JS click event combined with the 'beacon' transport method:

Capture outbound links

The attached patch moves the 8.x-3.x branch from jQuery's on() method and 'mousedown keyup touchstart' events to JavaScript's native addEventListener() method and the 'click' event.

We were already using the 'beacon' transport method so no change needed there.

I believe this more closely mirrors the current advice from Google, seems simpler, and resolves all of the extra-click issues in my tests. A similar approach may work just as well in 7.x code. Ready for review.

japerry’s picture

japerry
Location KVUO
CreditAttribution: japerry at Acquia commented
Status: Needs review » Closed (outdated)

With the sunset of legacy google analytics, the 8.x-3.x module is now unsupported. If this is still an issue with the 4.x version, please file a new issue in the queue.