Enchère d'en-tête
L'enchère d'en-tête est une technique programmatique avancée qui permet aux éditeurs de proposer leur inventaire à plusieurs SSP et échanges d'annonces avant de demander des serveurs publicitaires (DFP).
Google Ad Manager (anciennement DFP) a longtemps été le serveur publicitaire le plus populaire . DFP permettait aux éditeurs d'intégrer des partenaires de demande externes à leur stratégie publicitaire. Cependant, Google disposait d'un atout majeur : la possibilité d'acheter des impressions avant tout partenaire de demande externe, grâce à l'allocation dynamique dans AdX.
Cela a incité les fournisseurs indépendants de technologie publicitaire à développer une technique qui leur a égalisé les règles du jeu. Cette technique est désormais connue sous le nom d’enchères d’en-tête.
Malgré son adoption généralisée et sa popularité, les aspects techniques du header bidding restent encore un mystère pour de nombreux éditeurs. Afin que les éditeurs comprennent le header bidding, son fonctionnement, ses avantages et ses inconvénients, nous avons créé ce guide complet.
Le header bidding est un type d'enchère programmatique dans lequel les demandes d'enchères sont envoyées simultanément à plusieurs partenaires publicitaires en temps réel, ce qui signifie que chaque impression publicitaire a la possibilité d'être achetée à sa valeur maximale, en fonction de la demande disponible.
Ces enchères sont ensuite filtrées ( prix plancher et critères de ciblage) par les éditeurs sur leur serveur publicitaire . L'enchère la plus élevée est sélectionnée, puis la publicité s'affiche à l'écran. L'ensemble du processus est instantané.
L'enchère d'en-tête nécessite l'ajout d'un extrait de code JavaScript au rubrique du site Internet. Ce code JS permet aux éditeurs de générer des demandes d'enchères en utilisant les ressources du navigateur.
Histoire de l'enchère d'en-tête
Le header bidding a fait son apparition dans le monde de la publicité numérique aux alentours de 2014. Un an plus tard, en 2015, la technique connaissait un succès fulgurant. À ses débuts, le header bidding était désigné par divers termes : enchères sans étiquette, pré-enchères, enchères complètes, enchères parallèles, et bien d’autres, comme le rapporte cet article de Digiday. En juin 2018, AdExchanger a publié un article sur le header bidding , et le terme s’est imposé. La suite, comme on dit, appartient à l’histoire.
Comparaison avec la méthode en cascade
Avant le header bidding, l'écosystème programmatique utilisait un système en cascade pour la vente d'inventaire. Ce système (ou chaînage en série) consiste en une hiérarchie de réseaux et/ou de places de marché, classés par ordre de performance pour l'éditeur. L'ordre de vente est basé sur les performances passées des réseaux en termes de rendement ( eCPM ), de taux de remplissage, de latence, etc. L'impression (ou les impressions) est transmise de réseau en réseau, de haut en bas, jusqu'à sa (leur) vente.
C'est une question de priorités. Plus on descend dans la cascade publicitaire, plus les prix planchers du CPM diminuent, mais l'accès aux meilleurs inventaires pour les annonceurs se réduit également. Bien que ce processus soit censé garantir qu'aucun inventaire ne reste invendu et qu'un éditeur obtienne le meilleur prix possible, dans les faits, c'est l'inverse qui s'est produit.
La cascade d'éditeurs était un moyen inefficace de vendre l'inventaire :
- • Processus prenant du temps : L'inventaire prenait beaucoup de temps à se vendre, passant d'enchérisseur à enchérisseur.
- • Moins pour votre argent : Les éditeurs ne recevaient pas la vraie valeur de leurs impressions. Par exemple, il y avait des chances que les prochains enchérisseurs aient été disposés à payer plus, mais l'inventaire premium avait déjà été vendu aux enchérisseurs précédents à un coût inférieur. Et il n’y avait aucun moyen de comparer les performances et de les optimiser.
- • Concurrence déloyale: Les annonceurs n'avaient pas la possibilité d'atteindre les bonnes audiences, ce qui entravait finalement les opportunités de revenus des éditeurs.
- • Difficile de définir un ciblage : Le ciblage améliore les revenus, mais la configuration en cascade n'était pas adaptée pour faire correspondre les annonceurs avec les audiences.
De toute évidence, les opportunités de monétisation avec Waterfall n’étaient pas très intéressantes pour les éditeurs. Et ils ont plutôt choisi les solutions de technologie publicitaire de Google (AdSense et DFP). Cela a conduit Google à dominer la chaîne d’approvisionnement des technologies publicitaires. Google était (et dans une certaine mesure, est toujours) fermé au partage de ses tactiques commerciales.
Header bidding saisi comme solution :
L'enchère d'en-tête en temps réel donne aux éditeurs la possibilité de maximiser les revenus générés par chaque impression.
Étant donné que les enchères d'en-tête envoient des demandes d'enchères simultanément à tous les partenaires de demande, elles leur donnent une opportunité égale de faire leurs offres.
Sur la base des offres soumises, les éditeurs peuvent comparer les performances de chaque transaction à l'aide de données de niveau journal et travailler sur des ajustements pour obtenir un meilleur rendement.
Il est conçu pour concurrencer les enchères de Google. Par conséquent, les impressions vont simultanément aux partenaires d'enchères d'en-tête et au serveur publicitaire de Google.
Constatant ses avantages par rapport au modèle traditionnel de diffusion publicitaire, le secteur a commencé à investir dans cette technologie. En 2020, la plupart des éditeurs monétisent leur inventaire publicitaire (les chiffres à l'appui se trouvent dans la sous-section suivante) via le header bidding, ainsi que par d'autres méthodes : la publicité programmatique et les accords directs.
Effets sur les revenus de l'éditeur
Le header bidding a permis aux éditeurs d'augmenter leurs revenus de 20 à 50 % . Le Telegraph, un site d'information, a constaté une hausse de plus de 70 % de son CPM seulement neuf mois après la mise en place de cette technologie.
Grâce à la solution d'enchères d'en-tête d'AdPushup, CCNA7, un site Web éducatif de niche, a mis en œuvre des enchères d'en-tête avec actualisation des annonces pour bénéficier d'une augmentation de 500 % de ses revenus en l'espace de six mois.
Selon un rapport d’eMarketer, les dépenses mondiales actuelles en header bidding s’élèvent à environ 70 milliards de dollars. Et d’ici 2021, ce chiffre devrait augmenter de 87 % et atteindre 81 milliards de dollars.
80 % des 1 000 principaux éditeurs américains (selon le classement Alexa) utilisent le header bidding avec en moyenne 7 partenaires de demande par page.
Mais, c'est un côté des données. Selon les mêmes recherches d'eMarketer, le taux de croissance de l'adoption du header bidding semble diminuer. À l'heure actuelle, le taux d'adoption du header bidding est de 20 % et d'ici 2021, il passera à 15 %. Cela se produit à cause de deux choses :
Le header bidding atteint son seuil de croissance car la plupart des éditeurs cibles ont déjà adopté la technique.
Les éditeurs investissent dans d'autres technologies concurrentes (comme Open Bidding de Google ) pour monétiser leur inventaire.
Quelle que soit la raison, au niveau individuel, les éditeurs peuvent toujours tirer le meilleur parti des enchères d'en-tête, car la demande continue d'augmenter les dépenses publicitaires.
Header Bidding Wrapper et adaptateur
Le navigateur génère une demande d'enchère individuelle pour tous les partenaires de demande chaque fois qu'une impression est disponible. Pour cela, les éditeurs doivent insérer l'extrait de code de chaque partenaire de demande sur leur site Web. L'insertion ou la suppression de ces extraits de code chaque fois qu'un partenaire de demande est ajouté ou supprimé peut devenir fastidieuse très rapidement. De plus, apporter des modifications constantes au code d'en-tête d'un site Web sans l'aide d'un développeur dédié peut entraîner des pannes de site ou une perturbation de la mise en page.
Pour éliminer ces problèmes (du moins dans une certaine mesure), des wrappers d'enchères d'en-tête ont été développés.
Un wrapper d'enchères d'en-tête fonctionne comme un conteneur qui contient les extraits de code de tous les partenaires de demande en un seul endroit. Certains wrappers offrent même une interface graphique (comme AdPushup), de sorte que les éditeurs n'ont pas du tout à se soucier du code, mais activent et désactivent les partenaires de demande à partir d'un panneau de contrôle. Parallèlement à cela, le wrapper peut également être utilisé pour définir un prix plancher et les délais d'attente.
Certains wrappers de header bidding bien connus sont Prebid.js, Pubfood.js et BiddR°360.
Comment fonctionne le Header Bidding : côté client ou côté serveur ?
L'enchère d'en-tête commence dès qu'une page Web commence à se charger sur le navigateur de l'utilisateur. En parallèle, le wrapper lance l'enchère en envoyant des demandes d'enchères aux partenaires demandeurs.
Les enchères d'en-tête fonctionnent sur le modèle d'enchères au premier prix, ce qui signifie que le plus offrant peut diffuser sa création publicitaire et qu'il paie exactement ce qu'il a enchéri pendant l'enchère.
Avant que les enchères d'en-tête ne soient soumises à l'encapsuleur, les partenaires de demande lancent leurs propres enchères pour décider quel annonceur ou DSP participera à l'enchère d'en-tête principale.
Si aucune enchère de partenaires demandeurs n'atteint le prix plancher ou si les délais d'expiration ont expiré, l'inventaire est proposé à des réseaux de remplacement tels qu'AdSense, en fonction des paramètres Ad Manager.
L'enchère d'en-tête peut être globalement classée en deux types : côté client et côté serveur.
Dans le cas des enchères d'en-tête côté client, l'enchère s'exécute sur le navigateur de l'utilisateur. Cela permet la correspondance des cookies pour un meilleur ciblage, car les éditeurs peuvent autoriser les annonceurs à accéder aux données au niveau des enchères. Cependant, les enchères d'en-tête côté client sont connues pour provoquer une latence de page élevée, en raison d'une consommation plus élevée de ressources du navigateur et de réseau.
Dans le cas d'enchères d'en-tête côté serveur, l'enchère est menée sur un serveur d'enchères dédié, loin du navigateur de l'utilisateur. Cette technique économise la bande passante du réseau et les ressources du navigateur, réduisant ainsi la latence des pages. Cependant, en matière de ciblage, la méthode côté serveur ne parvient pas à fournir les résultats souhaités en raison de la diminution des taux de correspondance des cookies.
Afin de tirer le meilleur parti des deux types d'enchères, les éditeurs peuvent également choisir le header bidding hybride. C'est là que les éditeurs exécutent ensemble les enchères d'en-tête côté client et côté serveur, généralement dans un environnement de test multivarié (dont plus d'informations seront expliquées plus loin).
Pourquoi les enchères d'en-tête sont-elles meilleures qu'Adsense ?
Les enchères d'en-tête et Google Adsense ne sont pas des concurrents directs car ils répondent à des objectifs différents pour les éditeurs de différentes échelles.
Bien que les deux soient des méthodes de monétisation pour les sites Web, elles fonctionnent différemment. Google AdSense est destiné aux éditeurs nouveaux et à petite échelle. Il est facile à utiliser car il permet aux éditeurs de diffuser des publicités automatiques sous forme de texte, d'image, de vidéo ou de médias interactifs ciblées sur le contenu et l'audience du site. Il fonctionne sur le modèle CPC (Cost-Per-Click) et Google s'occupe de tous les processus de diffusion d'annonces.
D'autre part, le header bidding, comme mentionné plus haut dans notre guide, est une technique de publicité programmatique, qui permet aux éditeurs de proposer leur inventaire publicitaire à plusieurs échanges publicitaires simultanément. Il est plus avancé et destiné aux éditeurs à grande échelle.
En d’autres termes, si vous recherchez une solution de diffusion d’annonces à grande échelle, il est plus simple de passer de Google Adsense aux enchères d’en-tête.
Enchères d'en-tête et enchères en temps réel (RTB)
Les enchères en temps réel sont simplement un mécanisme qui rend possible l'achat et la vente de publicités via des enchères en temps réel. Le mécanisme est similaire à celui de la bourse où les traders achètent/vendent des actions en temps réel.
L'enchère d'en-tête et l'enchère en temps réel sont deux techniques utilisées en publicité programmatique et qui opèrent à différentes étapes de la technologie publicitaire.
Les enchères d'en-tête ont lieu avant l'appel du serveur publicitaire, ce qui permet aux éditeurs d'accroître la concurrence et potentiellement d'augmenter les revenus publicitaires, tandis que le RTB a lieu après l'appel du serveur publicitaire, les annonceurs enchérissant sur les impressions publicitaires disponibles en temps réel.
Avantages du Header Bidding
Voici les avantages des enchères d’en-tête pour les éditeurs :
- • Demande maximisée : L'enchère d'en-tête permet aux éditeurs d'ajouter plusieurs partenaires de demande. Ces partenaires de la demande sont en outre connectés aux DSP et aux annonceurs. Cette chaîne d'approvisionnement contribue à accroître la concurrence des offres pour l'inventaire et génère plus de revenus.
- • Échange transparent : Même avec une chaîne d’approvisionnement complexe, les enchères d’en-tête sont connues pour simplifier les choses. Les éditeurs peuvent facilement vérifier quelle partie de l'inventaire est vendue à quel partenaire de demande grâce aux données au niveau des enchères. En outre, de nombreux wrappers fournissent des rapports et des analyses avancés pour aider les éditeurs à surveiller leurs revenus et leurs performances.
- • Meilleur contrôle : Les enchères d'en-tête permettent aux éditeurs de configurer l'enchère en fonction de leurs besoins, notamment la personnalisation du prix plancher, la définition de délais d'attente et l'ajout ou la suppression de partenaires de demande pour équilibrer les revenus publicitaires avec la latence de la page.
- • Écart minimal : Les enchères étant organisées sur la plateforme de l'éditeur via un wrapper, cela aide les éditeurs à suivre les transactions. De plus, organiser des enchères simultanées contribue à réduire les écarts : moins de pièces mobiles signifie moins d’écarts.
- • Bénéficie également aux annonceurs : L'enchère d'en-tête est un succès car elle profite à la fois à la vente et à l'achat. Tout comme les éditeurs, les annonceurs achètent facilement l'inventaire vendu via le header bidding. L'environnement transparent et à faible écart encourage les annonceurs à investir également dans le header bidding.
- • Rivaliser avec Google AdX : Google AdX est connu pour transmettre l'impression à son partenaire en premier, puis aux autres réseaux ajoutés par l'éditeur. Cela diminue les possibilités de concurrence. Cependant, avec les enchères d'en-tête, AdX et les partenaires d'enchères d'en-tête peuvent enchérir ensemble.
- • Augmentation des revenus : Contrairement à la diffusion d'annonces en cascade où les impressions publicitaires étaient diffusées vers les sources de demande de manière séquentielle en fonction de priorités prédéterminées, les enchères d'en-tête donnent la priorité aux plus offrants. Avec les enchères d'en-tête, le plus offrant lors de l'enchère s'assure la possibilité d'afficher des publicités sur l'inventaire publicitaire des éditeurs, ce qui se traduit par des bénéfices plus élevés pour les éditeurs.
- • Qualité des annonces améliorée : Les enchères d'en-tête augmentent la concurrence entre les annonceurs pour l'inventaire publicitaire, en particulier ceux alignés sur l'audience d'un éditeur et désireux d'afficher leurs annonces. Par conséquent, les éditeurs ont plus de possibilités d'afficher des publicités adaptées aux intérêts de leur public, ce qui se traduit par une meilleure qualité publicitaire.
- • Temps de chargement plus rapides: Maîtriser les temps de chargement est sans aucun doute l’un des facteurs cruciaux pour une meilleure expérience utilisateur. Heureusement, les enchères d'en-tête réduisent les temps de chargement. Un wrapper d’enchères d’en-tête contacte rapidement les échanges publicitaires et les partenaires de demande pour sécuriser les enchères en quelques millisecondes.
Inconvénients du Header Bidding
Tout ce qui concerne les enchères d'en-tête sonne bien jusqu'à présent. Mais la technique n'est pas sans défis. Pour commencer, il est compliqué à mettre en place et à mettre en œuvre. Ensuite, la méthode côté client contribue à augmenter la latence des pages.
Voici quelques autres inconvénients que les éditeurs doivent connaître :
- • Configuration compliquée : Le processus de mise en œuvre est un peu délicat. Du choix du bon wrapper à l'intégration des codes de plusieurs partenaires de demande, les éditeurs ont besoin d'une expertise technique pour comprendre et mettre en œuvre le header bidding.
- • Coût majoré : L'enchère d'en-tête nécessite souvent une personne (ou une équipe) dédiée pour surveiller et améliorer les performances. Cela inclut la gestion des blocs d'annonces, l'ajout/la suppression de partenaires de demande, etc. Cela ajoute au coût de fonctionnement de l'enchère.
- • Latence accrue : En cas d'enchères d'en-tête côté client, les enchères s'exécutent sur le navigateur de l'utilisateur, ce qui contribue à une latence de page élevée. Cependant, avec les enchères côté serveur comme Open Bidding de Google, ce problème peut être résolu au prix de la correspondance des cookies.
- • Manque de transparence côté serveur : Dans le cas d'enchères côté serveur, les choses sont gérées par le fournisseur exécutant le serveur d'enchères, ce qui rend difficile pour les éditeurs l'accès aux rapports sur les performances des partenaires au niveau de l'enchère et de la demande. Le manque de transparence oblige les éditeurs à accepter les offres qu'ils reçoivent, ce qui minimise la portée de l'amélioration.
Header Bidding Wrapper et adaptateur
Le navigateur génère une demande d'enchère individuelle à tous les partenaires de demande chaque fois qu'une impression est disponible. Pour cela, les éditeurs doivent insérer l'extrait de code de chaque partenaire de demande sur leur site Web. L'insertion ou la suppression de ces extraits de code à chaque fois qu'un partenaire de demande est ajouté ou supprimé peut devenir rapidement fastidieux. De plus, apporter des modifications constantes au code d'en-tête d'un site Web sans l'assistance d'un développeur dédié peut entraîner des pannes du site ou une perturbation de la mise en page.
Pour éliminer ces problèmes (au moins dans une certaine mesure), des wrappers d'en-tête d'enchères ont été développés.
Un wrapper d’enchères d’en-tête fonctionne comme un conteneur qui contient les extraits de code de tous les partenaires de demande en un seul endroit. Certains wrappers proposent même une GUI (Graphical User Interface) comme AdPushup, afin que les éditeurs n'aient pas du tout à se soucier du code. Ils peuvent plutôt activer et désactiver les partenaires de demande à partir d’un panneau de contrôle. Parallèlement à cela, le wrapper peut également être utilisé pour définir un prix plancher et des délais d'attente.
Certains wrappers de header bidding bien connus sont Prebid.js, Pubfood.js et BiddR°360.
Approfondissons maintenant et parlons de deux wrappers d'en-tête d'enchères principaux et les plus couramment utilisés.
Types de wrappers d’en-têtes d’enchères
Open source
Comme leur nom l'indique, les wrappers d'en-tête open source sont des solutions gratuites et open source qui sont librement accessibles et personnalisables par tous. Ces wrappers sont généralement prebid.js, prebid server et pubfood. Il s'agit d'un modèle de développement axé sur la communauté, maintenu par les communautés de développeurs, puis intégré aux serveurs publicitaires pour que chacun puisse en bénéficier.
Avec cette solution, les éditeurs sont libres d'apporter des ajustements au wrapper en fonction de leurs besoins spécifiques. Cela inclut l'optimisation des performances des annonces, l'intégration de fonctionnalités supplémentaires et bien plus encore. Cependant, de nombreux éditeurs finissent par payer le support fournisseur pour plusieurs configurations, intégrations et autres types de support. Ainsi, les éditeurs souhaitant opter pour des solutions open source doivent bien connaître les technicités du logiciel pour mieux gérer ses fonctionnalités.
Emballage propriétaire
D’un autre côté, le wrapper propriétaire est une solution fermée proposée par une seule entité. Il s'agit d'un wrapper appartenant à des sociétés de technologie publicitaire. Il est livré avec son propre ensemble de fonctionnalités et de fonctionnalités qui facilitent l'efficacité et l'efficience des enchères d'en-tête. Cependant, en raison de sa nature propriétaire, il n'est pas possible d'apporter des ajustements ou des personnalisations à la solution, comme c'est le cas avec un wrapper d'enchères d'en-tête open source.
Bien que les éditeurs qui s'appuient sur un wrapper propriétaire puissent en être dépendants, l'un de ses avantages réside dans sa facilité de mise en œuvre et l'accessibilité du support en cas de besoin. De plus, ces wrappers ou adaptateurs sont livrés avec leurs propres outils d'analyse permettant aux éditeurs de mieux gérer et optimiser leurs opérations publicitaires. Mais les éditeurs doivent noter que la personnalisation est limitée car ils doivent s'appuyer sur le propriétaire du wrapper pour implémenter de nouvelles fonctionnalités ou résoudre certains problèmes.
Introduction de Prebid : Open Source HB Wrapper
Prebid est un wrapper d'enchères d'en-tête open source créé par AppNexus. Pour utiliser Prebid, les éditeurs insèrent leurs extraits JavaScript sur leurs sites Web. Cela permet aux éditeurs de configurer des éléments de campagne et d'effectuer des appels publicitaires asynchrones, sans avoir à développer de technique en interne.
Les éditeurs peuvent autoriser des partenaires de demande tiers à enchérir sur leur inventaire via l' adaptateur Prebid . Par exemple, si AppNexus fait partie des partenaires de demande avec lesquels vous souhaitez collaborer, vous devez intégrer votre compte Prebid à l'adaptateur d'AppNexus.
Étant une technique open-source, de nombreux fournisseurs de technologies publicitaires de premier plan contribuent au développement de Prebid, AppNexus et Rubicon Project étant les deux principaux contributeurs.
Prebid est conçu pour être flexible et peut être utilisé sur les ordinateurs de bureau, les appareils mobiles, les applications et même l'inventaire AMP. Il prend également en charge les enchères d'en-tête côté client, côté serveur et hybrides. Étant l'un des wrappers les plus populaires, la plupart des partenaires de demande prennent en charge les intégrations Prebid.
Solution côté serveur de Prebid : serveur Prebid
Face à l'intérêt du secteur pour le header bidding côté serveur , Prebid a développé sa propre solution, Prebid Server. Il s'agit d'une extension du wrapper prebid.js, qui fournit un code permettant d'intégrer les enchères des partenaires de l'éditeur via une configuration côté client et côté serveur.
Un éditeur utilisant déjà prebid.js permettant Serveur de pré-enchère cela nécessiterait simplement un serveur publicitaire et des partenaires intéressés par les enchères côté serveur. Fondamentalement, les éditeurs peuvent utiliser leur configuration de pré-offre existante pour l'activer avec Prebid Server.
Il y a encore une courbe d'apprentissage, où l'équipe technique interne des éditeurs devrait passer par la documentation de pré-enchère pour mettre à jour leur configuration.
Avantages et inconvénients du serveur Prebid
Avantages
- • Le serveur Prebid offre une concurrence accrue entre les partenaires de demande, ce qui entraîne potentiellement des revenus publicitaires plus élevés.
- • Il assure la transparence du processus d'appel d'offres, offrant ainsi aux éditeurs des informations précieuses.
- • Étant donné que les enchères ont lieu sur le serveur, celui-ci offre des temps de chargement plus rapides et une expérience publicitaire plus fluide qui contribue à une meilleure expérience utilisateur globale.
- • Le serveur Prebid simplifie la gestion des blocs d'annonces en intégrant des plates-formes côté serveur et côté client et en consolidant les rapports de performances pour tous les soumissionnaires et partenaires de demande.
Inconvénients
- • L'exécution d'un serveur Prebid peut entraîner des coûts pour l'infrastructure du serveur et potentiellement pour l'expertise technique nécessaire à sa gestion.
- • Étant donné que les enchères se déroulent sur le serveur, les éditeurs peuvent avoir moins de visibilité sur les enchères individuelles et les enchérisseurs gagnants par rapport aux enchères d'en-tête côté client.
- • Prebid Server peut avoir du mal à transmettre les cookies et les données utilisateur des navigateurs aux serveurs et à avoir un impact sur le ciblage publicitaire à mesure que l'industrie abandonne les cookies tiers.
- • Bien qu'il soit plus simple que les solutions personnalisées, Prebid Server nécessite néanmoins que les éditeurs possèdent certaines connaissances techniques pour la configuration et la gestion.
Prebid.js : solution côté client Prebid
Le client dans les solutions côté client Prebid représente les utilisateurs finaux qui consultent les publicités. Dans ce type de solution, les enchères (enchères en temps réel pour les impressions publicitaires) ont lieu dans le navigateur de l'utilisateur.
Voici comment cela fonctionne:
Une balise d'enchères, prebid.js, est intégrée dans le code source d'un site Web, puis exécutée dans le navigateur Web des utilisateurs lorsqu'ils ouvrent le site Web. Dès que la balise prebid.js est exécutée, le navigateur des utilisateurs appelle les enchérisseurs à participer à l'enchère.
Désormais, comme Prebid.js fonctionne directement dans le navigateur, il rassemble de nombreux cookies contenant des informations utiles sur ce qui intéresse les utilisateurs. Cela aide les annonceurs à cibler les utilisateurs en fonction de leurs activités de navigation récentes et à atteindre le bon public.
Avantages et inconvénients de Prebid.js
Avantages
- • Prebid.js permet aux éditeurs d'accéder à un plus grand nombre de partenaires de demande, ce qui contribue à accroître la concurrence et les revenus.
- • Ensuite, comme le serveur prebid, prebid.js permet également aux éditeurs de voir les offres des différents partenaires de demande, ce qui conduit à plus de transparence.
- • Les éditeurs contrôlent leur inventaire publicitaire et peuvent fixer des prix planchers et prioriser les partenaires de demande.
- • Prebid.js est open source, permettant les contributions de la communauté, la personnalisation et l'amélioration continue.
- • Les éditeurs ne sont pas liés à un seul fournisseur de technologie publicitaire, ce qui réduit la dépendance et améliore la flexibilité.
Inconvénients
- • Tout d'abord, l'intégration et la gestion de Prebid.js peuvent être complexes, en particulier pour les éditeurs ayant une expertise technique limitée.
- • La nature côté client de Prebid.js peut entraîner une latence accrue des pages et des temps de chargement plus lents
- • Ensuite, en tant que projet open source, la prise en charge peut varier et les éditeurs peuvent s'appuyer sur les forums communautaires et la documentation pour le dépannage.
- • Enfin, avec la participation des multiples partenaires de demande, des préoccupations peuvent survenir quant à la qualité et à la pertinence des annonces, ce qui pourrait affecter l'engagement des utilisateurs.
Enchères d'en-tête et AMP
En raison de la demande accrue de sites AMP, les enchères d'en-tête ont été mises à jour pour fonctionner sur les pages AMP.
Pourquoi le header bidding ne fonctionnait-il pas sur AMP ?
Parce que AMP fonctionne en supprimant les JS inutiles des pages Web pour les charger plus rapidement sur le navigateur mobile de l'utilisateur. Dans le même processus, il a également supprimé le HB JS.
Pour les éditeurs cherchant à monétiser leur trafic AMP, la technologie publicitaire propose deux solutions :
Configuration en temps réel (RTC)
RTC est une fonctionnalité de Fast Fetch, publiée par l'équipe AMP en 2018 comme alternative aux enchères d'en-tête traditionnelles pour les pages compatibles AMP.
Il permet aux éditeurs d'ajouter jusqu'à 5 partenaires de demande avec un délai d'expiration maximal de 1 seconde. La configuration de RTC est relativement simple et les éditeurs peuvent définir les fournisseurs avec lesquels ils souhaitent travailler en quelques lignes de code :
RTC est une bonne solution pour les éditeurs qui souhaitent mettre en œuvre rapidement les enchères d'en-tête sur les pages AMP et qui n'ont pas trop d'exigences ou de besoins de personnalisation.
Voici quelques fournisseurs qui prennent en charge le protocole RTC.
- 1. AppNexus
- 2.APS
- 3. Critique
- 4. Échange d'index
- 5.media.net
Intégration basée sur wrapper
La deuxième façon consiste à travailler avec un fournisseur qui fournit un wrapper d'enchères d'en-tête avec prise en charge AMP (comme AdPushup). Compte tenu de la nature d'AMP, seuls les wrappers avec intégration de serveur à serveur fonctionnent bien, et les implémentations côté client auront plus de chances d'être bloquées par AMP pendant l'exécution.
Les enchères d'en-tête basées sur un wrapper contournent la limite des 5 partenaires de demande en acheminant les offres via un seul emplacement RTC. Cela signifie que vous pouvez ajouter autant de partenaires de demande que vous le souhaitez. Mais ce n'est pas le seul avantage d'utiliser une solution basée sur un wrapper.
Avec RTC et son approche de balise unique, les éditeurs auront besoin d'un développeur pour effectuer des mises à jour chaque fois qu'ils souhaitent ajouter/supprimer un partenaire de demande. En revanche, un bon wrapper permettra aux éditeurs d'effectuer ces modifications à partir d'un panneau convivial. Les wrappers fourniront également aux éditeurs des données de rapport et d'analyse, ce pour quoi RTC n'a actuellement aucun support.
Vidéo Header Bidding et son fonctionnement
À l'instar des publicités display classiques , l'enchère d'en-tête vidéo permet aux éditeurs de vendre leur inventaire publicitaire vidéo au plus offrant. Initialement, l'enchère d'en-tête vidéo nécessitait des intégrations web et serveur distinctes ; désormais, de nombreux wrappers existants (comme Prebid.js) peuvent être configurés pour vendre l'inventaire vidéo, via des enchères côté client et côté serveur.
En 2016, les éditeurs craignaient que peu d'acheteurs s'intéressent aux espaces publicitaires vidéo, et donc qu'ils ne bénéficient pas de la même concurrence que pour les publicités display. Mais ces dernières années, les espaces publicitaires vidéo ont pris de la valeur. Selon Statista , les dépenses publicitaires vidéo s'élevaient à 26 millions de dollars en 2020 et devraient connaître une croissance annuelle de 6.8 %, pour atteindre 35 millions de dollars d'ici 2024.
De même, alors que le marché de la vidéo se développe, de nombreux annonceurs et partenaires de demande s'unissent pour encourager les éditeurs à expérimenter l'inventaire vidéo. OpenX, AppNexus et SpotX font partie des partenaires de la demande qui traitent de l'espace publicitaire vidéo.
Réponse de Google au Header Bidding : Open Bidding
Peu après l'immense succès du header bidding, Google a lancé sa propre version côté serveur, baptisée Exchange Bidding Dynamic Allocation (renommée plus tard Open Bidding).
Google a présenté Open Bidding en mettant l'accent sur ses avantages côté serveur. Concrètement, il proposait aux éditeurs un système d'enchères de serveur à serveur. Avec Open Bidding, Google permettait aux éditeurs de générer leur propre demande et d'utiliser également la demande de Google (AdX) pour organiser des enchères S2S sur sa plateforme.
L'enchère d'en-tête côté client et l'Open Bidding présentent chacune leurs avantages et leurs inconvénients ; il est donc impossible d'affirmer que l'une est meilleure que l'autre. Toutefois, l'enchère côté client se révèle plus transparente et offre de meilleurs taux de correspondance des cookies. L'Open Bidding, quant à elle, simplifie la configuration pour les éditeurs, car Google prend en charge l'intégralité du processus, de la mise en place à la gestion continue des enchères.
Les éditeurs peuvent utiliser simultanément le header bidding et l'Open Bidding sur Google Ad Manager . Cette méthode leur permet d'accéder à la demande de Google et d'ajouter leurs partenaires de demande internes afin d'optimiser la pression des enchères.
Voici comment cela fonctionne:
Une fois qu'une impression est disponible, les demandes d'annonces sont envoyées à Google AdX et aux enchères d'en-tête. Dans le système AdX, les acheteurs AdX et Open Bidding placent leurs enchères pour remporter l'impression. Pendant ce temps, le header bidding commence à collecter les réponses aux enchères de ses partenaires demandeurs. À la fin, AdX et Open Bidding transmettent leur gagnant. De même, le header bidding en passe un autre. Enfin, GAM compare ces offres et choisit le gagnant (l'offre la plus élevée).
Enchères d’en-tête vs. Open Bidding (EBDA) : quelle est la différence ?
Avant d'aborder la différence entre les enchères d'en-tête et les enchères ouvertes , comprenons d'abord rapidement ce qu'est l'enchère ouverte.
Qu’est-ce que l’Open Bidding (EBDA) ?
L'enchère ouverte, également appelée enchère d'échange ou enchère d'échange avec allocation dynamique (EBDA), est la solution de Google pour l'enchère d'en-tête. Étant un produit Google, l'enchère ouverte est directement intégrée à Google Ad Manager et permet aux éditeurs d'accéder à la demande provenant de différentes places de marché publicitaires sans avoir besoin de wrappers ou de configurations supplémentaires.
Qu'est-ce qui différencie les enchères d'en-tête des enchères ouvertes ?
La principale différence entre les deux réside dans la mise en œuvre et la plateforme technologique.
Le header bidding traditionnel utilise des wrappers de header bidding et n'est lié à aucun fournisseur de technologie publicitaire spécifique . En revanche, l'open bidding est directement intégré à Google Ad Manager et repose principalement sur les enchères via la plateforme d'échange publicitaire de Google, Google AdX , ainsi que d'autres plateformes participantes.
Ainsi, même si l’enchère ouverte fonctionne sur les principes du header bidding, il s’agit d’une solution fournie par Google. Il offre aux éditeurs la possibilité d'accéder à la demande de divers échanges publicitaires directement via la plate-forme Google Ad Manager.
La solution d'enchères d'en-tête d'Amazon : UAM et TAM
Amazon, troisième acteur majeur de la publicité numérique après Google et Facebook, est également un acteur clé du header bidding. Son service Amazon Publisher Services propose deux solutions de header bidding côté serveur : UAM et TAM.
UAM (Unified Ad Marketplace) est conçu pour les éditeurs de petite et moyenne taille. Amazon propose un tableau de bord permettant de gérer les enchères et d'intégrer la demande à leur site web.
TAM (Transparent Ad Marketplace) est destiné aux grands éditeurs. Ces derniers ont accès à plus de 20 partenaires publicitaires d'Amazon Marketplace, dont AppNexus, OpenX, Rubicon Project et SpotX. Ils peuvent également intégrer leurs propres partenaires à Amazon TAM.
Les éditeurs peuvent intégrer leurs serveurs publicitaires (DFP) à Amazon et mettre à jour les éléments de campagne avec de nouvelles modifications pour commencer à recevoir des offres.
Étant donné qu'Amazon est nouveau dans le jeu, il est recommandé d'utiliser UAM/TAM avec Open Bidding et Prebid pour obtenir de meilleurs résultats.
Prêt à essayer le Header Bidding ? Voici 5 étapes pour vous préparer
Nous recommandons ces 5 étapes pour préparer les enchères d'en-tête aux éditeurs qui découvrent cette technologie :
Étape 1 : Demandez si le header bidding vous convient
Si vous débutez avec le header bidding, il y a de fortes chances que vous ayez déjà utilisé AdSense pour monétiser votre trafic. Avec AdSense, la plupart des opérations techniques sont gérées par Google. Cependant, le header bidding repose entièrement sur votre expertise technique.
Vous pouvez vous renseigner sur le header bidding et apprendre les bases de JavaScript. Vous pouvez aussi investir dans la création d'une équipe dédiée aux opérations publicitaires pour gérer ces tâches. Si aucune de ces solutions ne vous convient, vous pouvez toujours externaliser la gestion de vos opérations publicitaires.
Étape 2 : Découvrez et lisez les en-têtes d'enchères
Même si vous faites appel à votre équipe de technologie publicitaire, investir du temps dans l'apprentissage de la technologie rapporte bien. Pour commencer, il vous aide à établir des partenariats avec des partenaires de demande HB.
Familiarisez-vous avec le fonctionnement des enchères d'en-tête, ce qu'elles peuvent et ne peuvent pas faire pour vous, et améliorez-vous à partir de là.
En savoir plus sur les différents types d'enchères d'en-tête, les plus grands acteurs du marché et le taux d'adoption devrait vous aider à prendre des décisions plus éclairées pour votre entreprise.
Étape 3 : Soyez prêt pour les défis
Les enchères d'en-tête sont fructueuses, cependant, il existe également des défis permanents avec la technologie. Tout d'abord, vous ajouterez des morceaux de code supplémentaires qui peuvent augmenter la latence.
Vous devrez vous débrouiller seul pour générer des rapports. Contrairement à Google, vous devez ici travailler avec vos ingénieurs de données pour créer une API de reporting et l'intégrer dans Excel ou des services similaires pour voir la croissance (ou le déclin).
Si votre équipe actuelle n'est pas en mesure de gérer cela, vous pouvez faire appel à des solutions de header bidding gérées.
Étape 4 : Choisissez soigneusement le partenaire de demande
Les partenaires de demande (ou partenaires de rendement) vous mettront en contact avec les annonceurs. Vous devez choisir ces partenaires avec soin. Quelques exemples de partenaires de demande sont Appnexus, Criteo et Index Exchange.
Ces partenaires ont des contrôles standard et des exigences minimales pour permettre aux éditeurs d'entrer dans leur cercle. Vous pouvez les contacter pour un partenariat, cependant, si vous n'êtes pas en mesure de les gérer vous-même, obtenir l'aide de fournisseurs de solutions d'enchères d'en-tête (comme AdPushup) peut vous aider.
Étape 5 : Testez, testez, testez et testez encore
L'enchère d'en-tête garantit aux éditeurs une rémunération attractive pour leur inventaire, mais cela nécessite des tests. Les tests A/B avec les enchérisseurs contribuent à augmenter les revenus globaux et permettent aux éditeurs d'identifier les stratégies les plus performantes pour leur inventaire.
Vous devez vous concentrer sur la recherche d'erreurs, l'ajout/la suppression de partenaires de demande à divers éléments de campagne et l'augmentation de vos revenus globaux.
Comment configurer les enchères d'en-tête ?
Pour mettre en œuvre les enchères d'en-tête, les éditeurs doivent placer un code JavaScript dans l'adresse de leur site Web. section. Ce code permet de déclencher l'enchère lorsqu'une impression apparaît.
Si l'éditeur est capable d'intégrer le site Web avec un wrapper d'enchères d'en-tête, alors Prebid.js est l'option la plus appropriée. Toutefois, si un éditeur n'a pas l'expertise technique pour le faire, vous pouvez opter pour un service géré fourni par un fournisseur de technologie publicitaire tiers.
Une fois le wrapper ajouté au site Web, les éditeurs peuvent entrer en contact avec des partenaires de demande pour accéder à leurs adaptateurs respectifs. Les adaptateurs permettent aux éditeurs de se connecter au marché du partenaire de demande et de trouver des acheteurs pour leur inventaire publicitaire.
La configuration peut être divisée en trois étapes simples :
Trouvez le partenaire idéal pour générer de la demande : une forte demande se traduit par des revenus importants. Si vous entretenez de bonnes relations avec les plateformes d'échange publicitaire et les SSP, l'ajout d'un partenaire de demande ne posera aucun problème. Ne vous contentez pas des partenaires les plus populaires ; examinez et comparez leurs services, et choisissez ceux qui correspondent le mieux à votre audience et à votre secteur d'activité.
Installez un wrapper d'enchères d'en-tête : Ensuite, vous devez placer un wrapper d'enchères d'en-tête sur votre site web. Ce wrapper sert de conteneur pour les codes de vos partenaires publicitaires et vous permet de définir les paramètres et les règles des enchères. Dès lors, à chaque fois qu'une impression est disponible, vos partenaires publicitaires reçoivent une demande pour enchérir.
Définissez des délais d'expiration et un prix plancher : ajouter trop de partenaires publicitaires sans configurer la campagne peut ralentir le chargement des pages. Les éditeurs doivent donc définir des délais d'expiration de session, c'est-à-dire des limites de temps pour la fin des enchères. De même, ils doivent définir des prix planchers pour les différents formats publicitaires et ajouter toute autre limitation nécessaire.
Une fois les étapes terminées, vous devez toujours surveiller et optimiser la configuration de manière continue pour vous assurer que vous maximisez les revenus au niveau des impressions sans causer de problèmes de convivialité.
Extensions d'enchères d'en-tête
Voici quelques extensions d'enchères d'en-tête que vous pouvez installer pour espionner vos concurrents afin de voir quelles relations de demande ils ont :
Headerbid Expert : Extension Chrome développée par Prebid, elle indique le nombre de partenaires publicitaires participant aux enchères sur une page web. Elle précise également le temps mis par chaque partenaire pour placer son enchère. Grâce à cette analyse rapide, les éditeurs peuvent déterminer si leur délai d'expiration est approprié ou s'ils sous-estiment la valeur de leurs inventaires, et ainsi identifier les solutions pour y remédier.
BidFilter : Cette extension affiche des résultats détaillés, notamment les noms des partenaires publicitaires ajoutés au conteneur, ainsi que les enchères reçues pour chaque format d'annonce . Les onglets de l'extension présentent la liste de toutes les enchères, les enchères gagnantes et les enchères infructueuses (partenaires n'ayant pas enchéri, volontairement ou suite à un dépassement de délai).
En clôture
Pour les éditeurs, le header bidding est un bond en avant par rapport au monopole de Google et aux inefficacités des autres enchères programmatiques. Cela a ouvert une plate-forme plus contrôlée avec une transparence requise des deux côtés pour la technologie publicitaire.
Bien qu'il ait encore quelques défis à relever, le taux d'adoption croissant est un signe que nous, en tant qu'industrie, continuerons à l'utiliser. Les premiers signes tels que l'introduction des enchères côté serveur et la disponibilité de HB pour l'inventaire vidéo et AMP sont un signe que la technologie est très flexible.
Si vous avez des questions ou des inquiétudes à ce sujet, n'hésitez pas à nous contacter.
Enchères d'en-tête et AdPushup
Améliorez votre expérience publicitaire et maximisez vos revenus grâce à notre solution smart+ Managed Header Bidding.
Nous aidons nos éditeurs avec bien plus que de simples enchères d'en-tête. Notre solution d'enchères d'en-tête est dotée d'une gamme de fonctionnalités pour vous aider à augmenter le rendement. Nous avons créé plusieurs fonctionnalités d'optimisation des annonces à l'aide de l'apprentissage automatique pour notre moteur d'enchères d'en-tête. En plus de cela, nous disposons d'experts chevronnés en opérations publicitaires, qui fournissent des services gérés accompagnés d'une assistance 24h/7 et XNUMXj/XNUMX.
Pour en savoir plus sur notre solution d'enchères d'en-tête Smart+, cliquez ici.
Les enchères d'en-tête sont un processus d'enchères en temps réel exploité avec du code JavaScript ajouté au code d'un site Web. Grâce à ce code, les éditeurs peuvent envoyer des demandes d'enchères simultanées aux acheteurs, recevoir leurs offres dans un délai imparti, choisir un gagnant et diffuser leur annonce.
Les enchères d'en-tête utilisent des wrappers et des adaptateurs pour connecter l'inventaire aux acheteurs. Pour réduire la complexité technique, le wrapper d'enchères d'en-tête agit comme un conteneur pour le site Web qui est capable de contenir des adaptateurs de plusieurs partenaires de demande. Pour ajouter/supprimer un partenaire, définir un délai d'expiration et d'autres personnalisations, les éditeurs peuvent apporter des modifications au wrapper.
Les enchères d'en-tête vidéo fonctionnent exactement comme les enchères d'en-tête d'affichage à l'aide de wrappers et d'adaptateurs. Pour mettre en œuvre les enchères d'en-tête vidéo, les éditeurs doivent avoir des partenaires de demande avec les acheteurs d'inventaire vidéo. En fonction des types d'acheteurs que vous avez, recherchez un serveur publicitaire VAST/VPAID et/ou mettez à jour les blocs d'annonces avec des annonces vidéo outstream.
DFP (ou Google Ad Manager) est un serveur publicitaire qui propose Open Bidding (le header bidding S2S de Google). En dehors de cela, les éditeurs peuvent également utiliser DFP pour afficher les performances (générer des rapports) de votre autre configuration d'enchères d'en-tête. Cela peut être fait en mettant à jour les éléments de campagne avec vos partenaires de demande (rendement).
80 % des 1 XNUMX meilleurs éditeurs américains utilisent le header bidding, notamment Forbes, The Guardian, Buzzfeed, entre autres.
Prebid.js est un wrapper d'enchères d'en-tête open source développé par AppNexus. Il offre des intégrations côté client, côté serveur, vidéo et AMP. Prebid.js permet aux éditeurs de configurer des éléments de campagne et de gérer plusieurs appels d'annonces asynchrones avec un serveur publicitaire.
Bien qu'AdSense soit un réseau publicitaire populaire, les enchères d'en-tête sont meilleures à bien des égards, telles que la possibilité d'ajouter/supprimer les partenaires de demande souhaités. Les enchères d'en-tête sont connues pour offrir un meilleur eCPM qu'AdSense grâce à un intérêt accru des grands annonceurs pour l'inventaire d'enchères d'en-tête. Le processus d'appel d'offres transparent et la concurrence loyale ont incité les annonceurs à choisir l'enchère d'en-tête, augmentant ainsi le flux de dépenses publicitaires via les marchés privés.
L'allocation dynamique oppose Ad Exchange à d'autres partenaires de demande configurés dans le DFP d'un éditeur, augmentant ainsi le retour sur investissement et encourageant les éditeurs à augmenter les prix dans Ad Exchange, augmentant ainsi la valeur de l'inventaire.
Oui, les éditeurs WordPress peuvent également mettre en œuvre des enchères d’en-tête. Tout ce qu'ils ont à faire est d'ajouter le code d'enchère d'en-tête ou le script d'enchère d'en-tête dans la section d'en-tête de leur site Web et c'est tout.
Amazon Transparent Ad Marketplace (TAM), également connu sous le nom d'Amazon TAM, est un wrapper d'enchères d'en-tête exclusif côté serveur conçu pour les éditeurs à grande échelle. Il est directement lié aux principaux échanges publicitaires tels que Magnite et PubMatic. L’accès à TAM se fait uniquement sur invitation. Les éditeurs utilisant TAM bénéficient de l'avantage de pouvoir exploiter la demande d'Amazon en plus de leurs partenaires SSP actuels. Cependant, TAM fonctionne comme une plate-forme en libre-service, obligeant les éditeurs à gérer eux-mêmes les aspects techniques des enchères d'en-tête.
Amazon Unified Ad Marketplace (UAM), également appelé Amazon UAM, sert de wrapper d'enchères d'en-tête de serveur à serveur adapté aux éditeurs de petite et moyenne taille. Il s'adresse à ceux qui n'ont pas de relations SSP directes, donnant accès aux propres SSP d'Amazon comme Pubmatic et Rubicon Project. UAM offre la commodité de l’intégration avec les configurations actuelles d’enchères d’en-tête. Cependant, il fonctionne sur invitation uniquement et est limité à des régions spécifiques comme les États-Unis, ce qui présente des obstacles à l'accessibilité.
