If this is in the wrong sub, please let me know.
How can we properly capture anonymous data when the Opt-in extension is enabled in Launch? When this is enabled, and users ignore our consent banner or decline, no beacons are sent for capturing anonymous data like site views and page visits. Is there a way for certain "anonymous" rules to override this and still send the beacon for data capturing?
Views
Replies
Total Likes
Hi @mmasonWD
there is no real anonymous/cookieless tracking supported in AppMeasurement.
You could use a server-side call using the Data Insertion API, but even there you would need to create some kind of user identifier, e.g. based on the user's IP address and user agent.
My two cents
Views
Replies
Total Likes
Thanks for the reply. We from our end totally understand users not wanting to be tracked. What we were after are the bare minimums like page views, site visits, etc anonymously. I know there are workarounds, but yeah we can't find anything straightforward to capture the bare minimums if opt-in is enabled.
Views
Replies
Total Likes
Technically though, opting out of tracking cookies... while you can't go cookieless, you can (or should be able to) prevent cookies from following the user..
First, if the user opts out, you can opt them out of the ECID. There is permissions for this in the extension.
Next however, in the absence of the ECID, Adobe will fall back to the old s cookies (s_vid, s_fid, etc)... but, there is a setting to force these to be session based... essentially, the user should get a "user id cookie" that will track them through the visit... however, once the session ends, those cookies should expire, and the next time the user comes to the site, they will get all new cookies with all new IDs... thereby preventing them from being followed / fingerprinted.
This should comply with a cookie opt-out policy. Now, if your opt-out specifically gives them to opt-out of tracking completely, this would be a problem... but if its just about following / identifying the user, this should meet the criteria.
Actually a good question whether this works for Web SDK as well.
Also, have you ever seen your approach documented to be used in a Launch environment? Maybe we could document it here in the community somehow?
Good point... given that WebSDK is a newer tech, that came out since a lot of these privacy issues came into effect, you would think it should have the equivalent...
I am not sure if WebSDK even bothers with the old s cookies (likely not), and I believe the ECID settings are all part of the WebSDK extension, so it should have the opt-out controls there...
Like anything, it's best to test your setup in Dev, QA or Staging... While incognito won't work for this... you might want to use a browser that isn't your primary to test this out... that way, you can do a full cookie purge, then go to the site hit some pages, etc... record your ECID and any other identifiers... also make sure you can find these pages in Adobe (maybe add a campaign like ?cid=usertest1 or ?utm_source=usertest1 (something that you can easily segment to pull all the data from you). Then close the browser... a few hours later, go back, do some more testing... check your ECID for this visit, make sure it's different... use another campaign ?cid=usertest2 or ?utm_source=usertest2
When you go check your data, make sure that Adobe sees these two tests as different users... 1 UVs, or 2 "people" if you have CJA / Device Stitching.. etc.
Views
Replies
Total Likes
Thank you for this response. I must be missing something or not understanding something correctly, but I am not seeing any options or descriptions for opting out of using the ECID in particular or how to do this as you described?
Views
Replies
Total Likes
The original ECID settings (non WebSDK) look like this:
There is a whole section on opt-in/opt-out.. there is a lot of control here....
This is all I could I could find in the WebSDK:
This isn't doesn't seem good at all? This came out after the original... I am not sure why they wouldn't have consent options built into this.... I wonder if it's because WebSDK uses server side cookies (i.e. not client cookies) that they saw no reason to build in any sort of consent controls?
I get that most consent is around advertiser data that follows you around the web... but that's not the only consent model that exists... this seems.... shortsighted?
Views
Replies
Total Likes