Google Tag Gateway (GTG) and/or Addingwell?

Context: why data collection is declining

Today, data collection is mainly impacted by two blockers: ad blockers and certain browser restrictions (including Safari).

The growing use of ad blockers

More and more users run ad blockers, which can prevent Google scripts from loading (Google Tag Manager Web or Google tag), and can sometimes block measurement requests directly.

Example

A user visits your site with an ad blocker. If gtm.js doesn’t load, your GTM container doesn’t start, so your events (page_view, add_to_cart, purchase…) won’t be sent.

Safari restrictions

Safari applies privacy protections (ITP) that can, in some cases, reduce the lifetime of certain marketing cookies to 7 days.

This can happen when Safari considers that the cookie is set in a “context” different from the site’s context (depending on the tracking architecture used, and especially how tracking is served/routed).

Example

A Safari user visits your site, then comes back 10 days later. If cookies expired after 7 days, they may be “seen” as a new user, which hurts attribution (campaigns), audiences, and journey analysis.

The Google Tag Gateway (GTG) solution

Overview of Google’s solution

In a standard setup, your page loads tags from Google domains. When a tag fires, requests are sent directly to Google.

With Google Tag Gateway (GTG), the logic is the same… except that:

• the browser loads GTM / Google tag from your own domain (instead of a Google domain),
• and some measurement requests also go through your domain, before being forwarded to Google.

Example (before / after)

• Before: the browser loads https://www.googletagmanager.com/gtm.js?id=GTM-XXXX 
• After GTG: the browser loads an equivalent file from your domain, for example - https://example.com/8kpl/gtm.js?id=GTM-XXXX 

The same applies to some measurement requests: they go through example.com/8kpl/… instead of going directly to a Google domain.

GTG in practice: reverse proxy + measurement path

GTG relies on two elements.

The measurement path (dedicated path)

GTG uses a dedicated path on your domain, for example: https://example.com/8kpl/ 

This path is used to:

• load Google scripts in first-party,
• carry measurement requests.

The reverse proxy (the “gateway”)

This is a component (often a CDN like Cloudflare) that receives a request on your domain, then forwards it to the right destination.

You can think of it as a “single front desk”:

• the browser talks to example.com,
• the infrastructure fetches the resource from the right place (Google, then back to the browser).

Example

You configure a rule like: “Everything that starts with /8kpl/ must be forwarded to GTG / Google endpoints.”

From the user’s point of view, everything happens on example.com, even though “behind the scenes” Google is responding.

Benefits and limitations

Partial reduction of ad blocker impact

With GTG, scripts and some requests go through your own domain. This mainly reduces blocks that rely solely on the fact that resources come from a Google domain.

Safari 16.4+ resilience thanks to the reverse proxy

In some scenarios, Safari limits cookies to 7 days when it considers that tracking is handled by an environment “different” from the site’s environment.

A DNS / edge reverse proxy makes it possible to:

• route tracking through the site’s infrastructure,
• present a more consistent context to Safari,
• and therefore improve cookie durability (e.g., long lifetime when the configuration is suitable).

GTG, which relies precisely on a first-party reverse proxy, naturally fits this Safari resilience model.

Scope

GTG applies to Google scripts and tags (Google tag, GTM, Google tags). It does not transform your non-Google tags (Meta, TikTok, etc.).

The Addingwell solution

Overview of the Addingwell approach

Addingwell is built on an architecture where event collection and delivery happen natively in first-party, with a full server-side layer.

Concretely, Addingwell provides:

• server-side tagging (your events are sent to your tracking server),
• advanced optimizations for ad blockers (Addingwell CDN option),
• and a Safari resilience approach, mainly via a Reverse Proxy (and, if a reverse proxy is not possible, a fallback option like Cookie Restore).

Example (server-side)

Your site sends an event (e.g., purchase) to your tracking endpoint (first-party). The Addingwell server receives this event and then forwards it to GA4, Google Ads, Meta, etc.

Addingwell in practice: ad blockers and Safari

Bypassing ad blockers (Addingwell CDN option)

Addingwell enables advanced bypassing thanks to:

• advanced proxying of the GTM library,
• advanced proxying of the GA4 library,
• and automatic transformation of GA4 requests (e.g., the /g/collect endpoint no longer appears).

Instead of a request that clearly looks like GA4 collection (with /g/collect), the request is modified so it no longer exposes that standard path. Many blockers rely on these easy-to-spot “signatures”.

Keeping cookies on Safari

The preferred solution when possible is Reverse Proxy DNS (e.g., Cloudflare), because it’s the most direct approach to be resilient to Safari 16.4+.

• Reverse Proxy DNS: aligns the first-party perception and keeps cookies over time.
• Cookie Restore: a fallback solution when you can’t set up a reverse proxy (useful to know, but not the primary option if a reverse proxy is feasible).

Benefits and points of attention

With Addingwell, you get the benefits of GTG (first-party, Safari resilience), with broader coverage:

• more advanced ad blocker bypass,
• a complete server-side stack,
• multi-destination support and governance/enrichment capabilities.

GTG + Addingwell setup

It’s entirely possible to combine GTG and Addingwell. The two solutions are not incompatible because they don’t play exactly the same role:

• GTG mainly provides a “reverse proxy + first-party delivery” layer (Google scripts + some requests via your domain)
• Addingwell provides a full server-side layer (collection, processing, redistribution to multiple destinations)

When does it make sense?

The GTG + Addingwell combo is relevant if:

• you want to enable GTG (Google recommendation, internal IT policy, standardization) while keeping a full server-side stack (multi-destinations, governance, ad blocker optimization),
• and/or you want a reverse proxy based on a measurement path that meets Google’s expectations.

Two common ways to combine them

Option A - GTG loads the tag, Addingwell keeps its collection endpoint (the simplest)

Here, you use GTG mainly to serve Google scripts in first-party (via the measurement path).

Then, when an event is triggered, it is sent to Addingwell’s collection URL (as in a classic Addingwell setup).

Example

• Scripts load via GTG: https://example.com/8kpl/gtm.js?id=GTM-XXXX 
• But events are sent to the Addingwell endpoint: https://tagging.example.com/…  (or another first-party endpoint already in place)

When should you choose Option A?

When you want a simple setup with the fewest changes: GTG handles first-party “loading”, and Addingwell remains your usual server-side entry point.

Option B - Measurement path as the single entry point (the most “GTG-aligned”)

Here, you go further: you use the measurement path as a single entry point for tracking.

The browser talks to only one base URL, for example https://example.com/8kpl/… .

Then the reverse proxy routes:

• some requests to Google (for GTG to work),
• and others to Addingwell (for server-side collection).

Example

• The tag loads via: https://example.com/8kpl/gtm.js?id=GTM-XXXX 
• And events are also sent via: https://example.com/8kpl/collect  → then the reverse proxy forwards them to Addingwell.

Why is this interesting?

you have a single “site” entry point (same domain + same path) for tracking, which is highly consistent with the GTG “measurement path” approach,

Point of attention

Option B requires more careful routing, because the reverse proxy must distinguish what should go to Google vs what should go to Addingwell (often via sub-paths or specific rules).

Implementation path (high level)

1. Set up GTG and choose a measurement path (an unused path).
2. Set up the Addingwell environment (server + first-party configuration).
3. Choose the architecture: Option A (in parallel) or Option B (behind the measurement path).
4. Test: tag loading, server-side event reception, then reception in platforms (GA4, Ads, etc.).

Key takeaways

✅ GTG and Addingwell are compatible
✅ Addingwell can be positioned behind GTG
✅ If you want to be fully aligned with GTG, you can use a measurement path as the entry point and route to Addingwell

Google Tag Gateway vs Addingwell comparison

Conclusion

• GTG only: a good first level of improvement, quick to enable, but focused on the Google ecosystem with partial ad blocker bypass.
• Addingwell only: a complete server-side stack, more structuring, with ad blocker optimization and advanced control.
• GTG + Addingwell: a compatible combination; Addingwell can be positioned behind GTG (notably via the measurement path) or used in parallel depending on the target architecture.