Options d'infrastructure pour les serveurs publicitaires (partie 3)

Cet article décrit les fonctionnalités et les produits de Google Cloud que vous pouvez utiliser lors de la création de votre plate-forme de diffusion d'annonces.

Cet article fait partie de la série suivante :

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

La diffusion d'annonce consiste à afficher auprès d'un client l'annonce (généralement, la plus pertinente) d'un des nombreux annonceurs disponibles, sur la propriété d'un éditeur. Cette propriété peut prendre la forme d'un site Web, d'une application ou d'un jeu.

La complexité d'un serveur publicitaire dépend des fonctionnalités qu'il propose. Pour reprendre les termes utilisés dans le secteur, un serveur publicitaire est un outil permettant aux éditeurs et aux annonceurs de gérer leurs campagnes, leurs annonces et le trafficking. Il ne se contente pas d'afficher une annonce statique comme un panneau publicitaire sur le bord d'une route. La diffusion d'annonces est effectivement sa fonction principale, mais les plates-formes adtech comme Google Ad Manager offrent bien plus de fonctionnalités et d'avantages.

Cet article explique comment créer une plate-forme de diffusion d'annonces solide comprenant les fonctions principales suivantes :

  • Gestion des campagnes, des comptes, de la facturation et des rapports
  • Sélection de l'annonce la plus pertinente
  • Affichage de l'annonce auprès de l'utilisateur ciblé
  • Gestion des événements tels que les impressions, les clics ou les conversions
  • Publication des opérations pertinentes dans les datastores analytiques

Les serveurs publicitaires traitent généralement des dizaines de milliers de demandes d'annonces par seconde, chaque réponse étant envoyée en quelques millisecondes. Pour pouvoir répondre à autant de demandes si rapidement, une solution de diffusion d'annonces doit satisfaire des exigences essentielles en matière de disponibilité, d'évolutivité et de faible latence. Aucune solution de serveur unique ne peut remplir toutes ces conditions : c'est pourquoi cet article examine les implications relatives à la conception d'un système distribué.

Il existe deux types de serveurs publicitaires :

  • Côté vente : ces serveurs permettent aux éditeurs d'optimiser leurs revenus publicitaires en gérant leurs annonceurs directement depuis l'interface utilisateur du serveur publicitaire. Un serveur côté vente héberge fréquemment les annonces, mais peut également héberger les références à une annonce. En outre, certains serveurs publicitaires proposent une interface utilisateur en libre-service aux acheteurs.
  • Côté achat : ces serveurs permettent aux annonceurs, aux services marketing ou aux agences publicitaires de gérer les mises à jour de leurs annonces. Plutôt que de fournir aux éditeurs les annonces réelles, ces utilisateurs fournissent un extrait de code qui communique avec le serveur publicitaire côté achat pour récupérer l'annonce.

Le schéma ci-dessous illustre l'architecture d'un système de serveur publicitaire possible.

Implémentation possible d'un système de diffusion d'annonces

Les principaux points d'entrée de la plate-forme du serveur publicitaire sont déterminés par Cloud Load Balancing :

  • pour demander l'annonce ;
  • pour récupérer la création ; (les annonces sont extraites du cache Cloud CDN le plus proche) ;
  • pour suivre des événements tels que les impressions ou les actions/clics de l'utilisateur (unique).

Les requêtes adressées à l'équilibreur de charge sont consignées via la journalisation et la surveillance de l'équilibrage de charge HTTP(S) ou via un code personnalisé s'exécutant sur les collecteurs. Elles sont publiées sur Pub/Sub avant d'être traitées par Dataflow à des fins d'analyse et de profilage utilisateur.

Les nœuds de calcul qui diffusent les demandes s'appuient sur les éléments suivants :

  • Information sur le budget
  • Profils utilisateur (uniques)
  • Détails de la campagne
  • Compteurs
  • Modèles entraînés à faire des sélections

Certains des éléments ci-dessus devront être adaptés à vos besoins spécifiques :

  • Vous n'avez peut-être pas besoin de plusieurs bases de données différentes pour la sélection d'annonces, et vous souhaitez peut-être trouver un compromis entre les bases de données hiérarchiques et les bases de données relationnelles pour des raisons de simplicité. Dans ce cas, vous pouvez utiliser Cloud Bigtable ou Cloud Spanner.
  • Vous avez peut-être besoin d'une latence de lecture inférieure à la milliseconde lors du traitement d'une demande d'enchère et de pouvoir accepter des coûts opérationnels supplémentaires. Dans ce cas, vous pouvez si possible utiliser des bases de données en mémoire régionales tierces avec réplication locale.
  • Vous souhaitez peut-être utiliser les collecteurs d'événements configurés sur des VM préemptives pour réduire les coûts. Si vous n'avez pas besoin du traitement en ligne, vous pouvez enregistrer vos événements à l'aide de Cloud Logging et les analyser avec BigQuery.

Gérer les campagnes

Pour gérer les campagnes, les annonceurs ont besoin d'un frontend utilisateur composé au minimum d'une interface Web et d'une interface utilisateur (UI). Les annonceurs doivent également fournir des fonctionnalités de création de rapports. Pour les options recommandées, consultez la section Frontend utilisateur (dans la partie 1).

La hiérarchie partagée des ressources configurée via cette interface utilisateur comprend les annonceurs, les campagnes, les budgets, les créations et la facturation. Lorsque vous créez cette hiérarchie, le système enregistre un ensemble de règles qui font partie du processus décisionnel de sélection de l'annonce. Ces données sont stockées dans le magasin de gestion des métadonnées (voir la partie 1).

La plupart des serveurs publicitaires traitent des milliards de demandes d'annonces par jour. Il est déconseillé de faire peser cette charge directement sur la base de données qui stocke les métadonnées appliquées à ces règles d'annonceur (sauf si vous décidez d'utiliser Cloud Spanner). Au lieu de cela, envisagez l'une des options couvertes par les modèles de stockage à lecture intensive (voir la partie 1).

Sélectionner l'annonce la plus pertinente

Recevoir et analyser les demandes d'annonces

Les demandes sont envoyées via un tag d'emplacement publicitaire placé sur la propriété de l'éditeur. Ce tag se présente comme suit :

<script src="[URL_TO_YOUR_AD_SERVER]?key=value"></script>

Lorsque le tag est chargé, une demande d'annonce est envoyée au serveur publicitaire. La demande contient des informations telles que les en-têtes HTTP, la valeur user-agent, le contexte de la page, l'adresse IP, les informations de ciblage, un éventuel identifiant utilisateur, ainsi que les détails de l'annonce, y compris sa taille.

Le serveur publicitaire doit fournir un point de terminaison HTTP [URL_TO_YOUR_AD_SERVER] pour recevoir et traiter ces demandes. Les options recommandées sont détaillées à la section Traiter des requêtes (dans la partie 1).

Établir le profil de l'utilisateur

La méthode de sélection des annonces diffère selon les serveurs publicitaires. Cette logique dépasse le cadre de cet article. Toutefois, la compréhension de l'utilisateur est essentielle pour afficher des annonces pertinentes. Cette solution suppose qu'une classification avancée des utilisateurs est requise.

Un serveur publicitaire acceptant de nombreux éditeurs est susceptible de reconnaître le même utilisateur sur des propriétés différentes. L'identifiant utilisateur (unique) peut prendre la forme d'un cookie Web ou d'un ID d'appareil mobile que l'utilisateur peut remplacer.

Le serveur publicitaire peut enrichir les informations fournies par la demande d'annonce (adresse IP, informations relatives à la page, etc.) avec cet identifiant utilisateur pour effectuer une recherche dans un datastore. Le serveur doit pouvoir rechercher un ID utilisateur parmi des millions de lignes pouvant représenter des téra-octets de données. Il doit renvoyer une réponse en quelques millisecondes et minimiser les coûts de gestion.

Le magasin de profils utilisateur (uniques) (voir la partie 1) fournit un aperçu de ce processus. Bien que vous puissiez utiliser n'importe quelle option mentionnée dans cet article, nous vous recommandons d'utiliser Cloud Bigtable pour la diffusion d'annonces, pour les raisons suivantes :

  • Il s'agit d'une base de données NoSQL orientée colonnes pouvant stocker des péta-octets de données.
  • Il récupère les lignes dans un délai de l'ordre de la milliseconde.
  • Il accepte la réplication régionale.
  • Il s'agit d'un service entièrement géré.

Sélectionner des campagnes et des annonces

Le processus de sélection des annonces s'effectue en quelques étapes, comme décrit à la section Sélection des annonces (dans la partie 1) :

  1. Établissez le profil de l'utilisateur à l'aide du magasin de profils utilisateur (uniques) (voir la partie 1).
  2. Sélectionnez les campagnes et les annonces correspondantes en utilisant une copie des données du magasin de gestion des métadonnées (voir la partie 1). Les copies sont réalisées à l'aide de l'un des modèles de stockage à lecture intensive (voir la partie 1).
  3. Filtrez les campagnes et les annonces pertinentes à l'aide des magasins de contexte (voir la partie 1).
  4. Sélectionnez une annonce.

Une fois que le serveur publicitaire a sélectionné les campagnes et les annonces correspondant aux segments d'utilisateurs, il les valide par rapport aux valeurs des données du magasin de contexte (limitation du nombre d'expositions, listes noires ou budget épuisé, par exemple). Le serveur publicitaire sélectionne ensuite la meilleure annonce parmi les campagnes et les annonces restantes. La logique de cette sélection finale dépend entièrement de vous. Par exemple, vous pouvez faire des compromis sur les campagnes en sélectionnant celle avec le CPM le plus élevé ou celle avec le budget restant le plus important. Vous pouvez également calculer le potentiel de CTR de l'annonce ou combiner des paramètres pour appliquer une pondération mixte.

Certains des systèmes de sélection les plus avancés utilisent le machine learning pour recommander des annonces par utilisateur ou par segment. Les workflows de machine learning ne sont pas détaillés dans cet article, mais vous pouvez obtenir plus d'informations sur la création de capacités de machine learning dans la partie 2.

Diffuser l'annonce sélectionnée auprès de l'utilisateur ciblé

Jusqu'à présent, les étapes détaillées pouvaient être considérées comme appartenant à la charge de travail de diffusion d'annonces côté éditeur. Une fois l'annonce sélectionnée, le serveur publicitaire renvoie toutefois un lien ou une partie du code HTML, qui peut pointer vers, au choix :

  • un emplacement sur le serveur publicitaire de l'éditeur ;
  • un emplacement externe pouvant appartenir à l'annonceur. Un serveur publicitaire de ce type est considéré comme un serveur côté achat et implémente un modèle appelé diffusion d'annonces tierces (3PAS). Grâce à cet emplacement, les annonceurs peuvent mettre à jour leurs annonces sans avoir à contacter le serveur publicitaire de l'éditeur ni à communiquer avec lui. Cet emplacement leur permet également de gérer leur propre suivi.

Les processus menant à la diffusion de l'annonce restent identiques, que les responsables marketing préfèrent héberger leurs propres créations ou les faire héberger sur le serveur publicitaire d'un éditeur.

Stocker des créations

Les créations sont des fichiers multimédias de type vidéos ou images. Le stockage de ces éléments nécessite un magasin d'objets évolutif et à disponibilité élevée.

C'est pourquoi nous vous recommandons le magasin Cloud Storage. Il est conçu pour héberger des péta-octets de données brutes ou non structurées. Il offre également des options de sauvegarde et d'archivage. Cloud Storage vous permet à lui seul de gérer le cycle de vie de vos créations en les faisant passer du stockage à chaud au stockage à froid afin de réduire les coûts avec Nearline, Coldline et Archive.

Diffuser des créations

Même si le stockage d'objets proposé par des solutions comme Cloud Storage est disponible dans le monde entier, il ajoute généralement de la latence réseau en raison de la distance. En outre, le stockage d'objets peut s'avérer plus coûteux que la diffusion d'annonces via un réseau de diffusion de contenu (CDN).

Comme les pixels publicitaires et les créations sont souvent du contenu public, vous pouvez utiliser l'une des deux solutions GCP pour mettre en cache le contenu dans Cloud Storage :

  • Rendre les objets publics : avec le contrôle du cache, Cloud Storage peut utiliser l'infrastructure Google existante pour mettre en cache le contenu, mais avec des fonctionnalités de type CDN limitées et aucun moyen de forcer l'expiration d'une création à l'échelle mondiale.

  • Associer Cloud Load Balancing et Cloud Storage : le contenu hébergé sur Cloud Storage peut utiliser Cloud Load Balancing avec Cloud CDN activé. Comparé au trafic de sortie de Cloud Storage, Cloud CDN offre des tarifs de mise en réseau réduits ainsi que la compatibilité des URL signées, les clés de cache et l'invalidation de cache.

    Le schéma suivant illustre cette seconde solution.

    Associer Cloud Load Balancing et Cloud Storage

Pour comparer les performances avec celles d'autres fournisseurs, consultez ces rapports Cedexis tiers.

Gérer des événements publicitaires

Différents types d'événements sont utiles au système, comme dans les exemples suivants :

  1. Demande d'annonce : après avoir reçu une demande d'annonce depuis un site de cuisine pour user_ABC, le système peut améliorer les segments user_ABC en ajoutant, par exemple, Cuisine > Cuisine indienne ou toute autre information reflétant les centres d'intérêt de l'utilisateur.
  2. Impression d'annonce : dans un modèle CPM, une annonce s'affiche pour un utilisateur ciblé. Le système enregistre l'impression afin que le budget restant puisse être mis à jour.
  3. Clic sur une annonce : un utilisateur clique sur une annonce. Cette action peut influencer les résultats de l'optimisation des annonces, en particulier si plusieurs utilisateurs (uniques) cliquent sur la même annonce au cours d'une période donnée.
  4. Conversion : un utilisateur clique sur une annonce et effectue une action attendue sur la propriété de l'annonceur, telle qu'un achat ou une inscription.

Lors du traitement des événements, il est important de trouver le bon équilibre entre le prix, la fraîcheur des données et les coûts opérationnels à chaque étape du processus, en particulier pour les opérations suivantes :

  • La collecte et l'ingestion de volumes importants d'événements (et leur vélocité) provenant d'impressions, de clics, de conversions et de demandes d'annonces
  • Le traitement des événements en temps réel ou hors connexion afin d'extraire des valeurs et de calculer des compteurs tels que des budgets, des plafonds et des taux de clics
  • L'exportation des résultats vers différents magasins en temps réel ou hors connexion afin de rapprocher la facturation ou d'appliquer les opérations de diffusion appropriées

Pour plus de détails, consultez la section Cycle de vie des événements (dans la partie 2).

Nous recommandons l'architecture d'intégration et de traitement d'événements en temps réel suivante :

Architecture d'intégration et de traitement d'événements en temps réel

Cette architecture présente les implications suivantes :

  • Les impressions et les clics adressent des requêtes à un point de terminaison HTTP afin d'obtenir un code statique hébergé sur Cloud Storage ou à un collecteur de serveurs Web hébergé sur Google Kubernetes Engine (GKE).
  • Les événements de requête sont consignés via les journaux HTTP de l'équilibreur de charge ou les événements capturés par les collecteurs sont publiés dans Pub/Sub.
  • Dataflow s'abonne au sujet Pub/Sub et traite les événements.
  • Dataflow exporte ensuite les événements bruts et/ou traités vers BigQuery à des fins d'analyse et vers la base de données analytiques (contextuelles) pour mettre à jour les budgets restants.

Le choix entre l'hébergement de code statique sur Cloud Storage ou sur des collecteurs GKE dépend de vos besoins :

  • Si vous devez effectuer des actions backend supplémentaires, utilisez GKE.
  • Si les coûts opérationnels vous préoccupent, utilisez Cloud Storage.
  • Si vous acceptez d'avoir à relancer des requêtes de manière occasionnelle, mais que vous souhaitez réduire les coûts liés à l'exécution des collecteurs GKE ou Compute Engine, utilisez des VM préemptives, comme indiqué dans la section spécifique à la plate-forme de calcul (dans la partie 1).

Étape suivante