Microsoft Monetize - Magasin de cookies côté serveur

Les données utilisateur, telles que les segments et le nombre de fois où un utilisateur a vu un élément créatif particulier, constituent une partie importante du processus de ciblage et de prise de décision pour la plupart des campagnes. Pour cette raison, nous devons conserver des données cohérentes et complètes sur un utilisateur, quel que soit l’endroit, le moment et la façon dont nous les « voyons » dans le paysage Internet.

Traditionnellement, les données utilisateur sont stockées dans le cookie du navigateur de l’utilisateur, mais dans de nombreuses enchères, Microsoft Advertising n’a pas accès au navigateur. (Par exemple, lorsque nous sommes passés à un appel publicitaire côté serveur à partir d’un échange.) Alors, comment reconnaître cet utilisateur et accéder à ses données utilisateur pertinentes sur plusieurs sites et plateformes ? Pour ce faire, nous avons conçu le magasin de cookies Microsoft Advertising, un système de stockage de données utilisateur côté serveur. Avec le magasin de cookies et la synchronisation des utilisateurs, nous sommes en mesure de :

• Synchronisez les données d’ID utilisateur et de fréquence entre tous les partenaires fournisseurs Microsoft Advertising.

• Stockez les données de cookies, à la fois les vôtres et les nôtres, côté serveur, afin qu’elles soient accessibles à chaque appel publicitaire.

  Remarque

  Pour obtenir une liste exacte des cookies définis par la plateforme Microsoft Advertising et des informations détaillées sur ce qu’ils contiennent, consultez Cookies.

Mappage des ID utilisateur

Si nous avions une étiquette de Microsoft Advertising sur chaque page pour chaque impression passée par notre plateforme, nous aurions accès au cookie pour chaque utilisateur que nous voyons. Mais on ne le fait pas.

Supposons que l’inventaire soit transmis par le biais d’une intégration côté serveur à Google Ad Manager, et que Google Ad Manager ait accès au cookie, mais pas nous. Lorsque Google Ad Manager nous transmet un appel publicitaire, il ide l’utilisateur en tant que ABC. Yahoo Ad Exchange appelle l’utilisateur 123 et AdMeld utilise 007. Nous devons savoir qu’il s’agit du même utilisateur afin que nous puissions appliquer toutes les données pertinentes et réglementer correctement le ciblage de fréquence.

La méthode exacte de mappage d’ID diffère selon notre partenaire d’intégration. Nous pouvons effectuer le mappage via un pixel sur la page de l’éditeur ou en mettant une annonce à l’utilisateur. Nous pouvons stocker le mappage d’ID utilisateur dans notre base de données ou il peut le stocker dans le sien. Voici quelques exemples d’intégrations.

• Ad Network X stocke le mappage dans sa base de données. Le réseau X place un pixel sur les pages de ses éditeurs, y compris mysite.com. Lorsqu’un utilisateur visite mysite.com, le pixel se déclenche et Microsoft Advertising peut marquer l’utilisateur comme étant 1938 dans le cookie du navigateur de l’utilisateur. Le pixel redirige également vers le réseau X pour leur indiquer que Microsoft Advertising appelle cet utilisateur 1938 afin qu’il puisse être mappé à l’ID utilisateur du réseau et stocké pour une utilisation ultérieure.
• Exchange Y stocke le mappage dans leur base de données, mais ils ne placent pas notre pixel sur la page. Au lieu de cela, la première fois que nous servons une publicité à cet utilisateur, nous lisons un pixel usersync qui ajoute un ID utilisateur unique au cookie de navigateur de l’utilisateur et redirige pour passer l’ID utilisateur à Exchange Y.
• Pour Exchange Z, Microsoft Advertising stocke la carte d’ID. Dans ce cas, la première fois que Microsoft Advertising envoie une publicité à un utilisateur, nous lisons un pixel à Exchange Z, qui nous transmet ensuite son ID utilisateur, que nous stockons. Désormais, sur les futures impressions, Exchange Z nous envoie son ID d’utilisateur, et nous pouvons le rechercher dans notre base de données.

Synchronisation entre centres de données

L’une des choses sur laquelle nous nous concentrons est de s’assurer que toutes les données utilisateur sont disponibles dans tous les centres de données Microsoft Advertising. Nous avons actuellement des centres de données à Los Angeles, dans la région métropolitaine de New York et à Amsterdam, et les utilisateurs sont acheminés vers le centre topologiquement le plus proche. Cela signifie que les utilisateurs au milieu de la États-Unis peuvent être parfois acheminés vers New York et parfois Los Angeles. Ou, en cas de problème réseau dans un centre de données, tout le trafic est routé vers l’autre centre de données.

Supposons que nous avons un utilisateur dans le Dakota du Nord qui voit un créatif six fois. Trois de ces fois, l’utilisateur a été routé vers le centre de données de New York, et trois de ces fois il a été routé vers LA.

Sur la septième impression, l’utilisateur est acheminé vers New York. Nous devons savoir qu’ils ont déjà vu cette création six fois, au lieu des trois fois qui ont été enregistrés à New York. Par conséquent, nous avons conçu nos centres de données LAX et NYM pour se synchroniser en transmettant des données de segment d’avant en arrière, tandis qu’AMS conserve ses propres cookies exclusivement.

Stockage de données de segment côté serveur

Les données de segment, qu’elles soient transmises par le biais d’un segment ou d’un transfert hors connexion, sont stockées dans le magasin de cookies au lieu du navigateur de l’utilisateur. De cette façon, les données de segment sont disponibles dans toutes les sources d’inventaire, les échanges tiers et les agrégateurs d’inventaire.

Vous pouvez également mettre à jour les données de segment à tout moment sans avoir accès à l’utilisateur via notre API Batch Segment.

Rubrique connexe

Mappage d’ID utilisateur avec getUID et mapUID