« Le second price auction faisait sens quand on était dans un écosystème fermé » (C. Emeriau, Index Exchange)

, Index Exchange

Index Exchange est parmi les plateformes supply side du marché qui teste la méthode des enchères selon le premier prix (1st price auction), qui consisterait, si elle venait à être adoptée, en un changement de taille dans cet environnement du RTB, bâti sur la logique du deuxième prix (2^nd price auction). La raison évoquée pour ce tournant est, entre autres, le développement du header bidding, levier qui est à l’origine de l’importante percée d’Index Exchange en France. Pour tenter de mieux comprendre les différentes options qui s’offrent aux éditeurs pour valoriser leurs inventaires, nous interrogeons Charles Emeriau, directeur du pôle Éditeurs Europe du Sud d’Index Exchange.

Pouvez-vous nous donner votre avis sur les pratiques qui deviennent tendance dans le marché du RTB consistant à migrer du second vers le first price auction? Le système des ad exchanges et du RTB a pourtant été au départ entièrement bâti sur la logique de second price pour éviter des déséquilibres dans le prix.

Le second price auction faisait sens quand on était dans un écosystème fermé. En header bidding, plusieurs exchanges entrent en compétition. Avoir un second price dans chaque exchange perd son sens. On peut très bien avoir un acheteur qui enchérit à 20€ sur le SSP n°1 avec un second price à 10€. Après, sur le SSP n° 2  un autre acheteur enchérit à 15€ avec un second price à 12€. Dans ce cas-là c’est celui qui a enchérit à 15€ qui va l’emporter dans le système du second price. Cela pose un problème, car l’acheteur avec l’offre pourtant la plus élevée ne l’emporte pas. C’est pour cela que le first price commence à avoir du sens. Chez Index nous ne le pratiquons pas, mais nous sommes en train de tester cette méthode avec certains de nos partenaires et avec les acheteurs qui nous le demandent, de plus en plus nombreux. Le marché évolue.

Rubicon, Appnexus et PubMatic ont récemment communiqué sur le lancement de prebid.org, une organisation qui favorise l’adoption de prebid.js qui est un « container » ou « wrapper » de header bidding en open source, développé par Appnexus, votre concurrent. Vous faites partie de prebid.org, mais vous proposez aussi une autre solution, votre propre wrapper. Pouvez-vous déjà nous expliquer en quoi ces deux solutions sont différentes?

Nous faisons en effet partie de prebid.org, nous travaillons en prebid.js avec nos éditeurs quand ils le souhaitent. Le prebid.js est un wrapper en open source. À l’heure actuelle, une cinquantaine de partenaires (SSP et DMP) s’en servent. S’agissant d’un open source, l’ensemble des SSPs ont contribué à la création de prebid.js – Appnexus l’a popularisé, mais nous l’avons tous construit ensemble. D’un autre côté, nous proposons aussi notre propre wrapper pour accompagner les éditeurs dans la mise en place du header bidding, un processus qui n’est pas toujours aussi facile qu’il ne paraît. Notre wrapper vous est proposé avec notre expertise: nos ingénieurs, qui font des milliers d’intégrations, qui se sont occupés de clients tels que Time Inc. ou Whashington Post, savent ce qui fonctionne ou pas, ils ont une visibilité beaucoup plus approfondie que celle dont dispose un éditeur qui va mettre en place sa solution de son côté. Notre wrapper intègre de nombreux partenaires, comme Criteo, Rubicon, Appnexus, qui viennent entrer en compétition avec les différents SSP. Il est construit pour faciliter le travail de l’éditeur, à travers une interface avec de nombreuses fonctionnalités qui lui permet de manager ses préférences sans avoir à toucher au code de la page, une fois le wrapper implémenté. Si, par exemple, l’éditeur souhaite modifier le time out ou enlever un partenaire, il lui suffit de se connecter à la plateforme directement, sans pour autant devoir toucher à sa page. Nous proposons aussi du reporting pour fournir des insights utiles, comme des informations sur la latence,  d’où placer son time out vis-à-vis de la demande, etc.

S’agissant d’un open source, l’ensemble des SSPs ont contribué à la création de prebid.js.

Le principe du header bidding est d’intégrer sur le header de la page de l’éditeur une solution qui lui permette d’appeler directement, pour chaque impression, différentes plateformes SSP du marché, comme Index, Appnexus ou Rubicon. Quand une plateforme comme la vôtre vient proposer ce service à l’éditeur, cela signifie que vous lui facilitez la tâche tout en ouvrant la place à tous vos concurrents. Pouvez-vous nous expliquer la logique pour vous?

C’est cela. De la même manière qu’en prebid, notre wrapper permet aux éditeurs de travailler avec différentes sources de demande (SSP). Le principe du header bidding est bien de rajouter de la compétition et que le plus haut CPM net l’importe. À partir du moment où nos clients ont une relation contractuelle avec un SSP, nous leur permettons de venir le rajouter chez nous.

Si votre concurrent gagne, demande-vous aussi une commission?

Nous ne prenons pas de commissions dans ces opérations. Si un éditeur travaille avec Appnexus ou Rubicon, cette relation reste entre le SSP et l’éditeur sans intermédiation de notre part: si leur CPM net est plus élevé que le nôtre, nous n’avons aucun regard sur la transaction.

La suite de l’interview de Charles Emeriau, directeur du pôle Éditeurs Europe du Sud d’Index Exchange sera publiée demain.

Propos recueillis par Luciana Uchôa-Lefebvre

(Images : Shutterstock et Index Exchange pour la photo de C. Emeriau.)