How to debug javascript client?

[peteruithoven]

There is a guide on debugging the tag manager: https://developer.matomo.org/guides/tagmanager/debugging
But there seems to be no way to debug the JavaScript Tracking Client? Things like page views, events etc.

I noticed that there are no network requests being send when I’m doing things that should trigger events tracking. The console log’s above those calls do get logged.

I tried overriding & logging _paq.push, but that doesn’t seem to work.

var _orgPush = window._paq.push
window._paq.push = (...args) => {
  console.log("matomo push: ", ...args)
  _orgPush(...args)
}

Am I missing something obvious?

[Lukas (Lukas Winkler)]

Hi,

The most obvious thing to check is if the matomo.js is loaded. As you probably noticed, the tracking code sets up window._paq as an empty array where every command is then added and once matomo.js has loaded it executes all of them in order.

Also make sure that you have not enabled DoNotTrack in your browser (and set up the tracking code to respect it client-side)

[peteruithoven]

matomo.js was loaded.

Classic mistake. Trying to pull the tracking code through webpack, where the _paq name probably get’s mangled:

Tracking Code with Webpack

After trying a lot of different scenarios, it doesn’t seem possible to have the Matomo tracking code compiled into webpacker. I have a Rails 6 app with webpacker, which uses webpack to compile all the Javascript into one file. This has the advantage of having all the JS in one place, and only one file to download. While I can get the Matomo tracking code to compile successfully into webpack, it doesn’t seem to send any data back to the server. It’s not a huge deal. I’m just putting the code in…

Putting it directly in the html seems to help.

Good tip checking window._paq, but for me it just contains:
{push: ƒ}

On https://matomo.org/ it does contain a lot of items.

[peteruithoven]

Update: You can add the tracking code through your regular code that you do pull through build looks like Webpack, but there are things you need to keep in mind:

• You can only use a local variable that you fill with window._paq initially, but for logic that’s called later on you’ll need to use window._paq. This is probably because the matomo.js script overrides window._paq, making you’re local variable invalid from then on. Logic that’s called later on could be tracking custom events for example.
• window._paq is not mangled, so that’s usable.

I don’t want to add it through a script in my html because I can’t easily disable tracking on non production environments. In my regular scripts I have faux environment variables that I can check for this.

Regarding debugging:

• The _paq is an object (no longer an array) after matomo.js is loaded, making it useless to check it’s content.
• Only reliable thing seems to be to check network traffic. A trackEvent should result in an immediate network call.