for a POC project for one of my clients, I’m looking for a way to bypass the AdBlocker and make sure the Piwik consent banner will be shown always to visitors from GDPR countries. Since the custom subdomain solution with CNAME DNS entry is not working (Piwik shows an error when I try to load the script), I’m using a custom template in GTM server-side integration to load the script, which allows me to use a custom domain + path. So far so good …
Now we are facing the issue on the Piwik side … Piwik Pro uses visitors’ IP addresses to determine which variant of the file to deliver so that visitors from a GDPR country see the banner, whereas others are opted in automatically. When I use GTM server-side integration, Piwik always delivers a version for non-GDPR countries.
In order to solve this issue I’ve tried to set headers like described in the article below, but unfortunately no luck. Maybe I’m missing something … would be great if someone could help me out, how exactly should the headers need to look, so that the “initial” file with Consent Manager is showing the banner to the visitors coming from GDPR countries.
Hi. Do you mean X-Forwarded-Proto, X-Forwarded-Host, X-Forwarded-For ? Those headers require additional whitelisting of IP addresses on the backend side (because otherwise it would impose a security risk on our end). This service is available only as part of the paid plans. So, if your intention is to set up tracking in the first party domain, you have to disable Ask for consent in countries under the GDPR and UK GDPR setting.
Thanks! I already thought about this as well, but the main objection is I can’t find a way to automatically opt-in visitors outside of GDPR countries. If you have a solution for that, I would really appreciate.
As an alternative, wouldn’t it be easier for Piwik just allow to pass over the visitor IP or visitor country as query parameter?
I guess you’d have to use javascript API to get the geolocation (there are a few vendors offering such a feature) and then Consent Manager API to automatically opt-in.
It doesn’t matter if it’s a param or http header. In both cases, we have to verify the source that is trying to override the original IP address.
Thank @kuba for the quick reply! I’ve already run a few tests yesterday but got confused a little by the API functionality.
For example, there are two functions to set the consent, one of them allows to set “initial consent”. In my understanding, initial consent is supposed to be a “default” value in case the user hasn’t provided any selection yet … however, it’s not the case. The function “setInitialComplianceSettings” overwrite existing values, which now open the question, how is that different to “setComplianceSettings” function. In addition, even if no consent is provided yet, after using “setInitialComplianceSettings” the visitor does not see the privacy banner, instead of a small message on the left bottom corner “you haven’t provided your consent selection yet”. But maybe I just don’t have a clear understanding of how it’s supposed to be used.
Regarding your comment:
It doesn’t matter if it’s a param or http header. In both cases, we have to verify the source that is trying to override the original IP address.
My guess would be … since those types of requests only make sense if someone uses a “proxy” or like myself server-side instrumentation, an API key passed over as a parameter could help solve this issue.
According to the docs, it notifies the system about the fact, that user has already seen the form and did not submit it. It explains the fact of showing a reminder. You can hide the reminder by using setComplianceSettings.
Yes. We verify it currently by using sharing secret. Unfortunately, it’s available only in the paid version.