Comment Index Exchange veut convaincre les éditeurs français avec son wrapper header bidding

Comment Index Exchange a-t-il tiré parti du développement du header bidding ?

Avant l’arrivée du header bidding, le modèle économique des SSP était une boîte noire : les éditeurs choisissaient un SSP primaire qu’ils plaçaient en haut de leur stack et auquel ils donnaient une grande autonomie. La plupart des mécanismes à l’oeuvre n’étaient pas transparents. Il y a quatre ou cinq ans, Index Exchange essayait déjà de convaincre les éditeurs en faisant valoir des frais transparents, mais qu’ils trouvaient trop élevés. Nous ne comprenions pas comment nos concurrents parvenaient à proposer des frais deux fois plus faibles que les nôtres. Puis nous avons compris qu’ils facturaient aussi des frais côté acheteurs.

L’engouement pour le header bidding a été largement lié à la volonté de mettre à jour ces pratiques. En 2015, nous tentions de convaincre les éditeurs de mettre en place cette technologie, qui était totalement nouvelle, mais cela leur semblait complexe et leurs ressources étaient limitées. Finalement, un grand éditeur new-yorkais a réuni une vingtaine d’autres éditeurs et nous ont dit être prêts à expérimenter le header bidding, mais comme ils n’en avaient pas les moyens ni le temps, ils nous ont demandé une solution.

Nous avons alors mis en place un wrapper afin d’alléger la contrainte technique. Depuis, nous avons vu une forte progression de l’adoption de notre technologie, car les éditeurs se sont rendus compte qu’il y a plus d’argent sur le marché qu’ils ne le pensaient.

Quel est l’intérêt pour les éditeurs d’utiliser un wrapper propriétaire alors qu’il en existe un open source, avec Prebid.js ?

Il y a effectivement deux wrappers majeurs sur le marché, le nôtre et Prebid. Notre wrapper est un produit de plateforme, tandis que Prebid est un code. Lorsque nous l’avons créé, nous avons cherché à résoudre les problématiques des éditeurs : adoption, latence, intégration, adaptation. Notre solution est autant une offre de produit qu’un service puisque nous aidons les éditeurs à mettre en place le wrapper au sein de son infrastructure. Chacun d’entre eux a généralement plusieurs sites et format publicitaires, parfois dans plusieurs pays, avec différentes configurations d’adserver.

Faire les choses bien en matière de header bidding dans un marché complexe est un vrai challenge. Le concept du wrapper open source est séduisant, mais il ne convient pas à tous les éditeurs car cela représente beaucoup de travail. Pas seulement pour le mettre en place, mais aussi pour l’entretenir. Nous avons créé un produit robuste, qui peut être maintenu et adapté simplement.

Nous observons que Prebid est surtout adopté par les acteurs “digital first” qui ont beaucoup d’ingénieurs, tandis que nous ciblons les grands groupes médias. Par ailleurs, nous ne prélevons pas de frais sur l’utilisation de notre wrapper.

Mais certains éditeurs craignent qu’un wrapper propriétaire leur fasse perdre la transparence sur leurs opérations publicitaires.

J’ai beaucoup entendu cette critique, oui. Mais notre produit est l’objet d’une grande attention de la part de nos clients, nous avons passé de nombreux audits, notamment techniques et de sécurité des données, des tests A/B…

Aux Etats-Unis, 30 % des 100 premiers sites de comScore utilisent notre wrapper. Parmi nos clients figurent NBC Universal, CBS ou Condé Nast. Nos ingénieurs travaillent main dans la main avec les leurs. Par ailleurs, le wrapper tient en un tag JavaScript hébergé sur le navigateur côté client, donc il peut être inspecté facilement.

Toutes les plateformes programmatique du marché sont connectés à notre wrapper, nos concurrents peuvent donc aussi inspecter le code. Nous avons reçu beaucoup de demandes pour le faire évoluer ces deux dernières années, ce que nous avons fait. S’ils pensaient que notre wrapper n’était pas neutre, les autres SSP n’y participeraient pas. Par ailleurs, le wrapper ne prend aucune décision : il applique les paramètres décidés par l’éditeur.