GDPR : add cookie check condition to Experience Cloud ID service Extension

[#1]

with GDPR coming in place, the call to the Experience Cloud ID service is coming into discussion. Several legal consultants in companies are claiming that the call only may be issued if there is a consent from the visitor to be tracked.

The current implementation of the standard extension, will always fire the call.

It would be very helpful if the extension would be able to do a cookie check, as such a consent cookie could be set, and the rule would only fire if the consent cookie is on an adequate level.

Stefan

[#2]

This sounds very similar to the already-existing "Enable EU compliance for Adobe Analytics" option in the Analytics tool/extension?

[#3]

Not really the same. The sat_track option in Analytics is an all or nothing on website tracking. Sat_track not set is "no tracking at all".

We're used to different consent levels for different kinds of tracking. Below is a typical settings screen, indicating to which kind of tracking a visitor gives consent.

So normal basic web tracking is allowed. However, the Visitor ID Service (Experience or Marketing Cloud ID) is seen by the legal advisors as a mean to identify and profile the visitor (i.e. collect personal information), and they advise to allow it only if the consent level is at least "relevant" (mainly, because the service makes a call to another domain - i.e. demdex.net). So we may only invoke the Experience Cloud ID service (and link it to Analytics) if the consent level is adequately set.

[#4]

This is in the works.  The ECID itself is being updated to have an ability to wait for opt-in before firing.  Then the Launch extension will need to be updated.  We'll be able to provide more technical details when it's a little farther along.

[#5]

Any idea/news on when this update will be available?

[#6]

Sorry, not at the moment.  I'm only parroting what I've heard, I don't have any inside knowledge of the roadmap.

[#7]

I have implemented a test with TrustArc, and I can stop everything but the Experience Cloud ID.  The only solution I can find is to put the code outside of Launch and wrap the entire launch include in a conditional statement.  If anyone has a better suggestion I would love to hear it.

[#8]

We have a test implementation running where the Experience Cloud ID ( via VisitorAPI.js) is hardcoded after the consent. But we ran into another issue: we track the pagehit before the consent popup as well (no mcid yet), and a pagehit after consent is set (mcid set), but both visits are seen as from different visitors, even with grace period enabled.

This issue is in the meanwhile under investigation at the Adobe Analytics team... still waiting...

[#9]

I created a rule which loads at the top, and the custom code is the visitorAPI.js file and added a condition.  Any reason why this won't work?  Then the code is still controlled by Launch but you can add the consent condition.

[#10]

Any updates on this?  My idea above didn't work.

[#11]

Hi Dave,

I made a custom JavaScript in which I copied the VisitorAPI.js code, and added a global scope function "getVisitorID" with some conditional code on retrieving a consent cookie, checking the cookie and if consent OK, making the call to the VisitorID service.

I load this script directly in the HTML code before Launch. In launch, in the Adobe Analytics tool configuration, in the Custom code for tracker, I call this "getVisitorID" function and assign the value to the s.Visitor. This seems to work quite well.

The issue is that the VisitorID service must be called before Analytics is called, so that the s.Visitor assignment is taking place at the right moment.

However, as stated in my earlier comment, since we already track the first call to Analytics before the enabling of the Visitor ID service (hence setting the cookie), the visits before and after consent are seen as from 2 different visitors. Until now still no response from Adobe Support on this issue yet.