Analytics news: August 2026

We're back from the summer break with a triple dose of news: June, July and August together. It may have been holiday season, but Google kept delivering on what it announced at Google Marketing Live in May: GTM and the Google tag are actually starting to merge into one system. On top of that, the Consent Mode deadline I wrote about in May has finally passed, and we can already see the first consequences. And since more and more of my work is server-side and media platforms, not just GA4 and GTM, starting with this issue I'm adding a separate section on exactly that. Let's start with the most important part: Tag Manager.

Google Tag Manager

GTM and the Google tag are becoming one system

In July, Google Tag Manager got its first interface change in this direction, specifically on the Overview page. For now, I think it's a change for the worse.

My objection is that the control for switching between workspaces has been moved somewhere very unintuitive when only the Default Workspace is active.

Other than that, showing the current Google data flow is a good idea.

These changes are probably just a prelude to what was announced at Google Marketing Live in May. At the end of August, Google announced that those changes will roll out in the near future.

I haven't found a container with these changes available yet, but here's what we know so far:

A simpler interface

The Overview page is getting another redesign. The update won't remove any features, but it will add several sections to the interface, including:

• Settings: a new central place to manage container settings. Optimize
• Advanced: a collapsible card with these tagging features:
  • Triggers
  • Variables
  • Templates
  • Folders

Unifying the Google tag and Google Tag Manager

Google tags will be turned into functional Google Tag Manager containers. Sites that use only the Google tag will get tagging features that used to be reserved for Tag Manager: a tagging interface, debugging and versioning. Each Google product (Ads, Analytics, Floodlight) still has its own tag, but management moves to one shared container.

I see this as a natural continuation of what I wrote about in May: Google keeps shifting the center of gravity toward GTM as the central management point. For audits, that's good news, with fewer mismatched configurations between GA, GTM and Google Ads. For access management, it's another reminder to clean up who has permissions to the container.

It's worth noting that no changes will be made to existing containers without the user's confirmation.

Visual tagging: GTM builds the configuration for you

The package also includes Visual tagging, for now in beta and only for purchase conversions in Google Ads. Instead of setting up selectors and triggers manually, you click through the site in Tag Assistant and GTM builds the configuration itself. It's an extension of the Visual Event Builder I wrote about when covering the May announcements.

Google Analytics 4

June 15 has passed, and the first effects are showing

In the May issue we wrote about the June 15 deadline, after which ad_storage becomes the only parameter that decides whether advertising data flows from GA4 to Google Ads, and Google signals is reduced to a reporting-only role. The deadline has passed, and industry audits are starting to show who wasn't ready for it.

The scale of the problem worries me. Some independent scans of Europe's largest websites show that a large share of sites had ad_storage set to "granted" by default before the user made a choice, and some didn't switch it correctly to "denied" after the user declined consent. (source: https://www.privado.ai/post/almost-half-of-top-websites-now-misconfigure-google-consent-mode)

If Consent Mode v2 on your site (or your client's) was set up correctly through a certified CMP, the change went by unnoticed. If not, now is the time to check, because nothing will mask the problem anymore.

GA4 announces a cleanup of traffic sources, then does nothing about it: Source Group

The June release notes include an interesting, if unspectacular, change in GA4: a new Source Group dimension that consolidates inconsistent source values into one label. Instead of "facebook", "fb" and "Meta-facebook", you simply get "Facebook". Google also says the dimension is ready to group traffic from AI tools (ChatGPT, Perplexity), which fits with what we wrote in May about the new AI Assistant channel.

Unfortunately, it stopped at the announcement. I haven't found this dimension in any property.

Finally, a way to exclude unwanted traffic from GA4

Google has finally added a Hostname filter, a new filter type under Data filters that lets you drop events from outside your approved domain. It's a small thing, but very handy if you've ever fought with data from suspicious copies of your site or staging environments ending up in your production property.

Stape and server-side

Starting with this issue, I'm adding a new section. More and more of my day-to-day work goes beyond client-side GA4 and GTM: server-side setups and integrations with media platforms such as Meta, TikTok and Google. It's usually the first thing I look at when auditing a client with a larger ad budget, so it makes sense to start summing it up here too.

Safari 27 (beta): tracking protection moves to the network level

This is by far the most important news of the period for anyone working with server-side tracking. An analysis of the WebKit code (Apple hasn't officially announced this in the release notes, but the changes are visible in the beta) points to three new directions:

• Link Tracking Protection now covers more platforms. In Private Browsing, Safari starts stripping parameters from links to Threads (xmt), YouTube (si) and X (twclid, cn, cxt). Until now, it mainly affected gclid, fbclid and msclkid.
• Advanced Fingerprinting Protection classifies more scripts as fingerprinting tools: LinkedIn Insight Tag, Tealium, Segment. This is dangerous because if your CDP gets classified as fingerprinting, every tag deployed through that platform inherits the restriction, even if the tags themselves aren't on the list.
• The most interesting (and most worrying) change: Safari starts blocking traffic at the network level by checking the destination IP address of a request, not just the domain or the script. The classic workarounds (your own subdomain, renaming the file, a custom path) stop working if the connection still ends up at the infrastructure of a known ad platform.

All of this is still in beta, so I'd treat it as a warning rather than a certainty, and it needs to be verified once the stable version is out. But the direction is clear and matches what Apple has been doing for a long time. It's one more argument for running your server-side infrastructure on your own domain (same-origin), not on the vendor's default subdomain address.