Pageview duplicates each visit to a page

We are tracking 3 site (development, QA and production). We installed correctly Matomo Tag Manager with the respective site_id, container_id and so on and created the same tags, variables and triggers on the 3 tag containers.

In the development environment we noticed that on the Analytics the pageviews were duplicated (i.e. if you were visiting the homepage, in the dashboard, it appeared as if you had visited twice the same page). We made a fix and it worked. Now the fix is in the QA environment (that is, the code is there) but we are experiencing the same issue of duplicated pages. I have checked and the tag, variables and triggers are the same for the Development site and the QA site. Any explanation about this oddity?

Btw, if we open the debug/preview mode for the Development website, I can see the Matomo event banner at the bottom of the page, whereas if I open the debug/preview mode for the QA website the banner does NOT appear

Is there any error in the browser console?
Also, what is the whole code you inserted in your page to integrate Matomo?
Do you use sometime _paq variable during bootstrap or during tracking?
How many Matomo configuration variable do you use in your container?
Can you share the configuration of pageview trigger(s) and tag(s)?

-no errors in the browser console

  • this is the whole code to install MTM
              __html: `var _mtm = window._mtm = window._mtm || [];
              _mtm.push({'mtm.startTime': (new Date().getTime()), 'event': 'mtm.Start'});
              var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
              g.async=true; g.src='${NEXT_PUBLIC_MATOMO_CONTAINER_ID}.js'; s.parentNode.insertBefore(g,s);`,
  • I do not use any _paq variable in any part of my application, however I am using the ‘@socialgouv/matomo-next’ package in order to be able to track the different URLs of my application (since in nextjs they are considered a single page app)
  • I use only 1 Matomo configuration variable (that is the same for all the containers)
  • also the pageview trigger and tags are the same (for the DEV container more tags and triggers are being tested today, so you will see some differences, but the tags and triggers for the pageview of matomo Analytics are the same)

could you also tell me why the debug mode is not working for the QA container? I am using the same browser and I can see the matomo cookie installed, but no banner shown for the QA container

Hi @francesca_gia

As this is managed by some kind of CMS, are you sure the code is present only once on the page?
Also it seems you use some kind of single page application (I see a history change trigger): Can you confirm that the page view doubloon appears on first page view and on history changes?

Are you sure the versions tested in each environment are the same? Be careful, the screenshots you provided show the state of the draft, not the state of the published live version. Also, which version is in debug mode? Also, are you sure you try to preview the good container? (when you preview DEV, you have to add ?mtmPreviewMode=931LmVSK to URLs whereas when you preview QA, you have to add ?mtmPreviewMode=NvEYI357 to URLs)

You did not answer to:


yes I replied to the errors in the browser console: It is the very first line of my previous answer :slight_smile:

yes, it is a SPA (we use Nextjs), but I am sorry I am not able to distinguish if the doubloon appears on first page view or on history change… can you explain me how could I see this difference?

regarding the draft version: I am not able to see that one is a draft version. I am pretty sure I have published all the changes I made :frowning:

And regarding the preview mode I am using the right URL “extension” but the banner does not appear :frowning:

→ Is there some case where there is no doubloon?

→ Try (but don’t valid) to create a new version. If there is some changes, then the draft is different than the last version…
Also, to be sure which version is in preview, disable the preview mode, then re-enable it. If you enable the preview in the left menu, then the draft will be in preview. I you enable via the bug icon in the versions page, then the preview will be enabled for this version.

→ Is there some case where there is no doubloon?

yes, as I explained, it works in the DEV container

→ Try (but don’t valid) to create a new version. If there is some changes, then the draft is different than the last version…

as explained, I was pretty sure I had published after every change and in fact I do not see any change compared to the previous one :frowning:

No, I wanted to ask, for the same environment, for a single visit, is there some cases where there is doubloons and other cases where there is no…

ah, ok… no we tested with different browsers and for the DEV container we were satisfied with the results :slight_smile:

Double pageview means _paq.push([‘trackPageView’]); gets executed twice.

Since you’re implementing via Tag Manager, there are only two possible explanations:

  1. Duplicated trigger
  2. Duplicated container tag

No other option.

If you’re 100% sure it’s not the trigger… then it’s the container tag that gets duped.

1 Like

hi @Kal, I am not sure about how I could duplicate the container tag :face_with_raised_eyebrow:. Could you please suggest me how I could check this option? In the code I am 100% confident there is only ONE script of Matomo Tag Manager and, as you can see from the screenshots, there are only 2 triggers.

And in any case, I still cannot see the debug banner for the QA container

Is your QA page public accessible?

1 Like

sure, this is the link (with the slug for the debug mode)

It works well:

Check your triggers.

This is what’s happening in the network panel at the first pageview:

We have:

  • Container
  • JS Matomo library
  • Pageview Hit
  • Heatmap functionality hit

So it’s all right up until now. Nothing’s duped.

But then let’s check what happens when you click somewhere, let’s say the first menu link…

1 click = 3 hits

You’re firing the tag multiple times… so the issue definitely lies in the trigger’s configuration.

After only 1 click: