CHRONIQUE. Ces dernières années ont montré de plus en plus de partenariats SSP-DSP afin d’avoir une intégration verticale totale et même l’utilisation d’ID solution. Cependant, avec les éditeurs et annonceurs utilisant différentes plateformes, une réflexion sur l’interopérabilité du frequency capping autour d’une publicité est nécessaire.
En français “limitation du nombre d’exposition”, le frequency capping permet tout simplement de limiter le nombre de fois qu’une publicité s’affiche à une personne, un device ou autre… Il y a aussi d’autres paramètres à prendre en compte comme :
- Où : L’endroit où s’applique le frequency capping, comme une page, une session, un placement publicitaire…
- Quand : Plus spécifiquement combien de temps et cela peut varier en minutes, heures, jours…
De façon générale, cela permet d’éviter une fatigue de l’utilisateur, de ne pas endommager l’expérience utilisateur et d’optimiser le budget des annonceurs car le but de la publicité est d’adresser le bon message, à la bonne personne et au bon moment. Dans cet article, la question ne tourne pas autour de l’aspect technique mais plus une réflexion autour du concept de frequency capping.
Maitriser le frequency capping OUI MAIS dans la chaine programmatique par qui, comment, combien de temps et à quelle fréquence ?
En programmatique, les différents acteurs peuvent paramétrer le frequency capping via le SSP (on peut aussi ajouter l’ad server pour la compétition avec les campagnes directes) et le DSP. Après il est vrai qu’il peut y avoir un conflit entre éditeur et annonceur :
- L’éditeur va paramétrer le frequency capping sur l’emplacement et l’utilisateur afin de maitriser la diffusion des publicités, que ce soit entre programmatique (open auction, deal etc…) et campagnes directes.
- L’annonceur va paramétrer le frequency capping pour maitriser la diffusion de la publicité et de son budget.
Si les deux acteurs ne sont pas en accord (communication, Deal Id…), cela peut créer des problèmes de diffusions de la publicité mais cet article tourne autour d’une autre situation avec le programmatique. Un annonceur peut diffuser une publicité via un DSP pour atteindre un éditeur mais le programmatique peut aider ce même annonceur à atteindre ce même éditeur via d’autres SSPs et même en utilisant d’autres DSPs. Le résultat est que la non-interopérabilité entre plateformes, ne permet pas une maitrise du frequency capping général mais seulement par plateforme (quand c’est possible) et cela impacte l’écosystème publicitaire jusqu’à l’utilisateur. On peut aller beaucoup plus loin car un SSP peut aussi avoir accès à un site ou une application en direct et via un intermédiaire (je ne parlerai pas ici de ads.txt ou Supply chain object). Au-delà des plateformes, on peut aussi penser au frequency capping par type d’inventaire, device etc…
Du coup, pour essayer de maitriser cette non-interopérabilité autour d’une publicité, il faut prendre les paramètres suivants en compte :
- Utilisateur, device…
- Les applications / sites (accès direct ou indirect)
- Type d’inventaire (display, vidéo, audio, native…)
- Type de publicité
- Etc…
L’industrie peut penser que les ID solutions peuvent aider à remédier à ce problème. Pour info, une bid request contient en moyenne entre deux ou trois ID solutions avec cet objectif d’identifier un utilisateur pour le reach et la mesure. Cependant, vu la quantité d’ID solutions sur le marché et les éditeurs n’utilisant pas le ou les mêmes ID, il y a toujours la situation où une publicité est diffusée sans contrôle de façon non-interopérable par un acheteur via plusieurs DSP.
Au final, juste dire frequency capping pour une campagne ou une publicité n’explique pas clairement qui l’a paramétré dans la chaine programmatique, pour quelle pub, quelle cible, quel inventaire.
Identifier la publicité en amont côté acheteur pour maitriser le frequency capping de façon interopérable
Comme dans beaucoup de cas en programmatique, l’éditeur (avec le SSP et l’ad server) a cette responsabilité car il est en relation direct avec l’utilisateur et aussi surtout car il peut recevoir une publicité en provenance de différents chemins (je ne parlerai pas de SPO aujourd’hui), c’est à dire de DSPs, où même d’acheteurs (stratégie). Pour aider à l’identification d’une publicité, ils existent des moyens comme :
- Ad Manangement API de l’IAB Tech Lab: Le DSP envoie en amont la publicité au SSP et en fonction de la réponse (oui, non, bloqué…), le DSP peut diffuser la publicité ou non. Si on part du principe que des DSPs et SSPs l’implémentent (ce qui n’est pas forcément le cas aujourd’hui), une interopérabilité pourrait se créer autour du frequency capping.
- Homemade API : Des plateformes (peu) proposent leur propre API pour la vérification des publicités.
- Protected audience API de Privacy Sandbox : Anciennement Fledge, PAAPI (Protected audience API) veut utiliser un mécanisme pour permettre au SSP d’auditer les publicités en amont venant d’une proposition nommée TERN (TURTLEDOVE Enhancements with Reduced Networking) de NextRoll.
Au-delà du fait que ces technologies apportent d’autres avantages comme éviter qu’une publicité soit bloquée pendant la livraison (annonceur bloquée, problème de créa…), aider à la réduction du volume de bid responses du DSP au SSP en OpenRTB (un bon point pour réduire l’impact environnemental) et apporter de la transparence autour de la fraud et de la brand safety, on peut penser qu’il n’y a pas qu’un type de frequency capping, mais plusieurs c’est-à-dire interopérable ET non-interopérable.
