Service

Server-side tracking for HubSpot, built in your existing GTM

Server-side tracking sends your GA4 and ad platform data through a server on your own subdomain instead of straight from the browser to Google, Meta and LinkedIn. That makes it harder for ad blockers and browser privacy rules to drop it, and lets you control exactly what each platform receives. I add it to your existing GTM setup, so your current tags and reports keep working.

By Vladimir Cvetkoski · Last updated 6 October 2026

Who it is for

This is for you if

→B2B companies running paid campaigns on Google Ads, Meta or LinkedIn whose platforms report far fewer conversions than HubSpot
→Teams with a large share of visitors on Safari or with ad blockers, typical for technical and developer audiences
→Companies that want Meta Conversions API or LinkedIn Conversions API without installing another plugin
→Teams whose existing server-side GTM was set up once and nobody is sure it still works

Symptoms

Signs you need this

→Ad platforms report fewer conversions than HubSpot shows leads, and the gap keeps growing.
→Returning Safari visitors show up as new visitors with no source. See why HubSpot shows so much Direct traffic.
→GA4 and HubSpot disagree on lead counts for the same period. See GA4 vs HubSpot mismatch.
→Meta Events Manager shows low event match quality or warns about duplicate events.
→A server container exists, but nobody knows what it sends or who pays for its hosting.

What I do

What the work covers

Server container setup

A server-side GTM container on a subdomain of your site, typically hosted on Stape or Google Cloud, connected to your existing web container.

GA4 routed through your server

GA4 events sent through your own subdomain, with first-party cookies set by the server instead of JavaScript.

Meta and LinkedIn Conversions APIs

Lead and page events sent server to server, with hashed match keys and event IDs so browser and server events are deduplicated, not counted twice.

Google Ads conversion tags

Google Ads conversions and enhanced conversions sent through the server container, with click IDs preserved.

Consent passthrough

Consent Mode signals respected on the server, so a visitor who declines is not tracked just because the request now goes through your domain.

Documentation and hosting handover

What each tag sends, where, and why. The hosting account is in your name and on your card.

How it works

Three steps

Map what you send today

I list every tag in your web container, what it sends and to whom, and agree which ones move to the server.

Build alongside, not instead

The server container is built next to your current setup and tested in GTM preview, so nothing goes dark during the switch.

Switch, compare, document

Tags move to the server one platform at a time. I compare event counts before and after, then hand over the documentation.

Scope and timeline

Typical scope

Typical effort: 15 to 20 hours for a server-side GTM build or rebuild with Meta Conversions API and GA4 routing
Timeline: Most fix projects complete within 1 to 2 weeks
Hosting: Typically Stape or Google Cloud, billed to your own account
Access needed: GTM admin, DNS for one subdomain, GA4, and admin on each ad platform

Server-side tracking is usually scoped as part of The Fix, often after an Attribution Audit shows where browser-side loss is costing you.

What you get

At the end you have

→GA4 and ad platform tags served from your own domain, with fewer events lost to blockers
→Meta and LinkedIn receiving server-side conversions with proper deduplication
→Control over what data each platform receives, in one place
→Your existing GTM setup still in place and documented

Architecture

How the pieces connect

01
Browser
Your existing GTM web container
02
Your subdomain
e.g. `data.yoursite.com`, first-party
03
Server GTM
Hosted on Stape or Google Cloud
04
GA4 and Google Ads
Events and conversions with click IDs
05
Meta and LinkedIn
Conversions APIs, deduplicated

The browser sends one stream of events to your own subdomain. The server container then forwards what each platform should receive, with consent applied.

Questions

Server-Side Tracking: common questions

Only part of it. HubSpot's own tracking code still runs in the browser, so server-side GTM does not change how HubSpot assigns Original Source. It also does not fix forms that drop UTMs or redirects that strip them. Those are fixed where they happen, see HubSpot form UTMs missing.

No, and it should not. A visitor who declines tracking must still be treated as declined. I pass consent state through to the server container so tags there follow the same rules as in the browser. See Consent Mode v2.

No. Your web container stays. I add a server container and change where some tags send their data. Your existing triggers, variables and reports keep working.

Cookies set by your own server can last longer than cookies set by JavaScript. Safari deletes JavaScript-set cookies after 7 days without interaction, and after 24 hours when the visitor arrived from a link-decorated URL. Safari also caps server-set cookies at 7 days when the tracking subdomain is a CNAME to a third-party host or resolves to a third-party IP address, so the real effect depends on how your subdomain is hosted.

HubSpot's native Meta and LinkedIn integrations can send lifecycle stage conversions, which is useful. Server-side GTM covers the website events those integrations do not, keeps deduplication under control, and puts every platform in one place you can inspect.

Describe what you are seeing

Send a few lines about what looks wrong. I reply within 1 business day and tell you whether it needs an audit, a fix, or nothing at all.

Describe your problem