Beyond Load Rules: Leveraging Consent Integrations for Compliance

“Why not just use load rules?” Our team recently released Consent Integrations, and that question has come up a few times now.

It’s a fair question. Load rules control when tags fire, so why consider an alternative like Consent Integrations instead of simply adding consent conditions into existing load rules?

While it may seem simpler to stick with load rules, it’s essential to recognize the potential pitfalls of that approach. By understanding these challenges, you can make an informed decision that prioritizes data privacy and regulatory compliance.

Wait, what are ‘load rules’ anyway?

Load rules are often associated with tag management, but here we’ll use the term more broadly, to include any conditional activation of data based on business logic. Many of Tealium’s products use load rules, albeit with different names. Tealium iQ’s client-side Tag Management, for example, relies on load rules to manage and deploy Javascript tags. Similarly, EventStream and AudienceStream utilize their own forms of load rules, called ‘Event Feeds’ and ‘Audiences’ respectively, to decide when to trigger activations. Load rules (regardless of the name) form the backbone of Tealium’s products, ensuring accurate and efficient data activation in various situations, across the stack.

And what are Consent Integrations?

Consent Integrations is a Tealium iQ feature that allows organizations to easily incorporate consent enforcement into their client-side data activation processes. Unlike load rules, which control when tags fire based on conditions such as page views or user interactions, Consent Integrations focuses exclusively on ensuring user consent is respected during data collection and processing activities.

This feature provides a comprehensive and failsafe approach to enforcing the consent decisions captured by any Consent Management Platform (CMP), including self-built ones. By utilizing Consent Integrations, organizations can improve their data privacy practices, mitigate regulatory risks, improve their downstream data quality, and build trust with their customers by respecting their consent choices.

OK, but what are the actual pitfalls of using load rules for consent enforcement instead of Consent Integrations?

1. Missed Initial Events

In the opt-in model of consent (like Europe’s GDPR), users must explicitly grant consent for certain tracking activities (by clicking ‘Accept’ in a consent pop-up, for instance). That means that a user’s initial pageview won’t have consent for those activities, ever. Even if the customer opts in as soon as the pop-up is shown, the page has already loaded, and those events have already been processed (firing only implicitly consented tags).

If you’re just using load rules, that means partners who need explicit consent will always miss a new customer’s initial event(s) before an explicit decision is made, leading to incomplete data collection. Even worse, missing those initial events means that the original source of the user is lost, which is a big problem for most attribution models.

Consent Integrations ensures tags process all permitted events, even when the initial explicit decision is delayed, without refiring any tags (unless you want to, more on that below).

2. User Error Means Data Leaks

Relying solely on load rules leaves room for user errors that can lead to data leaks. 

For instance, if your rule is: 

    event equals 'pageview'
    AND
    page_type equals 'order_confirmation'

it’s easy to add a simple consent condition

    event equals 'pageview'
    AND
    page_type equals 'order_confirmation'
    AND
    consent_marketing equals true

But if the consent condition is more complex, there’s increased room for error. Consider a slightly more complex rule with a few OR conditions, like:

    event equals 'pageview'
    AND
    page_type equals 'order_confirmation'
    AND
    is_employee equals false
    AND
    consent_marketing equals true

    OR 

    event equals 'pageview'
    AND
    page_type equals 'cart'
    AND
    is_employee equals false
    AND
    consent_marketing equals true

    OR

    event equals 'pageview'
    AND
    page_type equals 'product_detail'
    AND
    is_employee equals false
    AND
    consent_marketing equals true

I won’t include a more complex example, but anyone who’s managed enterprise data knows that the rules can become considerably more complex, no matter how well your data is structured.

This approach quickly becomes difficult to audit and maintain at scale, and the cost of making sweeping changes gets much higher with such fragmented logic as well.

The most dangerous user error here is an error of omission, where the operator of your tool fails to add a consent condition somewhere:

    event equals 'pageview'
    AND
    page_type equals 'order_confirmation'
    AND
    is_employee equals false
    AND
    consent_marketing equals true

    OR 

    event equals 'pageview'
    AND
    page_type equals 'cart'
    AND
    is_employee equals false
    AND
    consent_marketing equals true

    OR

    event equals 'pageview'
    AND
    page_type equals 'product_detail'
    AND
    is_employee equals false

In this case, you’d track all non-employee users on the ‘product_detail’ pages, even if they didn’t consent to marketing tracking! 

Using load rules for enforcement also relies on everyone who sets up a new tag ensuring their load rules have the appropriate consent conditions, every time – if they forget or don’t know about that requirement, you end up activating unconsented data.

Consent Integrations completely separates the consent enforcement from the load rules, making it easy to centrally manage and update at scale. If a tag hasn’t been assigned to a tracking purpose in Consent Integrations, that tag is not allowed to fire until it’s assigned one, dramatically reducing the risk of data leaks due to operator error.

3. Hard to Trigger Server-Side Tools Cleanly and Completely

In the first pitfall (‘Missed Events’) above, we talked about how events are reprocessed and tags generally don’t fire more than once for a given event. 

But for companies who are using a server-side event data activation solution like Tealium EventStream, there are times when you want to trigger server-side activations based on both the implicit and explicit consent decisions for the same event.  

Retriggering the Tealium Collect tag lets you trigger your implicitly consented server-side analytics (for instance) for all users immediately on landing (first Collect call), and then trigger your marketing partners for users who give consent without retriggering analytics (second Collect call).

Consent Integrations provides an option to retrigger tags, and includes attributes that can be used for the above server-side enforcement logic out-of-the-box.

But it’s still fine to use load rules if you update them to fire on consent change events instead of pageviews, though, right?

Though it’s a commonly-used workaround to the missed events in pitfall 1, changing your tag triggers from pageview events to consent change events will double-fire tags – every page on which the user changes a previous decision will fire two pageviews (one on the initial load, and one on the consent change)! That’s not the end of the world, but it’s not great for your data quality either. 

And your load rule logic becomes less intuitive to set up and maintain, since the business logic needs to be constantly adapted to consider consent.

    event equals 'consent_change'
    AND
    page_type equals 'order_confirmation'
    AND
    is_employee equals false
    AND 
    consent_marketing equals true

There can also be product-specific reasons to avoid the use of load rules for consent enforcement – some more advanced systems provide ways for users to fire tags without respecting load rules, like Tealium iQ’s optional array of tag ids in track calls. That’s a helpful feature, but if you’re using load rules for consent enforcement, it’s problematic, because it will ignore the consent conditions along with the rest of the rule.

The Consent Integrations feature works independently from load rules and will apply consent-decision-based enforcement on all tracking calls. Events are reprocessed as appropriate, seamlessly ensuring you maximize your consented data collection.

At Tealium, we are committed to empowering organizations with effective consent enforcement solutions. Tealium iQ’s Consent Integrations feature provides a comprehensive approach to managing tag firing based on consent decisions captured by any CMP, with out-of-the-box support for the most popular CMPs, and the team is already hard at work on a similar enforcement solution for EventStream.

We encourage you to explore the benefits of Tealium’s Consent Integrations and consider how they can help you navigate the complexities of consent-driven data collection, helping ensure privacy, accuracy, and compliance every step of the way.