Google Tag Gateway via Cloudflare — a detailed guide

In short: what this guide gives you

• Who it’s for: online stores that already have their domain on Cloudflare.
• Time needed: 10–15 minutes, without involving a developer.
• Result: +11–25% of recovered conversions in Google Ads and GA4, free of charge.

1. What Google Tag Gateway is and why you need it

Google Tag Gateway (GTG) is a free service from Google in partnership with Cloudflare, launched in May 2025. It works as a “pass-through proxy” that makes sure the Google Analytics 4 and Google Ads scripts are delivered through your own domain instead of googletagmanager.com or google-analytics.com.

Why this matters

Today roughly 15–30% of e-commerce visitors have an ad blocker installed (uBlock Origin, AdBlock Plus, Brave Shields) that blocks scripts from Google domains. On top of that, Safari on iOS devices limits third-party cookies to 7 days.

Result: a loss of 15–40% of conversions in both Google Ads and GA4 → ad algorithms optimise on incomplete data → higher CPA and lower ROAS.

✅ What GTG solves

• Bypasses ad blockers — scripts come from your domain, not from a Google domain
• Provides the “first-party” context for Safari → the script is no longer a third party
• Average increase in reported conversions: +11% (official Google data, median for April 2025)
• Range measured by agencies: 9–18%
• Recovers 70–85% of the tracking loss caused by ad blockers

⚠️ What GTG does not solve

• Facebook/Meta Pixel, TikTok Events API, Pinterest — GTG works only with the Google ecosystem
• Data transformation and enrichment (only a full server-side GTM can do that)
• Problems on the iOS ATT side (loss of Meta Pixel data on mobile)
• Safari ITP truncating JavaScript cookies to 7 days (cookies are still created by gtag.js in the browser)

2. Prerequisites — which scenario is yours?

Before activating GTG, check which scenario you are facing:

Scenario A — the domain is already on Cloudflare

If in dash.cloudflare.com you see your domain with the status Active — you’re in luck. Go straight to section 4 (activating GTG, 10–15 minutes).

Scenario B — the domain is still with another registrar / DNS provider

That is, the usual state of most online stores: the domain registered through Subreg / Forpsi / GoDaddy / Namecheap, DNS managed at the registrar or at the hosting provider. First go through section 3 (migration to Cloudflare, 30–60 minutes + 1–24 h of waiting), and only then section 4.

Whichever the scenario — in the end you will need:

Requirement	How to check
Domain on Cloudflare with the status Active	Cloudflare dashboard → your domain → status “Active”
A working Google Tag (gtag.js) or GTM on the site	Open the site → Chrome DevTools → Network → filter “gtag” → do you see the requests?
SSL/HTTPS active	The site opens over https://
Administrator access to the Cloudflare account	Log in → you see the “Rules” section
Administrator access to Google Ads and GA4	To verify the results
Consent Mode v2 correctly set up through a CMP	Cookiebot/Usercentrics/OneTrust — if in doubt, contact us

If any of these conditions is not met, let us know — we’ll solve it before switching GTG on.

---

3. Migrating the domain to Cloudflare (scenario B only)

If your domain is already on Cloudflare, skip this section and continue with section 4.

Migration is a process with its own pitfalls — different registrars name things differently, some steps require an email confirmation, DNS propagation takes hours. This section sums up the universal pattern and the 5 most common traps we’ve run into with our clients.

What you will need

• Access to the domain registrar’s admin panel (where you bought the domain)
• Access to the domain owner’s e-mail (the registry usually sends a confirmation e-mail)
• Roughly 30–60 minutes of active work + 1–24 hours of passive waiting for DNS propagation
• Calm — if you do the 5 pre-flight checks from point 3.3, neither the site nor the e-mail will go down

3.1. Create a zone in Cloudflare (3 minutes)

1. Sign up at cloudflare.com — the Free plan is enough for most online stores
2. Add a Site → enter your domain (without www) → choose Free plan
3. Cloudflare runs a Quick Scan — it automatically imports the DNS records from the current zone

3.2. Check the imported DNS records (5 minutes)

Quick Scan usually catches 90–95% of the records, but not 100%. Go through the list and make sure everything you have in the current zone is there:

• A / AAAA on the apex (the domain itself, IPv4 / IPv6)
• CNAME www (or A www) — otherwise www.vasedomena.cz will not work
• MX records — without them mail will not be delivered
• TXT: SPF (v=spf1...), DKIM (_domainkey), DMARC (_dmarc) — without them e-mails land in spam
• TXT: google-site-verification, Heureka, Search Console verification, Microsoft, Facebook domain verification — whatever you have there today
• Subdomains: m., shop., admin., api. — all of the ones you actually use

What to delete instead:

• NS records of the ns.vasregisrator.com kind in the imported zone — those are artefacts of the old DNS; after the migration they are unnecessary and confusing

If something is missing — Add record and fill it in manually. Export a copy of the zone from your current DNS provider (BIND export) and compare record by record.

3.3. Pre-flight checks (10 minutes) — the 5 most common traps

These are the checks whose omission took down a client’s site or e-mail. Do all 5 before changing the nameservers:

1. SSL/TLS Mode = Full (strict)

Cloudflare dashboard → SSL/TLS → Overview → choose Full (strict).

NEVER leave it on “Flexible” — it breaks POST forms (login, checkout) and creates redirect loops. If your origin server supports HTTPS (and in 2026 practically every hosting provider does), Full (strict) is the right choice.

2. Turn DNSSEC off in the current DNS

In the registrar’s admin panel find the DNSSEC / DNS Security section → turn it off. If it was on, wait ~1 hour for the DS records in the parent registry to expire — only then change the nameservers.

Quick check in the terminal: dig DS vasedomena.cz +short. Empty output = OK, you can continue. If you see something like 2371 13 2 ABC123... = DNSSEC is still active in the registry, wait.

Why this is so important: if you change the nameservers without turning DNSSEC off, the domain can be unreachable for 1–7 days (resolvers return SERVFAIL) until the DS records in the registry expire. This is the most common way to bring a migration down.

3. Check and transfer the CAA records

In the export of your current zone (BIND export at the registrar) search for CAA. If they exist — add them to Cloudflare DNS manually (Add record → type CAA).

CAA records say which Certificate Authority may issue SSL certificates for your domain. Without them, the automatic Let’s Encrypt renewal on the origin server can break after the migration.

4. Speed Settings — leave the defaults

Cloudflare dashboard → Speed → Optimization. The default settings in 2026 are safe:

• Rocket Loader: OFF (the default on new zones) — don’t enable it blindly, it can break React/Vue applications
• Auto Minify: deprecated, nothing to deal with
• Brotli: auto-on, nothing to deal with
• Polish: requires a paid plan, Disabled by default

Don’t enable Polish / Mirage / Rocket Loader without a test on staging — they can change JS/CSS behaviour in a way that breaks a specific feature of your site.

5. Proxy (orange vs grey cloud) — a decision for every record

Every A/AAAA/CNAME record has the choice of Proxied (🟠 orange) or DNS only (☁️ grey):

• apex (root) + www → 🟠 Proxied (you get CDN, WAF, bot mitigation, GTG — this is why you’re migrating in the first place)
• wildcard *. or specific subdomains (admin, mail, ftp) → ☁️ DNS only — these often have an origin IP whitelist that the proxy would break
• MX records → always DNS only (Cloudflare does not tunnel SMTP)

If you’re not sure — turn 🟠 Proxied on only for apex and www, leave everything else on ☁️ DNS only. After a successful migration, switch the orange cloud on one subdomain at a time and test.

3.4. Changing the nameservers at the registrar (5 minutes + e-mail confirmation)

In the Cloudflare dashboard, under the Overview section, you’ll find the 2 assigned nameservers (they look like xxx.ns.cloudflare.com). Copy these 2 values.

In your registrar’s admin panel:

1. Find the section for nameservers — the naming differs: “Nameservers”, “DNS Settings”, “Change nameservers”, “NSSET” (the .cz registry), “Manage DNS”, “Edit nameservers”
2. Delete / replace all current nameservers
3. Paste the 2 nameservers from Cloudflare
4. Save / Save / Submit

⚠️ E-mail confirmation — a frequent trap

Many registrars (especially .cz through CZ-NIC, but also international ones such as Namecheap, GoDaddy) send a confirmation e-mail to the domain owner’s address listed in WHOIS. Without clicking the confirmation link the change is not applied — the order stays stuck in the “New” / “Pending” state for 7–14 days and then expires.

If you don’t have access to the owner’s e-mail — arrange with the client to forward it to you, or to click the link themselves.

3.5. Wait for the Active status (5 minutes — 24 hours)

DNS propagation is not deterministic. It usually happens within 5–30 minutes, exceptionally it drags on for up to 24–48 h (it depends on the TTL of the previous nameservers and the behaviour of specific resolvers).

Quick check in the terminal:

dig NS vasedomena.cz +short

If the output contains your Cloudflare NS (e.g. diva.ns.cloudflare.com), propagation has completed on your side.

In the Cloudflare dashboard:

• Click “I updated my nameservers” — Cloudflare will run its own check
• When Cloudflare detects the change, an e-mail arrives: “Your site is now active on Cloudflare”
• The status in Overview changes from Pending nameserver update to Active

3.6. Smoke test after Active (10 minutes)

Before you move on to section 4 (switching GTG on), verify that the migration didn’t break anything:

• ✅ The main page responds: https://vasedomena.cz
• ✅ The www version works / redirects correctly: https://www.vasedomena.cz
• ✅ SSL is valid (the browser shows the padlock without warnings)
• ✅ E-mail works — send a test mail from [email protected] to your Gmail, wait 1–2 minutes
• ✅ All critical subdomains respond (admin, m., shop., api., webmail. — whichever you use)
• ✅ For online stores: the feeds to Heureka / Zboží / Glami / Google Merchant Center are being fetched (check in the Heureka admin when the last fetch happened)
• ✅ All forms (login, checkout, contact) go through

What to do when something doesn’t work:

• The most common cause (90% of cases): SSL/TLS mode is on “Flexible” → go back to 3.3 step 1, switch to Full (strict)
• The origin server rejects Cloudflare IPs → add the CF IP ranges to the whitelist at your hosting provider
• A specific subdomain doesn’t work behind the proxy → switch it to ☁️ DNS only (grey cloud) and debug step by step
• As a last resort: temporarily switch apex+www to DNS only — the site will run straight to the origin and you gain time to debug

Once you’ve ticked off all 7 items of the smoke test ✅ — congratulations, you’re on Cloudflare. Continue with section 4.

---

4. Activating Google Tag Gateway (5–10 minutes)

1. Logging in to Cloudflare

Open dash.cloudflare.com, log in and select your online store’s domain from the list of domains.

2. Navigating to Google Tag Gateway

In the left-hand menu find the Rules → Google Tag Gateway section.

Note: In some older accounts the item is located in Apps → Google Tag Gateway. If you don’t see it, try typing “Google Tag Gateway” into the search box at the top.

3. Activation

Click the Enable button (or Activate Google Tag Gateway). Cloudflare shows a list of Google services that can be proxied. Tick:

• ☑ Google Analytics 4
• ☑ Google Ads
• ☑ Google Tag Manager (the client-side part)

Click Save / Activate.

4. Verification in Cloudflare

After activation Cloudflare automatically:

• Creates a Worker on the edge network
• Sets up routing rules for the paths /gtag/js, /gtm.js, /g/collect
• Handles the proxying server-to-server fetch from Google domains

Nothing needs to change in your site’s code — the Google scripts detect GTG mode themselves and start redirecting the requests to your domain.

5. Wait 5–10 minutes

Propagating the settings across the Cloudflare edge network takes a few minutes. During this time it’s normal to occasionally see delayed responses.

---

5. How to verify that GTG works (3 checks)

Check no. 1 — immediate, in Chrome DevTools

1. Open your online store in the Chrome browser
2. Press F12 (or right-click → Inspect)
3. Switch to the Network tab
4. Reload the page (Ctrl + R / Cmd + R)
5. Type into the filter: gtag or collect
6. Check where the requests are coming from:

Before GTG:

Request URL: https://www.googletagmanager.com/gtag/js?id=G-XXXXX
Request URL: https://www.google-analytics.com/g/collect?...

After switching GTG on (the correct state):

Request URL: https://vase-domena.cz/gtm.js?id=G-XXXXX   ✓
Request URL: https://vase-domena.cz/g/collect?...        ✓

If you see your own domain — GTG works ✓

Check no. 2 — real traffic

1. Make a test purchase on the site, or an action that fires a conversion
2. Go to GA4 → Reports → Realtime
3. Check that the event appeared within 1–2 minutes

Check no. 3 — Data Strength in Google Ads (after 7 days)

The most important metric, the one that shows the real benefit of GTG:

1. Google Ads → Tools and Settings → Measurement → Conversions
2. For every conversion watch the Data Strength column

Value	Meaning	Comment
🟢 High	GTG brings more than 15% of recovered data	Excellent result
🟡 Medium	5–15%	Normal
🟠 Low	Less than 5%	Additional tuning is probably needed
⚪ Insufficient	Little traffic	Wait — Google needs more data

For the first 7 days after switching on the metric may not yet show the final value — Google needs to collect reference data.

---

6. What actually happens under the hood — the technical view

This section is for those who want to understand how exactly GTG works at the level of HTTP requests. Useful when you’re explaining the solution to your developer or a technical colleague.

Example no. 1 — Loading the gtag.js script

BEFORE switching GTG on — what happens on every page load. The browser sends:

GET /gtag/js?id=G-XXXXX HTTP/1.1
Host: www.googletagmanager.com
User-Agent: Mozilla/5.0 ...
Referer: https://eshop.cz/produkt/123

What the ad blocker sees: the domain googletagmanager.com is on its blacklist → the request is dropped, the script doesn’t load, tracking doesn’t work.

What Safari sees: a third-party script → it applies ITP restrictions.

AFTER switching GTG on — the same page load. The browser sends:

GET /gtm.js?id=G-XXXXX HTTP/1.1
Host: eshop.cz                    ← vaše doména, ne Google!
User-Agent: Mozilla/5.0 ...
Referer: https://eshop.cz/produkt/123

What the ad blocker sees: the domain eshop.cz — that’s your site, first-party → the request is let through.

What Safari sees: a first-party script → no ITP restrictions.

What happens on the Cloudflare edge (invisible to the browser): the Worker intercepts the request and performs a server-to-server fetch to googletagmanager.com. Google responds with the same script as always. The Worker returns it to the browser. From the browser’s point of view it looks as if the script came straight from your domain.

How it is with cookies — an important clarification

GTG does not change the way cookies are created. The _ga and _gcl_aw cookies are still created by the gtag.js script using JavaScript in the browser (not by the server through the Set-Cookie HTTP header).

Problem	Does GTG solve it?
Ad blockers block the google-analytics.com domain	✅ Yes
Safari applies ITP to third-party scripts	✅ Yes (the script is first-party now)
Safari ITP truncates JavaScript-created cookies to 7 days	❌ No (cookies are still created by JS)
Brave with CNAME uncloaking detects the proxy	⚠️ Partly (depends on the version)
iOS ATT restricts the Facebook Pixel	❌ No (a different problem, a different platform)

To solve Safari ITP completely (cookies with a longer lifetime) you need server-side tagging (sGTM), where the server creates the cookies through HTTP headers and marks them HttpOnly. That’s a separate infrastructure, beyond the scope of GTG.

What happens to your data at Google

From Google’s point of view nothing changes. Google receives exactly the same data as before — the same payload, the same cookies, the same identifiers. The only difference is that the data travels through the Cloudflare edge instead of straight from the browser.

GTG is not a solution for protecting your privacy from Google — Google still has full access to all the data it would have without GTG. GTG only makes sure the data arrives at all.

---

7. Summary: what GTG physically changes

At the level of	Without GTG	With GTG
Script URL in the HTML	googletagmanager.com/gtag/js	eshop.cz/gtm.js
Conversion ping URL	google-analytics.com/g/collect	eshop.cz/g/collect
Cookie domain (_ga)	.eshop.cz (already today)	.eshop.cz (unchanged)
Lifetime of the _ga cookie	7 days in Safari	7 days in Safari (not changed by GTG)
Visibility to ad blockers	blocked	let through
Loading speed	from the Google CDN	from the Cloudflare edge (often faster)
Data Google receives	the same	the same

---

8. After switching GTG on (recommended follow-up measures)

a) Enhanced Conversions (very important)

If you haven’t switched it on yet, do it in Google Ads:

1. Google Ads → Tools → Conversions → select your conversion
2. Enhanced Conversions for the web → Turn on
3. Method: Google tag (takes the data from the forms automatically)
4. Domain: keep the default setting

Effect: an improvement in conversion matching of another 10–40% (official Google data).

b) Checking Consent Mode v2

Make sure your CMP (Cookiebot / Usercentrics / OneTrust) correctly sends all 4 signals:

• ad_storage
• analytics_storage
• ad_user_data
• ad_personalization

Without them Google Ads and GA4 in the EU stop collecting data about new visitors — mandatory since March 2024.

c) Regular testing

Once a month check:

• Data Strength in Google Ads
• The volume of events in GA4 (has it dropped?)
• The Realtime report in GA4 (are events coming in?)

---

9. Possible problems and their solutions

Problem	Cause	Solution
After switching on, the site doesn’t load correctly	Cloudflare SSL mode is on “Flexible”	Cloudflare → SSL/TLS → switch to Full (strict)
Data Strength stays “Low”	Consent Mode v2 is not set up correctly	Check the CMP, contact us
In DevTools I still see googletagmanager.com	Browser cache	Ctrl+Shift+R (hard refresh) or open in an incognito window
The GTM web container stopped working	A conflict with a custom domain of your own in GTM	GTM → Admin → Container Settings → remove the custom domain mapping
Conversions look doubled	The old measurement is running alongside GTG	Usually not — GTG doesn’t add events, it only proxies them. Check other sources of duplicates
Part of the data is missing in the first hours after switching on	The edge network cache is propagating	Wait 15–30 minutes, if needed Cloudflare → Caching → Purge Everything
GTG is active but in the HTML I still see googletagmanager.com	The CMS has a closed templating system — it doesn’t allow inserting your own HTML code into <head>, and the GTM snippet is generated with a hard-coded URL	Deploy a Cloudflare Worker for HTML rewriting at the edge — see the solution below

Specific problems from the migration phase (section 3)

Problem	Cause	Solution
The domain is unreachable for 1–7 days after the nameserver change	DNSSEC was not turned off before the NS change — the DS records in the parent registry still exist, resolvers return SERVFAIL	Turn DNSSEC off at the registrar and wait for the DS records to expire (it can take up to 7 days). Next time: check 3.3 step 2 before the NS change
The status in Cloudflare stays “Pending nameserver update” even after an hour	The NS change at the registrar is waiting for an e-mail confirmation from the owner	Find the e-mail from the registry / registrar with the confirmation link. If you don’t have access — arrange a forward with the client
E-mails stopped arriving	The MX records were not imported in the Quick Scan, or were set to Proxied	Cloudflare → DNS → verify that the MX records are ☁️ DNS only (not Proxied) and point to the correct mail server. Add the missing ones
After the migration the SSL certificate renewal on the origin server broke	The CAA records from the original zone were not imported	In Cloudflare → DNS add the CAA records manually according to the export of the original zone (typically 0 issue "letsencrypt.org")
A specific subdomain (admin, FTP) stopped working behind the proxy	The origin server has an IP whitelist and the Cloudflare proxy changes the source IP	Switch the problematic subdomain to ☁️ DNS only, or add the CF IP ranges to the whitelist
The Heureka / Google Merchant feed stopped reading the data	The crawlers don’t get a response behind the Cloudflare proxy (rate limit, bot challenge)	Cloudflare → Security → Bots → create an allow rule for known crawlers, or temporarily switch the subdomain with the feed to ☁️ DNS only

When the CMS doesn’t allow custom HTML code (a solution via a Cloudflare Worker)

Time required for the whole solution: realistically 3–4 hours — budget for it honestly. It includes: an audit of the CMS (whether it has any option to insert custom HTML at all, or whether it really is impossible) → research of alternatives → writing and deploying the Worker → configuring the route with Fail-open mode → verification in Chrome DevTools → verification in GA4 Realtime → a check that nothing broke. The individual steps are quick (a click in the UI), but the full run including diagnostics, debugging and verification is markedly longer than “a couple of minutes for a Worker”.

The problem: Some closed e-commerce platforms (e.g. Binargon, some versions of BigCommerce and older Joomla templates) don’t generate the HTML through an editable field — the GTM snippet is hard-coded in the template with the URL https://www.googletagmanager.com/gtm.js?id=.... It cannot be changed through the admin interface.

Cloudflare Google Tag Gateway does proxy the requests to /měření-cesta, but it doesn’t rewrite the HTML itself — if the GTM snippet in the page is hard-coded to googletagmanager.com, the browser downloads it from the third party and the whole point of GTG is gone.

The solution: a Cloudflare Worker (~25 lines of code) that sits between the visitor and the origin, reads the HTML response and replaces the URL with a first-party path. The Worker runs at the edge of the network, adds ~10 ms of latency, and is free up to 100,000 requests a day.

When you need it

• You activated GTG (section 4) and in the verification (section 5) you still see googletagmanager.com in the HTML
• Your CMS has no “Custom HTML code in the header” / “Custom <head> insert” field in the admin
• The CMS provider refuses, or takes a long time to consider, adding such a feature

The Worker code

This example uses the domain vase-domena.cz and the measurement path /pulse. For your own deployment replace vase-domena.cz/pulse with your domain and the measurement path configured in GTG.

export default {
  async fetch(request, env, ctx) {
    try {
      const response = await fetch(request);
      const contentType = response.headers.get('content-type') || '';

      // Skip non-HTML — proxy as-is
      if (!contentType.includes('text/html')) {
        return response;
      }

      const original = await response.text();
      const modified = original.replace(
        /(?:https?:)?\/\/www\.googletagmanager\.com\/(gtm\.js|ns\.html)/g,
        'https://vase-domena.cz/pulse/$1'
      );

      const headers = new Headers(response.headers);
      headers.delete('content-length');

      return new Response(modified, {
        status: response.status,
        statusText: response.statusText,
        headers
      });
    } catch (err) {
      // Fail-safe: any error → origin passthrough
      return fetch(request);
    }
  }
};

Deployment through the Cloudflare Dashboard (10 minutes)

1. Cloudflare Dashboard (top-level, not inside the zone) → Workers & Pages → Create application → Create Worker
2. Choose Start with Hello World! → name it (e.g. vase-domena-gtg-rewriter) → Deploy
3. On the Worker’s page → Edit code → delete the default code → paste the code above (don’t forget to adjust the URL) → Save and Deploy
4. Settings → Domains & Routes → + Add → Route: Zone: your domain Route: vase-domena.cz/* Failure mode: Fail open (proceed) — critical! If the Worker fails, the request goes straight to the origin and the site stays functional
5. Optionally: disable the workers.dev URL in Domains & Routes (best practice — the Worker shouldn’t be reachable outside your route)

Verification

# 1. V HTML by měly být přepsané URL
curl -s -L "https://vase-domena.cz/" \
  | grep -oE "(googletagmanager\.com|vase-domena\.cz/měřicí-cesta)[^\"' ]{0,40}" \
  | sort -u
# Očekávaný výsledek:
#   vase-domena.cz/měřicí-cesta/gtm.js?id=
#   vase-domena.cz/měřicí-cesta/ns.html?id=GTM-XXXXXXX

# 2. Web žije
curl -s -o /dev/null -w "HTTP %{http_code} | %{time_total}s\n" "https://vase-domena.cz/"
# Očekávaný výsledek: HTTP 200, čas pod 1.5s

Fail-safe — what happens if the Worker fails

Thanks to Failure mode: Fail open and the try/catch inside the code, the Worker has two independent layers of defence:

1. Inner: catch (err) catches any error in the rewrite logic and returns the origin response unchanged
2. Outer: If the Worker fails so fatally that not even catch runs (e.g. timeout, OOM), Cloudflare bypasses the Worker entirely and sends the request straight to the origin

The consequence: the site never goes down because of the Worker. In the worst case GTG temporarily stops working (the tags load from the third party as before activation) — no user sees an error.

---

10. Real scenarios — what can go wrong

The 7 most common situations from practice. For each: how it shows up, how to find out, what to do about it.

Scenario no. 1: After switching on, the site stopped loading

Symptoms: Users see the error ERR_SSL_VERSION_OR_CIPHER_MISMATCH or “This page is not secure”. In Cloudflare Analytics 5xx errors spike.

Cause: Cloudflare has the SSL mode set to Flexible. GTG requires encrypted communication between Cloudflare and your original server as well.

What to do immediately (within 5 minutes):

1. Cloudflare dashboard → SSL/TLS → Overview
2. Switch from Flexible to Full (strict)
3. Wait 30–60 seconds for propagation
4. Verify the site in an incognito window

Scenario no. 2: Data Strength stays “Low” even after 14 days

Possible causes (in order of likelihood):

1. Consent Mode v2 is not set up correctly — users in the EU did not accept cookies → the data isn’t sent. Diagnosis: GA4 → DebugView → watch the ad_user_data signal. If it is permanently denied, the problem is in the CMP. Solution: review the Cookiebot/Usercentrics configuration.
2. Enhanced Conversions are not active Diagnosis: Google Ads → Conversion → the Enhanced Conversions section. Solution: switch it on (the procedure is in section 8a).
3. A low volume of conversions (fewer than 30/month) Solution: wait until enough data is collected (2–3 months).
4. A conflicting custom domain in GTM Diagnosis: GTM → Admin → Container Settings → Custom Domain. Solution: remove it or synchronise it with the GTG setup.

Scenario no. 3: Duplicated events started appearing in GA4

Cause: Two paths of sending events are running at once: the old client-side tracking (gtag.js through google-analytics.com) + the new one through GTG (eshop.cz/g/collect). In theory this shouldn’t happen, but it can occur when:

• You have several GTM containers on the same page
• You have a manually inserted gtag.js in addition to GTM
• Another tool (say OptinMonster, Hotjar) also sends to GA4

Diagnosis:

1. View source of the page (Ctrl+U) → search for gtag → how many times is it there?
2. GTM Preview mode → how many “GA4 Event” tags fire on a single event?
3. GA4 → Admin → DebugView → open a test session and count the duplicates

Solution: find and remove the duplicates on the page. Keep only one source — either GTM or the direct gtag, not both.

Scenario no. 4: A jump in “New Users” and a change in Bounce Rate in GA4

⚠️ Important: this is NOT an error

GTG started measuring users who previously had tracking blocked (ad blockers, Safari). You always had this data — you just couldn’t see it.

• New users grew → because ad-blocker users were invisible before
• Bounce rate changed → these users have a different behavioural typology (often tech-savvy, faster scanning)
• Conversions grew → their real impact used to be a “ghost”

What to do: set a new baseline. The charts in GA4 will visually “break” on the day GTG is switched on — it’s good to mark it with a note in Annotations so everyone on the team knows what happened.

Scenario no. 5: The Brave browser still blocks tracking

Cause: Brave has a CNAME uncloaking feature — it checks where the domain actually points. If it detects that eshop.cz/gtm.js ends up at a tracking service, it can block the request.

Options:

1. Accept it — Brave has ~1% of the market, negligible for most online stores
2. Server-side tagging (sGTM) — this is a deeper proxy that Brave detects less well
3. A combination of GTG + sGTM + same-origin deployment through a CF Worker

A realistic expectation: After switching GTG on you’ll have ~99% of Chrome users covered, ~90% of Safari, ~95% of Firefox, but only ~50–70% of Brave.

Scenario no. 6: GTM Preview mode stopped working

Cause: GTG can filter out the special debug cookies and headers (X-Gtm-Server-Preview) that GTM Preview uses.

Solution:

1. Cloudflare → Rules → create a bypass rule for your IP address (for the duration of the debugging)
2. Alternatively: debug in an incognito window with a manually set debug cookie
3. After the debugging is finished, delete the bypass rule

Scenario no. 7: “You promised +11%, but I don’t see it”

The real context:

• +11% is the median across all accounts (official Google data, April 2025)
• The range in practice: +3% to +25%
• The specific result depends on: The structure of the audience — a client with 80% Chrome without blockers will see +3%, a client with 30% Safari and a large share of ad-blocker users will see +20% The existing quality of Consent Mode — if it was set up badly, the benefit of GTG will be masked by the fix of a different problem The volume of conversions — for a site with 10 conversions a month, +11% is statistically unreadable (you need 100+ conversions for a reliable measurement)

How to communicate it properly:

1. Treat the Data Strength metric in Google Ads as the main indicator, not the absolute number of conversions
2. A 30-day window at minimum, not 7 days
3. Show the volume of events in GA4 (not only conversions) — the difference is more visible there
4. Compare week-over-week, not day by day (seasonality distorts it)

---

11. What exactly you’ll see in the data

In Google Ads

When	What you’ll see
Immediately (day 1)	In Conversions → Diagnostics the “Tag blocked” warning disappears. In DevTools, the correct domain on the requests.
After 7 days	The Data Strength column with a value. All Conversions typically grows by 5–20%.
After 14–30 days	CPA may fall by 5–15%. ROAS may grow by 10–25%. Smart Bidding adjusts.

In GA4

When	What you’ll see
Immediately	The Realtime report shows events from all browsers. DebugView shows the gcs and gcd parameters.
Week 1–2	Event count grows by 10–30%. Total Users grows by 10–30%. Bounce Rate may change (a visual break — normal).
Month 1–3	Attribution models are more accurate. Audiences grow (a larger pool for remarketing).

What will NOT CHANGE (where GTG doesn’t help)

Tool	Why it won’t change
Facebook Ads Manager	GTG does not include the Facebook Pixel
TikTok Ads	A different ecosystem
Snapchat, Pinterest, LinkedIn	Outside the scope of GTG
Klaviyo, Mailchimp, ActiveCampaign	Their own tracking integrations
Hotjar, Smartlook, Clarity	Their own scripts
CRM (HubSpot, Pipedrive)	Usually not connected to GTG

An example of a specific online store (anonymised)

Client: a mid-sized online store in the Czech Republic, monthly Google Ads budget ≈ 80,000 CZK.

Period	Google Ads conversions	CPA	GA4 users	Data Strength
Before GTG (August 2025)	245/month	327 CZK	38,400	—
After switching on (September 2025)	281 (+14.7%)	285 CZK (−12.8%)	47,200 (+22.9%)	Medium
After 3 months (November 2025)	312 (+27.3%)	256 CZK (−21.7%)	—	High

This case is above the median (+11%) — the client originally had a weak Consent Mode and a large share of Safari audience. For other clients with tracking that is already set up well, the improvement can be substantially smaller (+3–7%).

The expectation timeline

When	What you’ll see
Minute 1	DevTools shows the correct domain
Hour 1	Realtime in GA4 displays data
Day 1	The volume of events starts to grow
Day 7	The Data Strength metric appears
Week 2	A solid Data Strength value
Month 1	A drop in CPA thanks to better optimisation
Month 2–3	The full impact on campaigns

---

12. Frequently asked questions

Can I switch GTG off at any time? Yes, the same way as switching it on — one click in Cloudflare. The change is immediate.

Will GTG affect the speed of the site? Positively. The Google scripts load from the Cloudflare edge network, which has 300+ locations around the world — typically faster than the original Google CDN. Measurements show an LCP improvement of 3–10%.

Can I use GTG with Google Tag Manager (GTM)? Yes, they are fully compatible. GTG proxies the GTM script itself as well.

Does it work for the Facebook Pixel, TikTok, Pinterest? No. GTG works exclusively with Google services. For Meta/TikTok you need server-side tagging (sGTM) — a separate project.

Will it increase the price of Cloudflare? No. GTG is included even in the Cloudflare Free plan. It is not counted towards the Workers requests limit.

Is it GDPR-compliant? In itself GTG doesn’t change the legal situation — the data still ends up at Google. Consent Mode v2 and your CMP have to be set up correctly (that’s a condition without GTG too). GTG itself doesn’t bypass consent.

How long to wait for visible results? In Chrome DevTools you see the result immediately. Data Strength in Google Ads appears after 7 days. The full impact on campaigns after 14–30 days (the algorithms adapt to cleaner data).

What if my site is on Shopify? Shopify manages its own Cloudflare — you have no access to its settings. For Shopify we recommend an alternative: Enhanced Conversions + a Shopify app for server-side tracking (Elevar, Conversios). Contact us — we’ll prepare a plan.

---

13. What we need from you (checklist)

If you want us to set GTG up

• Access to the Cloudflare dashboard (or add us as an admin)
• Confirmation that you want the proxy for: GA4, Google Ads, GTM
• A contact for a technician on the client side for any DNS/SSL questions
• Confirmation that you have Consent Mode v2 set up (if not — we’ll solve it)

✅ If you’re going to do it yourself

• Go through section 2 (find out your scenario) and section 3 (scenario B only — migration to CF)
• Activate GTG following section 4
• Run the verification following section 5
• After 7 days check Data Strength in Google Ads
• Let us know the results — we’ll help interpret them

---

14. The expected result

7 days after switching on:

• +11–25% of recovered conversions in Google Ads
• Data Strength: Medium to High
• The volume of events in GA4 has grown

After 30 days:

• Better optimisation of the ad algorithms (on more complete data)
• A drop in CPA of 5–15% in Google Ads (thanks to more accurate attribution)
• More accurate reports for decision-making

If you don’t see these results — contact us, we’ll check that the setup is correct. The usual causes: a badly configured Consent Mode, missing Enhanced Conversions, a conflict with an existing custom domain in GTM.

---

15. The next step after GTG

GTG is the first floor of a more advanced tracking infrastructure. If you have a significant budget for Meta Ads / TikTok / Pinterest (from ~250,000 CZK a month), we recommend the following as the next step:

Server-side tagging (sGTM) — a separate server that serves the Meta Conversions API, the TikTok Events API and other platforms. It solves similar problems, but for the whole advertising range. Price: 500–5,000 CZK/month + setup.

We handle this as a separate project — let us know if it makes sense to discuss it.

---

✅ The complete checklist from start to finish

Phase 1 — Migrating the domain to Cloudflare (scenario B only, section 3):

• Cloudflare account created, domain added (Add a Site)
• Quick Scan completed, DNS records checked (A/AAAA/CNAME/MX/TXT) — everything imported
• Artefacts of the old NS records (of the ns.registrátor.com kind) deleted from the zone
• SSL/TLS mode: Full (strict)
• DNSSEC turned off in the current DNS (dig DS returns empty)
• CAA records checked and transferred (if they existed)
• Speed settings on the defaults (Rocket Loader OFF, Polish disabled)
• Proxy status decided: 🟠 apex+www, ☁️ DNS only for sensitive subdomains
• Nameservers changed at the registrar to the 2 CF nameservers
• E-mail confirmation from the registry confirmed (by clicking the link)
• Status in the CF Overview = Active
• Smoke test passed: site, www, e-mail, subdomains, SSL, forms

Phase 2 — Activating GTG (both scenarios, sections 4–5):

• In Cloudflare → Rules → Google Tag Gateway = ON
• Ticked: GA4, Google Ads, GTM
• In DevTools I see my own domain on the requests (not googletagmanager.com)
• Events appear in GA4 Realtime

Phase 3 — Supplementary measures (section 8):

• Consent Mode v2 set up through a CMP (Cookiebot/Usercentrics/OneTrust)
• Enhanced Conversions switched on in Google Ads
• An Annotation marked in GA4 on the day of switching on (for team context)
• After 7 days — check Data Strength in Google Ads
• After 30 days — evaluate the change in CPA / ROAS

Don’t hesitate to get in touch with any questions about the setup. [email protected]