How your cookie banner affects when Distil loads.
Distil works alongside your existing cookie banner. Set up the banner and Google's consent mode as you normally would. This section covers only what that means for Distil.
This isn't legal advice. Each site owner is responsible for their own installation of Distil tracking, and for meeting the privacy and consent rules that apply to them.
What has to wait for consent
-
The tracking script must only run after the visitor
gives analytics consent. With Google Tag Manager, that's the tag's
consent setting (Require additional consent →
analytics_storage). With a direct install, load it the way your banner loads other analytics scripts. - The starter script is designed to run before the banner is answered, so the visitor's landing page and referrer survive until consent is given. If it waited for consent, it couldn't do its job. Whether to run it before consent is your decision under your own privacy policy.
If a visitor declines, the tracking script doesn't load, and Distil records nothing for them.
What your cookie banner must do
The consent setting on the tracking tag only works if your banner:
- Uses Google's consent mode, with analytics consent set to "denied" by default before your GTM tags run. Most banners do this through their GTM template on the Consent Initialization trigger, or with a script placed above the GTM snippet.
- Updates consent first, then sends its event to GTM when the visitor accepts. If the event arrives before the update, Distil misses that first page, and starts on the next one.
If your banner doesn't use Google's consent mode, talk to Distil before publishing. Without it, GTM treats consent as given, and the tracking tag loads before the visitor has answered the banner, whatever the tag's settings.
Loading for new and returning visitors
The tracking tag needs both of its triggers, because consent arrives at different moments:
| Visitor | When consent arrives | Trigger that loads Distil |
|---|---|---|
| New visitor | When they accept the banner, which sends its consent event to GTM | Trigger B, on that event |
| Returning visitor | As the page loads, when the banner restores their earlier choice. Many banners do this just after GTM starts, and don't send their consent event again | Trigger A, on DOM Ready |
That's why Trigger A is DOM Ready, not Initialization or All Pages. Those fire before many banners have restored the visitor's choice, so the tag is blocked and nothing tries again. With banners that set their default late, they can also load Distil before consent. We tested all three on a real GTM container: only DOM Ready worked with every banner that uses consent mode correctly.
A banner that restores a returning visitor's choice very late (seconds after the page loads) can still be missed, unless it sends its consent event again on each page. Most banners do.
Firing option
Use Once per event. It lets the tag try again on each trigger: blocked on DOM Ready before consent, then run when the consent event arrives.
- Never Once per page. The blocked first attempt uses up the tag's one go, so it doesn't run when the visitor accepts. Every new visitor's landing page is lost.
- Never the Consent Initialization trigger. It fires before your banner has set consent, so the tag can run before the visitor has answered, even for visitors who then decline.
Comments
0 comments
Please sign in to leave a comment.