Construire des plates-formes publicitaires (présentation)

Cette présentation fait partie d'une série d'articles sur la création de plates-formes publicitaires sur Google Cloud. Comme ces plates-formes sont constituées de nombreux services différents et fournissent des services à de nombreux utilisateurs différents, cette série présente à la fois les options d'infrastructure partagées et spécifiques.

Comment fonctionne cette série

La série présente deux axes principaux :

Terminologie

Les termes suivants sont utilisés dans cette série et dans le secteur de la publicité :

  • Inventaire publicitaire : les espaces publicitaires proposés aux acheteurs.
  • Espace publicitaire : espace d'affichage d'une annonce sur une page Web ou mobile.
  • Tag d'emplacement publicitaire : petit morceau de code contenant des paramètres décrivant l'espace publicitaire.
  • Serveur publicitaire : technologie utilisée par les plates-formes de diffusion d'annonces pour diffuser des créations dans des espaces publicitaires au sein des propriétés d'un éditeur. Les serveurs publicitaires incluent généralement des fonctionnalités telles que la sélection, le comptage et la diffusion des créations.
  • Annonceur : organisation qui souhaite promouvoir un produit par le biais de différents médias, directement ou par l'intermédiaire d'autres acheteurs.
  • Audience : les utilisateurs (uniques) consultant ou utilisant la propriété d'un éditeur.
  • Segment d'audience : sélection basée sur un sous-ensemble de la taxonomie, qui génère un ensemble d'utilisateurs (uniques) que les annonceurs peuvent cibler.
  • Acheteur : achète des espaces publicitaires pour y afficher des créations. Les acheteurs peuvent être des réseaux, des agences ou des annonceurs.
  • Conversion : action prédéfinie par un annonceur qu'un utilisateur peut entreprendre sur la propriété d'un annonceur.
  • CPA : coût par action. montant qu'un acheteur paie par action. Les actions ou les conversions peuvent avoir des objectifs différents, par exemple acquérir autant d'utilisateurs que possible, fidéliser des clients clés très appréciés ou faire en sorte que des utilisateurs ciblés achètent quelque chose sur le site Web promu. Une action peut être le téléchargement d'un livre blanc, l'inscription à une newsletter ou un achat sur le site Web de l'annonceur.
  • CPC : coût par clic. Montant qu'un acheteur paie par clic sur une annonce.
  • CPM : coût par mille. Montant qu'un acheteur paie pour mille impressions.
  • Création : annonce présentée à l'utilisateur ciblé.
  • CTR  : taux de clics. Nombre de clics divisé par le nombre d'impressions.
  • CVR : taux de conversion. Nombre de conversions divisé par le nombre d'impressions.
  • DMP : les plates-formes de gestion des données fournissent des informations utilisateur supplémentaires aux acteurs des technologies publicitaires (ad tech). Ces plates-formes peuvent donner accès à un vidage de données ou, éventuellement, charger les données sur votre propre plate-forme si vous leur donnez accès à un espace de stockage tel que Cloud Storage.
  • Impression : lorsqu'une annonce est extraite de sa source et qu'elle est facturable.
  • Éditeur : dans le contexte de cette série, un éditeur possède un ensemble de propriétés numériques telles que des sites Web ou des applications mobiles, qui fournissent des espaces publicitaires pour l'hébergement de créations.
  • Propriété (de l'éditeur) : site Web, application ou jeu sur lequel l'éditeur fournit un espace publicitaire.
  • Fournisseur : offre des espaces publicitaires disponibles à l'achat pour le compte de plusieurs éditeurs.
  • Utilisateur ciblé : cible de l'annonce ; la personne qui est censée voir l'annonce.
  • Taxonomie : classification des attributs du public, généralement sous forme de hiérarchie.
  • Utilisateur (unique) : utilisateur pouvant être ciblé et connu ou considéré comme unique. Il est difficile de déterminer l'unicité et cette opération constitue souvent une conjecture "au mieux", dans la mesure où plusieurs personnes peuvent utiliser le même appareil ou que la même personne peut utiliser plusieurs appareils différents.

Les termes relatifs aux enchères en temps réel sont les suivants :

  • Place de marché publicitaire : marché publicitaire qui reçoit les demandes d'annonces des plates-formes côté vente (SSP). Après avoir reçu une demande, les SSP s'attendent à recevoir des annonces de toutes les plates-formes côté demande (DSP) accompagnées d'une enchère, avant de sélectionner l'offre gagnante et de la renvoyer du côté de la vente. Cette transaction doit être rapide. Par exemple, Google accorde environ 120 ms aux acheteurs pour renvoyer une offre.
  • DSP : les plates-formes côté demande reçoivent une demande d'annonce à laquelle elles doivent répondre dans un délai défini par la plate-forme SSP ou la place de marché publicitaire. Le délai imparti peut être de 100 ms seulement et aller jusqu'à quelques secondes. Les DSP décident si elles souhaitent faire une offre. Si c'est le cas, elles doivent sélectionner une annonce, déterminer un prix d'enchère et renvoyer leur offre à la place de marché.
  • RTB : enchères en temps réel. Processus consistant à exposer un inventaire publicitaire (espaces publicitaires) à des acheteurs programmatiques via un mécanisme d'enchères en ligne.
  • SSP : les plates-formes côté fournisseur (ou côté vente) font parfois partie d'un serveur publicitaire ou existent en tant qu'outil autonome recevant des demandes d'annonces émanant des éditeurs ou serveurs publicitaires. Les SSP envoient généralement une demande d'annonce aux places de marché publicitaires, mais elles peuvent aussi l'envoyer directement aux DSP. Une SSP peut enrichir cette demande avec un contexte d'audience supplémentaire, par exemple des données démographiques, pour augmenter la valeur de l'espace publicitaire. Les SSP s'attendent à recevoir l'annonce qui a remporté une enchère, qu'elles renvoient ensuite à l'éditeur ou au serveur publicitaire.

Terminologie supplémentaire utilisée spécifiquement dans cette série :

  • Backend : service ou base de données utilisés par l'interface utilisateur pour récupérer des données ou décharger un traitement, par exemple l'entraînement d'un modèle de machine learning.
  • Client : utilisateur de la plate-forme que vous fournissez.
  • Frontend ou interface : service traitant les requêtes externes.
  • Fonction : capacité spécifique offerte par un service exécuté sur une plate-forme.
  • Hors ligne : décrit tout processus qui ne fait pas partie de la prise de décision en temps réel.
  • En ligne : décrit tout processus devant s'exécuter dans le cadre d'un processus en temps réel.
  • Plate-forme : ensemble de services assurant l'une des fonctionnalités majeures telles que la diffusion d'annonces, la gestion de l'inventaire et les enchères.
  • Utilisateur de la plate-forme : éditeur, vendeur, acheteur, annonceur ou autre utilisateur employant une interface de plate-forme.
  • RPS : requêtes par seconde.
  • Service : une ou plusieurs fonctions proposées en tant qu'ensemble, généralement en tant qu'application unique.
  • Instance de travail : instance d'un service effectuant une tâche. Il y a généralement plusieurs instances de travail en parallèle.

Composants partagés

Différentes plates-formes publicitaires, par exemple les serveurs publicitaires, les plates-formes côté demande, les plates-formes côté offre et les places de marché publicitaires, possèdent un certain nombre de composants fonctionnels opérant de façon similaire, par exemple pour :

  • permettre aux utilisateurs de la plate-forme (fournisseurs, acheteurs) d'interagir avec celle-ci via le frontend ;
  • traiter les demandes, par exemple les demandes d'annonces ou les demandes d'enchères ;
  • gérer les événements et le cycle de vie des données tels que les impressions, les clics, les conversions et, le cas échéant, les enchères gagnées et perdues.

Le diagramme suivant illustre une architecture basée sur ces composants.

Architecture des composants partagés pour les plates-formes publicitaires

Interfaces utilisateurs

La plupart des plates-formes publicitaires nécessitent une interface client (frontend) généralement constituée d'une interface utilisateur s'appuyant sur une ou plusieurs bases de données différentes. L'interface doit répondre aux exigences suivantes :

  • Être accessible mondialement avec une latence garantissant une bonne expérience utilisateur.
  • Être hautement disponible pour que les clients puissent gérer leurs préférences à tout moment.
  • S'adapter à la demande, en tenant compte du fait que les clients sont susceptibles d'utiliser la plate-forme à leur gré et à tout moment (fuseaux horaires et base mondiale d'utilisateurs de la plate-forme).

En fonction de la plate-forme, ces interfaces peuvent être utilisées par les fournisseurs et/ou par les acheteurs, et faire partie intégrante d'un serveur publicitaire, d'une plate-forme DSP, SSP ou d'une place de marché publicitaire. Chaque interface offre des capacités d'administration différentes et gère des ressources publicitaires différentes (créations publicitaires, enchères, demandes, données démographiques, etc.).

Pour plus de détails sur ces concepts, consultez la section Interface utilisateur (Partie 1).

Demandes et sélection des annonces

La sélection d'annonce est effectuée par la plate-forme lorsqu'elle reçoit une demande. Il peut s'agir de demandes d'annonces générées à partir d'un tag d'emplacement publicitaire dans le contexte habituel de diffusion d'annonces. Les demandes peuvent également être des demandes d'enchères provenant d'une plate-forme SSP ou d'une place de marché publicitaire dans un contexte d'enchères en temps réel.

La partie sélectionnant une annonce doit :

  • être hautement évolutive : les requêtes ad-tech atteignent souvent des milliards de requêtes quotidiennes ;
  • être hautement disponible : compte tenu d'une telle ampleur, une seconde d'indisponibilité entraîne l'échec de requêtes et peut avoir des conséquences commerciales graves ;
  • offrir une latence minimale : les annonces doivent être diffusées aussi rapidement que possible aux utilisateurs ciblés, ce qui a une incidence sur la rapidité avec laquelle une annonce doit être sélectionnée. Avec les enchères en temps réel, la latence est une exigence critique, car les plates-formes SSP ou les places de marché publicitaires exigent que les enchères sur les offres leurs parviennent dans un délai spécifique parfois très court (jusqu'à 100 ms).

Les composants du processus de sélection des annonces sont les suivants :

  • un service frontend qui reçoit des demandes d'annonces ;
  • un ou plusieurs magasins de données utilisés par le service frontend pour prendre des décisions ;
  • un algorithme de sélection qui choisit l'annonce.

La section de traitement des requêtes (Partie 1) montre comment mettre en œuvre les services frontend, tandis que la section sur les modèles de stockage à lecture intensive (Partie 1) indique comment mettre en œuvre les magasins de données. Pour plus de détails sur les serveurs publicitaires et les enchères RTB, lisez les sections correspondantes dans les articles sur les serveurs publicitaires et les enchères (Partie 4).

Les plateformes DSP et les serveurs publicitaires utilisent la logique de sélection des annonces pour profiler l'utilisateur (unique), filtrer les campagnes et les annonces non pertinentes, puis sélectionner une annonce. En outre, pour les enchérisseurs, le processus de sélection implique également de décider d'enchérir ou non, de déterminer le prix de l'offre et éventuellement d'optimiser davantage leur offre. Vous pourrez trouver des liens pertinents pour ces deux cas de figure dans Options d'infrastructure pour les charges de travail de diffusion publicitaires (Partie 1).

Événements et gestion des données

La plupart des décisions prises dans une plate-forme publicitaire dépendent de données provenant de différentes sources, par exemple :

  • Les demandes d'annonces reçues par les interfaces des serveurs publicitaires.
  • Les demandes d'enchères reçues par les interfaces des DSP.
  • Les enchères gagnées ou perdues, reçues par les points de terminaison d'enchères gagnées des plates-formes DSP.
  • Les événements d'impression générés après la diffusion d'une annonce à l'utilisateur ciblé. Dans la plupart des cas, les impressions sont des impressions facturables. Les impressions facturables sont affichées et considérées comme visibles.
  • Les événements de clic, générés lorsqu'un utilisateur ciblé clique sur une annonce. Le nombre d'événements peut être inférieur au nombre d'impressions de plusieurs ordres de grandeur.
  • Les événements de conversion, générés lorsqu'un utilisateur ciblé effectue l'action souhaitée sur la propriété d'un annonceur. Le nombre d'événements est généralement inférieur au nombre de clics sur une annonce.
  • Les données semi-statiques gérées par les utilisateurs de la plate-forme.
  • Les données hors ligne provenant de l'analyse d'événements historiques.
  • Les données tierces, telles que les segments démographiques et les coûts associés, fournies par des sources externes telles que les DMP.

Au lieu d'un système basé sur des règles, le machine learning est un composant important qui peut tirer parti des données historiques pour entraîner des modèles en mode hors ligne, et des données en temps réel pour entraîner des modèles en ligne. Ces modèles peuvent ensuite être déployés localement afin que des composants ou des services individuels, tels que des serveurs publicitaires, puissent effectuer des prédictions en ligne. Les modèles peuvent également être utilisés pour renseigner des caches ou des magasins de paires clé-valeur qui diffusent les prédictions déjà réalisées.

La plate-forme doit pouvoir :

  • gérer des téraoctets de données quotidiennes à collecter, ingérer, traiter et stocker ;
  • s'adapter à des milliards d'événements quotidiens lors de la collecte, de l'ingestion, du traitement et du stockage des données ;
  • fournir des options pour le traitement hors ligne et en ligne en temps réel ;
  • exécuter des tâches de traitement du type machine learning dans un environnement distribué ;
  • transférer automatiquement les données pertinentes vers la base de données d'analyse, soit en temps réel via une diffusion en flux continu, soit ultérieurement par lots.

Pour des explications plus détaillées sur la gestion des jointures entre demandes d'enchères, résultats des enchères, impressions et clics, consultez la section Gérer les événements (Partie 3).

Serveurs publicitaires

Les serveurs publicitaires se composent généralement de composants partagés et de fonctionnalités de diffusion d'annonces, comme illustré dans le diagramme suivant.

Architecture des plates-formes publicitaires avec diffusion d'annonces

En tant que composant essentiel des serveurs publicitaires, la diffusion d'annonces nécessite :

  • Une latence faible : les annonces doivent être diffusées rapidement pour que les utilisateurs ciblés les voient de manière effective (si le défilement le permet) et pour garantir une bonne expérience de visualisation de l'annonce.
  • Une haute disponibilité : une fois qu'une annonce est sélectionnée, le fait de ne pas la diffuser en raison d'une panne de la plate-forme constituerait une perte de temps et d'argent.
  • Une bonne évolutivité : de nombreuses plates-formes doivent traiter des milliards de demandes d'annonces par jour et donc diffuser les milliards d'annonces correspondantes.

Même si certaines plates-formes DSP ou SSP diffusent des annonces depuis leur propre infrastructure, cet article part du principe qu'elles mettent en œuvre un serveur publicitaire dans le cadre de leur plate-forme. Pour en savoir plus sur la diffusion d'annonces, consultez la section Diffuser l'annonce sélectionnée à l'utilisateur ciblé (Partie 3).

Enchères

Le processus d'enchères est détaillé dans Options d'infrastructure pour les enchères RTB (Partie 4).

Les plates-formes DSP sont généralement constituées de composants partagés répondant aux exigences suivantes :

  • La réponse aux enchères doit avoir lieu dans un délai donné, ce qui rend la latence critique.
  • Les enchères sont calculées par demande, ce qui rend la logique de sélection d'annonce complexe. Cette logique additionnelle dans l'algorithme est généralement gérée par un service d'enchères supplémentaire. Pour plus de détails, consultez la section Enchères (Partie 4).

Le diagramme suivant fournit une vue d'ensemble d'une plate-forme côté demande (DSP).

Présentation globale d'une plate-forme côté demande

Étape suivante