Why do server-side conversions matter?

Browser-fired vendor pixels get blocked by ad blockers and capped by tracking-prevention features like Apple ITP, so conversions go uncounted and ad platforms optimize on bad data. The Synter Pixel collects one consent-gated event in the browser and Synter's backend forwards it server-side to your enabled, configured destinations via each destination's conversions API (Meta CAPI, Reddit CAPI, Google offline upload, etc.) using your own connection. That replaces N per-vendor browser pixels with one collection request and a server send, so a blocked vendor pixel no longer silently loses the conversion. The initial collection request is still subject to network blocking and consent.

Which ad platforms does the Synter Pixel send conversions to?

Synter supports Google Ads, Meta, LinkedIn, Reddit, TikTok, Microsoft Ads, Snapchat, Pinterest, X, and OpenAI Ads as destinations. Conversions are only sent to the destinations you've enabled and configured — each is a config-driven adapter, so adding a new one means registering an adapter rather than rewriting the fan-out logic. Leads are also routed to your CRM (Attio) when a CRM connection is present.

Why does GTM sometimes report zero conversions even when the tag is live?

Three common reasons: (1) the Lead trigger doesn't fit the form technology — embedded forms like Fillout, Typeform, and HubSpot don't fire GTM's native gtm.formSubmit; (2) the conversion action was removed in the ad account, so the tag fires into a dead action; or (3) the campaign isn't bidding on conversions at all. The Synter Pixel removes the first two failure modes for server-side conversions by owning a canonical Lead event and verifying each destination.

How does Synter make sure conversion tracking doesn't silently break?

Every attempted server-side send writes an audit row, each destination is verified with a safe, platform-specific probe that stamps verified_at (Google/OpenAI validate-only, Meta/TikTok test events, LinkedIn/Snapchat/Pinterest read-only lookups, X credential check), and a daily coverage monitor alerts whenever an org has a Synter Pixel configured, an active ad-platform connection, enabled destinations, and zero verified destinations. That turns an invisible failure into a paged alert.

Synter Pixel vs. Google Tag Manager: Why Server-Side Conversions Win

Q: Is the Synter Pixel a replacement for Google Tag Manager?

They solve different problems. Google Tag Manager is a container that loads and fires tags you configure in the browser. The Synter Pixel is a conversion system: one script captures a canonical event and Synter forwards it server-side to your enabled, configured ad-platform destinations using your own ad-account connection, plus routes leads to your CRM when one is connected. You can even deploy the Synter Pixel through GTM as a Custom HTML tag — GTM is a fine delivery vehicle, but it does not replace Synter's server-side conversion engine.

Two tools people confuse — and shouldn't

If you run ads, you have almost certainly been told to “just put it in GTM.” Google Tag Manager is great at what it does. But it does not do the thing most advertisers actually need: reliably count conversions and send them back to your enabled ad platforms.

The Synter Pixel does. This post explains the difference in plain terms, shows the architecture, and — because we believe in being honest about our own mistakes — walks through a regression we hit, how we fixed it, and the automated guardrail that now catches it.

The one-sentence difference

Google Tag Manager

A tag dispatcher. It loads in the browser and fires whatever tags you wire up — analytics, vendor pixels, custom HTML. It does not own your conversion data and does not send conversions server-side on its own. When a blocker, ITP, a bad trigger, or a removed conversion action gets in the way, it fails silently.

Synter Pixel

A conversion system. One script captures a canonical event, ships it to Synter, and Synter fans it out server-side to your enabled, configured ad-platform destinations using your own ad-account connection. Leads route to your CRM when one is connected. Every attempted send is audited, destinations are verified, and coverage is monitored daily.

You can use both. GTM is a perfectly good way to deploy the Synter Pixel — a Custom HTML tag that loads synter-pixel.js. What GTM does not do is replace Synter's server-side conversion engine.

How the Synter Pixel works

One script tag. From there everything is automatic and canonical — you don't hand-wire a trigger per event or a variable per click ID.

Capture (browser). synter-pixel.js auto-tracks PageView and — critically — Lead on any form with an email field (native HTML, HubSpot, Typeform, Contact Form 7, Webflow, Framer). Ecommerce events (ViewContent, AddToCart, Checkout, Purchase) are auto-captured on Shopify; on other sites you fire them with an explicit synter('track', …) call. It also grabs supported click IDs (gclid, fbclid, rdt_cid, ttclid, li_fat_id, msclkid, sccid, epik) plus UTMs. Collection is consent-gated — the pixel only sends once consent is granted.
Ingest (server). Events POST to /api/pixel/events and are stored as one canonical event — normalized once, not per vendor.
Fan out (server). A config-driven router forwards each event to your enabled destinations using your own platform connection and writes an audit row for every attempted send, so a silent no-op is visible.
Route leads to CRM. When a CRM connection is present, Lead events also flow to Attio, so sales sees the conversion, not just the ad platform.

website ──▶ synter-pixel.js ──▶ /api/pixel/events ──▶ destination-router
                                                          │
        ┌────────────┬────────────┬────────────┬─────────┴───────────┐
        ▼            ▼            ▼            ▼                     ▼
   Google Ads     Meta        Reddit       LinkedIn  … +6 more     Attio (CRM)
  (offline upload)(CAPI)      (CAPI)        (CAPI)                  for leads

Supported destinations today: Google, Meta, LinkedIn, Reddit, TikTok, Microsoft, Snapchat, Pinterest, X, and OpenAI Ads. Conversions only go to the destinations you've enabled and configured. Each is a small adapter, so adding a platform means registering one more adapter rather than rewriting the fan-out logic.

Side-by-side

What you need	Google Tag Manager	Synter Pixel
Where conversions are sent	Browser tags, unless you build server GTM	✅ Server-side to enabled destinations via each destination's API
Click-ID & UTM capture	Manual variables + triggers	✅ Automatic
Lead detection on embedded forms	❌ Native trigger misses Fillout/Typeform/HubSpot	✅ Auto-detects any email form
Ad-blocker / ITP resilience	❌ Each vendor pixel can be blocked individually	✅ Consent-gated collection request (still blockable), then server-side send once received
Lead routed to CRM	❌ Not a CRM tool	✅ Routes to Attio when connected
Verification it actually works	❌ Eyeball Tag Assistant	✅ Safe, platform-specific verification probe
Alerts when it breaks	❌ Silent	✅ Daily coverage monitor

The trap: the tag is live, but nothing counts

The most painful failure in conversion tracking isn't a missing tag. It's a tag that fires correctly and still reports zero conversions. Three usual suspects:

The Lead trigger doesn't fit the form. Embedded forms (Fillout, Typeform, HubSpot, Calendly) don't fire GTM's native gtm.formSubmit.
The conversion action was removed in the ad account, so the tag fires into a dead action.
The campaign isn't bidding on conversions (e.g. Maximize Clicks), so even correct conversions don't change delivery.

The Synter Pixel removes the first two from the table for server-side conversions: it owns a canonical Lead event and verifies the destination before declaring it healthy.

We hit this ourselves — here's what we did about it

In June 2026 we discovered that some customer pixel events were being stored but never forwarded. A shared backend bug — a mis-bound :settings::jsonb parameter when saving a destination — caused destination writes to fail for weeks. A production sweep found only 2 of 325 ad-running orgs had a verified server-side destination. The UI said “installed.” Reality said otherwise.

The root cause was that “is the pixel installed?” and “are conversions actually arriving?” are two different questions, and we only checked the first. We fixed it on three levels:

Fixed the bug and added a regression test to catch that parameter-bind bug if it regresses.
Swept production — removed orphaned destination rows and backfilled partial settings.
Added a permanent guardrail: a daily coverage monitor that alerts whenever an org has a Synter Pixel configured, an active ad-platform connection, and enabled destinations but zero verified destinations. It stays low-noise by only paging on unambiguous breakage, not on freshly-created pixels.

Being straight about limits: Google's server-side conversions still require your own conversion-action ID and a live Google connection — Synter can't invent those. The monitor proves a destination was verifiable; campaign strategy (are you bidding on conversions?) is a separate check.

So: GTM or Synter Pixel?

Want a reliable source of truth for conversions + leads? → Synter Pixel
Already manage every script through GTM? → Deploy the Synter Pixel as a GTM tag. Best of both.
Want conversions that aren't lost to a blocked vendor pixel and route one canonical event to your enabled destinations? → Synter Pixel, server-side.

Get started

Install the Synter Pixel once and it starts capturing pageviews and leads automatically (plus ecommerce events on Shopify) — then connect your ad accounts and Synter handles the server-side fan-out.

Install the Synter Pixel →