Options d'infrastructure pour les enchères RTB (partie 4)

Cet article se concentre sur les tâches principales réalisées par une plateforme DSP (Demand-Side Platform ou plateforme côté demande). Ces tâches incluent la gestion des demandes d'annonces, l'utilisation de données intelligentes, les enchères et la gestion des événements. En général, toutes ces tâches doivent être effectuées rapidement (en moins de cent millisecondes environ). Le délai de latence est défini par la plateforme SSP (Sell-Side Platform ou plateforme côté vente) ou par un échange d'annonces. Le reste de ce document utilise un délai standard de 120 millisecondes (le contrat de niveau de service le plus courant de Google).

Cet article fait partie de la série suivante :

Consultez la présentation de la terminologie adtech utilisée dans cette série.

Présentation

Outre la vente directe aux annonceurs, les éditeurs peuvent également exposer leur inventaire publicitaire aux acheteurs programmatiques, qui achètent les impressions via un système d'enchères en temps réel (Real-Time Bidding ou RTB). Les éditeurs peuvent utiliser cette solution pour vendre leur inventaire restant ou pour réduire la charge générale d'administration. Dans un système RTB, l'inventaire de l'éditeur est mis aux enchères et les acheteurs soumettent des offres pour des impressions d'annonces.

Pour mettre aux enchères des annonces, les éditeurs font appel à des plateformes SSP qui s'appuient sur des places de marché publicitaires et des plateformes DSP pour renvoyer automatiquement l'annonce ayant remporté une enchère. Consultez la section relative aux enchères dans la présentation pour plus de détails.

Le diagramme suivant décrit une architecture possible pour un système DSP sans diffusion d'annonces intégrée.

Architecture possible pour un système DSP sans diffusion d'annonces intégrée

Pour plus d'informations sur les interfaces d'administration, telles que les gestionnaires de campagnes et d'enchères, consultez la section Interfaces utilisateur (dans la Partie 1).

Parmi les différences notables entre cette architecture et celle présentée pour le serveur publicitaire décrit dans la Partie 3, on trouve les éléments suivants :

  • La prédiction par machine learning se fait hors ligne. Les prédictions sont copiées dans un stockage en mémoire au moyen d'un LSH (Locality-Sensitive Hashing, c'est-à-dire hachage sensible à la localisation) pour générer des clés basées sur des combinaisons de caractéristiques uniques. Découvrez les autres options permettant d'accélérer le machine learning dans le contexte de diffusion dans l'article sur la diffusion des annonces (dans la Partie 3).
  • Les données à lire par les enchérisseurs sont stockées dans une base de données NoSQL en cluster et en mémoire pour des lectures rapides.

Considérations relatives à la plateforme

La section des considérations relatives à la plateforme (dans la Partie 1) couvre l'essentiel de vos besoins. Cependant, les enchérisseurs doivent remplir un certain nombre de conditions, comme indiqué dans cette section.

Emplacements géographiques

Pour minimiser la latence du réseau, localisez vos enchérisseurs à proximité des principales places de marché publicitaires. La proximité étroite minimise le temps aller-retour requis par la communication entre les enchérisseurs et la place de marché. Les places de marché exigent souvent que la réponse leur parvienne dans les 120 millisecondes environ après l'envoi de la demande d'enchères. Dépasser ce délai trop fréquemment peut affecter la capacité du DSP à enchérir :

  • À court terme, l'enchérisseur manquera l'enchère spécifique.
  • À moyen ou à long terme, la plateforme SSP peut décider de limiter la plateforme DSP et lui envoyer moins de demandes d'enchères.

Équilibrage de charge

Cloud Load Balancing permet de gérer plus d'un million de requêtes par seconde à faible latence, sur plus de 80 sites dans le monde. Votre interface est disponible derrière une seule adresse IP globale, ce qui simplifie la configuration DNS. Cloud Load Balancing est également intégré avec Cloud CDN.

Lorsque vous utilisez Kubernetes, un équilibreur de charge répartit le trafic sur les instances de VM, et kube-proxy programme iptables pour répartir le trafic sur les points de terminaison. Cette méthode peut affecter les performances réseau. Par exemple, le trafic peut arriver à un nœud qui ne contient pas de pod adéquat, ce qui ajoute un saut supplémentaire. Kubernetes Engine peut enregistrer ce saut supplémentaire à l'aide de clusters de VPC natif utilisant des adresses IP d'alias et de l'équilibrage de charge natif des conteneurs.

Bien que Cloud Load Balancing soit l'approche que nous recommandons, vous pouvez envisager de configurer votre propre équilibrage de charge sur Compute Engine ou GKE. Considérons, par exemple, ce cas d'utilisation de limitation du nombre d'expositions :

  • Un nœud de calcul de l'interface DSP traite une demande d'annonce.
  • Si la demande concerne un utilisateur (unique) connu, les compteurs de fréquence sont incrémentés pour refléter la fréquence à laquelle une annonce ou une campagne a été diffusée à cet utilisateur.
  • Si l'utilisateur atteint un seuil maximal défini par un plafond, aucune enchère supplémentaire n'est soumise pour cet utilisateur (unique) pendant une période donnée.

Étant donné que les enchérisseurs RTB traitent des milliards de demandes par jour, si vous n'établissez pas d'affinité entre les demandes d'enchères pour un utilisateur (unique) et le nœud de calcul de l'interface DSP traitant ces demandes, vous devez centraliser les événements entrants par région pour regrouper les compteurs par utilisateur (unique). L'architecture décrite précédemment dans la présentation illustre cette approche centralisée : des collecteurs ingèrent les événements, Dataflow les traite, et enfin les valeurs du type compteurs sont incrémentées via un nœud maître Redis.

Une approche tenant compte de l'affinité permet au même nœud de calcul de l'interface de traiter toutes les demandes d'annonces relatives au même utilisateur (unique). Le frontend peut entretenir un cache local de ses compteurs ce qui (dans ce cas d'utilisation précis) supprime la dépendance au traitement centralisé. Le résultat est une réduction à la fois de la charge de gestion et de la latence.

L'affinité entre un demandeur et le système de traitement est généralement établie dans l'équilibreur de charge via l'analyse des en-têtes de la requête entrante. Cependant, les places de marché publicitaires retirent généralement ces informations utilisateur des en-têtes, et nous devons donc traiter la charge utile de la demande. Étant donné que cela n'est pas pris en charge par Cloud Load Balancing, si vous envisagez de configurer votre propre équilibrage de charge, vous pouvez vous pencher sur l'utilisation d'un logiciel tel que HAProxy.

En fin de compte, vous devez prendre une décision : vous pouvez choisir un service géré offrant une infrastructure globale ou un système personnalisé qui peut être adapté à des cas d'utilisation spécifiques.

Connexion à vos fournisseurs

Suivant votre relation et votre proximité avec les places de marché publicitaires et les plateformes SSP, envisagez les options de connexion suivantes :

  • Configurez une interconnexion par l'intermédiaire de l'un de vos partenaires, et demandez à la place de marché publicitaire ou à la plate-forme SSP de faire pareil avec les mêmes partenaires. Cette option peut fournir un contrat de niveau de service pour la disponibilité, la réservation de débit et la réduction des coûts de trafic de sortie.
  • Si la place de marché publicitaire ou la plateforme SSP est également un client Google Cloud, envisagez de configurer l'appairage de réseaux VPC, car cela peut réduire vos coûts de mise en réseau. Notez que cette option a des implications en matière de sécurité.

Si vous souhaitez réduire davantage la latence, envisagez les options suivantes :

  • Utilisez des sockets de domaine Unix, s'ils sont compatibles, pour communiquer avec un magasin de données local.
  • Utilisez des protocoles tels que QUIC ou UDP lorsque cela est possible.
  • Utilisez des tampons de protocole pour une sérialisation et une désérialisation plus rapides des données structurées entre les flux de données.

Traiter les demandes d'enchères

Les demandes d'enchères sont reçues par une interface qui a les mêmes exigences de dimensionnement que celles décrites dans la section dédiée aux interfaces.

Les demandes d'enchères sont généralement sérialisées au format JSON ou protobuf et incluent souvent l'adresse IP, l'ID du bloc d'annonces, les dimensions de l'annonce, les informations relatives à l'utilisateur, le user-agent, le type d'enchère et la durée maximale de l'enchère. De nombreuses plateformes DSP et SSP utilisent la norme OpenRTB. Mais quelle que soit la norme ou la sérialisation utilisée, votre code frontal doit analyser la charge utile et extraire les champs et les propriétés requis.

Votre frontend peut rejeter la demande d'enchère en renvoyant une réponse sans offre (par exemple un code d'état HTTP 204) ou passer à l'étape suivante.

Enchères

Un enchérisseur effectue les tâches suivantes :

  • Correspondance utilisateur : identifier l'utilisateur (unique).
  • Sélection des segments : récupérer et sélectionner les segments de l'utilisateur (unique) et leur prix.
  • Décision d'enchérir : certaines enchères sont trop coûteuses et certaines demandes d'annonces peuvent ne correspondre à aucune campagne existante. Un enchérisseur doit pouvoir refuser une enchère. Ce refus permet d'économiser du temps de traitement et des ressources.
  • Sélection des annonces pertinentes :** **si l'enchérisseur décide de faire une offre, il doit également sélectionner une annonce. Sélectionner une annonce pertinente peut améliorer les chances de susciter un clic de l'utilisateur et éventuellement de générer une conversion.
  • Optimisation des enchères : un enchérisseur doit toujours essayer d'identifier le prix d'offre minimal qui lui permettra de remporter l'enchère.
  • Création d'une réponse à une enchère : à l'aide d'OpenRTB ou d'une application personnalisée, l'enchérisseur génère et renvoie une réponse d'enchère, sérialisée au format protobuf ou JSON. La réponse doit inclure des informations telles que l'URL de l'annonce, l'enchère et l'URL du point de terminaison d'enchère gagnée pouvant être appelée si l'offre remporte l'enchère.

Le machine learning facilite souvent ces tâches de réponse aux enchères. Par exemple, le ML peut être utilisé pour prédire le prix optimal et déterminer si l'offre peut être remportée avant de prendre une décision. Cet article se concentre toutefois sur les décisions d'infrastructure. Pour plus de détails sur l'entraînement et l'utilisation de modèles de ML, consultez les articles suivants :

  • Éléments nécessaires pour créer et héberger des modèles, dans la section Machine learning (dans la Partie 2).
  • Considérations relatives à la latence lors de la diffusion de prédictions, dans la section diffusion de machine learning (dans la Partie 2).

Correspondance utilisateur

Il existe deux méthodes couramment utilisées pour identifier un utilisateur (unique) :

  • Pour la publicité sur mobile, vous pouvez utiliser un identifiant d'appareil réinitialisable. Les applications natives construites sur les plateformes Android ou iOS ont accès à l'identifiant d'appareil réinitialisable.
  • Pour la publicité sur le Web, les plateformes publicitaires peuvent utiliser des cookies afin de stocker un identifiant d'utilisateur réinitialisable. Cependant, les cookies ne peuvent être lus que par le domaine qui les a créés, ce qui complique le partage de l'identifiant entre plateformes. Les acteurs ad-tech peuvent créer des tables pour faire correspondre des cookies indépendants et obtenir ainsi une vision plus globale d'un client.

Les tables de correspondance peuvent être utilisées entre les plateformes SSP, DSP, DMP et les serveurs publicitaires. Chaque partenariat met en œuvre un processus différent, même si tous ces processus demeurent assez similaires.

Dans les enchères en temps réel, le processus de mise en correspondance des cookies a souvent lieu bien avant que la plateforme DSP reçoive une demande d'enchère. Soit la plateforme DSP lance une demande de correspondance de cookie auprès de la plateforme SSP pour l'impression d'une autre annonce, soit la SSP initie une correspondance de cookie avec la DSP ("pixel push") pour l'impression d'une annonce sans rapport. Le plus souvent, la DSP lance la synchronisation qui ne se produit pas nécessairement sur la propriété d'un éditeur, mais sur la propriété d'un annonceur. Le fonctionnement de la correspondance des cookies dans les enchères en temps réel est expliqué sur le site Web de Google Ad Manager et également de manière très détaillée sur le Web.

Les SSP et les DSP doivent se mettre d'accord sur quelle plateforme héberger la table de correspondance. Cet article part du principe que la DSP héberge le magasin de données de correspondance utilisateur. Ce magasin de données doit :

  • récupérer la charge utile correspondant à une clé spécifique en quelques millisecondes au plus ;
  • être hautement disponible dans une région ;
  • être présent dans toutes les régions ciblées afin de minimiser la latence réseau ;
  • gérer des milliards de lectures par jour ;
  • traiter des écritures rapides lors de la mise à jour des compteurs courants.

Les bases de données NoSQL conviennent parfaitement à une telle charge de travail, car elles peuvent être mises à l'échelle horizontalement pour gérer des charges lourdes et extraire des lignes individuelles extrêmement rapidement.

Si vous souhaitez un service entièrement géré capable d'extraire des valeurs sur la base d'une clé spécifique en quelques millisecondes, envisagez d'utiliser Cloud Bigtable. Ce service fournit une haute disponibilité, et son RPS ainsi que son débit s'adaptent de façon linéaire au nombre de nœuds. Au niveau conceptuel, les données sont stockées dans Cloud Bigtable dans un format tel que celui-ci :

key id_interne créé
ssp_id#source_id dsp_id 123456789

Sélection de segments

À ce stade du processus d'enchère, le système a reçu une demande d'annonce, l'a analysée pour en extraire l'ID utilisateur dans la plateforme SSP et a mis celui-ci en correspondance avec l'ID utilisateur interne à la DSP.

Avec une autre recherche, le système peut extraire des segments utilisateur du magasin de profils utilisateurs (uniques), les classer par prix et les filtrer pour identifier le segment le plus approprié. L'exemple suivant montre le résultat d'une telle recherche. (L'exemple est simplifié par souci de clarté.)

clé segments à jour
dsp_id [ {‘dmp1':{‘segment':'a',‘type':‘cpm',‘price': 1}} {‘dmp1':{‘segment':'b',‘type':‘cpm',‘price': 2}} {‘dmp2':{‘segment':'c',‘type':‘cpm',‘price': 1.5}} ] 1530000000

Suivant votre logique de classement et de filtrage, vous pouvez souhaiter promouvoir certains champs personnels (tels que le nom du fournisseur de données) dans la clé. Une conception de clé efficace peut contribuer à l'évolutivité et à réduire la durée des requêtes. Pour obtenir des conseils sur l'approche à adopter pour la conception de clé, consultez la section Choisir une clé de ligne dans la documentation de conception d'un schéma Cloud Bigtable.

Bien que cet article utilise Cloud Bigtable comme exemple de service pour la lecture de segments et pour la mise en correspondance des identifiants d’utilisateur, les magasins en mémoire tels que Redis ou Aerospike peuvent offrir de meilleures performances, même si cela a un coût de fonctionnement plus élevé. Pour plus de détails, consultez la section Modèles de stockage à lecture intensive (dans la Partie 1).

Pour avoir accès à davantage de données utilisateur externes, les plateformes DSP collaborent souvent avec des plateformes de gestion de données (Data Management Platforms ou DMP) avec lesquelles elles mettent en œuvre des techniques de mise en correspondance utilisateur similaires à celles utilisées avec la plateforme SSP.

Une DSP exploite deux sources de données principales pour profiler l'utilisateur :

  • Informations propres à l'utilisateur : une DSP peut avoir déjà, par le passé, reconnu un utilisateur sur la propriété d'un annonceur. La DSP a pu recueillir des informations sur l'utilisateur, telles qu'un cookie ou un ID d'appareil, dont elle peut maintenant tirer parti pour profiler l'utilisateur.
  • Informations tierces sur les utilisateurs : si une DSP fonctionne avec un nombre limité d'annonceurs, elle peut identifier des utilisateurs (uniques) en exploitant des données émanant de plates-formes DMP qui fonctionnent avec de nombreuses propriétés sur Internet ou dans des applications. La mise en correspondance des utilisateurs s'effectue soit à partir de l'ID utilisateur fourni par l'éditeur, partagé par la DSP et la DMP, soit directement entre la DMP et la DSP. Dans ce dernier cas, la DSP charge régulièrement des données hors ligne à partir des DMP avec lesquelles elle maintient également une table de correspondance.

Les données tierces peuvent être chargées de manière récurrente depuis un emplacement externe vers Cloud Storage, puis chargées dans BigQuery. Une autre solution consiste à charger les données en temps réel sur le point de terminaison que vous exposez et qui sert de frontal à un système de messagerie.

Traiter les événements

L'ingestion et le stockage des événements sont abordés dans la section Gérer les événements. Dans le contexte RTB, les événements supplémentaires suivants sont également collectés :

  • Demandes d'enchères : elles sont similaires aux demandes d'annonces et sont envoyées à un point de terminaison que vous fournissez à la plateforme SSP ou à la place de marché publicitaire.
  • Enchères gagnées : lorsque la plateforme DSP remporte une enchère, la plateforme SSP ou la place de marché publicitaire renvoie une notification à un point de terminaison d'enchère gagnante, préalablement défini par la DSP et inséré dans sa réponse.
  • Enchères perdues : les plateformes SSP ou les places de marché publicitaires peuvent informer les DSP quand leur offre n'a pas été retenue, mais elles offrent rarement d'autres informations. Certaines plates-formes SSP, telles que la place de marché de Google, envoient ces informations de retour dans la demande d'enchère suivante.

Ces événements sont utilisés dans différents services sur la plateforme pour effectuer les tâches suivantes :

  • Mettre à jour les compteurs : à l'instar du processus de sélection des annonces, certains compteurs gérant, par exemple, des plafonds ou des budgets restants, permettent de filtrer les campagnes ou les annonces non pertinentes.
  • Prendre des décisions relatives aux enchères : en utilisant l'historique des enchères remportées et perdues, ainsi que les prix, le système améliore son processus de décision d'enchérir ou non, et optimise les prix de ses offres.
  • Fournir des données pour la génération de rapports : comme pour la diffusion d'annonces, les utilisateurs veulent connaître les performances de leurs enchères et de leurs annonces.

Fusionner les données d'offres et d'enchères remportées

Votre enchérisseur doit prendre des décisions pour chaque demande d'enchère. Cela diffère de la diffusion d'annonces, où les prix sont calculés pour un lot d'annonces. Pour cette raison, fusionner les données le plus rapidement possible peut améliorer les décisions en matière d'offre.

Lors du traitement des événements de demandes d'enchères et de mise aux enchères, tenez compte des points suivants :

  • En matière de diffusion des annonces, il existe une différence notable, de plusieurs ordres de grandeur, entre le nombre d'impressions, de clics et de conversions. Dans le contexte RTB, une demande d'enchère, contrairement à une demande d'annonce, ne garantit pas une impression (votre enchérisseur doit enchérir et gagner cette enchère).
  • Le temps écoulé entre une demande d'enchère remportée et une impression est de l'ordre de quelques millisecondes.
  • Le temps écoulé entre une impression et un clic est de l'ordre de quelques secondes au plus.
  • Le temps écoulé avant une conversion peut atteindre quelques minutes, jours, voire semaines.

Ces cas de figure peuvent causer quelques problèmes lorsque vous fusionnez des données, car votre système doit attendre un événement qui ne se produira peut-être jamais (par exemple, un clic après une impression). Votre système peut également devoir attendre plus d'une journée ou d'une semaine avant qu'un événement ne se produise, par exemple une conversion à la suite d'un clic ou une conversion non liée à un clic (appelée conversion après affichage). Enfin, le système peut avoir remporté une enchère qui n'a pas généré d'impression rendue et facturable.

Lors de la construction de votre système, partez du principe que :

  • les données sont ingérées en temps réel via un système de messagerie tel que Pub/Sub ;
  • votre outil de traitement des données, par exemple Dataflow, peut gérer quelques millisecondes, voire quelques secondes d'attente pour une impression ou un clic après avoir remporté une demande d'enchère ;
  • le système doit pouvoir fusionner toutes les demandes d'enchères, les réponses aux enchères, les enchères remportées, les impressions, les clics et les conversions ;
  • l'identifiant de l'enchère est commun à tous les événements ;
  • les clics et les conversions qui se produisent au-delà d'un délai prédéfini peuvent être ignorés, par exemple lorsqu'il s'est écoulé trop de temps pour savoir avec certitude que le clic ou la conversion est lié à une enchère spécifique.

Pour déterminer le lieu où vous réalisez la fusion (dans le pipeline de données ou après que les données ont été envoyées au système de stockage), vous devez identifier si vous devez fusionner les données immédiatement ou si le processus de fusion peut attendre. Si vous décidez de fusionner les données immédiatement, vous pouvez mettre en œuvre un processus calqué sur celui-ci :

  1. Lire l'événement dans Pub/Sub ou Apache Kafka.
  2. Analyser et extraire les informations, en particulier l'ID de l'enchère.
  3. Effectuer une recherche par clé dans Cloud Bigtable pour voir s'il existe déjà des événements associés à cet identifiant d'enchère.
  4. Écrire l'événement dans Cloud Bigtable s'il n'y a pas d'événement préexistant.
  5. Fusionner l'événement avec les données existantes s'il y a des événements préexistants.
  6. Écrire l'événement dans BigQuery pour les analyses d'historique.
  7. Écrire l'événement dans un magasin de données rapide directement si le récepteur existe, ou écrire l'événement dans un système de messagerie permettant à un groupe de récepteurs de lire et d'écrire dans le magasin de données rapide.

Le diagramme suivant illustre ces étapes.

Architecture distribuée pour la gestion des événements et des demandes d'enchères

Lorsque vous mettez en œuvre cette solution, tenez compte des éléments suivants :

  • En raison de la nature distribuée de Dataflow et Pub/Sub, il est possible que les données ne soient pas ordonnées. Cependant, cela n'a pas d'importance car l'objectif est de réaliser une fusion complète dès que possible.
  • Vous devez effectuer votre propre récupération de mémoire dans BigQuery à l'aide d'une instruction delete (cet aspect est largement simplifié dans le diagramme). Vous pouvez planifier cette tâche à l'aide de Cloud Composer ou de tâches Cron.
  • Utilisez la fonctionnalité d'expiration de Cloud Bigtable pour supprimer les clics ou les conversions se produisant après une période prédéfinie.

Vous pouvez également améliorer le workflow en utilisant la fonctionnalité de traitement opportun et avec état proposée dans Apache Beam. Vous pouvez alors obtenir des événements ordonnés sans utiliser Cloud Bigtable.

Si vous décidez de fusionner les données hors ligne parce que vous pouvez tolérer un délai, le processus se présente comme suit :

  1. Lire l'événement dans Pub/Sub ou Apache Kafka.
  2. Analyser et extraire les informations, en particulier l'ID de l'enchère.
  3. Insérer les enregistrements traités dans un entrepôt de données tel que BigQuery.
  4. Fusionner les données à l'aide de l'ID d'enchère et des horodatages les plus récents tous les N intervalles, N étant un nombre prédéfini de secondes, minutes, heures ou jours. Pour cette tâche, vous pouvez faire appel à Cloud Composer ou à des tâches Cron.
  5. À l'aide de Cloud Composer ou de tâches Cron, supprimer les données obsolètes (les données présentant l'horodatage le plus ancien par ID d'enchère et par type d'événement), tous les N intervalles.

Exporter les données à proximité des enchérisseurs

Pour les options d'infrastructure relatives à la diffusion de données, consultez la section Modèles de stockage à lecture intensive.

Bien que les concepts d'exportation des données soient similaires à ceux de la diffusion d'annonces, les enchérisseurs doivent renvoyer leur réponse à l'enchère dans un délai prédéfini. Pour cette raison, certains enchérisseurs peuvent préférer utiliser des magasins de données capables de gérer des lectures et des écritures en moins d'une milliseconde, même si ces magasins nécessitent davantage de temps système. Les enchérisseurs utilisent généralement Redis avec, en complément, des esclaves locaux ou un service Aerospike régional. Pour en savoir plus, consultez les options d'infrastructure pour l'exportation des données, qu'il s'agisse d'agrégations en temps réel ou d'analyses hors ligne.

Étapes suivantes