Server-side: 10 myths debunked

In the wake of the cookieless era, the “server-side” model (i.e. server-based data collection) is steadily gaining traction among digital marketing teams in their campaign roadmaps. This new development has raised a number of question marks, doubts and fears, and has even spawned a few myths…

Myth #1: “With server-side model, tags are dead and so is tag management”

It’s true that the server-side model is also known as a tagless process, so it’s easy to believe that tag management is dead. But technically speaking, the reality is a lot more complex. Not all solutions are eligible for server-side. Server-side may already be compatible with consent management and analytics, but in practice it’s harder to implement for ad servers and personalisation solutions. The transition period will take some time, so until that time comes, both methods (client-side and server-side processing) will co-exist. Therefore, we haven’t seen the end of tag management yet. This also gives us the time to deal with the inevitable changes to the profession… we’ll come back to this topic later.

 

Myth #2: “Server-side is a job for developers”

The emergence of the server-side model has ushered in the feeling that the whole tracking deal has changed sides, namely that it’s been taken out of the marketing teams’ hands and given to the developers. Let’s be clear, this is a (major) shortcut. Admittedly, implementing tagless integrations is a technical job. That’s why the whole process will not be achieved in a day, but instead spread over a few years. But in this case, we’re talking about implementing integrations using the solutions available in the market. Once the solutions are up to speed (i.e. tag managers – a new name will probably be required – and partners’ solutions), server-side will remain in its rightful place behind the scenes. So marketing managers are still responsible for working on the data collected.

Myth #3: “Thanks to server-side, part of my job will go up in smoke”

No tags = the end of tag management and… the associated jobs? Do traffic managers and tagging specialists have any need to be worried? Not really. It’s all a matter of defining “tag management”. If we consider that the primary aim with tag management is placing tags in containers that are executed in a browser, then yes, that breed of tag management will be phased out.

However, if tag management is also seen as a way of processing data before they are passed along to partners, then tag management is far from having one foot in the grave. On the contrary, a new era is dawning. The server-side model opens up a wealth of possibilities, whether checking data quality, enriching data or distributing data to partners with greater precision. The bottom line is that server-side is a real catalyst for stimulating creativity when it comes to data.

Myth #4: “Server-side is a black box; basically we’re losing all control”

This feeling is perfectly understandable. With browser-side tag management, you get the impression that accessing collected data is a bit like reading from an open book, whereas server-side tag management seems to have slammed that book shut. But appearances can be deceptive. In practice, everything is still under complete control and perfectly accessible. The tag manager continues to be the hub where data are collected, processed and sent to partners. Instead of dealing with tags, the solution manages tagless integrations from server to server. Those integrations can still be seen and manipulated.

 Myth #5: “Server-side is managed in-house using bespoke developments”

This is often how new technological practices and features are launched, especially if some sections of the market have not yet got to grips with this new challenge (and this still applies to server-side). As such, it might be tempting to rely on in-house developments to control data exchanges between servers. But give into the temptation and you’ll lose sight of what really matters. The aim isn’t just to implement the server-side model, but also hide all the complex technical mechanisms involved, so that the market teams can focus on their daily activities with greater agility. When it comes to this challenge, a software product will always be more robust than a bespoke development.

Myth #6: “Server-side is going to be expensive…”

Since server-side requires all stakeholders to overhaul their technical infrastructure, dedicated budgets will admittedly be required. But the costs should be weighed against the benefits reaped. There will be a drastic fall in the number of tags that browsers have to manage for a given website, which will improve web performance and consequently enhance the user experience. Above all, switching over to a server-side model improves quality control and enriches data beyond the capabilities of a client-side arrangement. The process of migrating to the server-side model is in the teething stages, and its potential is still widely underestimated. It could potentially mean that partners will receive less data, but the data will be much more relevant.

Myth #7: “Server-side is a real SPOF”

In IT speak, a SPOF or “Single Point of Failure” means that the availability of an entire system depends on the availability of just one of its components. If that component fails, the whole system goes down. Since all transactions are carried out between servers with the server-side model (and not from browser to server), this raises questions about the ability of the server managing the transactions to shoulder the load. As a result, infrastructures will need to be scaled up to address two challenges, i.e. collect all the hits, and process / share the data. The good news is that tremendous experience has already been acquired in this particular area. For example, we know that processing activities can be buffered (temporarily put to one side) in case of an unexpected peak in the load, so that they can subsequently be processed in batches.

Myth #8: “Thanks to server-side, I don’t have to worry about consent”

This misconception should be cleared up as quickly as possible. Server-side is a technical process for collecting and processing data. It doesn’t make the slightest difference to the precautions that should be taken to comply with the GDPR (General Data Protection Regulation) and the consent collection directives issued by the data protection authority. Irrespective of whether information is sent from a browser or a server, consent must be obtained from the user.

Myth #9: “Setting up a consent process with server-side is complicated”

If consent management practices are based on an in-house development that hasn’t been designed to accommodate the server-side model, then migrating could be a painful experience. This doesn’t apply to solutions like TrustCommander, our Consent Management Platform, whose architecture has been designed from the ground up to embrace the server-side model. Therefore, propagating consent among partners with a server-side arrangement is painless.

Myth #10: “Server-side is bound to tighten up data confidentiality”

When it comes to security, nothing can be taken for granted. Just because interactions are managed from server to server doesn’t mean that they’ll naturally be more secure. It will be true if infrastructures are audited and secured in accordance with best practices, and if traffic between servers is secured with an encryption mechanism that is worthy of the name. Depending on the technical arrangements made, and even with server-side, it’s worth pointing out that a data layer may linger in the browser and therefore leave data exposed. If data are sensitive, the server-side model can be implemented without requiring a data layer. Therefore, the security of a server-side arrangement requires a set of measures… and choices.