In a great post from Project A, Martin Loetzsch and his team described how they implemented a custom server-side tracking solution. Though there are some ideas that I don’t follow (“it provides a cheaper alternative to Google Analytics Premium / Segment, etc.” — I don’t see Web Analytics and Server-side Tracking as two technologies that compete but rather complement each other). However, the whole approach is a very interesting one! In their solution you gather all the information and that will be transmitted to your DataLayer, ie. you already have a frontend Tag Management implemented. The events and parameter values are then tracked within a script on your server. The best part is that you would be able to handle everything as a first party. The cookies are very reliable and not blocked or restricted with ITP and other Browser-Add Ons. However, there are caveats with this approach.
1. Single Application Approach:
This will only work with a streamlined architecture, where your website is built in a framework, all widgets, features and functionality are part of this. You will have a controller that will know of every single-data Layer push function call. In modern websites and applications, that is not unrealistic, but in most websites we see today, we don’t have this super clean scenario.
2. Single Data Pipeline required:
Many interactions are simple AJAX calls to some API of your application. Adding a product to basket, requiring more products to display in a list, etc. All of these quick calls to APIs are simple functions that may bypass your server and tracking infrastructure. This requires that everything that comes and goes passes a server tracking checkup, and therefore bloating your already complex infrastructure.
3. Loss of all front-end tracked interactions:
Clicks, add-to-baskets, content consumption (scrolling, reading and dwelling on a website) and other interactions often have no explicit call to any server, and are missed in this approach.
Let’s have a quick look at the described criteria for this approach. When reviewing this approach, I focused on the technical feasibility, which I would rate as “sophisticated”.Despite the level of technical challenge, it is feasible for dedicated and very experienced data engineers, at an according level of cost. However, it does afford a high score on data sovereignty and data privacy, as the process is completely up to you and your own infrastructure. This process can now be maintained on a reliable technical infrastructure, one where JavaScript, Browser-side blocking and restrictions can be handled. Additionally, you have control over not sharing data with 3rd parties unless you want to. I would give this approach a high score.
These approaches might work and very well be a great solution. However, they are something for sophisticated projects, in which you have already built your own applications stack. Long existing and legacy driven projects will have no chance to go this path.
Learn about different approaches to server-side tracking in our free Ebook!
