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).
Gestionnaire d'annonces Google (anciennement DFP) a été le plus populaire serveur publicitaire pendant longtemps. DFP a permis aux éditeurs d'ajouter des partenaires de demande externes à leur pile d'annonces. Google avait cependant un tour dans son sac : lui permettre d'acheter des impressions avant tout partenaire de demande externe, en utilisant 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.
L'enchère d'en-tête est un type d'enchère programmatique dans laquelle demandes d'enchères sont envoyés simultanément à plusieurs partenaires de demande en temps réel, ce qui signifie que chaque impression d'annonce a la chance d'être acheté à sa valeur maximale, en fonction de la demande disponible.
Ces enchères sont ensuite passées à travers différents filtres (prix plancher et critères de ciblage) configurés par les éditeurs dans leur serveur publicitaire. L'enchère la plus élevée est sélectionnée parmi les enchères filtrées et, enfin, la création publicitaire s'affiche sur l'écran de l'utilisateur. Tout ce processus prend une fraction de seconde.
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
Les enchères d'en-tête sont arrivées à la technologie publicitaire vers 2014. Et seulement après un an, en 2015, la technique est devenue virale. Au début, les enchères d'en-tête étaient appelées diversement sans étiquette, pré-enchères, enchères complètes, enchères parallèles et bien d'autres noms, comme indiqué dans cette fonctionnalité Digiday. En juin 2018, AdExchanger a publié ceci article sur les enchères d'en-tête, et le terme a été cimenté. Et le reste, comme on dit, c'est de l'histoire.
Comparaison avec la méthode en cascade
Avant les enchères d'en-tête, l'écosystème programmatique utilisait une configuration en cascade pour vendre l'inventaire. La configuration en cascade (ou chaînage) implique une échelle de réseaux et/ou d'échanges, disposés de haut en bas par ordre de performance pour l'éditeur. Sur la base des antécédents des réseaux en termes de rendement (eCPM), taux de remplissage, latence, etc. La ou les impressions sont transmises de réseau en réseau, de haut en bas, jusqu'à ce qu'elles soient vendues.
C'est une question de priorisation. Au fur et à mesure que vous descendez la cascade, le CPM les prix planchers diminuent, mais les annonceurs ont également moins accès au meilleur inventaire sur lequel enchérir. Même si ce processus garantissait théoriquement qu'aucun inventaire ne restait invendu et rapportait à un éditeur le meilleur prix possible, en réalité, 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 enchères soumises, les éditeurs peuvent comparer les performances de chaque transaction à l'aide de données au niveau du journal et travailler sur des ajustements pour 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.
Voyant ses avantages par rapport à la cascade des éditeurs, l'industrie a commencé à investir dans la technologie. Avance rapide jusqu'en 2020, la plupart des éditeurs monétisent leur inventaire publicitaire (les numéros de support peuvent être trouvés dans le sous-titre suivant) via les enchères d'en-tête ainsi que d'autres méthodes—offres programmatiques et directes.
Effets sur les revenus de l'éditeur
Les enchères d'en-tête ont aidé les éditeurs augmenter leurs revenus de 20 à 50 %. Le Telegraph, un site d'information, a constaté une augmentation de plus de 70 % de son CPM juste après 9 mois de mise en œuvre des enchères d'en-tête.
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 meilleurs éditeurs américains 1K (basé sur le classement Alexa) utiliser l'enchère d'en-tête avec une moyenne de 7 partenaires demandeurs 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 Google Enchères ouvertes) 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 (au moins dans une certaine mesure), des enveloppes d'enchères d'en-tête ont été développées.
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.
Les enchères d'en-tête peuvent être globalement classées 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.
Les enchères d'en-tête et les enchères en temps réel sont les techniques utilisées dans publicité programmatique et intervenir aux 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 les partenaires de demande tiers à enchérir sur leur inventaire à l'aide de la Adaptateur de pré-enchère. Ainsi, par exemple, si AppNexus est l'un des partenaires de demande avec lesquels vous souhaitez travailler, vous devez intégrer votre 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
Considérant l'intérêt de l'industrie pour enchères d'en-tête côté serveur, Prebid a développé sa solution côté serveur appelée Prebid Server. Il s'agit d'une extension du wrapper prebid.js - où prebid propose un code pour intégrer toutes les offres des partenaires de demande 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
Tout comme la norme afficher des annonces, les enchères d'en-tête vidéo permettent aux éditeurs de vendre leur inventaire d'annonces vidéo au plus offrant. Initialement, 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 un inventaire vidéo, via des enchères côté client et côté serveur.
En 2016, les éditeurs craignaient que peu d'acheteurs soient intéressés par l'inventaire vidéo et qu'ils ne bénéficient donc pas du type de concurrence observée avec les annonces graphiques. Mais ces dernières années, l’inventaire vidéo est devenu précieux. Selon Statista, les dépenses publicitaires vidéo se sont élevées à 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 de temps après le succès massif du header bidding, Google a lancé sa propre version côté serveur et l'a nommée Allocation dynamique des enchères sur une place de marché (renommé plus tard Open Bidding).
Google a lancé Enchères ouvertes en se concentrant sur ses avantages côté serveur. Fondamentalement, il proposait aux éditeurs une vente aux enchères de serveur à serveur. Avec Open Bidding, Google a permis aux éditeurs d'apporter leur propre demande et également d'utiliser la demande de Google (AdX) pour organiser des enchères S2S sur la plateforme de Google.
Le enchères d'en-tête côté client et Open Bidding ont leurs propres avantages et inconvénients, nous ne pouvons donc pas dire que l’un est meilleur que l’autre. Cependant, en comparaison, le côté client s'avère plus transparent et offre de meilleurs taux de correspondance des cookies. Alors qu'Open Bidding évite aux éditeurs une configuration complexe, car Google s'occupe de tout, de la configuration à la gestion continue des enchères.
Les éditeurs peuvent exécuter simultanément des enchères d'en-tête et Open Bidding sur Gestionnaire d'annonces Google. Cette méthode permet aux éditeurs d'accéder à la demande de Google et d'ajouter leurs partenaires de demande internes pour améliorer encore 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'en arriver aux enchères d'en-tête vs Enchères ouvertes, commençons par comprendre rapidement ce qu'est l'appel d'offres ouvert.
Qu’est-ce que l’Open Bidding (EBDA) ?
Les enchères ouvertes, également connues sous le nom d'enchères d'échange ou d'enchères d'échange en allocation dynamique (EBDA), sont la solution de Google aux enchères d'en-tête. Puisqu'il s'agit d'un produit Google, Open Bidding est directement intégré dans Gestionnaire d'annonces Google et permet aux éditeurs d'accéder à la demande de divers échanges 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.
Les enchères d'en-tête traditionnelles impliquent l'utilisation de wrappers d'enchères d'en-tête et ne sont liées à aucun élément spécifique. fournisseur de technologie publicitaire. D'autre part, les enchères ouvertes sont directement intégrées à Google Ad Manager et impliquent principalement des enchères issues de l'échange publicitaire de Google, à savoir : Adx Google, ainsi que d'autres places de marché publicitaires 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, le troisième plus grand nom de la publicité numérique après Google et Facebook, est également un acteur clé dans le domaine des enchères d'en-tête. C'est Services aux éditeurs Amazon propose deux solutions d'enchères d'en-tête côté serveur : UAM et TAM.
UAM (marché publicitaire unifié) est conçu pour les petits et moyens éditeurs. Amazon propose un tableau de bord pour gérer l'enchère où les éditeurs sont autorisés à apporter leur propre demande et à l'intégrer dans leur site Web.
TAM (marché publicitaire transparent) est destiné aux grands éditeurs. Les éditeurs ont accès à plus de 20 partenaires de demande sur Amazon Marketplace, notamment AppNexus, OpenX, Rubicon Project, SpotX. De plus, les éditeurs peuvent amener leurs propres partenaires et les ajouter à 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 les enchères d'en-tête, apprendre le JavaScript de base. Vous pouvez également investir dans la constitution d'une équipe d'opérations publicitaires pour gérer ces tâches pour vous. Si rien de tout cela ne fonctionne, vous pouvez toujours choisir opérations publicitaires externalisées pour gérer les enchères d'en-tête pour vous.
É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 demander l'aide de solutions d'enchères d'en-tête 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
Les enchères d'en-tête garantissent que les éditeurs sont généreusement récompensés pour leur inventaire, mais pas sans mettre les tests en action. Le test A / B avec les enchérisseurs contribue à augmenter les revenus globaux et permet aux éditeurs de comprendre ce qui fonctionne le mieux 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 bon partenaire de demande : Une grande demande signifie de grands revenus. Si vous avez de bons contacts avec les échanges d'annonces et les SSP, alors ajouter un partenaire de demande ne sera pas un problème pour vous. Ne vous contentez pas d'opter pour les partenaires populaires, examinez et comparez leurs services, et choisissez ceux qui conviennent à votre profil d'audience en fonction du créneau dans lequel vous opérez.
Installez un wrapper d'enchères d'en-tête : Ensuite, vous devez placer un wrapper d'enchères d'en-tête sur le site Web. Cela fonctionne comme un conteneur, où vous placerez les codes de tous vos partenaires de demande et définirez les paramètres et les règles d'enchères. Après cela, chaque fois qu'une impression est disponible, vos partenaires de demande recevront des demandes d'enchères.
Définissez des délais d'expiration et un prix plancher : L'ajout d'un trop grand nombre de partenaires de demande sans configurer la campagne peut entraîner un chargement lent des pages. Par conséquent, les éditeurs doivent définir des délais d'attente de session, c'est-à-dire des délais pour la fin des enchères. De même, les éditeurs doivent fixer des prix planchers pour différents blocs d'annonces et ajouter d'autres limitations, si 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 :
Expert Headerbid: Extension Chrome optimisée par Prebid, elle indique le nombre de partenaires de demande enchérissant sur une certaine page Web. De plus, il indique le temps mis par chaque partenaire pour placer ses offres. Sur la base de l'analyse rapide fournie par l'extension, les éditeurs apprennent si leur délai d'attente est raisonnable ou s'ils sous-vendent leurs inventaires et leurs méthodes pour résoudre ces problèmes.
Filtre d'enchères: Cette extension affiche des résultats détaillés tels que les noms des partenaires de demande ajoutés dans le wrapper ainsi que les offres reçues sur des projets individuels. tailles d'annonces. Les onglets sur l'extension affichent une liste de toutes les offres, des offres gagnantes et des offres vides (partenaires qui n'ont pas enchéri intentionnellement ou en raison d'un délai d'attente).
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 préoccupations à ce sujet, n'hésitez pas à communiquez.
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 Smart+ Header, 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é.
