Category: Thought Leadership

How to Enrich Your Google Tag Manager Monitor Data with a New Google Analytics Integration

We <3 Simo

Last year, our favorite Google Analytics and Google Tag Manager expert, Simo Ahava, wrote a great blog post about How to Build a Google Tag Manager Monitor. This tool is extremely helpful for unlocking statistics on site tag fires from various dataLayer event pushes.

Many crucial data points used for activation and measurement rely on successful dataLayer pushes. We’ve made a few updates to Simo’s Google Tag Manager Monitor framework that have allowed us to join data with Google Analytics. These updates help us unlock the ability to identify stability issue trends and patterns across devices, browsers, and operating systems that can negatively affect dataLayer pushes. For marketers struggling with data leakage, this is a BIG WIN.

We’ve Been Tinkering

Let’s explore the various adaptations we have made to Simo’s methodology in order to join results from the Google Tag Manager Monitoring Tool with a Google Analytics dataset in BigQuery, and what these enhanced capabilities mean for marketers. The join we’ve created enriches data collected via the Google Tag Manager Monitoring Tool with Google Analytics data points such as device, browser, OS—crucial information in understanding trends and patterns that impact performance. 

This post provides a high-level overview for how adding a new metric to your analytics toolset can help you measure the stability of your analytics implementation. If you’re interested in digging deeper into specifics or discussing real-world use cases, please reach out to me


There are a few prerequisites to have in place before joining data from a Google Tag Manager Monitoring Tool with Google Analytics data:

  • Pre-existing implementation of Simo’s Monitoring Tool (use his guide to get started)
  • Access to Google Tag Manager
  • Access to Google Cloud Platform project 
  • Google Analytics 360 Export


Here’s a look at an architecture diagram showing the Google Tag Manager Monitor Tool integrated with Google Analytics:

The Secret Sauce

The MightyHive Data Science team has designed a series of updates to Simo’s monitoring tool to provide enhanced data and diagnostic insights, including updates to the tool template to capture the Google Analytics Client ID, allowing us to join Google Analytics BigQuery data sets. Our team also realized that to connect all events on a given page together, a universally unique identifier (UUID) needed to be set via a new custom HTML tag. 

With the updated Monitor Tool template and the UUID tag set, the team updated the Cloud Function and created a BigQuery Table Schema for the enhanced tool using three additional fields: ga_client_id, event_id, and urlpath.

For a more detailed breakdown of the custom HTML tags we used, key Google Tag Manager settings, and code snippets for the template updates, shoot me an email.   

What Does this Look Like IRL?

A client—let’s call them Company X—published a new version of their site around August 3. Once the updated site was live, Company X noticed that the gtm.load dataLayer event push began to fire later, or in some cases not at all. Because various tags were set to fire on gtm.load, those tags fired less frequently post-release. 

Tracking breaks like this are a marketer’s nightmare. Did the tag fail? Did someone publish an update with broken code or without the all-important dataLayer push? Is the break happening on a specific device, browser, or operating system? These questions and more can lead to a frustrating, time consuming wild goose chase, not to mention lost data until the issue is fixed. 

Calculating the Google Tag Manager Load Rate

To troubleshoot Company X’s misfire, we used a new metric: Google Tag Manager Load Rate.  We’ve calculated the load rate using the following simple formula:

Let’s say Company X has an order confirmation dataLayer event that occurs after gtm.js. Swapping out gtm.load for the order confirmation dataLayer event gives Company X its order confirmation fire rate. 


The Google Tag Manager Load Rate query calculates the fire rate in the following grouping:

  • Device Category – Google Analytics provided device category (desktop, tablet, mobile) 
  • Device Browser – Google Analytics provided device browser (Chrome, Safari, Firefox) 
  • Page Path – Page where the event occured
  • Load Count – Count of gtm.load events
  • JS Count – Count of gtm.js events
  • GTM Load Rate – Load Count / JS Count

Here’s what the query output looks like:

In this example, using our BigQuery Google Tag Manager Load Rate query, we can quickly see that Company X’s home page, or “/”, has the lowest load rate at 91%. This means that 9% of gtm.loads on the home page did not fire, therefore leading to 9% (!!!) of traffic potentially being untracked. 

Better Insights, Faster Solutions

Our updates to the Google Tag Manager Monitoring Tool help take some of the guesswork out of the equation by automating a solution that audits dataLayer fires to quickly diagnose issues as they arise. By leveraging our version of the tool supplemented with Google Analytics data points, Company X was able to quickly pinpoint a sharp decline in fire rates post-release on Chrome and Firefox, while Safari was unaffected. A speedy and definitive diagnosis helped Company X fix the issue fast, reducing data leakage and bolstering its analytics setup against future issues.

Data Leakage Be Gone!

In advanced analytics use cases, troubleshooting and diagnostics can monopolize an inordinate amount of time and resources, risking massive data leakage until an issue is resolved. Now that we have the ability to join Google Tag Manager Monitor Tool insights with Google Analytics datasets, we can pinpoint when and where dataLayer pushes fail and which devices, browsers, and operating systems they are failing on. For marketers, this means hours, days, or even weeks of time saved and minimal data lost. 

Interested in learning more? Email me at  


WEBINAR: ‘Mastering Creative Effectiveness’—A Roundtable with Google, MediaMonks, and MightyHive

Mastering Creative Effectiveness

On September 16, Live With MightyHive featured a conversation on Creative Effectiveness. Joining me in this episode were Ryan Tetuan, Head of Creative Solutions, Media Platforms at Google and Louise Martens, Global Head of Embedded Production at MediaMonks. The discussion was interesting and offers viewers some actionable tips on where to get started.

What does Creative Effectiveness mean?
“Does the work, work? Are our efforts paying off? Are we hitting the goals that we set out together with brands?”
– Louise Martens, Global Head of Embedded Production, MediaMonks

It didn’t take long for us to dive into an in-depth discussion about what Creative Effectiveness really means. We went on to highlight the greatest opportunities for brands and provided recommendations on how to get started with creative. Above all, collaboration is key to your team’s success.

How can creative and media buying work better together?
“As we are testing new tactics, what new creative ideas can we put out there? Hey, we just did this new research on the creative side and we now understand what consumers are responding to – Can we actually target that micro-moment using the targeting capabilities of DSP?”
– Mitchell Pok, Director, Creative Services & Technology, MightyHive

According to a recent study conducted by Google and Bain, creative is 1.5x more effective when developed collaboratively than it is when it’s created in separate silos. Nielsen states that 56% of a campaign’s performance is due to creative. The research shows that mastering Creative Effectiveness can drive meaningful results for your campaigns and broader business goals.

In this episode, we also identified various roadblocks we see across the brands we know. These roadblocks range from the briefing process to the democratization of campaign performance data.

What’s standing in the way of Creative Effectiveness?
“I had media teams within 20 yards of me. There weren’t any physical walls and my interaction with the media team was essentially an email from them with an Excel spreadsheet of sizes of ads to build. That’s it. No audience, no contextual data.”
– Ryan Tetuan, Head of Creative Solutions, Media Platforms, Google

Check out the video to join the discussion and find ways you can start mastering Creative Effectiveness today. To view the Google Marketing Platform Solutions Guides, click here.

Please don’t hesitate to contact us with any questions.

WEBINAR: Slides and Video for ‘The Essential Role of Data Taxonomy in Bayer Digital Marketing’


For the August 25 Live with MightyHive episode, I was pleased to be joined by special guest Jeff Rasp, VP Digital Platforms, Channels & Capabilities at Bayer. He and I discussed the many benefits of an airtight marketing data taxonomy and Rasp explained how consistent campaign naming conventions are the foundation of a Bayer in-house team that earned the AdExchanger award for “Best In-House Media Operation” in 2020

According to a recent report conducted by Dataroma, 57% of marketers spend a week out of each month manually integrating data. As part of the MightyHive and Bayer partnership, Bayer established a sound taxonomy early in the in-housing process to essentially automate that task. And in “The Essential Role of Data Taxonomy in Bayer Digital Marketing,” Rasp explains how he distilled the KPIs of multiple departments into a unified naming convention capable of great versatility. 

Today, the Bayer marketing team generates insights in minutes, not days. And in this episode, Rasp outlines how his team pivots to accommodate the diverse reporting needs across the company. Watch the video to see Rasp and I discuss: 

  • How to create a data framework and hierarchy
  • The power of a well-planned media taxonomy
  • Data governance and the importance of consistency




Thanks for watching! If you have questions about the role of marketing data taxonomy in your organization, please contact us.



Server-Side Google Tag Manager Deep Impact


Before we dive into server-side Google Tag Manager (GTM), I’ll prefix the meat of this post with a caveat: always respect user privacy

Any data collection techniques discussed here must be applied righteously and not as a workaround to circumvent data collection consent regulation.

10,000 Foot View

Here’s a familiar situation – Google Tag Manager as we’ve known it for years.

Your container is loaded on all pages, or screens in your site/app, and based on trigger events, data is sent to first- and third-party endpoints.

It works, it’s fine, but it’s not perfect. Tracking blockers, JavaScript failures, many, many requests to endpoints, and inefficient JavaScript are all risks, and potential performance problems that can lead to data quality issues.  

Server-side GTM moves the tag vendor request from the client to a server—a server on Google Cloud Platform living on a subdomain of your site. The container loaded in the browser/app still has tags and still sends a request but has way less code, sends fewer requests, isn’t necessarily affected by anti-tracking software, doesn’t send the user’s IP address to third-party tag vendors, and first-party cookies are correctly set in an ITP compliant manner.  

Out of the Box – What’s Cool?

There’s a lot to be excited about with server-side GTM in that, on the client side, it’s all very familiarbut way better! The “traditional” digital marketer can still set up their Facebook tag(s) with the same triggers, and deploy Floodlights as required. Same, same… but different.

As mentioned earlier, rather than sending data to the tag vendor endpoint, it’s sent to a subdomain. For example, if you’re on, server-side GTM will send data to, a subdomain you can have configured.  

And that’s great because…?

  • It respects user privacy: The user’s IP address isn’t sent to a third party.
  • It preserves data quality: Tracking prevention doesn’t happen on requests to your own domain.
  • It lightens code bloat from the client side: The tags require less work on the browser, shifting the workload to the server instead. This means what remains in GTM on the browser does less, so the site runs faster.
  • It consolidates requests from the client side: You can send multiple requests from the server based on one request from the client.

At MightyHive, we strongly advocate for focusing on what’s best for the user, not the ability to foil or circumvent anti-tracking software. Reminder: act righteously, not selfishly. As it stands now, data is collected, not captured. In the future data will be exchanged… Think about that for a minute.

Deeper Impact

Have you noticed that tracking requests are sent to your domain and not a third-party domain? The data collection workload is moved to your infrastructure.

Does that feel like just going back to web server logging? How different is this from web server logging?  


Analytics data is formatted (sessionized), cleaned (PII removed), integrated (joined with data from Google Ads, Search Ads/Display & Video 360) and presented ready to perform its function: analysis and optimization of all aspects of the online business, which, let’s face it, is all about better marketing.  

Web server logs don’t collect all behavioral data. Typically, log-level data isn’t integrated with marketing channel data, meaning there’s no feedback loop for activation of the data. 

But! There are similarities between server-side GTM and web server logging. The web server receives a request, typically for a page, builds the page content and responds, possibly setting first-party cookies along with the response. The server-side GTM endpoint also receives requests, and responds, potentially with cookies (but with less content).

Now… the web server knows what page it’s returning.

It knows what data to render on the data layer to record a transaction (for example). 

The data layer is picked up by a tag firing in the browser and then sent back to the tracking endpoint. 

The end point then takes the same data and fires it off to Google Analytics (GA) to complete the round trip and get your analytics data recorded. 


Wait one minute. If the web server knows it’s rendering a “thank you” confirmation page, and it knows what data to render on the data layer, why bother sending this to the browser for the browser to just send it back to the tracking end point and then to GA?  

Why not remove some steps for efficiency? The web server knows it is rendering a confirmation page. So it builds the exact same request the browser was going to, and sends the GA transaction data straight to the tracking end point. Cut out the client round trip.

It’s quite normal to fire off conversion tags, Floodlights, FB pixels, Adnxs, TTD, and so on to record transactions. Don’t send those to the client to handle. As the web server responds with the confirmation page, send those requests straight to the tracking endpoint. The endpoint responds with the details of the cookies to set, and the web server sends those with the confirmation page content in the response to the client.

Think how many marketing tags and tracking pixels fire on page level events. How many tags actually need to fire on the client? How many tags don’t even need to be exposed to the browser? What if, just maybe, you only had page-level event-triggered tags? Maybe you only need page-level tracking if you’ve removed all of your data bloat? Then you don’t need to CNAME the tracking subdomain, you can restrict access to your tracking endpoint to only allow your web server to access it via https (think IP range restriction). That’s a bunch less complexity and a fair amount of moving parts removed from the solution.

Simpler is better. No code is better than no code, as the saying goes.

In Conclusion

The server-side GTM solution offers a good and correct solution to digital analytics measurement. It’s good because data quality can be improved, user privacy is further protected, and significantly, it’s a step towards doing less work in the browser, meaning sites and apps get faster.

Thinking about the possible solutions the technology offers, with the right motivation in mind, demonstrates how versatile the solution is, how much power is available and what avenues are still to be explored to leverage first-party data.


Digital Hygiene: Fighting Data Bloat


Some years ago, as digital storage grew more affordable, the attitude towards data by many companies was to “store everything.” Every. Single. Data. Point. 

Next came “big data” and cloud computing, which brought even more data, more computing power, and ostensibly more opportunity and insights.  As a result, data consumption skyrocketed, driven by the Internet, social networks, and digital services.

To paraphrase my guru Avinash Kaushik, we now have more data than God ever intended anyone to have. 

The instinct to store everything is understandable. Why throw away data? But there have been a few unforeseen effects:

  • It increases the workload associated with data quality assurance
  • It increases data processing times
  • It makes data sets more complex and more difficult to work with
  • Most of the data is irrelevant to business analysis

The decision to keep all the data was an easy one. Discerning which data points should be considered is difficult. This consideration phase will be implemented either as companies are specifying a data project (BEFORE), or as they introduce a new release of their digital assets (AFTER).

For mature audiences only

Imagine you’re building the specification for your project and figuring out how to measure project success. You will most likely consider the following KPIs:

  • Key feature usage rate (conversion rate)
  • Marketing effectiveness (budget, cost per acquisition)
  • Vanity metrics (volume, users)

Sounds too basic? Fair enough. And yet that’s a great base to work from! 

Important Tip: Your project must be in sync with your organization’s maturity level.

First, you need to make sure the basic data you intend to collect from your site or app resonates with your product managers, your marketing team, or your analysts. They need to understand how these basic numbers can help shape your product or marketing strategies. 

Then, a specification document must be established. A Data Collection Bible of sorts. Call it a tagging plan, a data collection blueprint, a solution design document… get creative! That document will not be set in stone. It will evolve with your company as you enrich your data set to meet your measurement requirements. Make sure to include significant stakeholders in that process, or else…

Only after you’ve gone through a thorough data specification phase can you consider enriching your data during subsequent development cycles. Data enrichment will either be:

  • Vertical: more metrics to measure specific user events
  • Horizontal: more dimensions/attributes to give metrics more context

Keep enriching your data to assess the KPIs that support the measurement of your business objectives. Give them as much context as you can so the analysis is as relevant and actionable as possible.

Does your data spark joy?

All this talk about enriching your data sounds great, but you may be at a stage where you’ve collected way too much data already. Arguably, getting a ton of data means getting the fuel to power machine learning, artificial intelligence, or any reasonably advanced data processing.

Having said that, too much unidentified/non-cataloged data will ultimately yield confusion and storage/processing costs. For instance, if you have a contract with a digital analytics vendor (say Adobe or Google), it is very likely you’re paying a monthly/yearly subscription fee based on the number of hits your system collects and processes into reports, cubes, and miscellaneous datasets. Additionally, digital marketing teams are not known for questioning the status quo when it comes to data and tracking, in particular.

If you combine both facets of data cleanup, we’re looking at an optimization campaign that turns into a cost-saving effort. This is where you as a company should start asking yourself: “do I really need that data? Can my team function without measuring metric X and attribute Y?”

To borrow from Marie Kondo’s konmari method, you should keep only data points that speak to the heart. Identify metrics/attributes that no longer “spark joy,” thank them for their service before brutally disposing of them with a firm and satisfying press of the DELETE button.

How can you tell whether you should discard a specific data point?

This requires a bit of investigation that can be done in your data repository by looking at your data structure (column names and values for instance). If you cannot make up your mind, ask yourself whether one particular data point really “sparks joy,” or in our case, drives analysis and can be used as a factor in machine learning. In fact, this is a great occasion to actually use machine learning to find out! 

Feed your data set into R/Python (insert your favorite machine learning package here) and look at the results:

You could also look at factor analysis another way and see where a specific factor really contributes to performance, metric by metric:

Once you’re done analyzing which data points still belong in your data architecture, it’s time for pruning. If you have made the decision to delete existing data, this can be as simple as deleting a column or a set of entries in a database, data lake, or data repository. But that’s only for data you already collected. What about data collection moving forward? 

If you want to change the way data is collected, you need to go konmari on your digital assets: web site tracking, mobile SDKs, OTT devices. Using a tag management system (TMS), you can start by deactivating/pausing tags you no longer need before safely deleting them from future versions:

From a management perspective, stakeholders need to make themselves known and express clear data requirements that can easily be retrieved. That way, when you prune/retire data that is deemed to no longer spark joy, you’re not inadvertently sabotaging your colleagues’ reports.

And this is why you needed that Data Collection Bible in the first place!

Which data stage are you at? Before or after? Basic or complex? Don’t hesitate to contact MightyHive for a data maturity audit or a digital analytics health check!



Download the Slides and Video for Comparing Log-level Data to Ads Data Hub

**Scroll down to download everything**

High Fidelity: Log Files vs. Ads Data Hub

Recently I had the pleasure of being a guest on “Live with MightyHive” to talk about how Google Data Transfer Files (DT Files) compare to the data inside Ads Data Hub (ADH).

As a refresher, DT Files are the log-level data marketers can access from Google Marketing Platform (GMP). Google announced in 2018 that it would begin redacting user-level IDs in order to protect user privacy and comply with regulations like GDPR (and now CCPA, as we cover in this episode). Ads Data Hub, on the other hand, is the “data clean room” for GMP; a privacy-preserving application for analyzing campaigns and audiences without user-level data needing to leave Google.

What has happened is that the detailed user-level data offered by DT Files in many cases ends up heavily redacted (for both privacy and business reasons), whereas Ads Data Hub keeps user-level data 100% private and is consequently not nearly as redacted. Marketers NEED to understand this trade-off. This episode covers what you find when you compare the two, including:

  • The key differences between DT Files and Ads Data Hub
  • How to check data parity between DT Files and Ads Data Hub before making other comparisons
  • How to compare the effects of user ID redactions, Safari ITP, and CCPA between log-level data and ADH

We’ve packaged everything up and you can register to download these materials below:

  • The full episode video
  • The slide deck
  • Sample SQL queries for both DT Files (BigQuery) and Ads Data Hub

If you want to develop a better understanding of how Ads Data Hub differs from legacy analytics and log-level data, then this is a great set of materials. I hope you find them useful!


Preview the slides

A few sample slides from “High Fidelity: Log Files vs. Ads Data Hub” and the appendix of SQL queries for BigQuery and Ads Data Hub.



Harvard Business School Publishes “In-housing Digital Marketing at Sprint Corp.”


As a company that lives on the leading edge of digital media, the MightyHive ethos has been to train our own. With fast and frequent innovation it’s difficult to build educational material that can keep up. That said, digital transformation has been a buzzword for several years, and it’s a topic that keeps business leaders in all industries up at night. COVID-19 revealed the stark contrasts between businesses that have advanced their digital transformation efforts and those that have not.

MightyHive and Sprint had the privilege of working with Harvard Business School and Professors David Bell and Rajiv Lal to create a case study on Sprint’s digital transformation efforts over the past 3 years. The company’s leadership knew that more consumers would be interacting with the brand online–and expecting more from those interactions. A major component of the transformation strategy was bringing digital media planning and buying in-house. MightyHive was honored to help Rob Roy, Charlie Florio, Andrew Ronnfeldt, and the rest of the Sprint digital team in achieving this objective.

It was a bold vision that was not without its risks. The Sprint team was confident that being closer to their marketing data and execution would help them win in an extremely competitive telecom space, but there were few examples of other companies having made such a change.

MightyHive worked hand-in-hand with the team to manage the transition from their external agency and to refine their digital program. We helped identify new KPIs and measurement models, found ways to reduce waste, and created an audience framework that attracted higher-quality traffic. With performance wins in hand, we helped Sprint in the next phase of the journey, assisting in the design of their team structure, candidate profiles, and training new team members.

In all, Sprint saved $6 million in costs annually that would have gone to an external agency, savings that were reinvested into working media. This drove a substantive increase in sales through their digital channels.

We are humbled to have had the opportunity to work with the faculty at the world’s leading educational institution, the Sprint digital team, and to have our work included in the curriculum for future business leaders.

You can read more about Sprint’s story by purchasing a copy from Harvard Business Review or by reaching out to

Making Google Optimize More Effective with Double Blind Testing

Doug Hall
Senior Director of Analytics
Allison Hannah Simpson Blog Post
Allison Hannah Simpson
Marketing Associate

The Opportunity for Better Testing

We’re big fans of Google Optimize, a premium testing and personalisation tool. We’re also big fans of Double Blind Testing. Double Blind Testing weeds out the bias that can diminish the effectiveness of your data analysis. This article proposes integrating Double Blind Testing with Google Optimize to further validate your marketing research, thus helping your marketing dollars go further.

What is Double Blind Testing? A handy definition:

A double blind test is an experiment where both the subject and observer are unaware that the exercise in practice is a test. Double blind testing is referred to as the gold standard of testing. Double blind tests are used in science experiments in medicine and psychology, including theoretical and practical testing.

See how that’s different from Optimize testing? With Optimize, the analyst often sets up the test, runs the test, analyses the test, calls the winner (if there is one) and shares learnings. That last part of the process, sharing the learnings from the test, is the most important piece.

Caution: Unconscious Bias Ahead

One person wearing multiple hats during testing is also known as a single blind test and comes with consequences. A single blind test risks being influenced by unconscious bias. In a single blind test, the test participant is the only individual unaware of the experiment they’re being subjected to. The person running the test knows what is the control and what is the experiment.

There’s the rub. It’s quite possible for an analyst to draw a conclusion around results based on their knowledge of the test participant – not necessarily to the extent of creating manufactured data, but unconscious bias creeps in subtly.

For example, the analyst may be presented with an aggregated view of the data that shows the experiment outperformed the control. At first, this sounds like a success! However, confirmation bias could make the analyst less likely to dig deeper and explore the data under a more critical lens. With the results in the bag, the analyst moves on and misses important insights into the effects of the experiment.

The opposite is also possible: the control wins, so the experiment tanks. This cannot be true! So the analyst, misled by their cognitive bias, wastes time digging for signals that validate their hypothesis.

Change the Methodology to Remove Bias

Testing is a team effort. Divide [effort across the team] and conquer [cognitive bias] to achieve proper double blind tests. Let’s take a look at how a simple A/B test approach might change:

First, the test owner develops the hypothesis, which must remain private to the test owner.

Based on data [a] and feedback [b], we believe that doing [c] for audience [d] will make [e] happen.

We will know this to be true when we observe data [f] and get feedback [g].

We expect a change in metric [h] of magnitude [i] within [j] business cycles.

The test owner will then work with the designer and front end engineer to develop and implement the test experiment. It’s important for the test owner to keep the hypothesis a secret and only share what the test experiment is with other team members. The reason for the test should not be revealed.

The test is executed and now an analyst is introduced to the test data. The analyst has no previous knowledge of the hypothesis, experiment design or testing process at all. They only know this is a test in which they must perform a calculation on the presented data to determine the test experiment performance and significance.

Setting Up a Double Blind Test

Tell your data engineers to get the Google Analytics add-on for Google Sheets. Share the audience definition piece of the hypothesis with the data engineer. The data engineer will set up a query as shown below to produce two reports accurately representing the audience defined in the hypothesis. One report is the daily session, conversion volume and conversion rate for the test experiment. The other report is for the control. Name the report Population A and B – something anonymous will work.

Google Analytic Report Information

Now schedule the report to refresh daily. Having done this, hide the config sheet and make sure the test analyst is not given editor rights on the data so they cannot see the produced report config:

Hidden Google Sheet message

Now the analyst has blind access to the data with no awareness of what the experiments are for, what the hypothesised effect is, who the audiences are or which population corresponds with what experiment. Due to the blind data access, there is no cognitive bias in the analysis.

Google Sheet data

The analyst reports on the performance of each population as they see it in the numbers. Each member of the team is sufficiently removed from the hypothesis and test detail so as to achieve a double blind test production and analysis. Insert happy-dance here!

Integrate into Your Data Team’s Workflow

Google Optimize just leveled up by going one step further with Double Blind Testing. The double blind testing strategy has the power to improve your data analysis. It can open opportunities for you and your team by decreasing unconscious bias and increasing the effectiveness of your media spend. Choose to take more control of your marketing dollars by integrating this testing process into your daily workflow.

To learn more about Google Optimize and Double Blind Testing, reach out to us at

Apple, Google, Privacy, and Bad Tech Journalism


Wait, did they just say Safari now blocks Google Analytics?

(Spoiler alert: it doesn’t)

At the 2020 edition of the Apple Worldwide Developers Conference (WWDC), Apple announced that the new version of MacOS (nicknamed Big Sur) would ship with version 14 of the Safari web browser – promising Safari would be more privacy friendly. Which is a great move and in line with the regulatory and digital marketing landscapes.

However, based on fuzzy, out-of-context screenshots shown during the announcement, some digital marketing publications started asserting that the new Safari would block Google Analytics.

[Narrator’s voice: it didn’t]

Here are some of the articles in question:

Within minutes, that poorly researched bit of fake news was all over social media.

So what really happened? Should you worry?

Cooler heads always prevail, so let’s take a step back and look closely at what really happened.

What is ITP and why does it matter?

The WWDC is generally the occasion for Apple to announce new features and key developments in their tech ecosystem from desktop and mobile operating systems to SDKs, APIs, and all that good technical stuff.

In recent years, Apple has used the WWDC to announce changes to the way they handle privacy in web and mobile apps, namely with initiatives such as ITP (Intelligent Tracking Protection), which is used in Safari, Apple’s Webkit-based browser on Macs, iPhones, and iPads.

In a nutshell, ITP restricts the creation and the lifetime of cookies, which are used to persist and measure someone’s visit on one site (first party, a.k.a. 1P) or across multiple websites (third party, a.k.a. 3P). ITP makes things more difficult for digital marketers because users become harder to track and target.

If we use Google Analytics as a comparison, ITP can “reset” a known visitor to a new visitor after only a couple of days, instead of the usual 2 years – assuming users don’t change devices or clear their cookies.

If we look at ITP with our privacy hat on, even collecting user consent will not stop ITP from neutralizing cookies.

ITP arrives at the right moment; just as online privacy starts to finally take root with pieces of legislation such as GDPR and ePrivacy in Europe, CCPA in California, LGPD in Brazil, APA/NDB in Australia, APP in Japan, PIPA in Korea, and a lot more being made into bills and/or written into law.

Arguably the above pieces of legislation allow for the collection of user consent prior to collecting. So we should not really be worrying about Safari potentially collecting information that users consented to, right?

That was not even a consideration in the aforementioned pieces on “Safari blocks Google Analytics.”

Does the new Safari really block Google Analytics?

(Second spoiler alert: it still doesn’t)

The most obvious way to show you is with a test. Luckily, I had MacOS Big Sur beta installed so I took a look under the hood – especially on the sites that published that “Safari blocks Google Analytics” story. Let’s fire up Safari and turn on developer mode.

Sure enough, Google Analytics sends a tracking call that makes it home to Google collection servers. Safari does not block Google Analytics.

Now let’s take another look at that new privacy report: it shows “22 trackers prevented.”

Wait, the list shows! Didn’t we just establish that Google Analytics tracking went through?

Let’s clarify: what the panel below shows are the domain names of resources loaded by the page that are flagged in the ITP lists as potential tracking vectors using third-party cookies.

Other than that, ITP plays its role in drastically reducing the Google Analytics cookie’s lifetime to just a week as shown below.

Let’s drive this point home again if needed: Safari 14 does not block Google Analytics.

ITP is enforced as per the spec by blocking third-party cookies and limiting cookies to a lifetime of a week at most.

So what’s the big impact?

As mentioned, ITP is primarily going to reduce the time during which a visitor is identified. After a week, ITP deletes/resets the user cookie and the visitor is “reborn”. Not a great way to study user groups or cohorts, right?

If you’re worrying about the impact of ITP on your data collection, may I suggest reading this awesome piece on ITP simulation by my colleague Doug Hall.

What is important to remember is that Apple is using ITP block lists built in partnership with DuckDuckGo, a search engine that has made a name for itself as a privacy-friendly (read: anti-Google). I, for one, have yet to see what their business model is but that’s a story for another post.

At any rate, ITP lists are meant to block cookies for specific domain names.

Even if Apple did decide to block Google Analytics altogether, how big a deal are we talking about? According to StatCounter, Safari accounts for roughly 18% of browser market share (as of June 2020). Let’s round this up to a neat 20%. That’s an awful lot of data to lose.

Arguably, Google Analytics wouldn’t be the only tracking solution that could be impacted. Let’s not forget about Adobe, Criteo, Amazon, Facebook, Comscore, Oracle—to name a few.

So if you keep implementing digital analytics according to the state of the art, by respecting privacy and tracking exclusively first-party data, you’ll be a winner!

Is it really just bad tech journalism?

Let’s get real for a moment. If tech journalists posting the story about Safari blocking Google Analytics knew about ITP, they wouldn’t have published the story – or at the very least with a less sensational headline. Even John Wilander, the lead Webkit engineer behind ITP spoke out against the misconceptions behind this “Safari blocks GA piece.”

This is unfortunately a case of bad tech journalism, where half-truths and clickbait titles drive page views. Pitting tech giants Apple and Google is just sensational and does not highlight the real story from WWDC: privacy matters and Apple are addressing it as they should.

In this, I echo my esteemed colleague Simo Ahava in that this kind of journalism is poorly researched at best, intentionally misleading at worst.

Most of the articles on this particular topic backtracked and offered “updates” but they got caught with their hand in the cookie jar.

To be fair, it is also Apple’s fault for using misleading labeling.

But is it so bad considering we’re talking about a beta version of a web browser? Ìf anything, Apple now has a few months ahead of them to make adjustments before Big Sur and Safari.

Beyond the fear, uncertainty and doubt, this kind of publication is symptomatic of an industry that is scared by the effect that privacy regulation is having on their business.

How is MightyHive addressing this?

While we at MightyHive have long been preparing  for the death of the cookie and digital ecosystem focusing on first-party data, we can appreciate that initiatives such as ITP can make a digital marketer’s life very complicated.

We strongly believe that the future of digital marketing lies in first party data, consent and data quality.

Cookies are on their way out but this does not mean the end of the world.

Need help navigating the ever-changing digital marketing landscape? Contact us for guidance!

WEBINAR: A Programmatic Buyer’s Look at the ISBA Report’s “Unknown Delta”

A Programmatic Buyer’s Look at the “Unknown Delta”

Recently the Incorporated Society of British Advertisers (ISBA) set out to shine a light on the programmatic advertising supply chain, but despite exhaustive efforts to map and attribute every advertising dollar, the subsequent report could not account for a sizable fraction of digital advertising budgets. This “unknown delta,” as the ISBA calls it, is associated with causes ranging from fraud to inventory reselling. But regardless of the reasons, the ISBA report exposes a complex system that lacks transparency.

“[The unknown delta] is not meant to be assumed as fraud….This is important for anyone who is thoughtfully assessing this study; the unknowns can ideally become knowns.”

– Rachel Adams, Head of Media Activation US, MightyHive

The ISBA report is the focus of the latest episode of Live with MightyHive and features Rachel Adams, Head of Media Activation, MightyHive US. Adams brings years of agency buying experience and countless hours working with MightyHive clients on in-housing strategies and implementation. Together with Senior Director of Marketing Myles Younger, the two cover some of the report’s findings and strategies for optimizing the digital advertising supply chain and improving transparency.

This episode of “Live with MightyHive covers: 

  • Findings from the ISBA report
  • The advantages of simplifying your supply chain
  • The increasingly important role of transparency

Get the Video

Watch Episode 3: A Programmatic Buyer’s Look at the ISBA Report’s “Unknown Delta”, and view the slides below.

Subscribe to Live with MightyHive to hear about all of our upcoming webinar-workshops. And if there’s a topic you’re interested in, email us at

And check out MightyHive CEO Pete Kim’s thoughts on the ISBA report here: Marketers Deserve Better.