Deal ID

Un Deal ID est un identifiant alphanumérique unique que les deux parties – acheteur et vendeur – attachent à un accord programmatique négocié, qu’il s’agisse d’un accord préféré, d’un private marketplace ou d’un accord programmatique garanti, afin que toute requête d’enchère portant cet ID soit associée au prix, à l’inventaire et aux conditions spécifiques convenus par les deux parties.

Comment fonctionne un Deal ID#

Un éditeur ou son supply-side platform regroupe un segment d’inventaire (un emplacement, un segment d’audience, une section de contenu) avec un prix et d’éventuelles conditions personnalisées, puis génère un Deal ID pour celui‑ci. Cet ID est partagé de façon privée avec un acheteur, qui le saisit dans son demand-side platform comme cible de ligne d’article.

À partir de là, c’est du simple acheminement. Sous OpenRTB, le Deal ID circule à l’intérieur de l’objet « deal » de la requête d’enchère. Lorsqu’une impression correspondante se déclenche, le SSP signale la requête d’enchère avec cet ID, et seul l’acheteur qui le possède voit les conditions négociées, soit comme un prix garanti sans concurrence, soit comme une enchère privée avec un plancher négocié, selon le type d’accord. Les enchères des autres participants sur la même impression, s’il y en a, passent par le flux normal de real-time bidding.

Pourquoi les Deal IDs sont importants#

Ils permettent aux deux parties de négocier comme dans un direct buy traditionnel : prix fixe, placement spécifique, conditions personnalisées, tout en transigeant via le pipeline programmatique automatisé plutôt que via un ordre d’insertion manuellement géré. Trois types d’accords reposent couramment sur un Deal ID : les accords préférés (prix fixe, premier regard, aucune garantie de volume), les private marketplace deals (enchère sur invitation uniquement avec un plancher négocié) et les accords programmatiques garantis (volume réservé à un prix fixe, essentiellement un IO automatisé).

Pour les acheteurs, un Deal ID est également le moyen le plus simple d’obtenir un accès constant à l’inventaire d’un éditeur spécifique sans dépendre des gains de header bidding sur l’échange ouvert, où disponibilité et prix évoluent constamment.

Quand les Deal IDs posent problème#

La plupart des tickets « the deal isn’t spending » en opérations publicitaires remontent à un problème de Deal ID : une faute de frappe lors de la copie de la chaîne entre le SSP et le DSP, un accord actif d’un côté mais mis en pause ou expiré de l’autre, ou des incohérences de budget et de dates de vol entre les deux systèmes. Aucun de ces cas ne génère d’erreur évidente. L’accord renvoie simplement zéro enchère ou zéro impression, et il faut que quelqu’un compare les deux plateformes côte à côte pour repérer la discordance. Si vous auditez l’inventaire qu’un concurrent ou un partenaire achète réellement à grande échelle, l’index d’ad intelligence d’OpenAdLibrary constitue un moyen plus rapide de voir ce qui est actif sur le marché que d’essayer de le reconstituer à partir des rapports d’accords uniquement.

FAQ#

Un Deal ID est‑il identique à un Private Marketplace ?

Non. Le PMP est le type d’accord (une enchère sur invitation uniquement). Le Deal ID est l’identifiant qui dirige une requête d’enchère spécifique vers les conditions négociées de cet accord. Un accord PMP, un accord préféré, et un accord programmatique garanti utilisent tous des Deal IDs ; ils appliquent simplement des règles différentes une fois que l’ID correspond.

Qui crée un Deal ID ?

L’éditeur ou son SSP le crée et le délivre, puis le partage de façon privée avec l’acheteur, qui le saisit dans les paramètres de campagne ou de ligne de son DSP.

Plus d’un acheteur peut‑il utiliser le même Deal ID ?

En général, non. Un Deal ID est attribué à un acheteur spécifique pour un arrangement négocié précis. Certains SSP prennent en charge des configurations d’accords partagés ou multi‑acheteurs, mais c’est l’exception, pas la règle.

Pourquoi une campagne avec un Deal ID valide obtient‑elle zéro impression ?

Les causes les plus fréquentes sont une chaîne d’ID non concordante entre les plateformes, un accord mis en pause ou expiré d’un côté, ou un conflit de budget ou de dates de vol. Vérifiez les configurations du SSP et du DSP côte à côte plutôt que de supposer que le ciblage est erroné.