@kdekooter opened this Issue on March 15th 2019

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=

image

@Findus23 commented on March 15th 2019 Member

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 commented on March 15th 2019

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 commented on March 15th 2019

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

@tsteur commented on March 16th 2019 Member

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 commented on March 16th 2019 Contributor

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 commented on March 16th 2019

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 commented on March 18th 2019 Member

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 commented on March 19th 2019 Member

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 commented on March 19th 2019

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

@Shirkit commented on March 21st 2019

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 commented on March 21st 2019 Member

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 commented on October 3rd 2019

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 commented on January 30th 2020

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 commented on January 30th 2020

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 commented on January 30th 2020

@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.

This Issue was closed on January 30th 2020
Powered by GitHub Issue Mirror