Tracking user behavior is crucial for understanding customer journeys and optimizing campaigns. As browsers impose stricter cookie limitations—like 7-day tracking windows—marketers face growing challenges in accurately attributing conversions to their original sources.
Not all 'server-side' solutions are equal. This article examines three distinct tracking approaches: traditional client-side tracking that runs in the browser, server-side tagging that still depends on browser events and cookies, and customer data platforms that enable true server-side tracking by permanently linking customer identities with their acquisition sources. Understanding these differences is critical for choosing the right tracking architecture for your business.
Client-side tracking
The traditional approach to tracking involves embedding JavaScript tracking code directly into website pages. When a user interacts with the website, the tracking code captures events and sends data to the tracking server in real-time. This approach is easy to implement and provides detailed information about user behavior on the website. This is commonly referred to as 'client-side tracking'.
This was the prevailing tracking method on Internet but gradually fell out of favor. Early implementations allowed third-party websites to track users across any website on the web. The most visible form of such tracking was the proliferation of 'like' buttons that allowed Facebook and other social networks to collect detailed browsing profiles of their users. This led to widespread backlash with mainstream media coverage, and eventually browsers began blocking the ability of code on websites to access global user identifiers.
Consequently, ad platforms can no longer assign globally usable tracking identifiers to users that are traceable across the entire web. However, this doesn't stop client-side tracking from operating. Ad platforms now assign an identifier to each click that is transmitted to the website as part of the URL. Tracking code running on the website receives this identifier and associates it with a website-specific tracking cookie (a so called, 'first-party cookie'), ensuring that website activity is traceable back to the original click.
While use of click IDs has been somewhat restricted in IOS, it still works even there. Instead of user-unique click IDs, ad platforms use anonymized IDs shared among several users (such as the wbraid and gbraid identifiers used by Google Ads); they're just as useful for tracking as they typically point to a specific campaign and creative the user interacted with on the ads platform.
Client-side tracking has its drawbacks. It is susceptible to ad blockers and privacy extensions, which can hinder data collection. Additionally, the tracking code can increase page load times and potentially impact user experience. In practice, these issues are relatively minor and typically affect only 5-10% of traffic.
A much larger concern is the longevity of such tracking identifiers. While browsers allow them, they often restrict how long they can be stored to a short period (for example, 7 days), which isn't sufficient for many funnels.
Key takeaways
-
- Tracking code is embedded in the client-side (browser) environment
- Mechanism:
- Tracking code (e.g., JavaScript) is added to website pages
- User interactions and events are captured by the tracking code
- Data is sent directly from the browser to the tracking server
- Advantages:
- Easy to implement and widely supported
- Captures user interactions and events in real-time
- Provides detailed information about user behavior on the website
- Drawbacks:
- Susceptible to ad blockers and cookie blocking
- Increases page load time and may impact user experience
- Limited tracking across different devices or sessions
Server-side tagging
Some tracking solutions, notably server-side Google Tag Manager (sGTM/SSGTM), have adopted a hybrid approach to client-side tracking that they call server-side tagging. Instead of running tracking code in the browser, server-side tagging runs it in a virtual browser on a dedicated server, called a "container." In this approach, the browser still collects user events and data, but instead of sending it directly to the tracking server, it forwards the data to an intermediary server.
This simplifies the tracking code running in the browser, but it doesn't affect the core tracking configuration: the browser is still responsible for generating tracking events and storing user identifiers.
Why is it popular? Despite its limitations, it provides tangible benefits. Less tracking code running on the website offers marginal performance improvements. In some regulated industries, there may be regulatory restrictions on third-party tracking code placed on websites.
There's also a widespread outdated belief that tracking cookies set by SSGTM last longer than tracking cookies set otherwise in browsers like Safari. While this was true historically, Safari introduced anti-cloaking defenses in 2020, which treat the most popular SSGTM setup—where it runs on a separate server accessible at a subdomain of the main website—the same as any third-party tracker.
Otherwise, server-side tagging is equivalent to the client-side tracking discussed in the previous section. Server-side tagging still depends on tracking events originating in the browser. Even if they're sent to a first-party domain name, it relies on JavaScript code collecting each conversion event and cookies containing the original customer source and click identifiers still being present in the browser.
As it depends on click IDs and browser IDs being sent to the tracking server or container alongside each event, it only works with browser conversions where such parameters are present in cookies. It can't be used to reliably track server-side events, such as recurring payments in a payment system, trial subscription activations, CRM qualification and conversion events, and other similar conversions that don't correspond to an explicit browser action—and the original paid click ID.
Key takeaways
-
- Browser tracks events and sends them to an intermediary server
- Example: Server-side Google Tag Manager (GTM)
- Mechanism:
- Browser collects user events and data
- Data is forwarded to the intermediary server
- Intermediary server processes and sends data to the destination server
- Advantages:
- Allows for data manipulation and enrichment on the server-side
- May provide limited protection against ad blockers
- Drawbacks and requirements:
- Can only track conversions that occur in a browser
- Requires ad platform tracking cookies to be present at the time of conversion
- Requires additional server infrastructure and maintenance
Customer data platform tracking
Customer data platforms (CDPs), such as Able CDP, focus on collecting visitor data during the first website visit and linking it with an identifier, such as an email address. CDPs can then attribute conversions server-side using this identifier and send the attributed conversions to the destination server using a server-side tracking conversions API. This approach enables a unified view of the customer journey across multiple touchpoints and allows for real server-side tracking and data integration with conversion APIs.
Compared to client-side tracking and server-side tagging, the customer data platform's server-side tracking allows for recording the sources of customers and click identifiers, permanently associating customer details with the source and original click ID. This enables the processing of further conversions without relying on tracking cookies and without being restricted by the time elapsed between the click and the conversion.
Instead of using the stateless tracking implemented by client-side tracking and server-side tagging, which relies on all necessary data being present in the browser at the time of conversion, customer data platforms split event tracking into two stages:
- Website visitor source and paid click IDs are associated with the user identity as soon as it's provided, such as when completing a lead or sign-up form.
- When a conversion occurs, it's received server-side from a payment system, e-commerce platform, or CRM system, which ensures that no conversions are missed since no browser tracking is involved at this step.
The customer data platform then looks up the original customer source and tracking information associated with the visitor, making it available for reporting and sending the precise click ID back to the ad platform for attribution. This ensures that all conversions are attributed without relying on cookie longevity.
Key takeaways
-
- Collects visitor data on the first website visit and links it with a permanent customer identifier such as email
- Attributes conversions server-side using the customer database
- Mechanism:
- CDP collects visitor data during the first website visit
- Visitor data is linked to an identifier (e.g., email)
- Conversions are tracked and attributed server-side using the identifier
- CDP sends attributed conversions to the destination server
- Advantages:
- Enables a unified view of the customer journey across multiple touchpoints
- Allows for server-side attribution and data integration
- Doesn't rely on tracking cookies
- Prerequisites:
- Requires integration with a CDP platform
Conclusion
The shift from client-side tracking to server-side solutions reflects the industry's response to privacy restrictions and the need for more reliable conversion attribution. While client-side tracking remains easy to implement, its dependence on cookies and vulnerability to blockers limit its effectiveness—especially for businesses with conversion windows beyond 7 days.
Server-side tagging provides marginal improvements but still relies on browser events and cookies, making it unsuitable for tracking server-side conversions like recurring payments or CRM events. Customer data platforms offer the most comprehensive solution by permanently linking customer identities with their original source, enabling accurate attribution regardless of cookie limitations or time elapsed since the initial click.
The optimal tracking method depends on your specific needs: client-side for simple, short-cycle conversions; server-side tagging for regulatory compliance; and CDPs for businesses requiring complete attribution across extended customer journeys and server-side conversions.