I have configured and successfully used the sGTM with Stape for some time. To comply with the GDPR requirements, I am using Cookiebot. Cookiebot scans my website monthly and detects any new cookies.
Since the last scan, a new cookie “_xsd” has been detected. This cookie seems to be set via the server-side subdomain. Therefore, my assumption is that it originates from the sGTM container. The listed country is “FR”, meaning France. Server-side, I am only using GA4 and the Facebook API. The other GA4 cookies are also detected with the country of origin “FR”. So, I assume it has something to do with Google and the server-side implementation. The Cookiebot and Stape support teams cannot identify this cookie. It is also not set when manually accessing my page.
During my research, I used Google Search.
Under the term:
Cookiebot “_xsd”
I find numerous websites that also use Cookiebot and server-side tracking. In these cases, the _xsd cookie is also detected and listed as “unclassified” without any further description. I am at a loss.
Can anyone help me with this?
Thank you very much and best regards,
Sebastian
This is not a cookie; it is service information stored in sessionStorage to ensure the correct operation of the custom loader and protect against blockers.
thank you for your reply. Just for my understanding: Where does the whole thing come from? Is this from Google or from Stape?
I’m really happy that someone was finally able to explain it to me.
Many many thanks!
I just wanted to check in and ask: What steps did you take to prevent the sessionStorage service from setting information before user consent was given?
I couldn’t find anything helpful about this issue in the documentation or guide.
Just wanted to share my experience in case it helps someone else. I contacted Stape support about the cookie issue. The first response I got wasn’t very helpful, to be honest. But luckily, I got in touch with another support person who was much more knowledgeable.
They pointed out that in order to stop the cookie from being set, you actually need to disable Stape Analytics.
If you are using Stape Analytics, the _xsd entry in localStorage will be set along with the container load, this is used to determine if the user has an adblocker.
If you don’t want this to be set before user consent - you only need to load the container after the consent state is known. + remove the entry from localStorage on every page load if consent is denied if you don’t want this entry to be set. Or don’t use Stape analytics
Thanks for your thought but load the container after the consent is known was not recommended by your collegue.
If you need this record not to be setted for compliance purposes, then yes, unfortunately, you will have to disable Stape Analytics.
It is better to load the GTM in any case and to configure the tags to work on the status of the consent.
Regards,
Stape Support
I don’t really understand the why, but I guess if I load the container after consent, I can not benefit from the anonymous cookieless pings from for example GA4 which are allowed to send before consent.
I don’t really understand the why, but I guess if I load the container after consent, I can not benefit from the anonymous cookieless pings from for example GA4 which are allowed to send before consent.
Thats correct, in which case you’ll lose this cookieless pings GA4/GoogleADS. But in some regions they are considered not legal with a declined consent.
Your second suggestion I do not really understand. How to remove the entry from localStorage on every page load?
But luckily, I got in touch with another support person who was much more knowledgeable.