in my installation (2.4B3) it

1. does also not work "out of the box"
   for "normal" left mouse button click (LMBC) on downloads (same window)
   => nothing could be find in visitor log

but it seem to should work without having to do anything?

By default, the Piwik tracking code enables clicks and download tracking.

http://developer.piwik.org/api-reference/tracking-javascript#disable-the-download-amp-outlink-tracking

2. tracking of LMBC on outgoing links is working fine
   => link with symbol appaers in visitor log
   (tested with links with target="_blank" which opens in new window)

1. yes it definitely should work if your JS code has "enableLinkTracking" in it

If you're a developer and you know how we can track right click, middle clicks on outgoing links, please post a link or info here, thanks.

many of us reading this know how important this feature is: it would be a beautiful thing to measure right clicks and ctrl+click, middle clicks, and track those as Outlinks when applicable.

the good news is that there seems to be a possibility to do it. several solutions are discussed in this SO thread.

note: it will be enough to only support this feature modern browsers.

moving to 2.14.0 so we take a stab at this!

I don't understand. Tracking the right-click doesn't seem like a big thing but how do we know a user selected "Open in new tab" in the context menu or so?

@tsteur +1. We can track these clicks as outgoing link only because neither browser doesn't offer any API(or something similar) for this option.

Tracking the right-click doesn't seem like a big thing but how do we know a user selected "Open in new tab" in the context menu or so?

Here the idea is to assume that whenever there was a right click, it was followed by user. Since we can't determine whether right click leads to the link being opened, let's just assume it is opened.

I'm not sure about that. This would have to be a setting or so since it depends on the website / application. Some might eg define a custom context menu, it might be different for single page applications, etc.

It also depends on the website what users use the right click for. Eg on some sites users might tend to use it for "translate", on some more technical sites people tend to maybe use it for open in new tab, on some sites it is probably barely used since the users are not so advanced, ... Also the behaviour might be different for outlinks and for downloads.

If anything at all I would maybe provide an "opt-in method" for this. If feedback is good one can maybe change it after a few months to "opt-out".

I changed the title to get maybe better awareness of other users what is about to happen here. Feel free to comment feedback...

If anything at all I would maybe provide an "opt-in method" for this. If feedback is good one can maybe change it after a few months to "opt-out".

I still think we could opt-in and provide a opt-out in case it really poses problem for some users. That's because in this issue the scope is only for right clicks on Downloads and Outlinks which will be a very small part of all right clicks. eg. Users who right click to "translate" most of the time will right click anywhere in the window and likely not on a download link or outlink... Can you think of an actual use case where users would right click on outlinks/downloads and not want to open them in most cases?

I still think we could opt-in and provide a opt-out in case it really poses problem for some users

Opt-out really poses problems for some users too. I don't understand the problem with first making it opt-in and later opt-out? If you do make an opt-out by default it is basically a breaking change whereas opt-in first is the opposite of deprecating it. We could introduce this new feature, await more feedback etc and later make the switch so nobody will be surprised about a sudden change in behaviour. If you do make opt-out by default you don't give anyone the chance to be aware of this and to react quick enough etc.

For example one might only copy the outlink / download and send it to someone else (I do that sometimes eg to share it with other people etc) (one could still count this as a click in a new tab but not really), I sometimes just copy the text like this, I actually use it sometimes to search for those words and I very often use it for "inspect element" (which is a minority, only developers etc would do that). And I'm sure it often happens by accident or that users right click multiple times on it until they actually open it. In most cases it is probably a "link in new tab" but it always depends.

I wonder how many people actually use context menu + open in new tab as I'm sure most users don't use it at all. I know too many users who do not even use tabs at all (or open in new tab). There are also many advanced (technical) users that might rather use ctrl/cmd + left click or a middle click to open in new tab/window (which can be detected from what I know).

I'm not saying we should not track this at all, but if we do it should be at least opt-in for now.

you are right, there is no problem making it opt-in first and later
opt-out. This is a good solution let's do it 👍

turns out there was always such an opt-in already that can be easily reused. tracker.enableLinkTracking(var enable = true). enable can be set to true to detect middle clicks and to treat them as a "left click". We will reuse this to also treat "right click/open contextmenu" as "left click"

It is within the scope of this issue to track all of right click, middle click and Ctrl+click.

We will track in newer browsers if someone opens the context menu (right click, or ctrl+left click on mac, metaKey+left click on windows, ...), middle click and in some browsers (tested works in latest Chrome + Firefox, does not work in IE10) we also track if someone opens it directly in a new window (ctrl+ left click on windows, metaKey+left click on Mac)

fyi: updated JS client doc in matomo-org/developer-documentation@84934d7

This issue has been mentioned on Matomo forums. There might be relevant details there:

https://forum.matomo.org/t/download-tracking-fired-without-actual-download/47937/2