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.

[screenshot]
ECID Service Extension Settings
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.

[screenshot]
ECID working
[screenshot]
ECID Calls
[screenshot]
ECID Cookies – 1st party

[screenshot]
ECID Cookies – 3rd party
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.

[screenshot]
ECID Service Extension Settings – Opt-In
[screenshot]
ECID – no visitor ID

[screenshot]
ECID – no calls
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.

[screenshot]
ECID Service Extension Settings – Opt-in per Data Element
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.

[screenshot]
ECID Service Extension Settings for storage
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!

[screenshot]
“true” !== true
Yes, I know what a boolean is, and when something is a String. I did this:

[screenshot]
Javascript vs Cookie vs Type
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.

[screenshot]
ECID Service Extension Settings Permissions
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

[screenshot]
Pre-approving ECID
This is what happens:

[screenshot]
ECID working pre-approved
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:

[screenshot]
ECID and AA approved by different means
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.

[screenshot]
AA not allowed == no beacon
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”!

[screenshot]
Target v2 Extension Settings
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.

[screenshot]
Target not approved
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!

10 thoughts on “Consent and Launch

  1. Hi Jan,
    thanks for these valuable insights. One issue I ran into quite a lot with the following scenario:
    – Default value for AA and ECID are “false”
    – User arrives at the website and gets a consent-popup
    – User consents to tracking in AA as well as for ECID
    – Of course I am able to fire AA on consent-update, BUT: Even if I set opt-in values for AA and ECID to true, the hit won’t contain an ECID but rather a legacy visitor ID
    – A follow-up page view (with a “real” page-reload) will then generate an ECID, BUT the two IDs are not stitched together and thus ripping apart sessions

    Current workaround is kinda hacky:
    – On consent-update, I call Visitor.getInstance(“xxx@AdobeOrg”); and visitor.getMarketingCloudVisitorID(); to pre-fetch an ECID
    – Via a direct call to retro-fire any pixels that got consent with the change, I trigger the AA beacon
    – In “doPlugins” I make the above calls to the visitor service again and set s.marketingCloudVisitorID = visitor.getMarketingCloudVisitorID();
    – Works, looks dirty, but I (as well as my colleagues) could not find any other way yet to have a proper ECID set in the first hit immediately fired on consent-update

    Any trick I didn’t see?

    Best regards,
    Sebastian

    Like

      1. Thanks for confirming that I’m at least not completely on the wrong track. “Out-of-the-Box” with Web SDK (as well as ‘legacy’ implementation) would be ideal though.

        Liked by 2 people

    1. Hmm, I’m actually experiencing something else.
      On first page view, and when the user consent to AA and ECID – I see that AA is nice enough to wait for ECID to be fetched, and then AA will fire with the ECID correctly. It’s like this out of the box.

      Unfortunately I’m experiencing that Target does not do the same! Any ideas on this would be appreciated!

      Like

  2. nice article Jan; it does appear complex; why not just have a simple consent true option; then everything fires else false? To keep it simple.

    The question is the first page count e.g. tracking codes etc; Can Launch rules be used to have these values persist on consent to 2nd page?

    Thank You

    Like

    1. Hi Ravinder,

      A lot of people get consent for different “levels”, such as “tracking”, “re-marketing on-site”, and “general re-marketing”, because they think people will agree to some of it more easily than to all of it.

      And since the different applications can be managed separately, why not do it?

      Like

  3. Hi Jan,

    thanks a lot for this posting! But I would disagree with your note regarding Step 2:
    “Note: if you are using server-side forwarding to send Analytics data straight into Audience Manager, the “aa” setting will control both!”

    It seems like the AAM optin / optout in case of SSF controls s.contextData[‘cm.ssf’] that is described here: https://experienceleague.adobe.com/docs/analytics/admin/admin-tools/server-side-forwarding/ssf-gdpr.html. And this tiny little variable controls forwarding to Audience Manager and hence Audience retrieval or Cookie / URL destinations that would not be published if e.g. only “AA” has Pre Opt In Approval but “AAM” does not. Or the other way: We do want to prevent e.g. AAM URL Destinations like Facebook Pixel from firing while Analytics is allowed pre opt in. With setting previous permission for Analytics but not for AAM makes this work and we won’t receive uuid and stuff with the analytics request response.
    Alternatively setting disableThirdPartyCalls and / or disableThirdPartyCookies also prevents e.g. a Facebook Pixel URL destination from firing even when AAM is opted in. In this case I will see the destination in the response of my analytics request but the url destination itself will be surpressed.

    The good thing: Due to your posting I digged deeper and do not need to manually set s.contextData[‘cm.ssf’] anymore but can use the Opt-In feature of Adobe 🙂

    Best regards,

    Jonathan

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.