Month: April 2022

There are two ways to collect the signals that customers send out when visiting a website or using a mobile app. The first method involves getting the browser to execute small fragments of code (tags) when loading pages.

These tags collect and send the data (origin, content, profile, etc.) to the partners who have been authorised by the customer. Therefore, with the first method, everything relies on the browser. The second approach involves sending the data to the server, which will take care of supplying the data directly to the different partners’ servers according to a set of rules. In this case, data are collected, converted and shared from server to server without any involvement from the browser.

Server-side has become the hottest topic of discussion among digital teams when gathered around the coffee machine. Is there any justification for its popularity? Let’s take a look at the opportunities that a server-side strategy can bring.

• Quality of collected data: the server-side model ensures that the data collection process is centralised on a server, instead of being distributed by each browser. An effective server-side platform checks the quality of the data transiting over the server and corrects any identified errors on the spot, rather than waiting for the tech-ops team to develop a patch. All the data teams value this feature since data cleaning is a major challenge. The same process can also be performed with a tag-based approach, but it weighs down the container so much that it can affect the customer experience while making it much harder to install patches. Improving the quality of the collected data also increases the quality of the data that are transmitted, which ensures proper performance from the solutions receiving the data. In terms of reliability, meanwhile, server-side processing is also a way of reducing the discrepancies sometimes observed (due to browser constraints) between analytical and transactional data.

• Team agility: you are all familiar with the term “code freeze”, those times when no changes can be made to the site for fear of creating risks during critical periods. With a server-side approach, it is always the same data streams supplying the first server. When those streams need to be modified, corrected or transformed, the source code is left alone, since the data are manipulated asynchronously when transiting over the server. Patches can now be installed at any time, extra data can be sent, and data can also be modified. This is an especially useful advantage.

• Greater control over data processing compliance: just a single query to the server is required, which will subsequently process, adapt and divide the data among the different partners. The website publisher is therefore able to guarantee visitors that the stated data processing rules really will be applied. This will give the compliance teams an extra safeguard. Piggybacking is no longer possible.

• Operational quality of the site: this is one of the most important topics in the digital ecosystem, since all websites and mobile apps obey an industrial set of rules governing scalability and quality. There is nothing harder for a tech-ops team to deal with than a large mixed bag of tags with varying levels of compatibility, some of which have been deployed by third parties without the necessary precautions. The most common example involves slow loading pages, which are caused by large chunks of JavaScript code, JavaScript conflicts and security alerts in conversion funnels due to an unsafe tag.

• Improved website performance: reducing the volume of scripts needed on websites lowers the risk of affecting the customer experience, ramps up page loading times and allows techs to comply with internal standards and sometimes objectives. We know just how much performance powers the customer experience. A one-second delay can mean a 7% reduction in conversions (Strangeloop).

• Breaking free from the technical constraints linked to browsers: ad-blockers, with their blacklists that block calls to certain services from the browser, or simply cookie filtering mechanisms like Apple’s Intelligent Tracking Prevention (ITP). With server-side, calls are made from the server, beyond the reach of the ad-blockers. And as the service invoked on the server side can be hosted on a sub-domain of the website (rather than on a third-party domain), it is not intercepted by ITP-type mechanisms. A word of caution however… the server-side model does not exempt organisations from their obligation to comply with consent collection rules. Contrary to what we might hear, server-side does know how to share a consent signal.

• Team productivity: Team discovering server-side for the first time are sometimes caught off guard, since they did not think that a platform could help them take back control of the data streams. Ultimately, a server-side platform simplifies a number of data-based operations which, without server-side, are either flat-out impossible or extremely difficult to perform and require coordination between several teams. Some of the highly useful features that will turn you into a digital traffic controller include real-time quality control combined with alerting, real-time data enrichment with scores (CRM, predictive, etc.) and control over both data sources and destinations.

• Separation between collection and sharing duties: this is undoubtedly the most revolutionary benefit. Although data are still collected on the device, since that is where users interact with the website, mobile app or smart device, data transmission and the strategy for sharing and circulating data happen on the server. The JavaScript in the webpage can be trimmed down to the bare essentials, which will lighten the website, require less energy from the browser and deliver content faster. In many cases, code freezes are a thing of the past, and the teams can continue optimising their campaigns without having to interact with the website’s source code.

• Security and privacy: the server-side philosophy provides your users with a superior level of security and confidentiality by preventing any risk of their data being intercepted. The GDPR introduced the idea that brands do not own the data but are merely “leasing” the data. In addition, the risks are high. As such, building trust among users is even more essential, and any technology that protects access to data is heading in the right direction. Less piggybacking, fewer JavaScript files that reconfigure on the fly… these are just some of the advantages that should prove popular with the regulator.

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.