> For the complete documentation index, see [llms.txt](https://docs.jentis.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.jentis.com/key-features/google-tag-gateway.md).

# Google Tag Gateway

One of the key features of JENTIS is the Google Tag Gateway (GTG) out-of-the-box solution. Unlike traditional setups that require setting up a CDN and routing Google GTAG traffic via a predefined measurement path, JENTIS leverages your existing A-Record to pass data in a first-party context through a proxy within the JENTIS infrastructure.

This guide outlines how Google Tag Gateway works, supported connectors, implementation options, and best practices.

### What is Google Tag Gateway?

By default, `gtag.js` loads directly from `googletagmanager.com`, sending every hit straight to Google's servers from the visitor's browser.

Google Tag Gateway reroutes both the script loading and data transport through a first-party domain that you control:

* Script delivery: The tracking script is served from your first-party domain.
* Data transport: The `transport_url` passed into `gtag('config', ...)` points directly to your domain proxy.
* Google endpoint: Google's processing endpoint sits safely behind your first-party domain rather than receiving direct browser calls.

Because requests look and behave like native first-party calls, they bypass common tracking-prevention mechanisms and third-party ad-blocking rules.

<figure><img src="https://2315305008-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy15ncufYr341K5U8q6Of%2Fuploads%2FbnlWhNlWWdQ1xrMSHtm9%2Fimage.png?alt=media&amp;token=6eab86d4-8b83-4281-86b8-e60b44946390" alt=""><figcaption></figcaption></figure>

### JENTIS Server-Side Tracking vs. GTG

{% hint style="info" %}
**Key Takeaway**: Use JENTIS Server-Side Tracking for primary conversion tracking and business-critical data. Add GTG as a complementary proxy layer for client-side Google signals that cannot be moved server-side.
{% endhint %}

| Feature                | JENTIS Server-Side Tracking               | Google Tag Gateway (GTG)                           |
| ---------------------- | ----------------------------------------- | -------------------------------------------------- |
| **Primary Role**       | Main server-side measurement solution     | Complementary proxy for remaining client-side tags |
| **Performance Impact** | Substantial data uplift (20–40%)          | Minor uplift for client-side tags                  |
| **Logic Location**     | Processed entirely on the server          | Proxied on the client-side                         |
| **Use Cases**          | Core analytics, conversions, data control | Google Ads remarketing, client-side tags           |

### Supported Connectors

Google Tag Gateway is available in the JENTIS Tag Manager for the following connectors:

* Google Analytics 4
* Google Ads
* Floodlight

### Configuration Options

Connectors supporting Tag Gateway expose two main setup options. Resolution follows a strict priority order:

1. JENTIS-Managed Gateway (if enabled)
2. Custom Gateway URL (if configured)
3. Google Fallback (default fallback if neither option is enabled)

<figure><img src="https://2315305008-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy15ncufYr341K5U8q6Of%2Fuploads%2Fc34nHypBSwMy8qly55JE%2Fimage.png?alt=media&amp;token=2d666210-419f-4785-be69-3f40cfdbb34f" alt=""><figcaption></figcaption></figure>

#### Option 1: Bring Your Own Gateway (Custom Setup)

Use a custom gateway URL if your organization requires its own first-party proxy domain managed via external infrastructure (e.g., Cloudflare, Akamai, or custom reverse proxies).

{% hint style="info" %}
Custom gateways require DNS and proxy configuration maintained outside of JENTIS.
{% endhint %}

**Setup Steps:**

1. Create and configure the gateway endpoint in your chosen proxy/CDN infrastructure.
2. Set up necessary DNS records and HTTPS routing for your custom first-party URL.
3. Open the relevant connector tag (GA4, Google Ads, or Floodlight) in the JENTIS Tag Manager.
4. Expand the Google Tag Gateway tab.
5. Enter your complete custom gateway URL (including `https://`).
6. Save, preview, and validate the changes in container preview mode.
7. Publish your container changes.

#### Option 2: JENTIS One-Click Gateway

For teams looking for an automated setup without managing external proxy infrastructure or CNAME records.

**Setup Steps:**

1. Open the relevant connector tag in the JENTIS Tag Manager.
2. Expand the Google Tag Gateway tab.
3. Toggle on Enable JENTIS Google Tag Gateway.
4. JENTIS automatically generates the gateway URL using your existing JENTIS tracking domain.
5. Save, preview, and publish your container.

**Generated URL Structure:**

```
https://<hash>.yourdomain.com/g/<configURL>
```

{% hint style="warning" %}
Using Option 2 may occasionally generate minor console warnings or non-200 entries in the browser Network tab if `gtag` attempts to fetch secondary resources from an unexpected endpoint. You can safely ignore these as long as tracking fires normally.
{% endhint %}

### Best Practices

#### 1. Prevent Duplicate Conversions

If you run both a client-side tag via GTG and a JENTIS Server-Side connector for the same event:

* Pass the same `transaction_id` parameter in both event payloads.
* Google uses this shared identifier to automatically deduplicate conversions across client and server streams.

#### 2. Strategic Implementation

* Do not treat GTG as a replacement for server-side tracking—it is designed to enhance remaining client-side tags.
* Deploy JENTIS Server-Side tracking for reliable core measurement, using GTG specifically for tags (like Google Ads remarketing) that rely on client-side browser context.

### Why is My Data Still Sent to Google Directly?

Even when Google Tag Gateway (GTG) is enabled, you may notice network requests still heading directly to Google-owned domains (such as `doubleclick.net` or `google.com`).

This occurs because Google relies on 3rd-party cookies for cross-site identification and attribution. These cookies can only be accessed or set by sending requests directly to Google's primary endpoints.

While JENTIS cannot provide an exhaustive breakdown for every custom implementation, the native behavior for primary Google tags breaks down as follows (this is a current snapshot and might be changed by Google any time with no upfront information):

#### Endpoint Behavior by Google Product

| Google Product         | First-Party Route (via GTG)  | Third-Party Route (Direct to Google)                | Reason for Third-Party Direct Route                                                                       |
| ---------------------- | ---------------------------- | --------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
| **Google Analytics 4** | All `collect` streams        | Audience streams                                    | Audience building relies on 3rd-party cookies to sync user data across other Google advertising products. |
| **Google Ads**         | Standard conversion tracking | View-through conversions (`viewthroughconversions`) | View-through attribution depends entirely on 3rd-party cookies across external domains.                   |
| **Google Floodlight**  | Standard conversion tracking | View-through conversions (`viewthroughconversions`) | View-based conversion tracking requires 3rd-party cookie access for cross-site attribution.               |

{% hint style="info" %}
Exceptions apply. Google determines whether an individual data stream uses a first- or third-party route. This can depend on factors such as geographic location. Google Tag Gateway is a configuration setting, not a hard-coded implementation. Google may not use the configured route for every request.
{% endhint %}

### Frequently Asked Questions (FAQ)

<details>

<summary>Does Google Tag Gateway replace JENTIS Server-Side tracking?</summary>

No. GTG acts as a complementary layer. Primary conversion tracking and core analytics should always run through JENTIS Server-Side tracking to maximize data quality and uplift.

</details>

<details>

<summary>Do I need to configure new DNS records?</summary>

Only if you select Option 1 (Custom Gateway). In that case, DNS and routing must be set up via your Webserver or CDN provider (e.g., Cloudflare). Option 2 (One-Click) reuses your existing JENTIS tracking domain and requires no extra DNS steps.

</details>

<details>

<summary>Is Google Tag Gateway even relevant for our setup if we already replaced our old Google Tag Manager with JENTIS?</summary>

Yes, but only if you still run client-side Google tags inside JENTIS.

Replacing GTM with JENTIS means your *primary* tracking (analytics, key conversion events) runs server-side through JENTIS. However, certain Google features—most notably Google Ads Remarketing, Floodlight signals, or specific GA4 client features—still rely on client-side execution in the browser.

If you have enabled any client-side Google tags inside your JENTIS Tag Manager:

* Without GTG, those tags load directly from `googletagmanager.com` and send hits directly to Google. Ad-blockers and Safari (ITP) will block or restrict them.
* With GTG enabled, JENTIS proxies those specific client-side scripts through your first-party domain, restoring 4–6% lost data for those remaining client tags.

*If 100% of your Google measurement is sent purely server-to-server via JENTIS connectors, GTG is NOT needed.*

</details>

<details>

<summary>Since our company is not currently using a CDN, GTG is not a priority for us at the moment.“ — Is this true?</summary>

False. This is a misconception about how JENTIS delivers GTG.

While Google's standard documentation for GTG heavily emphasizes CDN setup (like Cloudflare, Akamai, or Fastly), JENTIS provides Option 2 ("JENTIS One-Click Gateway").

* With JENTIS Option 2, JENTIS hosts and handles the GTG proxy automatically using your existing JENTIS tracking domain (`tracking.yourdomain.com`).
* No external CDN, no custom load balancer, and no extra CNAME records are required.
* Therefore, not having a CDN is not a reason to skip GTG if you have client-side Google signals.

</details>

<details>

<summary>What is the real data uplift of GTG?</summary>

* JENTIS Server-Side Tracking Uplift: 20% to 40%. This recovers core conversions, bypasses ad-blockers, extends cookie life to 1–2 years via HTTP headers, and handles primary analytics.
* Google Tag Gateway (GTG) Uplift: \~4% to 8% incremental uplift *on remaining client-side Google tags only*.
* Why the difference? GTG only changes the *domain* from which `gtag.js` loads (making it look first-party). It does not convert the code into true server-side processing, nor does it override Safari ITP caps for client-set JavaScript cookies.

{% hint style="info" %}
Server-Side JENTIS is our heavy engine that recovers 20–40% of overall lost data. GTG is a 2-minute setting that gives us an extra 5% recovery specifically for our Google Ads remarketing audiences.
{% endhint %}

</details>

<details>

<summary>What is the implication if we already run server-side tags through the Cookie Lifetime Extender (CLE)? Does that impact client-side connectors like Floodlight?</summary>

Understanding the distinction:

* JENTIS Cookie Lifetime Extender (CLE): Works at the network/proxy level by setting or renewing first-party cookies via HTTP Response Headers directly from your main application or web server infrastructure. This protects critical tracking cookies (like `_ga` or `_gcl_au`) against Apple Safari ITP and Firefox ETP 7-day reductions.
* Google Tag Gateway (GTG): Solves a completely different problem—it changes the URL host path where client-side JavaScript files (`gtag.js`) are loaded from and where browser `gtag('config')` calls transmit their payloads.

Implications for Client-Side Connectors (e.g., Floodlight, Google Ads Remarketing):

1. CLE alone does not stop script blocking: While CLE preserves cookie longevity for users who successfully execute scripts, it cannot prevent ad-blockers or privacy extensions from blocking browser requests aimed at `https://googletagmanager.com/gtag/js)`. If the script download is blocked, your client-side Floodlight or remarketing tags never fire.
2. They address two different parts of the pipeline:

* CLE ensures that once a tag fires, the assigned user identifier and click IDs persist long-term in the browser.
* GTG ensures that the browser can successfully download the script and route hits without ad-blockers killing the network request.

Conclusion: Running the JENTIS Cookie Lifetime Extender (CLE) gives you maximum cookie durability, but you should still toggle on GTG for client-side Floodlight and Google tags to prevent the script downloads themselves from being blocked by hostname filters.

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.jentis.com/key-features/google-tag-gateway.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.