However, when cookie consent is withdrawn only one set of cookies are deleted (.example.com).
The www.example.com cookies remain including the mtm_cookie_consent cookie which causes .example.com cookies to be recreated when refreshing the page.
Setup MTM container using the following settings:
Enable Link Tracking
Enable Cross Domain Linking
Require Cookie Consent
Cookie domain set to .example.com
Register As Default Tracker
Refresh the page and check cookies created (There should be cookies for both www.example.com and .example.com when reproducing - in my testing I am using a website with a different subdomain of static.example.com)
It is expected here that cookies should only be set to .example.com
_paq.push(['forgetCookieConsentGiven']); and refresh the page. Check cookies, there should be cookies that remained for www.example.com:
When not using a cookie domain and having Require Cookie Consent enabled, the Cookie Consent works as expected. It only creates cookies for the subdomain that is being viewed and the cookies are deleted when withdrawing cookie consent.
@Starker3 can you reproduce this with standard Matomo tracking code alone?
BTW In step 3
Refresh the page and check cookies created (There should be cookies for both www.example.com and .example.com)
I'm not sure why there should be both cookies set. I would probably expect it to be set only one of them. Or not sure what you mean here?
@tsteur What I mean is that for reproducing the error there should be cookies for both .example.com and www.example.com
You are correct in that we would expect there to only be one set of cookies for .example.com
The cookies set directly after giving cookie consent are for www.example.com and the .example.com cookies are created after refreshing the page.
I'll try to reproduce using the standard tracking code.
I'm thinking it might be expected behaviour and it might not even be able to remove
static.example.com cookies but it's bit hard to understand as sometimes mentions
www. but images show
@tsteur That's just the subdomain that I was testing on. The actual site I tested is for example: static.example.com (I don't have this site setup to use www)
But I can maybe set that up to make sure it can be done the same way using www
(I've edited the original report above to make this clear)
I tested using a subdomain www and the same occurs. Will test using the standard tracker as well shortly.
@tsteur I've been able to reproduce this with the standard tracking code with the following added:
Would you like me to recreate this bug report in Core?
FYI - In some cases the cookies left behind are reversed (I.e. in the example above it was the subdomain cookie
www.example.com that was not removed)
It seems that having some plugins active or not may cause the other cookies to remain when using
.example.com instead of
The following is required in the tracking code in order to reproduce:
_paq.push(['requireCookieConsent']); _paq.push(["setCookieDomain", ".example.com"]);
Step 1: Visit the web page from a subdomain (In this example
Step 2: Execute
_paq.push(['rememberCookieConsentGiven']); from the console
Step 3: Confirm that cookies were created for the correct subdomain (
www. in this example):
Step 4: Refresh the page and confirm that cookies for the cookie domain specified is created (
Step 5: Execute
_paq.push(['forgetCookieConsentGiven']); from the console
Only cookies for the cookie domain specified are removed:
Step 6: Refresh the page, all cookies that were removed are created again because of the presence of
This can be reproduced on any subdomain of a website as long as the top level domain is set as the cookie domain. The only required settings are a top level domain set as cookie domain and cookie consent required.