Mtm_consent cookie is not setting in browser after rememberConsentGiven

Support & Bugs
,
1

Hi,

I am trying to enable/disable Matomo tracking based on user consent and use Matomo cookies to remember the user’s choice.

I am using ngx-matomo-client with requireConsent: 'tracking'.

When the user accepts consent, I run:

public async grantConsent(): Promise<void> {
  this.matomo.rememberConsentGiven();
}

When the user rejects consent, I run:

public async revokeConsent(): Promise<void> {
  this.matomo.forgetConsentGiven();
}

The behavior I am seeing is:

  • When consent is revoked, the mtm_consent_removed cookie is created.

  • When consent is granted again, the mtm_consent_removed cookie is removed.

  • However, no new mtm_consent cookie (or any other consent cookie) is created after granting consent.

Is this the expected behavior in Matomo?
Does Matomo only remove mtm_consent_removed and then rely on normal tracking cookies (_pk_id, _pk_ses, etc.) instead of creating a separate consent-granted cookie?

Also, is calling only rememberConsentGiven() sufficient, or should setCookieConsentGiven() also be called before it?

Thanks!

2

Hi @Satyam_Kumar no, that’s not the expected behavior. With requireConsent: ‘tracking’, rememberConsentGiven() should both delete mtm_consent_removed and write a fresh mtm_consent cookie (default ~30 years, value = a timestamp). The mtm_consent cookie is how the tracker remembers consent across page loads - without it, on the next navigation the user effectively hasn’t consented again and tracking is blocked. The fact that mtm_consent_removed gets written/deleted as expected while mtm_consent never appears means cookies aren’t globally blocked, something specific is suppressing this one write.

Could you share the URL where this is happening? I’d like to inspect the live tracker config and cookie writes directly, that’ll narrow it down much faster than guessing.

3

HI @raphael_martez The URL can be only accessed with in our company internal network. so you will be not able to access it .

4

/*!!! pluginTrackerHook */

/* GENERATED: tracker.min.js /
(function() {
function a() {
if (“object” === typeof window && !window.Matomo) {
return
}
window.Matomo.on(“TrackerSetup”, function(b) {
b.setCookieConsentGiven = function() {}
;
b.rememberCookieConsentGiven = function() {}
;
b.disableCookies()
})
}
if (“object” === typeof window.Matomo) {
a()
} else {
if (“object” !== typeof window.matomoPluginAsyncInit) {
window.matomoPluginAsyncInit = []
}
window.matomoPluginAsyncInit.push(a)
}
}
)();
/ END GENERATED: tracker.min.js */

@raphael_martez this code I found in the downloaded matomo.js file.

5

Perfect, now I think I know what is going on.
You have “Force tracking without cookies” enabled under Administration → Privacy → Anonymize data, right?

If this is true I see two paths forward:

  1. If you actually want cookie-based consent persistence: disable “Force tracking without cookies” under Administration → Privacy → Anonymize data. rememberConsentGiven() will then write mtm_consent normally and your code will work as written.

  2. If the privacy setting has to stay on (legal/policy reason): cookie-based persistence of consent is fundamentally incompatible with it. Store the consent decision client-side (e.g. localStorage) and on every page load call _paq.push([‘setConsentGiven’]) before any tracking calls, that re-arms tracking each session without relying on Matomo’s cookie persistence, which the plugin actively prevents.

1 Like
6

Hi @Satyam_Kumar I’m curious, where you able to fix it? :slight_smile:

7

You have “Force tracking without cookies” enabled

Hi @raphael_martez Yeah, that was the main cause. Thank you so much for your help ,you really saved me. I have been knocking my head against this issue for a couple of days and couldn’t figure out what was wrong.

1 Like