Reducing Page Flicker with Consent Management

[#1]

By @surebee @vinay_sodha 

Consent management platforms whether built in-house or through an external vendor have become more commonplace understandably as there has been more of a focus on consumers' privacy rights through the backing of GDPR and CCPA for example. When implemented, the ability to test or personalize on a page is governed by a user’s consent preferences.  

Given the diversity of site and technical governance requirements across the industry, consent management and therefore, Target implementations can vary. Despite the different combinations of consent management and Target implementations and the changing tide of privacy rights, the need to provide a personalization without flicker remains constant. In this blog, we will start with a brief overview of flicker, consent management and list some of the most common ways of mitigating flicker when implementing Target with consent management on your site. 

What is Flicker? 

At a high level, a ‘flicker’ of content can occur when default content is displayed on a page for example and then either through personalization or testing of content, there is a moment where the new content can be seen being updated. 

Flicker is generally managed by masking the entire page or parts of the page using a piece of code called the pre-hiding snippet. This code uses CSS styles to do the masking until the personalization content is successfully rendered. For more details, click here. The reason behind this is to provide the optimal user experience. Ideally, the user should enter the personalization or testing experience seamlessly. 

How Are They Related 

These two items that were previously unrelated can now cause an issue due to the race conditions required to render a test or personalization. Just to recap, page masking is employed so that the user doesn’t see the default experience and to ensure the new experience is rendered seamlessly. However, the need for consent management has presented a challenge in this process. Since a site for example may not initially know whether or not a user has consented to receive targeted content, the challenge becomes at what point 1) the page can be masked and 2) personalized content delivered. The various aspects – timing between showing original page content, collecting and processing user consent and ultimately delivering personalized content to the page; must be carefully considered to ensure the best user experience, i.e. personalization without flicker! 

Consent Management Overview 

Companies are required to manage consent for their users to comply with privacy regulations. While the definitions of essential vs nonessential cookies may vary based on technical governance and industry type; typically, Adobe customers require some variety of the following:  

1. Visitors to opt-in before any Adobe solutions execute 
2. Allowing visitors users to manage their opt-in and opt-out status  

Some of our customers use enterprise-level consent managers and others build their own. 

Listed below are some of the Adobe-provided options to supplement your consent implementation- 

• Opt-in service 

• Lets you set up a system to approve or deny the downloading of Adobe cookies only 

• It does not provide support for either gathering user consent preferences nor is it a repository for preferences 

• Implement consent with a consent management platform (CMP) using the Platform Web SDK extension 

Options to mitigate flicker 

Let’s take a look at a few different options to mitigate flicker. The best solution is dependent on your particular requirements and preference on how you would like the page to interact depending on consent.   

• The most straightforward option: Have a refresh of the page. The way this works is initially visitor tracking is not permitted, once the visitor agrees to consent the page reloads. Once the visitor has consented and the page is refreshed the Target tag can be loaded. 

• If we want to look at an option that doesn’t include a refresh of the page we can take it a step further and reactivate the tag on the same page load. The way this flow works is once we have received consent from the user the tag can be reactivated, however there are some caveats to keep in mind. Since the tag is reactivated on the same page load, it may be best to employ some solutions to mitigate any content that is changed due to testing to personalization. 

• One possible method to employ if you’re performing content changes above the page fold is to present the user with a ‘loader’ icon while the changes are being performed in the background.  

• Alternatively, if there isn’t a requirement to change content above the fold, changes can be limited to content changes below the fold. 

This list isn’t exhaustive and there are definitely further custom solutions to explore to comply with your organization’s privacy requirements and provide seamless personalization experiences to your users sans flicker.