Revert DOM modification caused by target VEC on consent opt out

[alexthomos22]

Is there a way to revert the DOM changes(e.g. background color) made using target VEC without reloading the page. we have a SPA website where target should only work when oneTrust cookie is accepted. The website currently don't reload when user accept/rejects the cookie, thus DOM changes made by target will persist until you move from one view to another or reload the page, and if the DOM modifications are in global components(header/footer), then moving from one view to another also not help. Implementing reload on cookie rejection has dependency with other tools, and the reason being seeking advice from community. we can definitely add a check in target custom code to check cookie consent before applying but then also take care when consent is rejected which add another layer of complexity. I am in favor of reloading the page but happy to explore if any one has better approach. Thanks 

[kandersen]

Hi @alexthomos22 

You can replicate the mboxDisable ( https://experienceleague.adobe.com/en/docs/target/using/activities/troubleshoot-activities/content-t... ) parameter into a cookie. 

From the browser console you can run: document.cookie = "mboxDisable=1; path=/";

You could trigger the same from your TagManager when consent is withdraw. 

With the cookie set it should require a refresh for any activities to stop being served. 

Now, I haven’t tested this, but in theory I believe it should work.

After setting the cookie your TagManager triggers the getoffer applyoffer (https://experienceleague.adobe.com/en/docs/target-dev/developer/client-side/at-js-implementation/fun... )

Hopefully - now with the mboxDisable cookie - Target should not return anything and remove any content delivered by activities. 

As a test you should be able to run the full script (setting the cookie and the getoffer/applyOffer) in the console to see that it actually works before trying to implement it. 

Let me know how it goes. 

[alexthomos22]

Thanks for your suggestion @kandersen 
We already have this in place. All the launch rules including getOffer, triggerView executes only when consent is accepted. 

The challenge is we are not allowed to refresh the page when consent is rejected after some time where user has accepted the consent and target delivered activities.

Example: Modification done by target on the page after accepting the consent 

setInterval(function(){console.log('hello')},1000);

Is there any out of the box way to stop above code executing when cookie is rejected and page didn't refresh?

Obviously, adding a check in code if(cookiePresent){console.log('hello')} but then what about the CSS?

This will work for simple use cases but when we have complicated use cases and the check itself fails then it could end up in GDPR violation

[kandersen]

@alexthomos22 my understanding is that you have the scenario of a user visiting the site where Target is delivering content. At some point the visitor decides to withdraw consent and you would therefore like to have Target stop delivering content, but without reloading/refreshing the page. Is that correct?

In the above scenario I would still recommend what i describe in my first response. A simple scenario would look like this: I would set a rule in the TagManager that monitors the consent widthdraw 'button'. When it is clicked i would execute a javascript that does the following:

1. Sets the mboxDisable cookie

2. fires off a Target request call (getOffer/applyOffer). When this is fired I would expect Target to stop returning any content due to the mboxDisable cookie being available.

At no time the page will be reloaded with the above approach.

Let me know if I misunderstood your request.

[alexthomos22]

Hi @kandersen 

Yeah, your understanding is almost correct, as instead of Target stop delivering content, please replace it as Target remove content which is already delivered.

Our challenge is when user withdraws consent then the changes made by target for example body background color should be removed without page refresh. We are able to stop target from delivering the content further but content which is already on present on the page will stay there until you refresh the page.

Thanks,

[kandersen]

Hi @alexthomos22 ,

Thanks for clarifying. I quickly tested my above approach and in theory it sounded great, but in the real world it didn't work. 

I have few other ideas. I'll quickly test it so I don't tell you something that won't work.

I'll keep you posted.

[kandersen · Accepted solution]

@alexthomos22 

I've been testing some approaches, but none of them are ending up with the result you're looking for.
The above suggestion didn't work, because as soon as the mboxDisable cookie was present Target wouldn't send any requests to the server, but it still required a refresh to remove the existing content.

Then I thought of having getOffer on opt-out click pass a mbox parameter and have an activity with default content to be served. So when users opt-out they would qualify for a new activity that wouldn't have any changes. Problem with this approach is that content would only be updated if a change was applied to the same element in the activity with default content. 

So I don't see any options for this to work without refreshing the page. 

My absolutely last try would be @Ryan_Roberts_ who is one of the smartest people i know.

[alexthomos22]

Thanks a lot @kandersen for investigating, highly appreciate the efforts 

meanwhile I will chase for page refresh, the ultimate solution.