Revert DOM modification caused by target VEC on consent opt out | Community
Skip to main content
A
alexthomos22
October 18, 2024
Solved

Revert DOM modification caused by target VEC on consent opt out

  • October 18, 2024
  • 1 reply
  • 1253 views

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 

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by kandersen-1

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.


@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.

1 reply

kandersen-1
Community Advisor
kandersen-1Community Advisor
Community Advisor
October 18, 2024

Hi @alexthomos22 

 

You can replicate the mboxDisable ( https://experienceleague.adobe.com/en/docs/target/using/activities/troubleshoot-activities/content-trouble ) 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/functions-overview/adobe-target-getoffer )

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. 

Test forum signature
A
alexthomos22Author
October 18, 2024

Thanks for your suggestion @kandersen-1 
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-1
Community Advisor
kandersen-1Community AdvisorAccepted solution
Community Advisor
October 21, 2024

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.


@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.

Test forum signature
Terms & ConditionsAccessibility statement

Loading footer...