“The customer is not a moron, she is your wife.” This less famous quote by David Ogilvy is about 70 years old, but has lost none of its relevance.

In fact, it is directly in line with Apple’s Tim Cook’s appeal at CPCD on January 29. Coverage of it has been very one-sided, focusing on Cook’s alleged criticism of Facebook. However, Cook gave a tour d’horizon of using technology for good, and the resulting corporate responsibility and positioning of Apple.

David Ogilvy couldn’t have known any of this 70 years ago, but he urged even then to take consumers seriously, to respect them as people who are intelligent enough to see through over-the-top advertising and who had better not be bored to death. “You cannot bore people into buying” in 2021 also means that you don’t buy the data of umpteen marketers together, in order to then track a consumer via targeting across the most diverse applications. In the 20s of this century, as in the 50s of the past, you need content: advertising that fascinates, that interests, that can generate resonance on its own.

But we no longer live in the time of Ogilvy or Bernbach. We live in the time of technology and data. If Ogilvy understood creativity as a measure of courtesy to consumers, modern marketers must face the challenge of how the demand for this courtesy plays out in their own strategy on data and technology. Or within Tim Cook’s logic, how to live up to one’s social responsibility as an advertising company—and thus as a service provider in this field. 

Not everything should go through the cycle of it emerging, being misused and consequently banned before we look at it critically and allow it to be possible with the right effect. The events surrounding elections in once democratic fortresses, or the division of societies through the spread of fake news should concern everyone who uses these media or uses them commercially for themselves. This is not solved with a one-time boycott as an advertising partner of Facebook, as effective as the #StopHateForProfit initiative was. 

But even then, criticism was mixed in with the applause, and questions were raised about financial or moral motives, about one-time restrictions or permanent consequences.

There was little discussion, however, about whether it was enough to point the finger at the social media giants or whether the company should reassess its own handling of customer data. In Germany in particular, the discussion about customer data usually only takes place in connection with legal initiatives, i.e. the DSVGO. What is allowed and what is not seems to be more important than what is right and what is not. The sudden abandonment of cookies is understood as an obstacle in the same way as the advent of adblockers five years ago.

However, in 2020, the year of COVID, two other major developments are significant that put the issue in a different light. One is the debate around purpose for brands. More and more marketing decision-makers believe their brand needs to communicate what role it wants to play in society, what it should stand for. One can argue whether candy bars need a socially relevant role or whether such a question should be decided in marketing and addressed in communication. But one can hardly argue whether brands that claim such a strategy for themselves also need to provide answers about their responsibility in handling and using data. This topic is causally located in marketing and is a direct question of communication. 

The second major issue in 2020/21 is that of direct customer access. D2C (direct to consumer) was one of the big winners at a time when many brands felt that the absence of a strategy in ecommerce; the dependence on a few platforms can make business very cumbersome, to put it nicely. The investment of a billion on the part of Dr. Oetker was not about a few leased delivery trucks, but about owning the last mile, bringing access to customers and the use of data for assortment and sales planning.

And while this deal was one of the big headlines in Germany during COVID, it’s important to note that most marketers have a purpose strategy in place rather than a data strategy. The Marketing Tech Monitor 2020 suggests that this strategy isn’t even in the drawer—no, it’s mostly not even in the planning stages.

It is becoming increasingly difficult to engage with customers because their media behavior has changed so massively. And even if many still carelessly release all cookies with every single website visit, marketing that continues to rely solely on the data policy of third parties will be too expensive in the long run. An idea about direct access to customers, about a first-party data strategy and on which technology this should be mapped, is becoming more and more essential. Technology for the benefit of people, as Tim Cook put it. And how do companies position themselves in this regard, what is their responsibility, who wants to be “a good corporate citizen in a tech world?” Marketing has to answer these questions, because the customer becomes pickier, but never becomes stupid. As David Ogilvy described it 70 years ago.

This article was originally published in German at Horizont. You can find follow-up coverage from Horizont here.

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 familiar—but 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 www.mysite.com, server-side GTM will send data to tracking.mysite.com, 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?  

Very. 

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. 

Phew!

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.

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?

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:

• Apple Insider
• Plausible Analytics (GA competitor)
• Search Engine Journal

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 google-analytics.com?! 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.

Google Chrome to Drop Third-Party Cookies

On January 15th, Google announced that third-party cookies would be blocked in Chrome by 2022. Over the past 24 months, increasingly aggressive iterations of Intelligent Tracking Prevention (ITP) in Apple products have challenged the third-party cookies used for measurement and targeting. However, Chrome currently commands a majority of desktop browser share globally, which makes Google's announcement significant for the industry. In the next 24 months, third-party cookies will become effectively unusable for advertising measurement.

Based on current usage, by 2022 the market will be dominated by browsers that block some or all third-party cookies by default.

The Next Two Years

With this announcement and self-imposed deadline, Google will have to work out how their own ad platforms will interface with third parties, such as ad exchanges. The programmatic advertising ecosystem of which Google is a significant part of is based on third-party cookies. As things stand, Data Management Platforms (DMPs) will be significantly challenged. Likewise, view-based and today's multi-touch attribution (MTA) solutions are effectively moot. Many forms of third-party data, already challenged by government regulations like GDPR enforced in May 2018, will cease to exist.

Google has proposed a mechanism to allow for anonymized and aggregated measurement called the Chrome Privacy Sandbox which was announced in August 2019.

Sand What?

In August 2019, Google announced an initiative aimed at evolving the web with architecture that advances privacy, while continuing to support a free and open ecosystem. They call it a "Privacy Sandbox." Right now, these constitute a set of proposals for browser APIs that will eventually serve as privacy-preserving technical alternatives to third-party cookies.

There aren’t any tangible tools inside the Privacy Sandbox—at least not yet. Google said in their blog post that it aims to "eventually" build these tools with the industry over the next two years to ensure interoperability in the programmatic and ad tech ecosystem.

How Will We Target Audiences Without Cookies?

Third-party cookies have been used for everything from frequency management to behavioral targeting. How might marketers continue to employ these tactics moving forward?

Audience-based and user-level targeting have been the cornerstone of programmatic buying over the past decade. Indeed, the very concerns around ad targeting and user privacy contributed to Google's announcement.

There is every reason to believe that targeting will still be possible, as will attribution, but the mechanisms will need to radically change. The scale and scope of addressable audience targeting will decrease and advertisers may turn to federated learning, contextual targeting, and other techniques to drive business performance through programmatic platforms. Another suggested approach would be for the browser itself to segment audiences based on their browsing behavior, and once there are a sufficient number of other browsers in this interest group an advertiser could target them.

What about frequency management? In October 2019 Google introduced frequency management across bid requests without a third-party cookie associated with them. Instead, Google employs machine learning to analyze behavior from across their ad inventory and provide an estimate with a high degree of confidence the number of impressions an individual had been exposed to.

Lastly, publishers with first-party audience relationships are poised to fill in audience targeting gaps left by the removal of third-party data cookies. For example, this would include a publisher with a paywall that requires a user to login to read content. Publications are likely to sell more curated inventory packages (here's an example from Meredith), much of which will be available programmatically via private marketplaces (PMPs) and programmatic direct/guaranteed deals.

Spending on programmatic direct channels has grown significantly in recent years and is expected to continue climbing.

How Will We Measure?

Conversion tracking will become increasingly difficult to measure using current approaches, but there are several solutions available now and on the horizon. For example, as Campaign Manager log-level data loses fidelity, solutions like Google Ads Data Hub stand to open up new possibilities with more durable data and more privacy-safe methodologies. Likewise, platforms like Amazon and Facebook are working on similar solutions.

Source: "The New Possibilities of an ID-Redacted World"

Google's proposal for a conversion measurement API would allow for click-based attribution without using cross-site trackers. Trials for click-based conversion measurement sans third-party cookies will start by the end of 2020. Read more on the Chromium Blog and in AdExchanger.

What about view-based conversion tracking? Most current approaches will cease to work in any major browser once Chrome deprecates third-party cookies, but Google has indicated that the future of measurement may be more probabilistic or panel-based. Whether this will allow for view-through conversion tracking remains to be seen.

How MightyHive Will Adapt

As with many businesses in the programmatic space, a number of MightyHive services are built to some extent on top of the third-party cookie, such as programmatic audience activation, dynamic creative, and advanced attribution.

In their current state, these technologies will not work in two years’ time. However, there is every reason to believe that ad tech will continue to innovate and adapt with these changes opening up new opportunities for more advanced and smarter marketers in a new cookie-less era.

• We have already started developing targeting and measurement approaches independent of cookie-based approaches for use on multiple bidding and measurement platforms. Further, as a leading Google partner, will be collaborating closely with Google on the Privacy Sandbox protocols and work hard to bring these solutions to our clients.
• MightyHive has deep, holistic consultative expertise to bear on these challenges. For example, we have invested heavily into data science, API and Cloud-driven solutions to help marketers gradually increase the utility of their first-party data while simultaneously reducing reliance on third-party cookie pools.
• As part of S4Capital, with our sister company MediaMonks, our clients are exploring end-to-end digital strategies that leverage first-party data to drive content and programmatic media.

We argue consumers should always be the first constituent in considering the digital advertising experiences online and adapting to this shift requires marketers to place more attention on the value exchange traded for a consumer's attention. The key will be to move with the market, as opposed to push against it and seek short-term fixes.

As always, MightyHive is your partner and your advocate.