Le header bidding est devenu au fil des ans une technologie programmatique de référence, dans la mesure où il permet d’améliorer les revenus publicitaires par rapport aux méthodes traditionnelles de yield management et les systèmes du type passback (ex: cascade). Comprendre l’ensemble du processus qui se cache derrière la technologie de header bidding est essentiel pour optimiser votre chiffre d’affaires. Dans cet article, nous allons donc vous présenter les différences entre une configuration côté client et une configuration côté serveur.
Qu’est-ce qu’un wrapper de header bidding ?
Avant d’explorer les avantages et les inconvénients du header bidding côté client et côté serveur, il y a une notion qui doit être comprise en premier lieu : la notion de wrapper, un indispensable pour implémenter et opérer des enchères sur votre site.
Un wrapper de header bidding est un conteneur ou un cadre qui aide les éditeurs à rassembler les offres de plusieurs partenaires de demande en simultané, selon un ensemble de règles. Cette technologie contrôle et optimise le processus d’enchères dans l’objectif de collecter l’offre la plus élevée pour chaque requête publicitaire.
Chez Opti Digital, nous avons choisi de travailler avec le wrapper Prebid. Pourquoi ? Car cette solution gratuite et open source a été adoptée par la grande majorité des éditeurs du monde entier et rassemble la plus importante communauté de développeurs, assurant ainsi l’évolution constante de la technologie.
Prebid peut être mis en œuvre de deux manières :
- Prebid JavaScript (JS) : côté client.
- Prebid server : côté serveur.
Définition du header bidding côté client
Dans un système côté client, le tag (Prebid.JS) est placé dans le code source du site Web de l’éditeur et exécuté dans le navigateur Web de l’utilisateur lorsque la page est chargée.
En d’autres termes, lorsque Prebid JS s’exécute, le navigateur de l’internaute appelle les partenaires de demande ( SSPs enchérisseurs) pour participer à l’enchère. Le plus offrant remporte l’enchère et renvoie la valeur du CPM à Prebid JS.
Comme Prebid.JS fonctionne sur un navigateur, la bid request (demande d’enchère en temps réel) est enrichie de cookies fournissant ainsi aux acheteurs des informations pertinentes sur les intérêts de l’utilisateur. Cela permet aux annonceurs de cibler les utilisateurs en fonction de leur historique de navigation récent et donc, atteindre leur public cible à moindre coût.
Définition du header bidding côté serveur
Dans un modèle côté serveur, les enchères d’en-tête (header bidding) sont exécutées sur un serveur plutôt que sur le navigateur de l’utilisateur. Au lieu d’envoyer plusieurs requêtes, l’utilisateur envoie une seule bid request au serveur qui appelle de multiples SSP capables de répondre immédiatement.
Cette méthode présente un avantage considérable sur la vitesse de chargement du site Web, car elle nécessite moins de puissance de traitement de la part du navigateur de l’internaute. Si les pages chargent plus vite, l’expérience utilisateur est également améliorée et l’affichage des publicités optimisé.
Avantages et inconvénients des deux techniques
| Header bidding côté client | Header bidding côté serveur | |
|---|---|---|
| Avantages | Cette configuration améliore la transparence et le contrôle côté éditeurs. En utilisant la technologie open source Prebid JS, vous avez accès à tous les partenaires de demande compatibles. Les cookies sont directement synchronisés entre les utilisateurs, les vendeurs et les acheteurs, ce qui permet aux annonceurs d’identifier l’utilisateur qui se trouve sur le site de l’éditeur. | Les éditeurs peuvent ajouter d’autres SSP et régies publicitaires pour participer aux enchères. Le header bidding côté serveur unifie les enchères au lieu de gérer et de configurer chaque ad unit séparément. Il améliore la vitesse de chargement de la page et l’expérience utilisateur. |
| Inconvénients | Ce système augmente la latence de la page car il exécute toutes les requêtes publicitaires sur le navigateur de l’utilisateur, ce qui peut dégrader l’UX. Les navigateurs peuvent limiter le nombre de partenaires de demande qui communiquent simultanément. Cette configuration peut être incompatible avec certains navigateurs qui bloquent les connexions aux pixels externes, ce qui se traduit par des enchères peu performantes. | Il entraîne un manque de transparence, car le processus d’enchères se déroule à l’intérieur du serveur, les éditeurs n’ont aucun contrôle sur ce processus. Il entraîne une baisse du taux de matching des cookies. En effet, la plupart des données utilisateur sont filtrées lors de leur transfert vers le serveur, ce qui rend plus difficile l’identification et le ciblage des utilisateurs par les annonceurs. |
Quelle solution les éditeurs doivent-ils privilégier ?
Les deux technologies présentent des avantages et des inconvénients, ce qui fait qu’il est difficile de savoir laquelle est la plus adaptée à votre monétisation publicitaire, à moins que vous ne puissiez tester les deux.
Même si la technologie côté serveur améliore considérablement le référencement, la méthode la plus utilisée aujourd’hui reste le header bidding côté client. Cela s’explique pour quatre raisons:
- Parce que les éditeurs préfèrent éviter la complexité technique liée à une implémentation côté serveur : l’infrastructure du serveur, les demandes d’enchères et la gestion de synchronisation des cookies.
- En outre, certains SSP peuvent encore utiliser des cookies tiers pour le ciblage et ne sont pas encore compatibles avec le header bidding côté serveur.
- Dans la mesure où les cookies tiers sont toujours disponibles dans le navigateur Google Chrome, les éditeurs choisissent de continuer à en bénéficier aussi longtemps que possible.
- Enfin, Prebid JS évite tout simplement les frais supplémentaires liés aux serveurs.
Toutefois, il est essentiel de préparer la fin des cookies tiers. Lorsque ces derniers seront supprimés de Chrome, les deuxième et troisième arguments disparaîtront et les éditeurs qui continuent à utiliser le header bidding côté client risquent de perdre de l’audience en raison de la latence, plus ou moins importante, de leurs pages.
Chez Opti Digital, nous avons développé notre premier wrapper Prebid côté serveur en 2019. Depuis sa sortie, et après avoir appréhendé sa complexité, nous avons fait le choix de constamment optimiser les paramètres de cette technologie, pour atteindre aujourd’hui des résultats optimaux. Les coûts du serveur sont mutualisés et contrôlés par notre département IT.
La configuration du serveur Prebid étant délicate, les éditeurs peuvent bénéficier de notre expertise pour anticiper la fin des cookies tiers.
Pour réduire la latence de votre site web et augmenter votre audience, contactez-nous !
