Let me start by proclaiming with clarity and sincerity:
No, Safari 14 (or any other version of Safari) will not block Google Analytics from loading and running on a website.
In the midst of Apple’s yearly Worldwide Developers Conference, the company showcased some of the privacy improvements to the upcoming version of the Safari web browser (version 14).
In fact, the biggest revelation was the new Privacy Report, which is designed to elucidate how much the browser is working towards mitigating the damage caused by cross-site trackers.
The Simmer Newsletter
Subscribe to the Simmer newsletter to get the latest news and content from Simo Ahava into your email inbox!
On New Year’s Eve 2018, I published an article which instructed how to scrape pages of a site and write the results into Google BigQuery. I considered it to be a cool way to build your own web scraper, as it utilized the power and scale of the Google Cloud platform combined with the flexibility of a headless crawler built on top of Puppeteer.
In today’s article, I’m revisiting this solution in order to share with you its latest version, which includes a feature that you might find extremely useful when auditing the cookies that are dropped on your site.
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:
When custom templates were released for Google Tag Manager, I updated my workflow for working with GTM. Instead of instinctively rushing to the Custom HTML tag and the Custom JavaScript variable, I started considering whether the custom script that needed to be deployed could be transformed into a custom template first.
While publishing numerous templates into the community gallery, I always spent some time over the past 12 months tinkering on an extremely complicated template translation: the Snowplow Analytics JavaScript tracker.
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.
One of the most versatile triggers in Google Tag Manager is the Custom Event trigger. As its name indicates, you can use it to fire your tags when an event is pushed into dataLayer.
This process is at the heart of GTM’s dataLayer system. And it’s not just custom events. Every single trigger type in Google Tag Manager uses the event key in a dataLayer.push(), which is why you’ll see events like gtm.