Consent and Launch

I’ve pondered, written, deleted, re-written, forgotten, re-written, merged, and then deleted this article a bunch of times before. What you’re reading today is like the 50th iteration. The kudos go entirely to my colleagues in product management and engineering, who (in my opinion) are doing a blast of a job with Launch and the Extension that they are building around it.

To tell you the truth, only since the Experience Cloud ID Service Extension supports opt-in have I considered this whole complex of topics learnable. Before, I simply dabbled a bit, then threw the baby out with the bath. Hence, the frequent deletions of half-finished articles. Anyway, now that this makes sense, follow me experimenting and making sense with it.

Stage

The whole topic is about how your friendly marketer wants to use her tools transparently, according to the “say what you do – do what you say” mantra.

Not only since GDPR has she decided that she wants people to be able to opt out of targeting and tracking, and for some of your sites, she wants to implement opt-in.

The former tracks until people say stop, whereas the latter doesn’t until people give the OK.

Note that I will not look at this from a legal standpoint at all. First, IANAL, and secondly, you shouldn’t, either.

The ECID Service Extension offers a bunch of settings around consent, such as whether the site should use opt-in or not.

I want to step through all of those, one by one, baby steps. I also want to add other stuff, like Analytics and Target, when it makes sense.

So, let’s start really easy.

Step 1 – ECID Service

When you create a Library that contains just the Core and ECID Service Extensions, you are not using opt-in. The default setting in the Extension is ‘None’, meaning it’ll presume it has the right to go for it.

Load the page and you’ll see it working.

That is what ECID does. It makes some calls, sets some cookies (one of them on the demdex.net domain, for cross-site targeting), and generally makes itself at home in my browser.

Now let’s set it to ‘Opt-in’ and see what happens.

As expected, I would say. Note that I did not delete any cookies that were set in the first test! The ECID simply did not do anything. Good!

There is a third option, to “determine at runtime”. This allows you to use a Data Element to decide, when the page loads, whether opt-in should be enabled or not.

The Data Element can be any type, but it must return boolean true or false.

No need for screenshots, here, because true behaves exactly like setting ‘Opt-in’ to ‘Yes’, and false behaves like ‘No’, the default.

The next three settings will tell the ECID Service Extension to store the state in a cookie. I don’t know why.

So I make a new Data Element, that can be used for the third option, and this is the perfect moment to state that Javascript’s way to handle types makes me hope no car, train, or other vehicle will ever be programmed with Javascript!

Yes, I know what a boolean is, and when something is a String. I did this:

Seriously! I mean, who builds something like that?

Anyway.

Now I can change a cookie and switch between opt-in and default, easily.

The funny thing: I still do not know what those storage settings do, exactly. There is clearly no cookie being set.

Let’s park this and move on.

The next two options are about permissions, i.e. what Launch is allowed to do.

There are two ways to set these.

1. Via Data Element — “Previous Permissions”, or
2. by ticking the relevant boxes — “Pre Opt In Approvals”

Previous Permissions win when there is a conflict, but the idea for both is to tell Launch which of the applications it should consider opted-in.

The way I see it, “Pre Opt In Approvals” are there, so you can manually set things like “we’re waiting for visitors to say Target is OK, but we’re tracking them automatically” as your default policy.

There are 5 permissions in that list (“AAM”, “ECID”, “MEDIA_ANALYTICS”, “ANALYTICS”, and “TARGET”), meaning Launch can be told whether to consider Audience Manager, the ECID Service itself, Analytics, Media Analytics, or Target opted-in.

You can do the exact same thing with “Previous Permissions”, it’s just a different format. And you can use the exact same format for the “Pre Opt In Permissions”, too, in the box underneath the checkboxes.

So, let’s pre-approve ECID

This is what happens:

As expected.

If we tick all the boxes, we can see what the JSON object should look like:

"preOptInApprovals":{"aa":true,"aam":true,"ecid":true,"target":true,"mediaaa":true}

This is precisely what the Data Element has to return for the “Previous Permissions”, or if you use a DE for “Pre Opt In Permissions”.

Let’s try this. I’m setting to pre opt-in via checkbox, then provide {"aa": true} for “Previous Permissions” via Data Element. The result:

Perfect!

You only have to return those elements that should be approved.

Time for the next level: more Extensions!

Step 2 – Analytics

Let’s create a “Pagename” Data Element (for testing, I am using the most excellent Core – Constant Data Element Type), install the Analytics Extension, provide Report Suites, and correct the char set and currency settings as appropriate.

Let’s also create two Rules, one to set the Pagename using our DE, and one to fire the beacon.

Let’s then provide {"aa": false} for “Previous Permissions” and see what happens.

Cool!

The Analytics Extension does everything it usually does, but it refuses to send the actual call.

And if we set {"aa": true}, everything works as usual.

Note: if you are using server-side forwarding to send Analytics data straight into Audience Manager, the “aa” setting will control both! It turns out that I was wrong, see below for Jonathan’s comment.

Step 3 – Target

So… let’s install the Target v2 Extension and make a Rule that loads Target and fires a page load request.

Careful, though!

When you install the Target v2 Extension, you have to set “GDPR Opt-in” to “Enabled”!

If you don’t, Target will simply ignore any opt-in malarkey that is happening in Launch!

Here is what it looks like when you do it correctly, and when you do not pre-approve Target.

Same as with Analytics: everything happens as usual, but the actual request is suppressed.

Notes

Wait! One more test is in order: what if I set “GDPR Opt-in” to “Enabled” in the AT Extension settings, but “No” in the ECID Service Extension?

No panic! Target fires as expected! And so does Analytics!

This was pretty easy, wasn’t it?

What I like about it all is that it is really easy to embed Launch and all applications into an existing consent management framework.

It is literally as easy as creating a Data Element that reads the relevant permissions and hands them back to Launch in the JSON format shown above.

Example: for one customer that we work with, we read two cookies. One tells us whether Analytics is OK, the other says the same about Target. So we have a Data Element that reads both cookies, then returns the structure, as needed.

If the visitor has approved Analytics, but not Target, the DE returns {"ecid": true, "aa": true, "target": false}, and that’s it.

Note how I completely ignored the pre-approvals for AAM and MEDIA_ANALYTICS. I do not use the AAM Extension, instead I use server-side forwarding. And the other is not my thing at all.

More Notes

You know as well as I do that that’s obviously not it. The Prince of Darkness is in the dastardly details.

One big subject that really annoys a lot of Analytics people: how exactly do you handle the very first page load for a new visitor?

When they first load your page, they may not have consented, so depending on your legal department, you cannot track them.

Then, when they consent, the question is how do you now catch up?

You could simply put everything in place, and then the next page would be tracked. But that way you’d lose any campaign tracking codes, and those are important!

So do you send tracking as soon as the visitor has consented?

Probably a good idea!

But what about Target? Wait for consent, then replace stuff on the page? Doesn’t sound right to me, although it may work for your visitors (test it!). You’d likely wait for page 2 of the visit to start targeting.

If you have an event-driven data layer (EDDL), you may ask the people who work on the consent manager to push an event into it as soon as the visitor has consented or declined. This could then trigger an Analytics call (or not).

My weird brain thinks about this as a situation with a great tendency for race-conditions, and I may or may not take this as a hint to write an article about firing Rules based on more than one event. Hmm…

Before I go into that now, I leave you to ponder how you can integrate with your consent management. Have fun!