Server-side GTM for a small site: worth the hosting bill or another thing to break?

Everyone keeps pushing server-side GTM now that ad blockers and Safari have eaten into cookie lifetimes, but for a site doing a few hundred leads a month I'm not convinced it pays off. You take on a cloud container that bills per request, plus a second place where a broken tag can quietly drop conversions. The gain is real if you need longer-lived first-party cookies or you're sending the same clean events to several ad platforms at once. If all you're running is GA4 and one Meta pixel, a well-tested client-side setup with consent mode and a CAPI integration usually gets you most of the way there. How are people measuring whether it actually recovered lost conversions? A before-and-after comparison gets muddied by everything else that changed that month.

Run both side by side for a couple of weeks instead of comparing month over month. Keep the client-side tags live, dedupe on event ID, and track the gap between platform conversions and CRM leads. That gap is what you're actually recovering, and it's a lot less noisy than a before-and-after.

Side by side is the right call, but at a few hundred leads a month the test is shakier than it looks. Two weeks gets you maybe 150 leads, and a 5 to 8% gap in a sample that small is mostly noise. So set the bar before you start. Get the client-side setup fully fixed first, with consent mode and CAPI deduped on event ID, and only look at server-side if the platform-versus-CRM gap is still above about 10%.

My rule of thumb is that if you're sending to one or two platforms and the gap is under 10%, stay client-side. The hosting bill is small, but the real cost is the time someone spends maintaining a container that can break quietly. Server-side starts paying off when three or more platforms consume the same events, or when you really need longer-lived first-party cookies. At that point you maintain the event pipeline once instead of inside every tag.

Split out the leads that never made it into the CRM because of form or sync failures before you compare the gap to that 10% line. Server-side tracking can't fix those, so if you skip that step you'll end up blaming (or crediting) the tagging for a problem it was never going to solve.

Agreed, and the first thing I'd check is where the event fires. Plenty of lead forms send the conversion on the submit click or on the redirect to the thank-you page, before the CRM has accepted the record. If the webhook times out or a required field fails in the Zap, the pixel has already counted a lead that never reached the CRM. That gap looks like a tagging problem, but it's really a sync problem.

To tell them apart, pull the form submission log or webhook log for the same two weeks and compare it to the CRM count. If the form count and the platform count match, the gap is downstream of the form, and moving the tag server-side won't close it. The only difference tagging could realistically fix is the one between the form log and the platform count.