What We Learned Implementing Server-Side Tagging on Our Own Website

Why We Ran This Experiment

At rtCamp, we don’t recommend technologies we haven’t tested ourselves. As third-party cookies fade and first-party data become more important, we explored server-side tagging (SST) to understand what it can realistically improve for measurement and performance in a privacy-first world and where its limits still are.

So we used our website as a testing ground. Over the course of this experiment, we implemented server-side tracking for four marketing platforms: Google Analytics 4, LinkedIn Conversions API, Parse.ly, and Salespanel. Each presented different challenges, and together they gave us a comprehensive view of what SST adoption actually looks like in practice.

This post shares our findings, the technical details, the surprises, and the honest assessment of when SST makes sense and when it doesn’t.

Server-Side vs Client-Side Tagging: A Visual Comparison

Before diving into our implementation, here’s how the two approaches fundamentally differ:

Our Setup: Infrastructure & Platform Selection

We chose Stape as our server-side infrastructure provider. Unlike self-hosting on Google Cloud Platform (where costs fluctuate with traffic), Stape offers fixed pricing based on request volume. More importantly, it handles server maintenance, SSL certificates, and scaling, letting us focus on the actual tracking implementation instead of DevOps.

Why We Chose Stape

We tested four platforms, deliberately chosen to represent different levels of SST maturity:

1. Google Analytics 4: The gold standard, native SST support
2. LinkedIn Conversions API: Native support, but requires hybrid approach
3. Parse.ly: No native template, custom API work required
4. Salespanel: No native template, extensive custom integration

Implementation Details: Platform by Platform

1. Google Analytics 4

GA4 represents the ideal SST scenario. We configured our website to send a single, lightweight data payload from the GTM Web Container to the Stape-managed Server Container via a custom subdomain. Inside the server container, a GA4 client intercepts incoming requests and translates raw data into a standardized event data model. When triggers fire, the GA4 tag constructs a clean outgoing request to the GA4 Measurement Protocol API.

2. LinkedIn Conversions API

LinkedIn introduced our first real challenge: deduplication. Running both the browser-based Insight Tag and the server-side Conversions API (CAPI) risks double-counting conversions. A form submission would trigger both tracking methods, inflating reported numbers.

We solved this using a Unique Event ID variable (provided by Stape) across both containers. The same ID passes through the client-side GA4 event parameter and the server-side CAPI call. LinkedIn’s deduplication engine recognizes both signals as a single event.

3. Parse.ly

Here’s where things got interesting. Parse.ly doesn’t offer a native tag template in the GTM Gallery, so we built the integration ourselves.

Parse.ly’s server-side tracking uses the https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fp1.parsely.com%2Fplogger%2F endpoint, accepting event types including pageview, heartbeat, and conversion. The first obstacle: the standard API Connector template only supports POST and PUT methods, but Parse.ly requires GET requests. We modified the template’s Fields tab and adjusted the code to build a query string from event data.

The second obstacle was subtler. Per Parse.ly’s documentation, events like heartbeat or conversion require a preceding pageview event. We implemented sequential firing logic to ensure correct event order, a detail that would have caused silent data loss if missed.

4. Salespanel

Salespanel demanded the most extensive work. The platform relies on a unique visitor UUID for identification, requiring an additional infrastructure layer.

We built a helper PHP plugin in WordPress that fetches a visitor_id from the Salespanel API and stores it in a first-party cookie (salespanel_visitor_id). The GTM Web Container retrieves this cookie value and passes it to the server container as an event parameter within a standard GA4 tag, essentially piggybacking on the GA4 data stream.

The server container then uses the API Connector to send a POST request to https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fsalespanel.io%2Fapi%2Fv1%2Fcustom-activity%2Fcreate%2F, including the visitor identifier, category, label, and metadata.

Implementation Effort Summary

*Time estimates assume familiarity with GTM and basic API concepts

The Honest Assessment: Pros vs Cons

Our Recommendations

Based on this experiment, here’s how we’d advise approaching server-side tagging:

1. Start with GA4

The ideal proving ground. Quick results build familiarity before tackling complex platforms.

2. Audit Your Stack

Check which platforms have native SST support. If critical tools lack templates, budget for custom development.

3. Consider Hybrid

Don’t assume fully server-side is always best. We maintain hybrid for LinkedIn to ensure proper deduplication.

4. Build Monitoring

Server-side failures are silent. Set up dashboards tracking event volumes and API response codes from day one.

5. Capture Baseline

Record 30 days of pre-SST data across all platforms. Enables proper before/after comparison to justify ROI.

The Bottom Line

Server-side tagging is currently in a “hybrid” state of adoption. For major platforms with native support, it’s mature and delivers on its promises. For mid-tier vendors, it requires a “workaround” mindset and genuine technical expertise.

Is it worth it? For organizations heavily dependent on accurate conversion tracking, especially those affected by ad blockers or operating in privacy-sensitive industries, yes. The investment in SST infrastructure pays dividends in data quality and future-proofing.

For smaller teams with simpler tracking needs and platforms that lack native SST support, the cost-benefit calculation depends on ad spend and the number of tracking and analytics scripts being used. If using just 2-3 tracking tools, custom development effort can outweigh the gains.

Our experiment gave us firsthand knowledge of both sides of that equation, knowledge we now apply when advising on tracking infrastructure decisions.

Frequently Asked Questions

What is server-side tagging?

Server-side tagging shifts tracking script execution from the user’s browser to a controlled server environment. Instead of loading multiple third-party scripts directly in the browser (which can be blocked, or impact performance), your website sends a single data streamyour own server, which then distributes the appropriate information to each marketing platform.

How much does server-side tagging cost?

Costs vary by approach. Self-hosting on Google Cloud Platform can range from $50-500+/month depending on traffic. Managed providers like Stape offer fixed pricing plans starting around $20/month for basic usage, scaling up based on request volume. Factor in implementation time: native integrations take hours, while custom API work can take days.

Does server-side tagging bypass ad blockers?

Largely, yes. Because server-side tracking routes data through your own subdomain (e.g., metrics.yourdomain.com), it appears as first-party traffic rather than third-party tracking. Most ad blockers target known third-party domains, so this approach can recover 15-25% of previously blocked events. However, some sophisticated blockers may still detect and block server-side implementations.

Do I need server-side tagging for GA4?

Not necessarily, but it provides significant benefits. GA4 works fine with client-side tagging, but server-side implementation improves data accuracy (especially for users with ad blockers), enhances page speed, and gives you greater control over what data is shared with Google. If data accuracy is critical to your business decisions, server-side GA4 is worth considering.

What’s the difference between CAPI and client-side tracking?

CAPI (Conversions API) is the server-side equivalent of browser-based pixel tracking. With client-side tracking, a pixel in the user’s browser sends conversion data directly to the ad platform. With CAPI, your server sends conversion data to the platform’s API. Many platforms (Meta, LinkedIn, TikTok) recommend running both simultaneously with deduplication to maximize data capture while avoiding double-counting.

How long does server-side tagging implementation take?

It depends heavily on which platforms you’re integrating. Native integrations like GA4 can be completed in 2-4 hours. Platforms requiring hybrid approaches (like LinkedIn CAPI) take 4-8 hours, including testing. Custom API integrations for platforms without native templates (like Parse.ly or Salespanel) can take 1-3 days, including debugging and validation.

What is Stape, and why use it for server-side tagging?

Stape is a managed server-side tagging platform that hosts and maintains GTM Server Containers. Instead of setting up and managing your own servers on Google Cloud Platform, Stape handles infrastructure, SSL certificates, scaling, and maintenance. This removes DevOps overhead and provides predictable pricing based on request volume rather than variable cloud computing costs.

Is server-side tagging GDPR compliant?

Server-side tagging improves GDPR compliance posture but doesn’t automatically make you compliant. The key benefit is that you act as a data gatekeeper; you can strip PII (like IP addresses or email addresses) before forwarding data to third parties. However, you still need proper consent mechanisms, data processing agreements, and privacy policies. Server-side tagging is a technical enabler for compliance, not a compliance solution itself.

Considering Server-Side Tagging?

We’ve been through the implementation trenches and can help you assess whether it’s the right move for your organization.

Let’s talk.