Overview
Detect GA4, GTM, Meta Pixel, TikTok Pixel & Google Ads, free — client-side vs server-side, or connect Servero for live data.
WHAT SERVERO IS, AND WHY THIS EXTENSION EXISTS Servero is a server-side tagging platform: it hosts your Google Tag Manager server container, GA4, Meta Conversions API, and TikTok Events API dispatch behind your own first-party domain, so tracking survives ad blockers, Safari/iOS Intelligent Tracking Prevention, and third-party cookie restrictions that otherwise quietly erase a large share of your conversion data. The pitch, in Servero's own words: recover the conversion data lost to ad blockers, browser restrictions, and missing click IDs, so your advertising and analytics platforms optimize with a complete picture — better match rates, better ROAS, less budget spent optimizing against data that was never actually collected. Pricing is deliberately simple: every plan includes every module — CNAME, SSL, Consent Mode V2, audit log, gateways, and a WordPress plugin — with no add-ons and no surprise bills, priced by traffic volume. Servero positions this as saving $400 to $1,000 a month versus comparable server-side tagging setups elsewhere. Getting started takes a free account, a container deployed under your own subdomain, and a CNAME pointed at it — no infrastructure to run yourself. Who Servero is for: any team running paid ads or first-party analytics that depends on accurate conversion data — ecommerce stores losing purchase events to ad blockers, agencies who need clean attribution to prove ROAS to clients, and any site that has already noticed its ad platforms' reported conversions don't match what actually happened. This extension is the free, no-account half of that story. Before you decide whether you need server-side tagging at all, you should be able to see — on your own site, or anyone else's — exactly what's firing, and whether it's already resilient (server-side) or still fragile (client-side, one ad-blocker update away from silently breaking). That's what Servero Tracking Health Check does, for free, with no account required, on any site. WHAT IT DETECTS A Meta Pixel Helper / GA Debugger equivalent, but for server-side tagging. It detects GA4, GTM, Meta Pixel, TikTok Pixel, and Google Ads on any site and labels every signal client-side or server-side — the one distinction that actually predicts whether that tracking survives real-world browsers, on any vendor's server-side setup, not just Servero's own containers. WHY CLIENT-SIDE VS SERVER-SIDE IS THE SIGNAL THAT MATTERS A GA4 hit sent to www.google-analytics.com is trivially blocked by every ad blocker and increasingly by browser-level tracking protection. The same hit, routed through a first-party subdomain running a server-side tagging container, survives those blocks because the browser sees it as a normal same-site request. Every detection this extension makes is tagged client-side or server-side for exactly this reason. RESULTS YOU CAN EXPECT FROM USING IT Open it on your own site and you'll immediately know whether your GA4/GTM/Meta/TikTok/Google Ads tracking is client-side-only (meaning a meaningful share of it is likely being silently dropped by ad blockers and ITP) or already running server-side (meaning it's resilient). If it's client-side, that's your answer for why ad-platform reported conversions have been running lower than what you know actually happened — and the case for moving to a server-side setup like Servero's. If it's already server-side, this extension confirms it's actually working, shows you the real tag/measurement IDs firing, and lets you inspect the exact payload — client ID, consent diagnostics, click IDs — going out on every hit. TWO TIERS, NO PRESSURE TO SIGN UP "This page" works instantly on any site, no account, no setup. "My container" is for a Servero account holder, adding a live event feed straight from your own container's server-side logs. The free tier isn't a crippled trial — it's a complete, standalone tool that also happens to be the on-ramp to Servero itself. WHAT "THIS PAGE" DETECTS, WITH NO LOGIN Live network classification, as it happens. GA4, GTM, Meta Pixel, TikTok Pixel, and Google Ads requests are classified in real time into a running list, with timestamps and hit-type badges you can filter by. Tag and measurement IDs, front and center. Every detection carries its actual ID — a GTM container ID (GTM-XXXXXXX), a GA4 measurement ID (G-XXXXXXXX), a Google Ads conversion ID (AW-XXXXXXXX), or a Meta Pixel ID — as its own monospace chip next to the vendor name. POST body parameters, not just the URL. Browser performance APIs only expose a request's URL, never its body — and GA4 puts most of a hit's real payload (client ID, engagement time, consent diagnostics, session fields) in the POST body. This extension reads those bodies properly via chrome.webRequest in the background service worker and merges the decoded parameters into each hit's param table — the same class of data a tool like Tag Assistant shows, and structurally impossible to get from a content script alone. Click IDs, from the URL and from cookies. Scans for gclid, fbclid, ttclid, msclkid, epik, fbc, and fbp and shows whichever are present — useful for confirming an ad click actually carried its attribution parameters onto the landing page. Consent state, read from the page's own gtag calls. A content script running in the page's real JavaScript context hooks dataLayer.push and reads the literal arguments passed to gtag('consent', 'default' | 'update', {...}) — Google's documented Consent Mode API — so the values shown are real granted/denied states, not a guess. The one check that genuinely needs a browser extension: HttpOnly cookie verification. Whether your FPID cookie is marked HttpOnly is one of the most reliable signals a server-side tagging setup is configured correctly, and it's structurally invisible to any page or content-script JavaScript by design. This extension checks it properly via the privileged chrome.cookies API in the background worker — no page-level script could ever do this correctly on its own. DATA LAYER TAB — A LIVE window.dataLayer INSPECTOR, NO LOGIN A live, expandable inspector for window.dataLayer, the same public array GTM itself reads from — works identically on a WordPress GTM plugin, a Shopify theme's snippet, or hand-rolled code, with no platform-specific logic needed. Every push is listed in order; click one for its full JSON payload. GTM's own lifecycle events (Container Loaded, DOM Ready, Consent Initialization) and gtag() calls are labeled automatically. Capped at the last 200 pushes per page load. MY CONTAINER TAB — LIVE EVENTS FROM YOUR OWN SERVER-SIDE CONTAINER Needs a free Servero account and an API token, stored only in chrome.storage.local, never sent anywhere but Servero's own API. Once connected, the popup polls your container's live event log every few seconds and renders each event with its full raw payload on click — the same data your dashboard's live-events page shows. Filter by event name or hit type, see possible-duplicate flags, and check click-ID badges against the exact same body/header precedence your dispatcher uses when forwarding to ad platforms, so what you see here matches what CAPI dispatch actually sees. TOOLBAR BADGE A green dot means this tab's traffic matches one of your own signed-in containers. A blue dot means server-side tagging was detected, but not one of yours, or you're signed out — the generic signal that works on any site. No badge means nothing GA4/GTM-shaped was detected. DETECTION RELIABILITY, SAID PLAINLY Every detection reads network requests and cookies the way you would in DevTools, just automated — it can miss obfuscated setups or flag a false positive, which is why every item carries a confidence level. Two things most tag-debugging extensions aren't honest about: Meta and TikTok pixel detections can only ever prove a client-side pixel exists, since their server-side APIs run server-to-server with no browser-visible request; and gcs/gcd consent parameters are always shown raw, never decoded, because Google has never published that encoding. PRIVACY AND PERMISSIONS Nothing leaves your browser unless you explicitly connect a Servero account. Every permission this extension asks for maps to one specific, necessary capability — none are requested speculatively. host_permissions (any site, plus localhost): detection is the extension's entire purpose and has to work on any site, not just Servero customers — that's what makes it useful as a free, no-account tool. localhost is included so it also works during local development. webRequest: reads only the POST body of GA4/GTM collect-endpoint requests, filtered by pathname inside the handler, to show the same hit parameters a tool like Tag Assistant shows. There is no lower-privilege way to see a POST body at all — browser performance APIs structurally can't expose it. cookies: looks up exactly one cookie name, FPID, on the current page's domain, purely to check whether it's marked HttpOnly — never any other cookie, and never its value for any other purpose. Content scripts can't read HttpOnly cookies by design, which is the entire reason this permission exists. storage: saves your connected-account container list locally, so you don't have to re-enter it every time you open the popup. WHO SHOULD USE THIS Marketers auditing a site's tracking setup, developers debugging a server-side tagging migration, agencies validating a client's implementation before billing for results, or anyone who's opened DevTools' Network tab and squinted at a wall of requests trying to find the real GA4 hit. If you've used Meta Pixel Helper or a GA/GTM debugger before, this covers the same ground and adds the one thing none of them show: whether what you're looking at survives ad blockers. GETTING STARTED Click the icon and you land on "This page" immediately — no login. Open any site running GA4 or GTM and it starts classifying hits as they load. Switch to "Data Layer" to watch window.dataLayer live. To see your own server-side container's live feed, switch to "My container," create a free account at servero.io if you don't have one, paste an API token from Settings to API Tokens, pick a container, and start watching. DETECTION CONFIDENCE, ITEM BY ITEM GTM and GA4 requests landing on Google's own domains (googletagmanager.com, google-analytics.com) are high-confidence, direct matches — there's no ambiguity in a request to a domain only Google controls. Meta Pixel and TikTok Pixel matches against their documented request patterns (facebook.com/tr, connect.facebook.net/.../fbevents.js, analytics.tiktok.com) are also high-confidence. Google Ads matches against googleadservices.com or a gtag/js?id=AW- request are high-confidence too. Server-side GTM is deliberately medium-confidence: it's a first-party loader with GTM-style structure, upgraded to "confirmed" only once an HttpOnly FPID cookie is also present — the same heuristic standalone "GTM Server-side Tagging Detector" extensions rely on, a strong signal but not certain proof, and the extension doesn't pretend otherwise. Consent Mode presence, from a gcs parameter on a GA4 hit, is also medium-confidence and always shown as the raw value, never decoded. KNOWN LIMITATIONS, STATED UP FRONT INSTEAD OF DISCOVERED LATER POST body decoding handles form-urlencoded bodies (what GA4 actually sends) and raw text/URL-encoded bodies; a collect endpoint sending a JSON body instead falls back to no extra param enrichment for that one hit beyond the query string — not silently wrong data, just no bonus detail for that specific case. The webRequest listener that reads POST bodies runs broadly, filtered down to collect-path pathnames inside the handler rather than at the match-pattern level, because match patterns can't express "any host, this exact path shape" precisely enough without either false positives or missing first-party subdomains — the per-request check itself is a cheap pathname comparison, not a real performance concern for a debugging tool. In the My Container tab, containers reached only through a custom CNAME domain don't auto-match against the page you're viewing yet, since the container list endpoint doesn't currently return custom domains — manual selection still works fine for those. The consent-state reader only catches calls made through dataLayer.push/gtag(); a site implementing Consent Mode through some other internal mechanism wouldn't be picked up, since this covers the standard, documented path rather than every conceivable custom implementation. WHY THIS WAS BUILT Every existing "tag helper" extension answers "is a pixel installed" and stops there. That question made sense in 2015. It doesn't anymore, because the actual failure mode teams run into today isn't "no pixel installed" — it's "pixel installed, firing, and still losing 30-40% of conversions to ad blockers and Safari's tracking prevention, without anyone noticing until the ad platform's numbers stop matching reality." Servero was built to fix that failure mode with server-side tagging infrastructure. This extension was built because before you can fix that problem, you need a fast, free, honest way to see whether you even have it — on your own site, or a client's, or a competitor's, without creating an account, installing a container, or reading a single line of documentation first. FREQUENTLY ASKED Does this extension send my browsing data anywhere? No, unless you explicitly connect a Servero account in the "My container" tab. Without that, every detection happens locally in your browser and is shown only to you. Does it work on sites that aren't Servero customers? Yes — "This page" detects and classifies GA4/GTM/Meta/TikTok/Google Ads traffic and server-side tagging on any site, run by anyone, using any vendor's server-side setup. The extension doesn't care who operates the server-side container. Do I need a Servero account to use this? No. The entire "This page" and "Data Layer" experience works with zero account, zero setup, on any site. An account is only needed for "My container," which streams your own container's live server-side event log. What does it mean if a site shows only client-side detections? It means that site's tracking hasn't been moved behind a first-party server-side tagging setup, and a meaningful share of its conversion data is likely being silently dropped by ad blockers, Safari ITP, and third-party cookie restrictions — exactly the gap server-side tagging platforms like Servero exist to close. Is the data shown here the same as what I'd see in DevTools? Largely yes, but assembled and labeled automatically — including the one thing DevTools' Network tab doesn't show you on its own: whether a hit's POST body carries the real hit parameters, and whether the underlying cookie is HttpOnly, both of which this extension decodes for you. TRY IT NOW Install it, open any site you care about, and look at the "This page" tab. If everything you see is labeled client-side, that's a concrete, specific answer to "is my tracking actually resilient" — and the starting point for deciding whether to move it behind a server-side setup like Servero's. If you're already running server-side tagging, this is the fastest way to confirm it's actually working as intended, on every page, in real time.
0 out of 5No ratings
Details
- Version0.9.1
- UpdatedSeptember 17, 2026
- Size58.64KiB
- LanguagesEnglish
- DeveloperWebsite
Email
connect.serveroio@gmail.com - Non-traderThis developer has not identified itself as a trader. For consumers in the European Union, please note that consumer rights do not apply to contracts between you and this developer.
Privacy
Servero Tracking Health Check has disclosed the following information regarding the collection and usage of your data. More detailed information can be found in the developer's privacy policy.
Servero Tracking Health Check handles the following:
This developer declares that your data is
- Not being sold to third parties, outside of the approved use cases
- Not being used or transferred for purposes that are unrelated to the item's core functionality
- Not being used or transferred to determine creditworthiness or for lending purposes
Support
For help with questions, suggestions, or problems, visit the developer's support site