We understand that it feels much easier to take the approach of pushing all of this information client-side, but finding the right mix of client-side and server-side is where we see Snowplow customers unlocking huge value. Besides the fact that it is more direct to record server-side data directly from servers, here are a number of other particularly compelling use cases for server-side tracking which we frequently see:
You want to collect data that you can’t expose client-side for commercially sensitive reasons - across most industries there are things too sensitive to expose on the client-side that would still be beneficial to track. An example that illustrates this well is margin or profit data in Retail, e.g. relating to, SKUs which are added to a basket or that make up part of a transaction. Having this data in an analytics system is valuable: it enables companies to calculate the actual return on marketing spend (based on profit generated rather than revenue). But retailers will likely want to treat that margin data as confidential, and not expose it client-side so that visitors to the website can see exactly what profit is made on different items sold.
You want to track events that do not occur in the user’s browser - there are numerous cases of this across a range of industries. Again to use a Retail use case, actions such as fraud checks and order returns would be tracked server-side.
You want to change the narrative on ad-blocking - catching up with ad blockers on the client-side is a valiant effort but you can track mission critical data server-side for greater reliability.
Server-side tracking has come a long way since server-log analysis in the past. Using Snowplow server-side trackers (e.g. our Python, Java, Scala, Ruby, C++ or PHP trackers), users can define their own rich events and entities, and send that information into Snowplow in near real-time, all exactly as they can client-side. The order returns example from a Retailer can illustrate how using a server-side tracker gives you richer data. When using server-log analysis in the past, you were stuck recording very basic data points i.e. this endpoint was hit at this time from this IP address. Now, harnessing server-side tracking allows you to collect granular data which tells you this red sweater was returned, in size medium, from shopper 123, via click and collect.
Sounds great - but what about joining the data? If say your objective is to understand a customer journey, this will now involve stitching client-side and server-side data about an individual user. Traditionally this has been challenging, with some web analytics tools making reverting to the option of pushing everything client-side seem sensible. However, for Snowplow users stitching this data is very simple!
You can use identifiers from three different categories; device identifiers (cookie IDs, IDFVs), User IDs or IP Addresses, to start constructing the data stitch. You will want to identify the same user across the client-side and server-side data; to join this data, we would expect this stitch to be done at the data modeling stage of the Snowplow pipeline.
There are two use cases where you would want to join your client-side and server-side data:
The first is where we are stitching together client-side and server-side events related to a journey through a website or mobile app, where you have made a deliberate decision to track some things server-side and some things client-side. For this use case in web we also ideally want to know that the client-side and server-side events are from the same session.
For an unknown user e.g. browsing a website, where the events are recorded client and server-side, it is possible to have server-side code that reads the Snowplow first party cookie (because this is set on the company’s own domain), the
domain_sessionid value and record these with the server-side events. An example of doing this with the Python Tracker can be done as documented here.
The second use case for the data stitch relates to a customer journey where the server-side event doesn’t happen in the browser - for example, with a Retailer and a returned item coming back to the warehouse via the post.
For known users e.g. a user returning the red sweater, we should have a purchase ID or user ID on the return form which can be mapped to the transaction ID for the stitch.
Fundamentally, there is no right or wrong approach to tracking implementation and there is no one-size-fits-all for any business model or vertical. This is why the flexibility to instrument tracking in any number of ways is core to the Snowplow product. It is worth thinking about whether the right combination of client-side and server-side tracking could allow you to unlock greater value and deliver better insights from your data in competitive times.
Get in touch with the Snowplow team if you want to discuss how to evolve your tracking to collect richer data.