Some questions about using the Matomo Proxy Script together with Image Tracking

So the point of the Matomo Tracker Proxy is to hide the host Matomo is running on, the point of Image Tracking is to enable tacking when the visitor has JS disabled.

Since image tracking does not seem to be possible the “proxy” way, the Matomo host is revealed by the image tracking code even if using the Matomo Tracker Proxy for tracking by JS, which is a huge disadvantage.

So the only way to hide the Matomo host completely is to do without image tracking. Is that correct?

I have made some tests with uBlock origin (in Easy Mode) with/without proxy script and with image tracking and have come to the following conclusion:

  • Using default tracking (without proxy script) leads to a blockage of the Matomo host and since JS is not disallowed, image tracking is not done, hence the visit is invisible to Matomo.
  • Using tracking through the proxy script at least does not show the Matomo host in uBlock origin, but the on-site matomo.js is blocked and since JS is not disallowed, image tracking is not done, hence the visit is invisible to Matomo.

Access with JS disabled (tested with NetSurf browser on a computer and Bromite browser with JS disabled on Android) resulted in image tracking being done, so at least that one worked.

My current point of view is, that although the Matomo host gets revealed by the image tracking code, it’s worth it to combine the use of the proxy script and image tracking, because that way at least the Matomo host does not get easily revealed to uBlock origin users on first sight, as the image tracking code is only visible in source view.

Any thoughts on this?

The perfect solution would be image tracking the proxy way, but I guess that can not (easily or at all) be accomplished, right?

One more thing:

What up with the different versions of the image tracking code using a paragraph or not?

I mean

<img src="{$IDSITE}&amp;rec=1" style="border:0" alt="" />


<noscript><p><img src="{$IDSITE}&amp;rec=1" style="border:0" alt="" /></p></noscript>

as both are shown in the Matomo FAQ?

Or is it meant that you always need the paragraph when putting the code into the noscript section?


I don’t get this point. Image tracking means embedding an “image” into the page that just loads the normal tracking API request. The tracker-proxy just takes an request to the tracking API and forwards it to the Matomo server. So as long as you use the tracking proxy URL in the image tracker, it should work perfectly fine.

Having a <p> or not changes nothing. The major difference is if you put it in a <noscript> or not which means it will only be loaded if the browser has JS disabled.

I have just tried with exchanging the regular image tracking URL with the proxy URL and it just doesn’t work.

I’m not sure if it is a problem with the module or its proxy script implementation (current WP-Matomo 1.0.22 module for WordPress and Piwik Web Analytics 1.1.0 module for an older PrestaShop 1.6 installation) or something else, but there must be a reason why the Noscript code field gets removed when selecting the proxy script in the WordPress module and why the shown image tracking code is the same (= regular image tracking URL to the Matomo instance) for default and proxy script in the PrestaShop module.

But I think I am going to remove image tracking again anyway, because it just records the visitor and how many pages he visits, but since the visited pages are not identified, it doesn’t really make much sense at all.

Might be. Maybe @WP_PiwikDev knows more.

I have done some further tests using the latest code from the matomo-org / tracker-proxy Github repo and image tracking by accessing the proxy script is indeed not working, which may be confirmed by the following note in the README file:

the <noscript> part of the code at the end is removed, since it is not currently used by Matomo, and it contains the (secret) Matomo URL which you want to hide

Accessing the img link that is provided by the <noscript> code shows the pixel, but the visit is not recorded, which may have to do with caching (since “pagespeed” shows up as part of the gif image name)?

Hopefully @WP_PiwikDev passes by and throws some light on that matter. It’s not really important, but requires some clarification.

BTW In case anybody should be wondering why the WP-Matomo (WP-Piwik) module v1.0.22 does not seem to be working with the setting Enable Tracking » Add tracking code: Use proxy script:

It’s because there is an error in the last line of the code (matomo.js instead of matomo.php).

The solution is to first select Use proxy script and Save changes, then switch to Enter manually, make the change from matomo.js to matomo.php and Save changes again.

I already took a look, but don’t know how to file a bug report for that module as I’m not registered at, so maybe someone else having access may want to do that.