Server-side Migration: why proceed step by step

Migrating to the server-side must be done gradually, partner by partner. The aim is to give yourself time to “test and learn” and to work on the quality of the data.

No, opting for server-side does not mean that all partners have to be migrated in a hurry. On the contrary, everything is converging today to encourage companies to follow a progressive approach. There are at least two reasons for this. Firstly, partners are far from being ready for a server-side implementation of tags. Secondly, it is highly recommended to give yourself time to learn.

As a result, for at least the next few months, tag management will be neither totally client-side nor totally server-side but… hybrid. How to proceed? First of all, by preparing your organisation for server-side. Then, by following these steps for implementation.

Step #1: Choose your architecture

Two methods are possible today to implement a server-side collection: APIs and the “master tag” – note that these two methods can be combined. The first is to use the server-side APIs provided by a platform such as Commanders Act to transmit all the events expected in the context of your use cases. To achieve this, take the time to catalogue your events for each of these cases.

As for the “master tag” method, it is so named because, even in server-side, it involves the deposit of a tag – but only one tag. It is this tag that collects all the events required by your scenarios within the browser in order to communicate them to the server-side solution for processing.

Here, a precaution must be taken: this tag must be deposited in first-party mode. Otherwise, browsers such as Safari or Firefox (and Chrome next year) inhibit this tag, which leads to data loss. Fortunately, via the subdomain delegation process, it is quite possible to position the Commanders Act master tag as a first-party tag.

Step #2: Working on data quality

This stage must be the object of all attention. The data collected via the server-side represents your “data hub”: the data base on which your partners’ activations will be based. This is also the right time to review the datalayer and the catalogue of events to be integrated. The aim is to improve the collection of data, of course, but also to anticipate the deployment of new use cases.

This work should be an opportunity to “receive the data”. There are two objectives: firstly, to ensure that consent is properly propagated so that the information disseminated to the various partners is in line with the user’s preferences. Secondly, ensure that the data is standardised, and therefore formatted so that it can be used.

This is why Commanders Act provides several tools (source data quality or live events inspector) to take the stock of the data sent to the data hub and check its quality. This work can be carried out in real time and the platform provides the necessary tools, in particular with a “data cleansing” function that enables erroneous data to be corrected automatically before being sent to partners.

Taking the time to work on data quality is both a prerequisite and a benefit. A prerequisite because, without quality data, the server-side mechanism quickly jams. A benefit, because this increased quality also generates more precise activations, and therefore a tangible return on effort and more effective campaigns.

Step #3: Migrate a first partner

Is the collection method agreed? The data has been worked on? It is time to migrate a first partner, if possible a “good candidate”, i.e. a partner who has well documented the migration process. This is the case, for example, with Facebook, which, like others, recommends keeping both data streams, client-side (from the classic pixel) and server-side (from the “Conversion API”), for an observation period.

This period will be used to control the quality of the distributed data. To this end, Commanders Act offers several monitoring and alert tools in its platform, so that this “test and learn” work can be carried out with peace of mind.

Once the server-side connector has been deployed , a period of observation is required – say two weeks – to ensure that no service disruption occurs. After this period, the client-side tag can be deactivated to retain only the server-side activation.

The good news is that this work mechanically benefits the other partners and therefore helps to speed up subsequent migrations. Tap into the Commanders Act destination catalogue and plan these migrations.

To successfully complete the server-side migration, don’t lock yourself into a project management system pressurised by deadlines. Prioritise the migration of partners according to your business imperatives and involve the media teams in the various stages of the project. Above all, give yourself time to work on the quality of your data and to test the implementations, one partner at a time. Your data deserves this time and attention.

Why server-side will become your best ally? Find out in our white paper.