Server-side event tracking is the solution to ad blockers, Apple’s ITP, and privacy changes that are breaking browser-based analytics.
Browser tracking relies on JavaScript running in someone’s web browser to collect and send data to analytics platforms. Server-side tracking processes events on your servers before sending them to the same platforms. The key difference is that browser tracking can be blocked by ad blockers, privacy settings, and tracking prevention systems, while server-side tracking cannot.
Tracking Prevention
Ad blockers like uBlock Origin, AdBlock Plus, and Ghostery actively block tracking scripts and prevent network requests to analytics domains. Apple’s Intelligent Tracking Prevention blocks third-party cookies, restricts first-party cookie lifespans, and prevents cross-site tracking. Each Safari update introduces more restrictions, reducing attribution windows and degrading conversion data quality.
Proxy systems and VPN services mask IP addresses and geographic locations. Enterprise firewalls block analytics scripts. Corporate content filtering systems prevent tracking pixels from loading. Users can disable JavaScript, clear cookies, or install browser extensions that break tracking entirely.
Browser tracking is vulnerable because the code executes in the user’s environment where they control script execution, cookie storage, and network requests. Server-side tracking operates from your servers after user actions occur, making it immune to client-side blocking mechanisms.
Implementing Server-side Conversions
It’s recommended to start by ensuring your browser analytics implementation is well-organized, fully functional, and clean. You should consider using a tag management system like Google Tag Manager or Segment with clear labeling and consistent naming conventions.
The goal is to track the exact same events server-side that you’re tracking in the browser. When properly implemented, browser and server events merge together when sent to external systems like Facebook Ads, TikTok Ads, Google Ads, and HubSpot.
You can begin by listing every system that receives analytics data from your current browser implementation. It’s helpful to research the server-side APIs available for tracking conversions and events. Most major platforms now provide dedicated server-side APIs including Facebook Conversions API, Google Ads offline conversions, and TikTok Events API.
Example Server-side API Requests
Here’s what real-world server-side analytics API calls look like under the hood, to give you an idea of what information you’ll be collecting and sending during a full implementation.
TikTok
{
"id": 28318995,
"incoming_id": "REDACTED",
"incoming_type": "event",
"sent_at": "2025-09-26T22:53:59Z",
"destination": "tiktok",
"endpoint": "https://business-api.tiktok.com/open_api/v1.2/pixel/track/",
"request": {
"event": "Lead",
"context": {
"page": {
"url": "https://apply.saas.app/phone/verify"
},
"user": {
"external_id": "REDACTED",
"phone_number": "REDACTED"
},
"client_user_agent": "REDACTED"
},
"event_id": "REDACTED",
"timestamp": "2025-09-26T14:53:59-04:00",
"pixel_code": "REDACTED",
"properties": {
"value": 1,
"currency": "USD",
"content_id": "/phone/verify",
"description": "Apply.saas.app customer onboarding enrollment started event",
"content_type": "product",
"content_category": "apply.saas.app"
}
},
"response": {
"code": 0,
"data": [],
"message": "OK",
"request_id": "REDACTED"
}
}
Facebook Conversions API (CAPI)
{
"id": 28318994,
"incoming_id": "REDACTED",
"incoming_type": "event",
"sent_at": "2025-09-26T22:53:59Z",
"destination": "facebook",
"endpoint": "https://graph.facebook.com/v23.0/REDACTED/events",
"request": {
"data": [
{
"event_id": "REDACTED",
"user_data": {
"ph": "REDACTED",
"fbp": "REDACTED",
"country": "REDACTED",
"external_id": "REDACTED",
"client_ip_address": "REDACTED",
"client_user_agent": "REDACTED"
},
"event_name": "InitiateCheckout",
"event_time": "REDACTED",
"custom_data": {
"customer_segmentation": "new_customer_to_business"
},
"referrer_url": "https://apply.saas.app/phone/verify",
"action_source": "website",
"event_source_url": "https://apply.saas.app/phone/verify",
"data_processing_options": [],
"data_processing_options_state": 0,
"data_processing_options_country": 1
}
],
"access_token": "REDACTED"
},
"response": {
"messages": [],
"fbtrace_id": "REDACTED",
"events_received": 1
}
}
Replicating Browser Events
A good approach in many circumstances is to piggyback off an existing GTM implementation, using the dataLayer as a shared resource for tracking both client and server events. If you’re currently working with a well-organized, solid analytics system in the browser, then it makes sense to replicate that on the server-side. To do this, you can implement a server-side tag management system that functions like Google Tag Manager for server events. You would send events to one place, and that system pushes events to all your external platforms.
Customer Data Platforms (CDP)
CDPs are tools that you can send these server-side events to. Google Tag Manager offers a server-side option that’s very limited and often not a good choice. Other providers exist as well, but among them, Segment offers the most mature commercial solution with extensive pre-built connectors. mParticle provides enterprise features and data governance. For maximum flexibility or critical automation requirements, a custom development stack may be ideal. RudderStack is an excellent open-source option that allows customization and self-hosting. The system should support custom connector development. Every real server-side tracking project I’ve worked on required some custom integration that couldn’t be handled by standard connectors.
You would set up connectors for each external platform within your tag management system. Many systems include pre-built connectors for major platforms. For systems without existing connectors, it’s important to ensure your platform supports custom connector development. You would then modify your server-side application code to send events alongside your browser tracking. This can be simple or complex depending on your system size, number of integrations, and organizational structure.
Technical Implementation Process
A well-organized development team can create a service class for event tracking. If your codebase is structured properly, adding event tracking throughout the system can be straightforward. The requirement is tracking events in your server-side code (PHP, JavaScript, Python, etc.) rather than only in the browser. The critical component is implementing shared event IDs between browser and server-side events. This allows external platforms to identify duplicate events and merge data properly.
You would load a centralized JavaScript file from your website and applications where you want to track events. You can create a first-party cookie for your domain containing a unique session ID for each visitor. These cookies are not currently blocked by ad blockers and provide a reasonable attribution window depending on the browser. When you collect email addresses, you would also track a user ID that serves as a unique identifier for that email/account. When events occur in your application, you would send API requests to your event tracking endpoint that include the user ID, anonymous ID from the cookie, event properties, and user attributes.
Understanding Limitations
For specific technical details about cookie behavior across browsers, you can visit the Cookie Status website. Events triggered from web applications should be fine when they originate from your website or app. This approach will make API requests to your backend for sending server events. We can’t do this with AJAX requests made with JavaScript inside Google Tag Manager because GTM won’t be loaded for visitors blocking tracking. You would send the anonymous ID with the value from your first-party cookie in all server-side events.
Browser JS to Server API
Once you have a backend API set up to receive and submit server-side events, you can add a single JavaScript file called analytics.js to your website or application that loads on every page. If you already have a solid browser implementation in Google Tag Manager, you can often avoid extensive server-side implementation beyond the API by piggybacking off data layer pushes. This analytics.js file should be loaded from your own domain and won’t be blocked by current ad blockers (though you could name it something different as a precaution). It would track page view events on every page asynchronously without blocking user flow and listen for changes to your data layer where events are pushed for Google Tag Manager.
By monitoring data layer changes like this, you can hijack these events to create corresponding server-side events. This is extremely productive when possible because you’re replicating an existing browser implementation with server-side events rapidly. It’s especially effective for organizations tracking many different event types. You can implement this across your top-level domain and load the same analytics script on subdomain applications, creating user ID and anonymous ID tracking at the root level. A typical API structure for handling events like this uses a JSON structure like this:
POST /api/trk/
{
"event": "phone_verified",
"context": {
"url": "https://apply.saas.app/phone/verify",
"host": "apply.saas.app",
"path": "/phone/verify",
"query": '?utm_source={platform}&utm_medium={medium}&utm_campaign={campaign}',
"title": "{page title}"
},
"properties": {
"event_id": "unique-id-here",
"value": 99.99
},
"user": {
"anonymous_id": "cookie-value",
"fbp": "fb.1.1758912824086.124141881448277665",
"ttp": "01K63NYAY2K92FG6RHP5M0W2MF_.tt.1",
"user_id": 927043,
"ip_address": "96.84.76.253",
"user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 18_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.5 Mobile/15E148 Safari/604.1"
}
}
Including an event ID parameter with a unique ID for each event in the properties object is a critical aspect of all this. The user object should contain the anonymous ID, user ID if available, and attribution information including advertising click IDs, UTM parameters, and other data required for conversion APIs.
Syncing with Browser Tracking
After implementing server-side event tracking, you would update your browser tracking to use the same event IDs as your server-side events. This allows advertising and analytics platforms to identify browser and server events as the same event and merge the data. Data merging is important because browser tracking still works for many users and provides additional detail not available with server-side events alone. Ideally, users allow tracking and you send both client-side and server-side events to your backend systems.
You can verify your implementation in Facebook Events Manager, TikTok Ads Manager, Google Analytics, or other platforms. Many systems provide match rates showing the percentage of events sent with matching data and shared event IDs.
These systems try to automatically identify and merge duplicates, but sending explicit event IDs is substantially better, especially when accuracy and precision are important. You won’t get 100% match rates. Users with ad blockers or tracking protection will only send server-side events with no corresponding browser event to match. It’s not necessary to fixate on achieving perfect match rates.
Most people implementing server-side tracking already have browser tracking sending events to analytics and advertising platforms. They want to add server-side tracking to improve ad spend effectiveness, which is critical given privacy laws reducing tracking effectiveness.
You can follow the process described above, then update your existing Google Tag Manager implementation. You would modify your current events so that server-side events sent from JavaScript to your tracking API also push an event ID with the event information to your data layer for GTM. This ensures your existing browser events include the same event IDs as your server-side events, enabling proper matching and data merging across platforms.
Background & Experience
I did my first full Segment server-side code implementation back in 2014, when it was a new, unheard-of product. It was done for a large insurance company, at a time when server-side tracking wasn’t really done or advocated for anywhere. I advocated for server-side tracking before privacy issues became mainstream, immediately recognizing the value when Segment introduced server-side capabilities well before current privacy concerns existed.
Over nearly a decade, I’ve implemented server-side tracking for numerous mid-to-large organizations across different industries. Every system I’ve built has been mission-critical for companies spending significant money on advertising, giving me real-world experience with both technical implementation and business impact.
Conclusion
Server-side event tracking has become essential for maintaining accurate analytics and advertising performance as browser-based tracking becomes increasingly unreliable. The implementation requires careful planning and technical execution, but the results are worth the effort.
The key to success is starting with a clean browser tracking implementation, choosing the right server-side tag management system, and properly implementing shared event IDs between browser and server events. Organizations that implement this correctly see improved ad performance, better attribution, and more reliable analytics data.
While the technical complexity can vary depending on your existing systems and organizational structure, the fundamental approach remains consistent across different platforms and industries. The focus should be on replicating your browser events server-side, syncing the two implementations with shared event IDs, and verifying everything works through platform-specific validation tools.
The investment in server-side tracking pays dividends in improved data quality and advertising effectiveness, making it a critical component of modern digital marketing infrastructure.