Matomo tracking seems pretty much unusable with the default setup it is providing due to how adblockers behave, but on the other hands massive amount of LLM training crawlers and other bots make using a website's access logs also not a viable option to have even a basic statistics of website visitors, so I made some changes to Matomo tracking that go around the first issue.
This is a short checklist on fixing it to see a more realistic view on website's visitors. Changes are created against common adblocker behavior by observing what things adblockers do block.
- Check that default piwik.php and piwik.js filenames are not being used. With piwik.php, symlinking it to something like p.php is useful.
- In case of the piwik.js, more advanced approach is required,
action_name
and references topiwik.php
should be changed (e.g. to p.php if you used that),action_name
can be likekissmygdpr
. - Files piwik.php and piwik.js should not be edited, do a symlink e.g. in case of piwik.php, and in the case of piwik.js, create a PHP file that opens the piwik.js file, and generates something like
whatsthis.data
using strtr function to replace the things that hit adblockers. Using an extension like.data
ensures that pattern matching to.js
extensions is not picking the file. - Configure your webserver to serve the
.data
file as JS mimetype. - Edit your tracking script to point to the generated and files produced by symlinking.
- Use the setting
_paq.push(["disableAlwaysUseSendBeacon"]);
in the tracking script, beacons are likely to get blocked by anti-tracker settings. - To pass Matomo file integrity checks, use the
fileintegrity.ignore
inconfig.ini
file with the files you want to ignore.
By using these steps, Matomo tracking should finally be usable once again in the world of modern web.