GTM vs sGTM vs Zaraz vs Gateway: I Tested All Four with Real E-commerce Data

The Weight of Third-Party Scripts and Alternative Approaches

Client-side event tracking is no longer sufficient on its own for reliable data collection. Safari 26’s Advanced Fingerprinting Protection, ITP restrictions, and ad blockers can leave browser-side data 30-40% incomplete. Server-side and edge-based approaches have become a necessity.

One of the factors that most significantly impacts web performance is third-party scripts. Analytics, ad pixels, A/B testing tools; each one loads a separate JavaScript file in the browser, negatively affecting Total Blocking Time (TBT) and Largest Contentful Paint (LCP) metrics. On e-commerce sites especially, this load can reach serious levels. On platforms like Shopify, an app installed to improve SEO and performance can simultaneously disrupt data flow.

Total Blocking Time (TBT) measures the total duration during which a page is unresponsive to user interaction. Long-running JavaScript tasks directly increase this metric.

Largest Contentful Paint (LCP) measures how long it takes for the largest visual element (image, heading block, etc.) on the page to render. Third-party scripts can delay LCP by blocking the main thread.

In this post, I compare Google Tag Manager (client-side), Server-Side GTM, Cloudflare Zaraz, and Google Tag Gateway using real e-commerce data. First, I will cover why the client-side vs. server-side distinction is now critical, then look at the strengths and weaknesses of each approach.

Client-Side vs. Server-Side Tracking: The Fundamental Difference

To understand the four approaches in this post, we first need to clarify the basic distinction: where is data collected and where is it processed?

Client-Side (Browser)

The traditional approach. JavaScript code runs in the browser, and events are sent directly to third-party servers (Google, Meta, TikTok).

User browser → JavaScript SDK → analytics.google.com / facebook.com

The problem: The browser has full control over this data flow. Ad blockers can block scripts. Safari ITP and AFP can restrict cookies and fingerprint APIs. Users can disable JavaScript from browser settings. The result: collected data is incomplete.

Server-Side (Server/Edge)

Data first goes to your own server or edge layer, where it is processed and distributed to destinations.

User browser → Your domain/server → analytics.google.com / facebook.com

The advantage: Independent of browser restrictions. Provides 1st-party context. Data enrichment, filtering, and deduplication are possible. Consent management can be controlled server-side.

Why This Distinction Is Now Critical

Three developments in the second half of 2025 eliminated client-side’s standalone sufficiency:

1. Safari 26 AFP (September 2025): Client-side trackers lost access to fingerprint APIs, query strings, and referrer¹².
2. Chrome Privacy Sandbox shut down (October 2025): 3P cookies remain in Chrome, but they are already blocked in Safari and Firefox. Server-side is the only reliable path for cross-browser consistency³⁴.
3. Consent Mode v2 mandate (July 2025): Non-compliant sites lose Google Ads remarketing and audience segmentation⁵⁶.

The details of these three developments and changes in cookie policies are covered later in this post.

In this context, each of the four approaches below occupies a different position along this spectrum:

Approach	Position	Browser dependency
GTM (Client)	Fully client-side	Fully dependent
sGTM	Client hit → server processing	Partial (initial hit from client)
Zaraz	Edge (CDN) processing	Minimal (near-zero JS)
Gateway	Proxy (transparent)	Low (proxies existing tags)

Overview of 4 Approaches

GTM (Client-Side)

Google Tag Manager is the most widely used tag management solution that runs in the browser. It listens for events through the dataLayer and manages tags via its trigger and variable system.

Advantages:

• Extensive integration library (hundreds of templates)
• Powerful trigger, variable, and custom JavaScript support
• Large community and documentation resources
• Free

Disadvantages:

• Each tool loads a separate script in the browser; high performance cost
• Vulnerable to ad blockers
• Security risks from third-party scripts (XSS, data leaks)
• Safari 26 AFP can cause GTM scripts classified as trackers to lose query string and referrer access

Recommended when: Small to mid-size sites, setups requiring many integrations, teams with GTM experience.

Server-Side GTM (sGTM)

Server-Side GTM runs the GTM container on the server side instead of the browser. The client sends hits to a proxy endpoint, and the server-side container processes the events and distributes them to the relevant destinations. It is typically hosted on Cloud Run or a dedicated server.

Advantages:

• 1st-party context: hits travel through your own domain
• ITP (Intelligent Tracking Prevention) bypass capability
• Full data control; you decide server-side which data goes where
• Resilient against ad blockers
• Consent Mode v2 can be managed server-side

Disadvantages:

• Infrastructure costs (Cloud Run bills increase as traffic grows)
• Setup and maintenance complexity
• GTM knowledge is still required; server management is added on top

Recommended when: High-traffic sites, setups with CAPI (Conversions API) requirements, teams with engineering capacity. For teams that do not want to manage their own infrastructure, managed hosting solutions like Stape significantly reduce the setup and maintenance burden.

2026 update: With sGTM v3.2.0, the GA4 Client no longer loads gtag.js; all Google JS libraries are loaded through the Web Container Client. The readAnalyticsStorage sandbox API allows GA client/session IDs to be read securely.

Cloudflare Zaraz

This solution came with Cloudflare’s 2021 acquisition of Zaraz⁷. It runs third-party scripts on Cloudflare Workers at the edge instead of in the browser⁸. No additional JavaScript is loaded into the browser unless explicitly requested.

Advantages:

• Zero JS load in the browser; performance impact is virtually none
• Included in Cloudflare plans (free up to 1 million events per month)
• Easy setup; configuration through the Cloudflare dashboard
• Built-in consent management
• Customizations via JavaScript SDK

Disadvantages:

• Cloudflare dependency; the site must be behind Cloudflare
• Fewer integration options compared to GTM
• dataLayer incompatibilities⁹; migrating an existing GTM implementation one-to-one is not always possible
• Debugging and troubleshooting is more difficult¹⁰

Recommended when: Sites already using Cloudflare, projects that prioritize performance, setups requiring only a handful of tool integrations.

2026 update: With Zaraz Automated Actions (November 2024), pageview, custom event, and e-commerce tracking can be automated on a per-tool basis. The Managed Components program allows vendors to build their own integrations. Consent management is Google Consent Mode v2 and IAB TCF compliant.

Google Tag Gateway

Google Tag Gateway is not a tag manager. It is a tool that only proxies Google tags (gtag.js, GA4, Google Ads) through your own domain¹¹. It recovers signals lost when ad blockers block Google endpoints.

Advantages:

• Completely free
• Can be set up in 5 minutes
• According to Google’s own data, a median 11% signal recovery
• Can run alongside an existing GTM or Zaraz setup

Disadvantages:

• Only applies to Google tools (Meta has its own gateway solutions¹², other platforms like TikTok are out of scope)
• No tag management features
• Not a standalone solution

Recommended when: As an add-on to an existing setup, in scenarios where Google Ads conversion loss is occurring.

2026 update: Google Tag Gateway exited beta in May 2025. In January 2026, GCP integration (one-click deployment via Global External Application Load Balancer) and Akamai support were added¹³. It is no longer limited to sites behind Cloudflare; sites using GCP or Akamai can also use Gateway.

Comparison Table

	GTM (Client)	sGTM	Zaraz	Gateway
Execution point	Browser	Server	Edge (CDN)	Proxy
Performance impact	High	Low	Near zero	None
Setup difficulty	Low	High	Medium	Very low
Cost	Free	Variable (infra)	Free (1M events/month)	Free
Ad blocker resilience	Low	High	Medium-high	High (Google only)
Number of integrations	Very high	High	Medium	Google only
GTM knowledge required	Yes	Yes	No	No
Consent Mode v2 support	Partial	Full	Full (built-in)	Full (Google tags)
Resilience to 2026 browser restrictions	Low	High	High	Medium-high

Real-World Data Test

To ground this comparison in reality, I ran two separate GA4 properties on an e-commerce site simultaneously: one through GTM, one through Zaraz. Both platforms tracked the same users over the same time period. Below are the observational results from the collected data.

Overall Numbers

Metric	GTM	Zaraz	Diff
Total events	131,163	559,385	+326.5%
Total events (excl. page_view)	90,992	103,196	+13.4%
page_view	40,171	456,189	+1,035.6%
session_start	12,809	16,118	+25.8%
purchase	140	143	+2.1%

At first glance, Zaraz appears to have collected 4.3x more events. But once you strip out page_view, the difference drops to just 13%. This suggests that the increase in session_start and other interaction events is a reasonable gap explainable by ad blocker bypass. The real anomaly is in the page_view numbers.

The page_view Problem

The page_view-per-session ratio is striking: 3.1 in GTM, 28.3 in Zaraz. A page-level breakdown reveals the source of the discrepancy.

Page	GTM	Zaraz	Diff
/arama	3,713	85,642	+2,207%
/arac-kamerasi	1,674	58,501	+3,395%
/sarj-data-kablosu	601	16,530	+2,650%
/sepet	556	615	+10.6%
/order	715	731	+2.2%

Category and listing pages show enormous gaps, while cart and order pages stay within roughly 10%. This is not a Zaraz bug; it is a default configuration decision. Zaraz listens to history.pushState and replaceState calls and fires a page_view on every URL change. Listing pages where the URL changes during filtering, sorting, or pagination are the most affected by this inflation. On sites with SPA-like behavior, this feature needs to be disabled or customized.

The Attribution Problem

The event-level source/medium distribution paints a dramatic picture between the two platforms.

Source	GTM Sessions	Zaraz Sessions
(direct) / (none)	8,699	20,480
google / organic	10,598	38
All referral	9,101	40

Event-level attribution in Zaraz is completely broken. At the event level, 99.5% of sessions are reported as direct/none. Organic search and referral sources are virtually invisible at the event level.

However, the session-level source/medium table tells a different story. Zaraz works correctly at the session level, and it even captured some referral sources that did not appear at all in GTM. On the GTM side, missing referral exclusion or cross-domain configuration may also have caused some sources to disappear. For this reason, configuration details on both sides need to be considered when comparing attribution.

E-commerce Funnel

The critical question: are conversion events reliable? The funnel comparison draws a clear picture.

Step	GTM	Zaraz	Diff
view_item	16,843	17,690	+5.0%
add_to_cart	858	814	-5.1%
begin_checkout	740	774	+4.6%
add_payment_info	196	210	+7.1%
purchase	140	143	+2.1%

The daily purchase distribution also confirms the consistency.

Date	GTM	Zaraz	Diff
February 22	12	11	-1
February 23	22	23	+1
February 24	17	15	-2
February 25	16	16	0
February 26	25	26	+1
February 27	27	29	+2
February 28	21	23	+2

From view_item onward, all funnel ratios are nearly identical. The daily purchase difference is 2 at most. Cart abandonment tracking included, e-commerce conversion tracking works at a reliable level on both platforms.

Zaraz-Specific Benefits

Certain events that Zaraz collects by default had not been configured as separate events on the GTM side. This data was already present in the dataLayer, but since no triggers or tags were defined for them in GTM, they were not forwarded to GA4. Zaraz automatically reads the dataLayer and collected these events without additional configuration⁹¹⁴.

Event	Count	Description
consent_default	14,377	Consent default state
user_data	3,515	User data event
search	3,297	On-site search
consent_update	2,562	Consent update
login	215	Login
sign_up	40	Registration

The consent events and on-site search data in particular are valuable. In GTM, these can be collected by defining separate triggers and tags; Zaraz’s advantage is that its dataLayer compatibility allows it to provide these out of the box.

The Shifting Landscape in 2026

When I published the first version of this post in early March 2026, the focus was on the performance and data quality gap between GTM and Zaraz. However, three developments in the second half of 2025 fundamentally changed the tracking ecosystem.

Safari 26 and Advanced Fingerprinting Protection

Safari 26, released in September 2025, enabled Advanced Fingerprinting Protection (AFP) by default¹². Client-side scripts classified as trackers can no longer:

• Access high-entropy APIs (screen resolution, hardware info)
• Retain long-lived storage written by scripts (cookies, localStorage)
• Access query string parameters or document.referrer

Apple exempted standard campaign parameters (UTM), but fingerprinting was fully blocked. This directly degrades data quality from client-side tracking for Safari users.

Practical impact: Client-side solutions like GTM collect less and lower-quality data from Safari 26 users. Server-side or edge-based solutions are unaffected by these restrictions. Safari and Firefox also block bounce tracking protection, preventing tracking via redirect chains; cookie and storage data for intermediary domains without user interaction within a set period are cleared.

Beyond this, Safari has been capping the lifetime of JavaScript-created cookies (document.cookie) to 7 days since ITP 2.1 (February 2019). localStorage and IndexedDB are also purged after 7 days of non-use. When link decoration is detected (query parameters from known trackers), this drops to 1 day. Server-set cookies (Set-Cookie header) are exempt from this restriction, but Safari performs CNAME cloaking detection: if the tracking subdomain’s IP address resolves to a different subnet than the main domain, those cookies are also reduced to 7 days¹⁵.

The End of Chrome Privacy Sandbox

In October 2025, Google officially shut down the 6-year Privacy Sandbox project³⁴. Attribution Reporting, Protected Audience, Private Aggregation, and IP Protection APIs were removed. 3P cookies remain in Chrome.

What does this mean? No changes in Chrome in the short term, but 3P cookies are already blocked in Safari and Firefox. Server-side/1st-party is the only reliable path for cross-browser consistent data collection.

The Evolution of Cookie Policies and Google’s Reversal

The cookie story is the most turbulent in the tracking ecosystem. In January 2020, Google announced it would remove third-party cookies from Chrome “within 2 years.” What followed: 4 delays (2021, 2022, twice in 2024), then a complete reversal in July 2024. According to Google’s own data, removing 3P cookies reduced publisher revenue by 34% on Google Ad Manager and 21% on AdSense¹⁶. With the Privacy Sandbox shutdown in October 2025, Topics API, Protected Audience, and Attribution Reporting were also removed. What survived: CHIPS (partitioned cookies) and FedCM.

CHIPS (Cookies Having Independent Partitioned State) isolates third-party cookies on a per-site basis; a cookie is only accessible in the context of the top-level site that set it, preventing cross-site tracking. FedCM (Federated Credential Management) manages federated authentication flows (Sign in with Google, SSO, etc.) at the browser level without requiring third-party cookies.

The result: 3P cookies remain in Chrome, but are already non-functional in Safari and Firefox. This shows why any tracking stack that works consistently across all three browsers needs to be 1st-party and server-side focused.

Cross-Browser Cookie Behavior (2026)

	Chrome	Safari	Firefox
3P cookies	Allowed	Blocked by default	Partitioned per site
JS-set 1P cookie max lifetime	Unlimited	7 days	Unlimited
Server-set 1P cookie max lifetime	Unlimited	Unlimited (7 days if CNAME/IP mismatch)	Unlimited
localStorage/IndexedDB	Unlimited	7 days if unused	Unlimited
Fingerprinting protection	Minimal	AFP (default)	Known fingerprinter blocking
CNAME cloaking detection	None	Yes (IP subnet check)	None

This table summarizes why server-set 1st-party cookies are critical. sGTM sets cookies via Set-Cookie headers through your own subdomain (on the same IP subnet), bypassing Safari’s 7-day limit. Zaraz, running on Cloudflare’s edge, is already in a 1st-party context; cookies are set server-side through Managed Components.

The difference between CNAME cloaking and true 1st-party: CNAME cloaking is when a tracking subdomain (e.g., track.example.com) is pointed to a third-party server (e.g., cdn.tracker.com); Safari detects this via IP subnet check and reduces cookies to 7 days. sGTM and Zaraz do not use this approach. sGTM points your subdomain (e.g., ss.example.com) to a server running on the same IP subnet (Cloudflare proxy or GCP Load Balancer); Safari accepts this as true 1st-party. Zaraz does not even require a separate subdomain redirect since it already runs on the site’s Cloudflare infrastructure. While CNAME cloaking is considered a gray area, setting 1st-party cookies through the same infrastructure is an approach consistent with browser policies.

Consent Mode v2 Mandate

Consent Mode v2 has been fully mandatory for EEA traffic since July 2025⁵⁶. Non-compliant sites:

• Lose remarketing and audience segmentation in Google Ads
• Experience gaps in attribution and conversion reporting
• Cannot send data without ad_personalization and ad_user_data parameters

There are two modes: basic (no data at all without consent) and advanced (behavioral modeling via cookieless pings). In advanced mode, when consent is denied, Google tags still load but no cookies are written. Instead, cookieless pings are sent: consent state, page views, and conversion events are transmitted without persistent identifiers. Google processes this data through behavioral modeling to recover a portion of conversion data lost from non-consented users. Server-side solutions can control consent management with more granularity.

The Expansion of Google Tag Gateway

Gateway exited beta in May 2025 and gained two important integrations in January 2026¹³:

• GCP integration: One-click deployment via Global External Application Load Balancer
• Akamai support: Expansion to CDN infrastructures beyond Cloudflare

This means Gateway is no longer limited to Cloudflare users. It is a low-cost layer that can be added alongside an existing GTM or Zaraz setup, recovering a median 11% of lost signals.

Cookieless Tracking and Alternative Measurement Methods

Tracking methods that do not rely on cookies are no longer an optional extra; they are part of the core strategy. Key approaches:

• Enhanced Conversions (Google Ads): Customer data collected at conversion time (email, phone) is SHA-256 hashed and matched against Google’s signed-in user database. Enables cross-device conversion tracking without cookies; most advertisers report a 5-25% conversion uplift¹⁷.

• Server-side CAPI integrations: Platforms like Meta CAPI, TikTok Events API, and Pinterest CAPI send hashed 1st-party data server-to-server, bypassing the browser entirely. The common model: checkout/form data → hash → server-side delivery → platform matching¹⁸.

• Cookieless analytics tools: Tools like Plausible, Fathom, and Simple Analytics operate without any cookies. They do not require a consent banner under GDPR. Sufficient for basic metrics (page views, referrer, device), but fall short for e-commerce funnel analysis and ad attribution.

• Contextual targeting: Ad targeting based on page content rather than user identity. According to 2025 research, contextual ads perform within 5-8% of behavioral targeting on CTR, within 10-12% on conversion quality, and outperform on brand safety.

• 1st-party data strategies: Data collected through loyalty programs, newsletter signups, account creation, and purchase history forms the foundation of cookieless tracking. CDPs (such as Segment, Bloomreach) unify this data into a single customer profile.

GA4 + BigQuery: Raw Data Ownership with Consent Mode

In Consent Mode v2’s advanced mode, GA4 sends cookieless pings when consent is denied. This data can be exported to BigQuery, providing a depth of analysis that the GA4 interface does not offer¹⁹.

What is and isn’t available in BigQuery for consent-denied events:

Available	Not available (null)
event_name (page_view, purchase, etc.)	user_pseudo_id
Event parameters (transaction_id, value)	ga_session_id
event_timestamp	Traffic source fields
privacy_info.analytics_storage = “No”	User/session identity

Practical usage:

• Consent ratio multiplier: Calculate the ratio of consented vs. non-consented users to estimate total conversions. Example: with a 60% consent rate and 100 observed purchases from consented users, estimated total is ~167.
• Event-level analysis: Total purchase events, revenue, and product data can be analyzed even without user/session identity.
• BigQuery ML modeling: Build propensity models based on consented user behavior patterns, then apply predictions to the non-consented segment.

GA4’s own behavioral modeling (conversion recovery visible in the UI) is NOT included in the BigQuery export. You need to build your own models.

Setup and cost: BigQuery linking is set up in GA4 Admin. Daily export is free (standard: 1M events/day limit). Streaming export costs approximately $0.05/GB. Small to mid-size sites typically stay within the free tier²⁰.

Situational Decision Guide

There is no single “best” approach. The right choice depends on the site’s architecture, the team’s capacity, and priorities.

Scenario	Recommended approach	Why
Using Cloudflare, few tools, performance is the priority	Zaraz	Zero JS load, free, easy setup
Many integrations, complex trigger logic	GTM (client)	Broadest integration library, flexible trigger system
CAPI requirement, ITP bypass, data control	sGTM	1st-party context, full data control
Experiencing Google Ads conversion loss	Gateway + existing setup	11% signal recovery in 5 minutes
E-commerce, high traffic, attribution is critical	Hybrid (Zaraz + server-side event processing)	Edge performance + server-side data enrichment
High Safari traffic, experiencing data loss	sGTM or Zaraz + server-side	AFP and ITP bypass, 1st-party context
Consent Mode v2 compliance required	sGTM or Zaraz (built-in consent management)	Server-side consent control, granular management

Key Considerations

• Zaraz: Check the auto page view configuration, watch out for SPA behavior. Default settings are not suitable for every site structure.
• GTM: Test the dataLayer quality provided by your marketplace or platform, verify enhanced measurement settings.
• sGTM: Factor in infrastructure costs and maintenance burden. Cloud Run bills can climb quickly as traffic increases.
• Gateway: Not a standalone solution; think of it as an add-on to your existing setup.
• Consent: Regardless of the approach, consent configuration directly affects results. Significant differences can emerge between scenarios where consent mode is active versus inactive.
• Privacy-first alternatives: Consider options beyond GA4 as well. Tools like Umami and PostHog can reduce the consent burden by operating without cookies.

Closing Zaraz’s Gaps with Server-Side Event Processing

Zaraz’s edge performance is strong. However, the attribution loss, event-level data corruption, and platform CAPI integration limitations I observed in the test results show that it is not sufficient on its own. This is where server-side event processing comes in.

The core idea: Zaraz continues collecting events at the edge (zero browser JS load is preserved), but the collected events are forwarded to a server-side layer where they are processed, enriched, and distributed to multiple destinations.

User browser
  → Cloudflare Edge (Zaraz: event collection, zero JS load)
    → Scout Collector (batch processing, enrichment, deduplication)
      → Destinations: Meta CAPI, GA4 Measurement Protocol, Google Ads, Klaviyo, TikTok...

I am implementing this approach with Scout, which I am developing under dnomia. Scout takes the events collected at the edge by Zaraz, processes them in batches, enriches them with profile data, and distributes them to multiple destinations (Meta CAPI, GA4 Measurement Protocol, Google Ads, Klaviyo, etc.) from a single point.

A similar evolution is happening on the Meta side. Meta Signals Gateway has moved beyond CAPI Gateway to become a hub that can route data not only to Meta but also to Google BigQuery, TikTok, Snapchat, and custom endpoints¹². The single-point distribution logic is strengthening for e-commerce sites using multiple platforms.

Zaraz Limitations and Server-Side Solutions

Zaraz limitation	Server-side solution
Event-level attribution loss	Server-side UTM and click ID storage, profile-based enrichment
Geo inaccuracy (edge IP issue)	Geo resolution using the actual user IP
CAPI integration limitations	Direct Meta, Google Ads, TikTok, Pinterest CAPI support
Consent management complexity	Multi-layered consent model, CMP auto-detection
ITP cookie limitation	Server-set 1st-party cookie (CNAME proxy)

Is It Always Necessary?

Short answer: no. For projects with simple GA4 tracking such as blogs or corporate sites, Zaraz alone is sufficient. However, in the following scenarios a server-side layer becomes unavoidable:

• E-commerce, CAPI requirement, attribution is critical: Zaraz + server-side event processing or sGTM is needed.
• Multiple ad platforms (Meta + Google + TikTok): The single-point distribution advantage of server-side stands out. Instead of separate integrations for each platform, everything is managed through one collector.
• Data enrichment needs: When data like user profiles, past purchase history, or segmentation information needs to be appended to events, the edge layer falls short.

Conclusion

In 2026, the answer to “is client-side enough?” for event tracking has become clear: it is not sufficient on its own. Safari 26 AFP, the Consent Mode v2 mandate, and the Privacy Sandbox shutdown have made server-side or edge-based approaches a necessity.

The right tool still depends on context:

• Performance-first, using Cloudflare: Zaraz
• Complex trigger logic, many integrations: GTM (client) + Gateway
• CAPI, attribution, data control: sGTM
• E-commerce, multiple platforms, data enrichment: Hybrid (Zaraz/GTM + server-side event processing)

The real data comparison in this post makes one point clear: e-commerce conversion events (purchase, add_to_cart) are consistent within 5% across both platforms. The real differences emerge in attribution, page_view inflation, and resilience to browser restrictions.

When choosing your tracking stack, start with “which is right for my setup?” instead of “which is the best?” The answer is usually not a single tool, but the right combination of layers.

Google’s UCP protocol means checkout happening on Google surfaces, making site-based pixels completely blind. This development further increases the necessity for server-side tracking. I examine this in detail in the UCP: Agentic Commerce and E-Commerce Ecosystem post.

We also covered why GA4 and GTM’s built-in scroll tracking falls short and a content-scoped alternative in Scroll Depth Tracking. Beyond user-side tracking, interaction data can also be collected on the developer side: in Developer Interaction Tracking, I explained how I analyze file read/edit patterns using Claude Code hooks.

Footnotes

1. Safari 26 Tracking Changes ↩ ↩²
2. Safari 26 Tracking Changes: Impact on Marketing Measurement ↩ ↩²
3. Google Privacy Sandbox Shutdown ↩ ↩²
4. Google Pulls The Plug On Topics, PAAPI And Other Major Privacy Sandbox APIs ↩ ↩²
5. Consent Mode v2 Explained ↩ ↩²
6. About Consent Mode - Google Ads Help ↩ ↩²
7. Cloudflare acquires Zaraz to enable cloud loading of third-party tools ↩
8. Zaraz Use Workers to Make Third Party Tools Secure and Fast ↩
9. Zaraz DataLayer Compatibility ↩ ↩²
10. Traps you should avoid when migrating from GTM to Zaraz ↩
11. Cloudflare Zaraz vs Google Tag Gateway ↩
12. Meta Signals Gateway vs CAPI Gateway ↩ ↩²
13. Google Tag Gateway GCP Integration ↩ ↩²
14. Zaraz Settings Reference ↩
15. Safari ITP - Everything You Need to Know ↩
16. Google Cookie Deprecation U-Turn ↩
17. Google Ads Enhanced Conversions Guide ↩
18. CAPI and Enhanced Conversions Don’t Need Cookies ↩
19. Navigating Consent Mode in GA4 BigQuery Export ↩
20. GA4 BigQuery Export Cost ↩

Key Takeaways

• 01 Client-side tracking alone is no longer sufficient for reliable data collection: Safari 26 AFP, ITP, and ad blockers can leave data 30-40% incomplete
• 02 Zaraz carries a page_view inflation risk: 28.3 page_views per session with default settings (vs. 3.1 with GTM)
• 03 E-commerce conversion events (purchase, add_to_cart) are consistent within 5% across both platforms
• 04 Consent Mode v2 has been mandatory since July 2025: non-compliant sites lose Google Ads remarketing and audience segmentation
• 05 Google Tag Gateway gained GCP and Akamai integration in January 2026: no longer limited to Cloudflare
• 06 There is no single right answer: the right tool depends on site architecture, team capacity, and priorities

Frequently Asked Questions (FAQ)

+ Can Zaraz replace GTM?

In terms of performance, yes. But it is not yet a full alternative when it comes to integration variety, trigger flexibility, and event-level attribution accuracy.

+ Is Zaraz free?

Free up to 1 million events per month. After that, $5 per additional 1 million events.

+ Are Google Tag Gateway and Zaraz the same thing?

No. Gateway is a tool that only proxies Google tags. Zaraz is a tag management solution that serves as a GTM alternative. The two can be used together.

+ Should I choose sGTM or Zaraz?

sGTM is stronger for data control and CAPI integrations but comes with infrastructure costs. Zaraz is easy to set up and has near-zero performance impact. Team capacity and budget are the deciding factors.

+ Can Zaraz's attribution problem be fixed?

The event-level attribution issue depends on configuration. Session-level works correctly. It can be enriched with server-side event processing.

+ What is the fundamental difference between client-side and server-side tracking?

Client-side tracking collects data by running JavaScript in the browser; it is vulnerable to ad blockers, ITP, and Safari 26 AFP. Server-side tracking processes data at the server or edge layer; it is independent of browser restrictions and delivers higher data quality.

+ How does Consent Mode v2 affect tracking?

Consent Mode v2 has been mandatory since July 2025. Non-compliant sites lose remarketing and audience segmentation in Google Ads. In basic mode, no data is sent without consent; in advanced mode, cookieless pings enable behavioral modeling.

+ Which approach is right for a small site?

For a blog or corporate site, Zaraz (if using Cloudflare) or GTM alone is sufficient. Server-side tracking becomes necessary when e-commerce, CAPI requirements, or multiple ad platforms are involved.

+ Why do cookies expire in 7 days on Safari?

Since Safari ITP 2.1 (2019), cookies created via JavaScript are capped at 7 days. Server-set cookies (Set-Cookie header) are exempt from this restriction, but if a CNAME/IP mismatch is detected, they are also reduced to 7 days. This is why server-side tracking is essential for reliable 1st-party cookie management on Safari.