Recently I published an article on how to set up an impact test for the “flicker effect” omnipresent in client-side A/B-testing tools. Be sure to check out that article first to get some context to what we’re going to be talking about here. In this short follow-up, I’ll show you how to measure the average time of the anti-flicker snippet delaying page visibility, if you choose to deploy the snippet.
“Flickering” or “Flash Of Original Content” (FOOC) is a phenomenon where there’s a (typically) slight but observable delay in the browser updating the site or element layout if the user is included in a variant group for experimentation. This manifests in the original, unmodified element being rendered in the visible portion of the page before the experiment library updates it with the variant. There are ways to mitigate the flicker:
The shadow DOM is a way to add HTML structures to the web page so that they remain isolated from the rest of the document object model (DOM). It’s a popular concept with web components, as it allows for encapsulation of web structures so that they aren’t affected by style declarations of the parent tree, for example. However, being such a “hidden” structure, anything that happens in the shadow DOM is also hidden from Google Tag Manager’s listeners.
With so many people working from home or remotely in these turbulent times, it’s time to revisit one of my oldest articles, and discuss the options you have for excluding or segmenting internal traffic in Google Analytics. The traditional method of IP address exclusion is not necessarily the best option anymore, unless all your employees use a specific VPN to connect to the site. In this article, we’ll go through some of the tools you have at your disposal.
With the enforcement of SameSite settings in the latest versions of Google Chrome, it’s become a mad scramble to get cookies working across first-party and third-party contexts. I’ve covered this phenomenon before in my SameSite article, as well as in my guide for setting up cookieless tracking for iframes. Recently, Google Analytics updated its libraries (App+Web, gtag.js, and analytics.js) with a new setting: cookieFlags (analytics.js) or cookie_flags (App+Web and gtag.js).
One of the hard-and-fast rules in Google Analytics is that once hits have been collected and processed into your data properties, those hits are untouchable. This means that if you mistakenly collect duplicate or incorrect transactions, PII traffic, or referral spam, for example, it’s extremely difficult, if not downright impossible, to purge or change this data in Google Analytics. Another staple of Google Analytics’ strict schema is that displacing hits in time is also very difficult.