One of the aspects of website compliance for the EU’s General Data Protection Regulation (GDPR) that can be most confusing is conditional firing. If you have a website that processes the personal data of EU visitors and do not have conditional firing set up, you are almost certainly not GDPR compliant. The reason is simple: if you process personal data like cookie IDs and your tags automatically fire on page load (and by default, they usually do), you are processing personal data without consent and, with few exceptions, are doing so unlawfully.
What is conditional firing?
Conditional firing is when tags are blocked by default and only load once a trigger signal, i.e., the condition, occurs. As it relates to GDPR compliance, this would be when a visitor consents to data processing. This is typically done within tag managers or, for tags that are hard-coded directly onto a page, via conditional firing wrappers. Once a visitor provides consent, a signal is pushed (typically from a consent management platform, or CMP), to the tag manager or tag wrapper to inform them that they’ve been given consent and therefore can proceed to load and process data.
When should conditional firing be used?
Conditional firing should be used any time consent is the legal basis to justify data processing. Conditional firing prevents data collection happening prior to a visitor providing consent, and if they reject any or all purposes for processing. Even if you have a CMP set up and are properly informing users of processing purposes, if your tags are loading and collecting personal data before a visitor explicitly provides consent, you are not GDPR compliant, and your CMP is just a pop-up.
These key factors are why conditional firing capabilities are a critical feature for CMPs. A well thought out solution will make conditional firing straightforward and simple, as opposed to requiring users to manually tweak code for each tag on the page.
What does conditional firing look like in practice?
Conditional firing has separate requirements for tags that are hard-coded onto a page, versus tags housed within tag managers. It’s worth noting that in our experience, most websites tend to use a combination of hard-coded tags along with tags hosted in tag managers.
Hard-coded tags
Tags that are hard-coded are directly embedded onto a site. If you’re not using a tag management solution of any kind, your tags will generally fire automatically as the page loads. As such, to enable conditional firing, hard-coded tags must be placed in a wrapper, which is a special kind of tag that houses other tags. This wrapper receives trigger events—in this case, consent received or denied. Once the wrapper receives consent from the CMP, it will unwrap and allow the tag inside to load.
See Figure 1 below for a sample workflow of how a wrapper would enable consent on page load.
Figure 1: Conditional firing wrapper workflow enabling consent for hard-coded tags
There are some common pitfalls to avoid with conditional firing for hard-coded tags:
- More than one tag per wrapper: While placing all your tags into a single wrapper may seem like a quick and easy way to implement conditional firing, it could cause problems if a visitor only provides consent to some vendors, but not all. If partial consent is provided, you must configure the wrapper to either allow all tags in the wrapper to fire, which is not privacy compliant, or allow none of the tags in the wrapper to fire. Disabling all tags in the wrapper from firing maintains compliance, but potentially interferes with site functionality and monetization.
- Improper configuration: If conditional firing is improperly configured, tags may load prior to consent being given, or just never load, again either not privacy compliant or interfering with site functionality and monetization.
Tags in tag managers
Most tag managers have built-in conditional firing capabilities based on events, ie. when a page is loaded, a user clicks, etc. When a website event occurs, the condition is fulfilled and the tag manager allows the tag to load. When it comes to setting up conditional firing within a tag manager, you must ensure that they are configured to listen for a consent event.
See Figure 2 below for a sample workflow of how a tag manager enables consent events on page load.
Figure 2: Tag manager workflow enabling consent events
A common pitfall with conditional firing for tag managers is improper configuration. If conditional firing is improperly configured—for example, by not setting up a consent trigger in the tag manager or if the CMP is not sending a signal—tags may load prior to consent being given or just never load. Both interfere with privacy compliance, site functionality, and monetization.
What are the exceptions?
The most notable exception to when tags need conditional firing to process personal data based on consent is when the tag is for a TCF-compliant supply-side platform (SSP). TCF-compliant SSPs don’t need conditional firing because, by default, they do not process personal data unless consent is provided.
The first thing a TCF-compliant SSP’s tag does when it loads is look for a CMP. If there is no CMP, it assumes no consent was given and holds an auction without processing personal data. However, if there’s a CMP on-page, it sets off a chain of events:
- SSP waits for CMP to send it the user’s consent preferences.
- Upon receipt, consent preferences are passed to downstream vendors, e.g., DSPs (demand-side platforms), DMPs (data management platforms), etc.
- These vendors check the consent string that is passed downstream by the SSP to verify preferences and determine whether they are allowed to process personal data.
- The SSP holds a programmatic auction and downstream vendors use data they have been granted permissions for to bid and process data where applicable.
See Figure 3 below for an illustration of the workflow of TCF-compliant SSPs.
Figure 3: Workflow for a TCF-compliant SSP
There are some common challenges with SSPs that must be considered and avoided:
- The SSP loads before the CMP: As mentioned above, the first thing an SSP does is look for a CMP. If the SSP loads first, it will not find the CMP and will proceed to run an auction as if no consent was given. This means lowered CPMs and revenue.
- The SSP is not TCF compliant: While most major SSPs in-market are TCF-compliant, if an SSP is not, it may not check for a CMP. A non-TCF-compliant SSP will require additional work to create a method that is able to balance compliance via conditional firing, and any additional latency caused as a result.
You may have noticed that the pitfalls discussed are typically caused by human error. To lower this risk, an ideal solution should automate as much of the conditional firing set up as possible. Always remember to thoroughly test your implementations.