Ad Exchange dans le cadre des enchères en temps réel (RTB) est l'une des solutions AdTech qui transforment le marché de la publicité en ligne. Sa fonction principale est d'ancrer un grand nombre de SSP et DSP, qui n'ont pas d'intégration directe entre eux, ainsi que de revendre une variété de trafic publicitaire entre eux.
Grâce à une commande pour le marché américain, nous avons plongé dans les spécificités de la construction de la plateforme Ad Exchange. Et dans cet article, nous présentons quelques idées et résultats.
Énoncé du problème
Les enchères en temps réel (RTB) permettent la vente d'espace publicitaire sur les sites en temps réel pour afficher des publicités pertinentes auprès du public cible.
En bref, le diagramme de processus est le suivant:
- l'utilisateur final demande une page Web ou une application mobile où une place pour une bannière est réservée (le code de la plate-forme de vente d'inventaire publicitaire est intégré - SSP, Supply Side Platform);
- Pour garantir le prix de vente maximum de l'inventaire, le SSP via Ad Exchange organise des appels d'offres entre différents DSP (Demand Side Platform), dont l'objectif est d'acheter l'inventaire le moins cher possible;
- après l'annonce du gagnant de l'enchère, le DSP gagnant envoie un code de bannière SSP, qui est affiché à l'utilisateur;
- un autre aspect du processus est DMP, un système tiers qui fournit au DSP des informations détaillées sur l'utilisateur final (au-delà de ce qui peut être transmis par SSP sous forme de cookies, etc.) pour justifier l'opportunité de l'achat et le coût proposé.
Il existe aujourd'hui de nombreux échanges Ad Exchange. En outre, de nombreux fournisseurs de services partagés implémentent leurs propres enchères (fermant en fait la fonctionnalité d'Ad Exchange). Mais notre client était sûr qu'en raison de nouvelles idées, il pourrait rapidement entrer sur le marché et résister à la concurrence.
Les échanges fonctionnent selon différents principes: quelqu'un offre une marge plus importante, quelqu'un de moins, quelqu'un vend des équipements uniques, d'autres se concentrent sur les biens de consommation conditionnels. Le marché est assez jeune et en plein développement, il n'y a donc pas de modèles économiques testés au fil des ans ici: tout repose sur des hypothèses et des expériences audacieuses. La plupart des joueurs travaillent selon un schéma simple: ils reçoivent une demande de l'un des SSP avec lesquels ils ont pu se mettre d'accord et l'envoient à tous les DSP intégrés en prévision d'un meilleur pari. Revenus Ad Exchange - Différence entre le prix d'achat et le prix de vente de l'inventaire publicitaire au SSP et au DSP moins les coûts d'exploitation.
Notre client a suggéré d'optimiser ce schéma en répartissant correctement les demandes SSP vers le DSP - sans envoyer de demandes délibérément «perdantes», réduisant ainsi les coûts d'exploitation. Pour cette raison, vous pouvez réduire la commission de l'échange sans perdre de revenus et rendre votre offre plus attrayante dans le contexte de la concurrence d'Ad Exchange dans la lutte pour le SSP et le DSP. Et connecter plus de partenaires donnera à la fois des revenus et de la stabilité sur le marché.
Pour mettre en œuvre cette stratégie sur le marché américain, nous avons été chargés de réaliser Ad Exchange avec une répartition intelligente des demandes, ce qui devait fournir un bon pourcentage de rachat. En théorie, pour une telle distribution, vous pouvez utiliser beaucoup d'informations qui accompagnent la demande, même des données des systèmes tiers mentionnés ci-dessus (DMP). Cependant, les analyses complexes nécessitent des ressources, donc la tâche consiste en fait à trouver un équilibre entre les coûts d'une distribution intelligente et le gain (par rapport aux autres acteurs du marché) de sa mise en œuvre. Dans un marché relativement récent et immature, la construction de solutions très complexes, la compression des dixièmes d'optimisation, n'a tout simplement pas de sens.
Une caractéristique importante du projet, en plus des charges élevées attendues, était le respect des exigences non fonctionnelles pour la rapidité des enchères mises en place par SSP. Dans ce segment de marché, le délai d'attente pour attendre une réponse du SSP à 300 ms, qui devait être respecté avec les appels vers les systèmes externes (DSP), est suffisant.
Le projet a démarré à l'automne 2016. Grâce à l'expérience de l'équipe dans ce domaine, après trois mois, nous avons réalisé le premier prototype et après trois autres MVP (produit minimum viable), ce qui nous a permis de collecter les premières analyses pour démarrer la distribution intelligente des demandes dans Ad Exchange.
Le lancement de MVP a montré que l'hypothèse du succès commercial du projet est correcte - Ad Exchange a commencé à gagner de l'argent pour le client. Les plans de développement initiaux d'Ad Exchange comprenaient une étude plus approfondie des données - la connexion des informations sur les utilisateurs finaux des systèmes externes aux analyses. Mais au stade MVP, il a été décidé d'utiliser uniquement les données du SSP. C'était suffisant pour réaliser le bénéfice escompté.
Architecture de la solution
La solution est basée sur le modèle de chaîne de responsabilité, qui permet de ne pas fixer l'itinéraire des demandes au sein du système, en ajoutant facilement des processeurs et divers services, de la vente aux enchères elle-même aux outils de filtrage.
Le client ne nous a pas limités dans la pile de technologies utilisées. Par conséquent, en prenant soin du développement futur et du support du projet, nous avons construit une solution évolutive horizontalement en utilisant Postgres et Hadoop.
Ad Exchange lui-même est écrit en Java - en même temps, nous n'avons utilisé aucun framework pour ne pas s'affaisser dans la charge (nous avons travaillé à un niveau bas).
Pour respecter le délai SSP mentionné, nous avons sélectionné les paramètres du garbage collector (G1 a été utilisé) et élaboré un travail synchrone avec un grand nombre de demandes - nous avons utilisé un client HTTP qui ne bloque pas le flux, ainsi qu'une extension du protocole HTTP keep-alive qui permet d'envoyer plusieurs demandes dans une connexion TCP.
Les composants logiciels sont déployés sur du matériel loué à l'hôte, comme les conditions de la tâche n'ont pas permis l'utilisation du cloud en raison du chevauchement des ressources des machines de cloud virtuel (l'allocation des ressources nécessaires peut prendre du temps, mais nous ne l'avons pas). À l'heure actuelle, Ad Exchange utilise quatre serveurs physiques, dont l'un est redondant (pour les mises à jour transparentes, etc.).
L'open source Apache Kafka est utilisé comme courtier de messages - il est idéalement intégré dans notre modèle «un abonné - de nombreux éditeurs», bien qu'il ait dû être légèrement tordu pour que les messages répétés n'arrivent pas.
Chacun des serveurs fournit en mode normal environ 10 000 requêtes par seconde (ces paramètres ont été définis lors du développement de la solution). Maintenant, la charge moyenne est de 15 à 20 000 requêtes par seconde, et au pic, le flux de requêtes a atteint 40 000 requêtes par seconde pendant plusieurs heures, et Ad Exchange a fait un excellent travail.
La répartition des demandes entre les serveurs est effectuée par l'équilibreur de charge du logiciel nginx, qui est configuré pour notre tâche. D'après notre expérience, sur nginx, vous pouvez conserver jusqu'à 60 à 70 000 requêtes par seconde, sans affecter un équilibreur matériel distinct. Si à l'avenir la charge sur Ad Exchange sera supérieure à ce seuil, nous prévoyons d'acheter un équilibreur matériel qui répartira les demandes entre plusieurs du même type nginx.
Il surveille ce qui se passe, sous réserve d'une augmentation constante de la charge, un système de surveillance, qui fait partie de la création d'Ad Exchange.
Stockage
Étant donné la dépendance à l'égard de l'analyse lors de la distribution des requêtes, la base de données fait partie intégrante de notre Ad Exchange. Le système stocke des informations sur les offres, les participants aux enchères et les transactions.
Cela n'a aucun sens de collecter un tel volume de données pour toute la période d'Ad Exchange, de sorte que le stockage possède une architecture à plusieurs niveaux. Toutes les données d'enchères sont stockées par semaine. Sur cette base, des unités intermédiaires de niveau supérieur sont construites, qui sont stockées pendant plusieurs mois. Et sur la base des intermédiaires, les agrégats finaux sont utilisés, qui sont utilisés dans les analyses à long terme et pour les rapprochements avec SSP et DSP. Entre autres informations dans ces unités, il y a des données sur le nombre de paris qui ont été faits et combien d'argent l'échange va payer SSP ou s'attendre à recevoir de DSP.
Les points de terminaison sont stockés pendant toute la durée d'Ad Exchange.
La collecte d'analyses et la formation d'agrégats fournissent des services distincts.
Pour que le stockage corresponde à la vitesse du système lui-même, j'ai également dû travailler avec lui. En particulier, pendant un certain temps, nous nous sommes battus avec l'hébergeur, car les données de transaction n'avaient tout simplement pas le temps d'écrire dans la base de données. Il s'est avéré que la panne était un problème matériel avec la matrice RAID. Après l'avoir remplacé, nous avons pu compresser 90 000 requêtes par seconde sur Postgres (en insérant des données dans la base de données).
Le reste d'Ad Exchange est sans état, ce qui permet une mise à l'échelle horizontale facile à l'avenir. Il ne stocke aucune donnée sur les demandes - le maximum d'informations reçues sur le DSP à sélectionner. Afin que nous puissions ajouter de nouveaux serveurs pour traiter les demandes selon les besoins.
Filtrage du trafic
Le filtrage du trafic est un élément clé du système qui vous permet de réduire la charge et de respecter les délais indiqués par le client.
Selon la tâche à accomplir, tout Ad Exchange:
- accepte les demandes du SSP;
- organise une vente aux enchères (envoie des demandes à plusieurs DSP, compare les prix proposés, identifie le gagnant);
- est d'accord avec la victoire du SSP (rapporte le prix du gagnant moins sa commission, attend une réponse avec le prix final du spectacle);
- termine la transaction (signale au DSP nécessaire sa victoire, conduit le trafic des utilisateurs).
La distribution des demandes intelligentes dans Ad Exchange est incluse au stade initial de l'enchère.
Lorsque nous recevons une demande du SSP avec certaines informations (IP, agent utilisateur), nous la détaillons en utilisant les informations accumulées dans le système - informations utilisateur connues, liste des DSP auxquels des demandes similaires ont été envoyées, leurs réponses, etc. Cela est nécessaire pour sélectionner la combinaison la plus avantageuse de DSP pour chaque demande. Grâce à la sélection d'une telle combinaison, le système vous permet de ne pas envoyer de demandes aux DSP qui n'enchérissent pas ou ne le font pas, mais qui sont trop bas. Pour ce faire, un service distinct en temps réel compile une carte de la façon dont le DSP répond aux requêtes (ces cartes sont stockées dans Redis).
En parallèle, nous vérifions l'état du DSP - si la proportion de réponses dans le délai tombe, le système réduit automatiquement le nombre de demandes à ce DSP. Dès que la charge sur le DSP est réduite (et que la proportion de réponses correctes dans un délai acceptable augmente), le nombre de demandes revient progressivement à son niveau précédent.
Parmi les DSP qui ont répondu à temps, nous organisons une enchère interne - sélectionnez la meilleure offre et envoyez-la au SSP. Depuis la demande de SSP jusqu'à notre réponse, pas plus de 300 ms ne s'écoulent, conformément aux exigences de l'industrie.
Étant donné que nous envoyons les données au SSP, où se tient notre enchère, nous devons tenir compte des enchères gagnées sur place. Le serveur d'enchères est déjà engagé dans leur journalisation à l'étape suivante, lors du traitement du trafic utilisateur. Grâce à lui, la carte de réponse DSP s'enrichit de nouvelles données (ainsi que des informations collectées sur l'utilisateur final).
Une comparaison des données obtenues au stade de l'enchère et des paramètres connus du trafic des utilisateurs nous permet de filtrer les bots (clickers publicitaires, robots de recherche, etc.). Un tel trafic n'est pas racheté par DSP, et en l'absence de son propre système de filtrage, il se transforme en pertes de clients, qui devront être couvertes par la marge.
Il convient de noter que le filtrage du trafic bot n'a pas été démarré immédiatement. Mais après l'inclusion de simples verrous, le gain de marge était d'environ 50%.
Soit dit en passant, en plus des outils de filtrage automatique du trafic dans notre système, il est possible pour le client de modifier manuellement les valeurs de seuil d'un certain nombre de paramètres, ajustant ainsi la marge.
Le trafic utilisateur lui-même est essentiel pour nous, mais lorsqu'il est traité, il n'est plus nécessaire de tenir dans 300 ms. Il utilise un système de traitement séparé, qui peut retenir un peu l'utilisateur, mais ne permettra pas de perdre cette demande.
Pour assurer la stabilité de la solution, un sous-système a été introduit qui, comprenant la charge actuelle d'Ad Exchange, "coupe" les demandes d'enchères, qu'il ne peut physiquement pas traiter. Ainsi, le système est protégé contre la croissance incontrôlée de la charge du SSP.
Perspectives
À ce jour, Ad Exchange que nous avons créé fonctionne et fait de bons bénéfices. Et nous fournissons le support et l'intégration de nouveaux partenaires (DSP / SSP) selon les besoins. Au total, plusieurs dizaines de systèmes ont déjà été intégrés. Chacune de ces intégrations implique non seulement une connexion logicielle, mais également des tests complets du service, car sous de fortes charges, les problèmes du service connecté peuvent affecter d'autres partenaires.
En général, le marché évolue vers le fait que le SSP et le DSP se connecteront directement, ce qui rendra les échanges inutiles. Mais l'intégration repose sur les capacités de SSP et DSP. Malgré l'existence de l'API ouverte décrite (protocole OpenRTB), elle n'est pas encore universellement reconnue sur le marché. Par exemple, un acteur majeur comme Appnexus a récemment intégré la prise en charge d'OpenRTB.
Essentiellement, Ad Exchange est un fournisseur de liquidité. Il est donc peu probable que la décision, dans un avenir proche, perde de sa pertinence. De plus, le modèle d'échange ne fait que gagner en popularité sur le reste du marché publicitaire.
Auteur de l'article: Nikolay Eremin
PS Nous publions nos articles sur plusieurs sites du Runet. Abonnez-vous Ă nos pages sur les
chaînes VK ,
FB ou
Telegram pour découvrir toutes nos publications et autres actualités Maxilect.