Blog
Why SignalHost: what tags in the browser lose, and what your own tagging server wins back
Published · 6 min read
Every number in GA4, Google Ads and Meta starts as a request from a visitor's browser to an address that belongs to Google or Meta. A growing share of browsers is built to stop exactly those requests, and nothing tells you when it happens: the report simply shows less. SignalHost moves that traffic onto your own domain and a tagging server of your own, built and run for you. This is the case for it, in the order the problems reach you — and, at the end, the honest list of what it does not do and who does not need it.
What your reports never show you
With tags in the browser, every measurement is a request to someone else's domain: the Tag Manager script from googletagmanager.com, each GA4 hit to google-analytics.com, each Meta event to facebook.com. Ad blockers, privacy extensions, browsers with tracker blocking built in, and DNS filters on office and home networks recognise those hostnames and paths and drop the request. The page loads normally. The visit simply never arrives.
You cannot see this loss in GA4, because GA4 only shows what arrived. How large it is depends on your audience — far larger for a technical, young or privacy-minded crowd than for a general one — and it lands on every report at once: fewer users, fewer sessions, fewer conversions, and campaigns that look worse than they are.
Blocking is one of four reasons GA4 shows fewer conversions than your shop: why GA4 undercounts, and which parts can be won back.
Where it costs most: conversions and the ad platforms
A lost page view is an annoyance. A lost conversion costs you twice. Google Ads, Meta and TikTok decide where your budget goes by learning from the conversions they receive, so every purchase a blocker swallows is one the bidding never learns from, and every campaign reports a worse return than it earned.
The second loss is the ad click itself. A conversion only counts for a campaign when it can be tied to the click that led to it, and that tie is a click ID — gclid for Google, fbclid for Meta, ttclid for TikTok — which sits in the landing page's address and is gone from it with the visitor's next click. Something has to keep it until the purchase, and that something is a cookie. Set from another site's address, Safari refuses it outright, and the purchase three pages later arrives with no click attached.
What SignalHost changes
- Your tags load and report from your own domain. With metrics.yoursite.com as your tagging address, every request goes to your own site as far as the browser is concerned, and no list aimed at Google's hostnames matches it.
- Nothing is left to recognise. Filter lists also look for gtm.js, /g/collect and measurement IDs on any domain. SignalHost encodes every request into one opaque path, differently for every customer, so the file name, the event name, your measurement ID and the page address are no longer in clear.
- Conversions reach the ad platforms from your server. Google Ads, Meta, TikTok, Reddit, Pinterest, Snapchat and LinkedIn receive your events through their own server interfaces — Meta's Conversions API, TikTok's Events API and the rest — instead of a pixel in the browser. Keep a pixel as well if you like: send the same event_id to both and each platform counts the event once.
- The click survives until the purchase. Your server container keeps the click ID in a cookie on your own domain — FPGCLAW for Google Ads, _fbc for Meta — so a purchase pages or days later still reaches the platform with the click it came from.
- One event, every destination. The events your site already sends to GA4 also feed every platform you connect, translated into each platform's own names, so you set an event up once instead of once per platform.
What you would otherwise build and run yourself
None of this is new technology. Server-side Google Tag Manager is Google's own, and you can host it yourself. Doing so means a Google Cloud project with billing, a tagging server kept running in production and a second one for Preview, your own domain mapped to it with a certificate, a server image to keep current, and a bill that grows with your traffic. Then the containers: a web container whose Google tag sends to your server, a tag for every event, a server container that receives and forwards them, and for each ad platform a template, credentials and a trigger — every one of which can fail without an error anywhere.
SignalHost does that part. You connect your Google account once — Tag Manager and read-only Analytics, nothing else — and it builds and publishes both containers in your own account: the Google tag pointed at your server, tags for sixteen standard events from sign-ups and leads to every step of a checkout, the server side, and each ad platform you add. It takes about four minutes, and you paste one snippet into your site.
The containers stay yours. They live in your Tag Manager account, under your login: edit them, add your own tags, or leave and keep them. When a tag needs to change — because Google changed something, or because we added an event — your containers are updated without you pressing anything. It runs on European infrastructure, with no Google Cloud project and no per-request cloud bill on your side.
What you can see that you could not before
- Live request and event counts for every container, so "is it working?" has an answer within seconds instead of in tomorrow's report.
- Two numbers per event: everything that arrived, and how much of it came with analytics consent — your consent rate, measured rather than guessed.
- Pages, traffic sources, countries, browsers and devices, counted from the page views your server delivered. Aggregates only: no IP address and no client ID is stored.
- A Troubleshooting card that follows your page views from your site through your server into GA4's own realtime report, and checks the path to each ad platform you connected.
- With Growth, Enterprise or Unlimited, Tag Manager's Preview mode connects to your server container as it would to one you run yourself.
What it does not do
- It does not replace consent. A request to your own domain needs the same consent as one to Google's. Visitors who decline stay declined: Google's tags send only what Consent Mode allows, and Meta, TikTok and the other platforms receive nothing for them.
- It does not make GA4 match your container page. Analytics leaves out the visitors who declined cookies; your server counts every request. The difference is your consent rate, not lost data.
- It cannot keep the ad click without your own domain. On the free signalhost.io hostname your tags are already off Google's domains, but the click cookie still comes from another site and Safari refuses it. Your own domain, on a paid plan, is what makes the click survive.
- It does not bring back a visitor whose browser runs no scripts at all, or one who leaves before the page has loaded.
Who needs it, and who does not
You need it when money depends on the numbers: you run ads on Google, Meta, TikTok or the others and want them to learn from every sale; you sell online and your shop's order count and GA4 disagree; your audience is technical, young or careful about privacy; or you report to a client whose budget follows the dashboard.
You probably do not need it if you run no ads, your site has a few hundred visits a month, and nobody decides anything from the figures. Analytics in the browser is good enough when ten per cent either way changes nothing.
The quickest way to find out which you are is to measure it. The free plan is ten thousand requests a month and never charges anything. Set it up, then compare a week of conversions in GA4 and in your ad platforms with the week before.

