Consent and Launch, part II – Opt-in

This post picks up where Consent and Launch gave up ended: what exactly happens when you’re doing opt-in and a visitor has not given consent ever before?

I had this down as somewhat mysterious and full of traps and pitfalls, but once I switched on the metaphorical light, I saw that it was surprisingly easy and entirely straight-forward.

So this is a short post, and I think that is a good thing!

Consent Management

First of all, the situation:

We have a web site, and we have a legal department that says we should get an ok from any visitor to our site before we track them.

We also have Adobe Analytics, deployed via Adobe Experience Platform Data Collection (formerly known and subsequently referred to as “Launch”). We may have Adobe Target, but only so that I can write a small paragraph on how that makes no difference (in my humble opinion, and you may obviously disagree).

On our site, we have some 3^rd-party Javascript that generates a popup (“PLEASE let us track you, ok?”), handles the responses, and manages cookies. In essence, the 3^rd-party Javascript handles everything that has to do with consent.

It also provides callbacks, informing other parties of when the consent changes. And it may provide some API for other scripts to check consent, too.

While there are Extensions for Launch for a bunch of those 3^rd-party consent managers, I would like to explain this generically, mainly because doing so helps me understand the underlying mechanisms.

Flow

When a page loads, we can gather “Previous Permissions” using a Data Element. Everything that is allowed will simply work at this point.

The Data Element will likely use the 3^rd-party tool’s API to determine what is allowed and what isn’t.

At some point, a visitor may give consent.

The 3^rd-party tool will signal the change, and our callbacks or listeners will pick up on the change.

While for Target, this may have no impact (see further down), for Analytics, consent should lead to an immediate tracking call!

Agreed?

Ok, let’s look at how this works.

Technical flow

Let’s take the example of when a visitor arrives for the very first time.

They are unknown to us and the site, there are no cookies that we could recognise. So for now, they are not opted in and the consent manager will therefore show the pop-up.

Meanwhile, Launch will load. It is configured to use “Previous Permissions” with a Data Element. That DE looks for the relevant cookies, or queries the consent manager’s API, but no cookies are to be found, and consent manager says ‘no’. So the DE returns false across the board, and Launch passes that on to all Extensions that need it. In our case, that would be ECID, Analytics, and Target.

As a result, the Experience Cloud ID Service doesn’t send any requests to demdex.net, doesn’t generate any visitor ID, and generally stays inert. Analytics does its job, mostly, but it stops just before sending the tracking call. And Target refuses to replace any content.

Perfect!

We also have a Rule in Launch that installs one or more event listeners.

Now the visitor clicks on the big button and gives consent.

The consent manager sends one or more Custom Events, signalling changes in consent.

Our event listeners pick those up, and check them.

The one that we are interested in: did the visitor give consent for Analytics?

If so, the event listener simply calls the Launch consent framework and tells it so:

adobe.optIn.approve([adobe.OptInCategories.ECID, adobe.OptInCategories.ANALYTICS]);

Or you can do it in a workflow, like so:

adobe.optIn.approve([adobe.OptInCategories.ECID], true); // the second parameter tells the system to record the approval but wait for more
adobe.optIn.approve([adobe.OptInCategories.ANALYTICS], true); // same here
adobe.optIn.complete(); // now act on it

And that’s all there is to it.

Launch and the Extensions now take over and do the rest, namely the ECID will generate a visitor ID, and the Analytics Extension will now send the tracking call that it had formerly prepared but not sent.

Complexities

If your brain works like mine, you will probably think of a billion edge cases now, wondering how Launch will deal with those.

Before we go into any of those, let me re-state this: the Extensions take over and do the rest.

It is enough to just approve the applications you can and want to approve, and Launch and Extensions will handle it just fine.

I’m writing this because of Sebastian’s comment on the first article, posted a couple of weeks ago.

If in your case, Launch does not automatically fire Analytics & Target after opt-in, then something is wrong! And you do not need to trigger any tracking, manually!

If Launch fires those, but not ECID, again, something is wrong!

Repeat: a proper call to adobe.optIn.approve() is all you need to make.

But Target?

Yes, this works with Target, too.

When the consent comes in, Target will duly go out, fetch any content, and replace what it is told to replace.

This is something to think about.

If Target is triggered after consent is given, it would potentially change parts of or even the whole page. That would likely be after the visitor has already seen the page for a bit. The ultimate flicker, so to speak.

I say don’t do it.

If the visitor consents to Target, be content in knowing that from their next page onwards, you can target them as much as you’d like.

Caveat: if you use Target to inject things rather than replace them, by all means, do it!