Matomo: Move `action_name` query parameter off first position so requests do not get ad-blocked

[kdekooter]

Despite being on the exact same domain as the website uBlock still blocks calls to matomo. It seems to block based on the phrase .php?action_name=

[Findus23]

Correct, the EasyPrivacy list used by ublock and others is blocking the .php?action_name string.

So there is no bug in Matomo and everything is working as intended :slightly_smiling:

[kdekooter]

Agreed that is not a bug. But is being blocked by an adblocker intended? Can we somehow work around this? I set up matomo with the specific purpose of not being blocked by privacy addins.

[kdekooter]

Maybe moving it to the second position in the query string would suffice.

[tsteur]

I think there's not too much point cause ad blockers will eventually just find a different way to detect it. It would maybe work for a few weeks and then fail again.

[fdellwing]

It would maybe work for a few weeks and then fail again.

EasyPrivacy list still does not block matomo(js|php), so there is hope.

[kdekooter]

Yes but it is quite sensitive to .php extensions.

I ended up working around this by letting the client send tracking calls to /mtm instead of /matomo.php and rewriting this back on the server side with nginx:

location /mtm { 
   rewrite ^/mtm(.*)$ /matomo.php$1 break; 
}

[mattab]

Let's leave the ticket opened as it is a valid request (at least for some of our users, not all would agree) :ok_hand:

[tsteur]

btw you can also just POST instead of using GET requests and the action_name will be gone. Something like _paq.push(['setRequestMethod', 'POST']);.

You won't be able to use log analytics to replay tracking requests with that, but most people don't do this anyway. I would say this issue is pretty much resolved and any further solutions would probably need to be developed in some plugin as we likely won't change it anyway.

[kdekooter]

Thanks @tsteur I tried that but it turns out POST requests to this URL are blocked (by Brave) as well.

[Shirkit]

If there's one thing I've learned is that blockers will block you. Their goal is to block analytics and tracking on client-side, so if you try to trick them, they'll just find a workaround.

The people who put out the lists do no want to be tracked online. It all started with annoying ads, then when remarketing showed up, now all analytics suffer as well.

[tsteur]

If there's one thing I've learned is that blockers will block you. Their goal is to block analytics and tracking on client-side, so if you try to trick them, they'll just find a workaround.

The people who put out the lists do no want to be tracked online. It all started with annoying ads, then when remarketing showed up, now all analytics suffer as well.

my thinking too 👍

[negreanucalin]

I think a more general approach should be made. For example the POC made for this covers all parameters, ad-blocking softwares are changing and more rules are being made.
For example uBlock Origin (v 1.22.4) matches idSite, send_image etc see here
I think this should be closed in favor of the POC.

[kdekooter]

Unfortunately the POC issue was closed because "we don't really want to work around ad blockers / privacy lists in such a way at this stage".

Leaving us with blocked requests, severely limiting the reliability of analytics data.

[Shirkit]

I'll repeat my comment: the more sneaky ways analytics try to track users, the more ad blockers will push back. You don't seem to understand this. Grab server side tracking data and combine it into your analytics. For now, since they'll start to scramble that data as well.

[kdekooter]

@Shirkit Totally agree with the sneaky argument.

I tried to be not-sneaky by self-hosting an open-source analytics solution on my own domain. I did not expect to be defeated by an ad-blocker while tracking my own authenticated users.

[dave-dm]

I think there's not too much point cause ad blockers will eventually just find a different way to detect it. It would maybe work for a few weeks and then fail again.

that's completely false. you just need to obfuscate based on some seed that is unique to each mamoto user.

ad blockers can only block file names and urls, things that are easily regexable. anything else is too much overhead for an adblocker.

it's extremely trivial to get around ad blockers for analytics purposes and mamoto should make it easy to do so, because that's one of the main reason to use it.

[sgiehl]

@dave-dm you can simply force the tracking to use POST requests. So no ad blocker will be able to block the requests based on GET parameters

[dave-dm]

@dave-dm you can simply force the tracking to use POST requests. So no ad blocker will be able to block the requests based on GET parameters

thanks that works, I couldn't find anything about how to solve it on google.

[kdekooter]

Blockers like PrivacyBadger block POST requests as well...

[dave-dm]

Blockers like PrivacyBadger block POST requests as well...

fortunately it's not that popular yet, POST seems to bypass the most popular ones. I think mamoto should add optional random obfuscation of the 'request' variable with a custom seed initialized at installation. as well as custom obfuscation of mamoto.js. that would make it forever ad blocker proof, and really wouldn't be that hard.