Pour en finir avec le sujet des DMP

AdExchanger publie ce matin un article assez documenté confirmant que les direction marketing font machine arrière et abandonnent leurs projets de DMP, faute de résultats probants en contraste avec les attentes élevées.

AdExchanger publie ce matin un article assez documenté confirmant que les direction marketing font machine arrière et abandonnent leurs projets de DMP, faute de résultats probants en contraste avec les attentes élevées.

L’article intitulé “Oversold And Overpromised: Marketers Move Away From DMPs” met en avant les principales limitations des DMP sur les trois dernières années, et on y retrouve les 3 principales critiques formulées dans mon billet “Do you really need a DMP in 2018?” [publié en janvier 2018].

Quel est le problème ?

En synthèse, il s’agit de :

  • la fin du “far west” autour des données 3rd party, une des principales valeurs des DMP, pour cause de renforcement ds législations autour de la Privacy (GDPR et consorts)
  • la fin de l’ère du tout cookie, dans un monde devenant “mobile first” voire “mobile only”, les promesses non tenues des ID cross-device, leurs match-rates catastrophiques
  • le disconnect entre les DMP et le reste de la chaine programmatique, en particulier au niveau des contenus, campagnes, copys, etc. Les DMPs s’occupent des ciblages et uniquement des ciblages

Mais en plus, viennent quelques griefs plus spécifiques liés non pas aux produits par eux mêmes mais aux équipes des éditeurs qui sont moins facile à joindre en après-vente pour les phases d’implémentation, que pendant l’avant-vente. Bizarrement.

Alors que faire ?

Comme je l’ai déjà écrit ici, ceci devrait être un wake-up call pas seulement au sujet des DMPs mais plus largement concernant tout le programmatique.

Une bonne stratégie serait de concentrer ses efforts sur les actions relationnelles, basées sur un CRM up-to-date, offrant des possibilités de filtrage et de ciblage, manipulant uniquement des données 1st Party et en full opt-in, et en ayant le soucis de servir et d’informer les prospects et clients, au lieu de maximiser des CTR.

Human, after all. Let’s move on :)

Do you really need a DMP in 2018?

A couple of months ago, I was discussing with two business contacts of mine about their plans and priorities for 2018: they had to decide about strategic investments, and they asked my opinion about choosing and implementing a DMP for their business. This got me thinking. Well, it’s 2018, and DMPs are so 2016…

A couple of months ago, I was discussing with two business contacts of mine about their plans and priorities for 2018: they had to decide about strategic investments, and they asked my opinion about choosing and implementing a DMP for their business. This got me thinking.

Well, it’s 2018, and DMPs are so 2016…

Reminder : DMPs are an (optional) link in the RTB programmatic chain. DMP’s main capability is to combine 1st, 2nd and 3rd party data in order to create specific audience segments, to be exposed to display ad campaigns.

If you live in the EU, or if your business has some B2C activity with individuals from Europe, then you will soon be bound by the now famous GDPR regulation. As we’ll explain here after, the GDPR regulation has some direct consequences on the way a DMP (and on a wider scale, the programmatic ad-tech industry) can be operated.

3rd Party Data Vendors

The business of selling massive amounts of anonymous data will probably not survive GDPR. This business was already in bad shape a couple of years ago, and most of the pure players had tried to pivot to some other form of activity, but this time it’s getting worse. GDPR enforces full opt-in for data collection, and makes it mandatory to clearly state the all usages for the collected data.

Where do 3rd Party Data vendors collect their data from has always been the dirty little secret in this ad-tech industry. It’s in nobody’s interest to ask too much questions. All you want to know, is that someone acts as a proxy, sells data and does the dirty job in the back-office. And I won’t even discuss 3rd party data accuracy.

Here for instance, Oracle Bluekai thinks I’m a soccer and WorldCup enthusiast, and a NASCAR fan. Those of you who do know me also know how ridiculous this is.

It’s going to be _very_ tough for data vendors to be able to collect, trace, anonymize and allow for deletion of all collected data. I honestly don’t see how these business could survive. The funny thing is that every now and then, I stumble on interviews from 3rd party data vendors(*) who swear to God that they are already GDPR compliant, or they will soon be…

The market for 3rd Party Data is almost dead. Let’s consider DMPs only for 2nd and 1st party data then…

(*) : not all of them.

2nd Party Data

Second party data is just someone else’s first party data. 2nd party data happens when several advertisers and/or published agree to ID sync and share information about their common audiences. With GDPR, all data collected will have to be collected with full opt-in, and after presenting all the details of the use of the data to the individuals.

Collecting the opt-ins for a 2nd party data sharing scenario on some Example.com website could look like this:

Do you believe that many people would simply click « OK » and blindly accept to share their personal data with sites and services they never heard about, if they are asked to? I don’t think so.

I think we can assume that 2nd party data partnerships will disappear when GDPR comes into play.

OK then. Let’s play safe and use DMPs just for 1st party data

Why not. But if your DMP is only useful for using your first party data for segmentation, you could probably directly use some modern DSP capabilities. Or if you want to use some of your CRM data, you could use services of some CRM onboarder like Temelio or Graphinium. Or if you want to do social advertising, or retargeting, you could use formats from Facebook, Amazon, Google, or twitter such as « custom audiences », RLSA, and the likes.

And you don’t need a DMP. And you don’t have to spend 3 to 6 months on the deployment and invest between 100 and 200k€ of your budget on year 1 just for the platform fees and setup.

DMPs for insights and customer intelligence?

Not really either. In a recent industry report, 9 out of 11 DMP vendors were rated « Poor » about « Analytics and audiences insights offerings ». By design. Simply because most of the DMPs were designed as activation platforms, not as analytics platforms. There’s a disconnect between DMP capabilities and the reality. In my opinion, this is partly caused by the name « Data Management Platforms » and the fact that few people do their homework and fully try to understand what they’re really buying.

If you want to get insights about your customers, and want one platform for actually managing all PII and non-PII data, also while keeping track of the opt-ins and be able to provide an audit trail, you should probably look for CDPs (aka Customer Data Platforms) which are getting more and more popular as the deadline for GDPR compliance comes closer.

If I was running your business, would I buy a DMP in 2018?

Would I sign a PO for a three years engagement for a DMP, if I were you? Probably not.

More than 50% of enterprises currently use a DMP, either directly or through an agency partner, according to Gartner’s Marketing Technology Survey (published Sept 2017, also numbers may slightly differ in our old Europe). Of the marketers without a DMP, one in five felt they didn’t need one.

Does this means that it’s the end of « Data Driven Marketing »? Absolutely not. There are many tools and solution alternatives, and also, GDPR is a great opportunity for businesses for adopt a different, more long term and customer centered approach to online marketing. And I’m convinced that your customers will appreciate this.

The Golden Age for DMPs is behind us. I’m glad I wrote my DMP blog posts series in 2016 :)

What then?

Start with small data. Do your homework. Understand your customers. Understand who they are, and why they buy from you, what they like in your brand and products. And surprise them. Please them. Add value by easing their lives as a customer, solving one issue at a time.

See also…

[DIGIDAY UK] GDPR is coming, and data management platforms are in the crosshairs

[DIGIDAY UK] With GDPR looming, DSPs are under pressure to adapt

[DIGIDAY UK] Ad retargeters scramble to get consumer consent

[DIGIDAY UK] Once a must-have, marketers sour on DMPs

DMPSeries #6 – De l’importance d’avoir défini les Use Cases DMP

Dans le billet précédent, j’ai présenté 5 facteurs qui – à mon sens – sont clé dans la réussite d’un projet DMP chez un annonceur. Le second point insistait sur l’importance des Use Cases et des KPIs. Ici j’explique pourquoi.

Sixième billet d’une série consacrée aux plateformes DMP.

Dans le billet précédent, j’ai présenté 5 facteurs qui – à mon sens – sont clé dans la réussite d’un projet DMP chez un annonceur. Le second point insistait sur l’importance des Use Cases et des KPIs.

Alors bien entendu, si ça semble être simplement du bon sens de dire qu’avant de se lancer dans un projet de mise en place d’une DMP, il est plus que conseillé d’avoir déjà réfléchi en amont à l’utilisation de cette DMP et à quels cas d’usage on souhaitera répondre. Ça frise la Lapalissade :)

Mais au delà de ce truisme, il faut comprendre que le fait d’avoir pris le soin en amont de définir et de documenter de façon claire et compréhensible une liste de Use Cases prioritaires sera bénéfique non seulement au projet DMP lui-même, mais aussi plus largement à votre société.

Les bénéfices obtenus seront de plusieurs ordres :

a – Les bénéfices en interne

  • s’assurer qu’on a bien identifié tous les besoins et les business cases qui seront confiés à terme à la DMP
  • collecter l’ensemble des besoins des différents services : branding, marketing, pays ou départements, marques, CRM, etc

On aura pris soin de recenser tous les besoins surtout en termes d’activation, de la part des différents services : l’équipe acquisition, le marketing, les agences média, le CRM, les ventes, les différents départements / marques ou pays, etc.

On évitera ainsi de lancer un projet de DMP qui serait uniquement piloté par exemple par l’équipe acquisition avec une vision très media et display tout en oubliant les uses cases du CRM, ou réciproquement.

Le fait d’avoir listé l’ensemble des besoins et des cas d’usage des différents services et départements permet aussi – bien entendu – d’obtenir leur adhésion au projet dès le départ, et de pouvoir prioriser les différents use cases, car il y aura immanquablement des arbitrages à opérer, et certains use cases pourront être repoussés pour les phase II ou phase III du projet.

b – Les bénéfices pour le chiffrage

  • lister les sources de données à prendre en compte
  • lister les plateformes d’activation à prendre en compte
  • valider la faisabilité technique / fonctionnelle / juridique des use cases

Les principaux bénéfices à ce niveau sont assez clairs : soumettre vos use cases aux fournisseurs technologiques (ie les éditeurs de plateformes DMP consultés dans votre RFP) permet de vous assurer que la plateforme sélectionnée sera en mesure d’opérer les use cases que vous comptez réaliser. Ca n’est pas anodin.

Accessoirement, ceci permet aussi au fournisseur de réaliser un chiffrage plus précis, parce qu’ayant une vision plus détaillée du travail d’intégration et de configuration à réaliser (besoin de mettre en place un import de données CRM ou pas, nombre de sites Web à tracker, nombre de plateformes DSP à interfacer, avec des connecteurs standards déjà existants ou bien des besoins d’intégrations spéciques, etc.)

c – Les bénéfices pour la planification du projet d’implémentation

  • prioriser la réalisation des use cases (ie imports CRM en phase 1 ou phase 2 ; use cases LAL nécessitant un cookie pool déjà conséquent ; etc)
  • matière de base pour prioriser (prioriser sur 3 axes : urgence, importance, délai de mise en oeuvre)

Là encore, les éditeurs de plateformes DMP et leurs équipes projet ont l’habitude de réaliser ce type de projet. Ils sont en mesure de vous conseiller sur un planning et un phasage optimal pour la réalisation de vos use cases. Typiquement, le use case très populaire qu’est le « look alike modeling » est généralement relégué en phase II ou en phase III, car il suppose pour être efficace que la DMP ait au préalable collecté un volume de profils et de données conséquent. On ne met pas en œuvre un « look alike modeling » dans les 3 premiers mois d’un projet DMP. Ca serait juste du temps perdu.

d – Les bénéfices pour le déroulement du projet d’implémentation

  • prioriser les uses cases c’est aussi pouvoir planifier les besoins et les disponibilités des resources. Par ex, on saura que sur la 2ème quinzaine de tel mois, on aura besoin de l’IT pour réaliser l’export depuis le CRM vers la DMP, etc
  • ensemble des uses cases = ensemble des données devant être collectées et des “personas” d’audiences à considérer, donc à partir de là on peut lister les données nécessaires, rechercher les sources de données correspondantes en 1st party, voire le cas échéant chercher à complémenter via de la 2nd party, auquel cas on n’attendra pas la fin de l’implémentation de la DMP pour entamer les discussions de partenariat et le paperwork lié à l’échange des données, ou autre type de contrepartie
  • aussi, in fine, disposer du catalogue de l’ensemble des données à considérer permet d’en déduire et de définir les taxonomies

Et c’est ici sans doute l’argument le plus important : c’est uniquement par l’étude des use cases souhaités et priorisés par le client qu’il sera possible par déduction de lister les données nécessaires devant être collectées par la DMP, et que l’on pourra aussi en déduire les taxonomies pour ces données. Le cas échéant, quand les données nécessaires ne seront pas disponibles directement en 1st Party sur les sites web ou apps du client, on pourra investiguer dans les jeux de données des fournisseurs 3rd Party ou bien imaginer des partenariats de données 2nd Party avec d’autres acteurs.

Quels use cases considérer ?

Les use cases à considérer ne sont pas uniquement restreints à ceux qui répondent à la question : « quel contenu ou quelle bannière vais-je afficher à telle ou telle audience ? ».

Par exemple, c’est le cas de cette chaine d’hôtellerie haut de gamme qui exclue de toutes campagnes de publicité en media display les 5 ou 10% de ses meilleurs clients, qui sont des business travelers et qui réservent déjà naturellement plusieurs nuitées par moi dans les enseignes du groupe. La marque a décidé de ne pas risquer de froisser et d’ennuyer ses clients fidèles avec des publicités inutiles. En revanche, elle laisse aux équipes CRM et aux programmes de fidélisation toute latitude pour s’assurer que ces meilleurs clients seront très bien servis et qu’ils seront satisfaits de leur expérience avant, pendant et après leurs séjours dans l’hôtel.

Bonus : Avoid the “Creep Factor”

Citation de Tom Goodwin de l’agence Zenith (voir à ce sujet mon précédent billet) :

“Millions of conversations in media is about data, distribution and targeting.
Nothing about the actual ad served.”

Quand on imagine les Use Cases, on devrait aussi et surtout se mettre à la place du client final, du prospect. Par exemple, le cas de l’opérateur Telco qui envoie un emailing de promo sur les nouveaux forfaits 4G (ou broadband, disons fibre) à des clients existants qui… ne sont pas éligibles à l’offre parce qu’ils vivent dans une zone/région non couverte. Il en résulte de la frustration du client.

Pourtant l’opérateur détient toutes les données utiles et connait son client.

En principe !


Jusqu’à encore récemment, je fus ingénieur avant-vente spécialisé sur la DMP chez Adobe. Néanmoins, je m’attache ici à présenter le sujet DMP de façon neutre, en restant au niveau des généralités, sauf mention contraire. Ce billet fait partie d’une série de billets consacrés aux DMP. Vous pouvez trouver la liste de ces billets via ce lien.

DMPSeries #5 – Facteurs clés de succès d’un projet DMP

Dans ce billet, j’évoque quelques sujets et points d’attention qui doivent être pris en compte avant de mettre en œuvre une plateforme DMP. C’est un peu un pêle-mêle, mais vous devriez vous y retrouver. Bonne lecture !

Cinquième billet d’une série consacrée aux plateformes DMP.

Je profite de quelques jours de coupure des fêtes de fin d’année pour rédiger et poster le 5ème billet de la série DMP. Le précédent billet date de quelques mois déjà, et j’avais prévu d’en publier 7 ou 8 dans la série. Il était temps que je m’y remette !

Dans ce billet, je vais évoquer quelques sujets et points d’attention qui doivent être pris en compte avant de mettre en œuvre une plateforme DMP. C’est un peu un pêle-mêle, mais vous devriez vous y retrouver.

1 – Avoir des objectifs clairs

Vous êtes sur le point de lancer votre entreprise dans la mise en œuvre d’une plateforme DMP, un projet qui va s’étaler sur plusieurs mois (généralement entre 3 et 6 mois) et qui s’accompagnera d’une facture pour votre entreprise de quelques centaines de K Euros pour la première année, entre les coûts de mise en œuvre et les frais de licence. Parfait.

A ce stade, vous devez a minima avoir les idées claires sur les objectifs recherchés, sur la question de qui est le principal commanditaire et qui sera le « owner » de la DMP et qui l’opèrera au quotidien.

Si, comme la plupart des clients, vous passez par une phase très formelle de RFP pour sélectionner la plateforme DMP que vous mettrez en œuvre dans votre entreprise, prenez soin de bien détailler ces aspects dans le document de consultation. Les réponses que vous recevrez des différents fournisseurs technologiques n’en seront que meilleures.

Ceci se décline directement sur le point suivant (2 – Use Cases & KPIs) et également sur le point 3 consacré à l’organisation.

2 – Use Cases et KPIs

Si vous êtes sur le point de lancer un projet DMP dans votre entreprise, vous devriez disposer des principaux Use Cases (*) que vous voudrez implémenter. Non seulement ceci vous permettra en interne de vous assurer que toutes les parties prenantes sont en phase, mais en plus, ces Use Cases seront très utiles comme base de discussion avec les fournisseurs technologiques afin d’évaluer les capacités de leurs solutions DMP dans _votre_ contexte. Traduction : les descriptifs de ces Use Cases doivent absolument figurer dans les dossiers de consultation RFP.

(*) Pour rappel, le second billet de la série comporte une liste des use cases classiques pour un annonceur.

Un dernier point concernant les Use Cases : de ce côté de l’atlantique, nous n’avons pas la chance d’avoir des audiences aussi importantes que celles de nos voisins nord-américains. Chez eux, tout est plus simple : il leur suffit de quelques use cases basiques d’exclusion pour réaliser des économies conséquentes sur leurs dépenses média en Display RTB, ce qui permet d’assurer le ROI de la DMP.

Dans notre vieille Europe, les audiences sont plus fragmentées et les Use Cases sont ainsi nécessairement plus complexes, voire trop dans certains cas, et au final certains peuvent n’avoir aucun impact sur les dépenses médias. On ne joue pas à armes égales. C’est comme ça. Il faut le savoir.

Si le sujet du ROI de la mise en œuvre de la DMP est un sujet important dans votre entreprise, veillez à réaliser des projections plausibles.

Comment choisir ces Use Cases et combien en retenir ?

Par expérience, suivant le spectre des techniques que vous voudrez utiliser, entre 3 et 10 use cases relativement détaillés permettent de faire le tour de la question. Pensez à indiquer des niveaux d’importance relatifs (mandatory ; important ; facultatif) pour chacun, surtout s’ils sont nombreux.

En général, les dossiers de consultation RFP sont préparés avec l’aide ou parfois intégralement par un prestataire externe, type cabinet conseil ou agence spécialisée. Ces acteurs sont généralement habitués à sélectionner et à prioriser les Use Cases importants.

Comment choisir les KPIs à suivre ?

Au niveau des use cases, mais aussi de façon plus globale, il est important de réfléchir en amont et de se concerter en interne entre toutes les parties prenantes sur les KPIs à suivre au long de la mise en œuvre du projet DMP, et sur les premiers mois de son exploitation.

Ainsi, ces KPIs viseront non seulement à s’assurer de l’intérêt de l’utilisation de la DMP (diminution des coûts d’acquisition ; économies réalisées sur les budgets média Display RTB ; augmentation de la perf des campagnes en CTR et conversions ; diminution du churn des utilisateurs ; augmentation du panier moyen ou de la fréquence des commandes ; performances comparées entre deux DSP ; etc.) mais aussi à suivre et à s’assurer du bon fonctionnement de la plateforme (nombre de visiteurs « cookifiés » ; taux de match en cross-device ; pourcentage des contacts CRM matchés ; etc.)

3 – Organisation & Exec Sponsor

L’organisation tant interne que externe du projet DMP est un sujet primordial, voire crucial.

On a tous entendu parler de projets DMP qui mettent des mois, parfois plusieurs semestres avant de démarrer, où d’autres qui ne démarrent jamais. A mon sens, dans une majorité des cas, les causes sont à rechercher du côté de l’organisation mise en place, ou de l’absence d’organisation mise en place, justement.

En effet, un projet DMP fait directement intéragir des services et des départements qui ne travaillent pas habituellement ensemble : marketing, ventes, le channel, le online, les apps mobiles, la DSI, le légal, les agences média, les partenaires conseil, sans oublier les fournisseurs technologiques. Et ça n’est pas toujours simple.

Aussi, il est primordial de définir une organisation, de distribuer les rôles et les responsabilités, et de nommer un Exec Sponsor qui aura autorité en interne pour faire exécuter ce qui est nécessaire.

Pour définir les rôles et responsabilités, un RACI doit être réalisé et accepté par les différents intervenants internes et externes, et un Chef de Projet doit être nommé. Il ou elle aura le soutien de l’Exec Sponsor qui lui confèrera ainsi la légitimité pour faire décider, exécuter, relancer, mais aussi parfois pour arbitrer et trancher.

4 – Moyens & pré-requis

Ici principalement il s’agira de confectionner une Check List détaillée, revue et validée par le fournisseur technologique retenu, des différents chantiers à réaliser dans l’optique de l’implémentation de la DMP : pose du tag DMP sur les sites Web, revue des plans de marquage du web analytics, modifications du dataLayer, instrumentation des apps mobiles, imports et exports avec le CRM ou le datalake le cas échéant, etc.

Typiquement, on peut rencontrer des cas dans lesquels on s’aperçoit que les plans de marquage du web analytics ne sont pas à jour ou pas à niveau et que ceci devra être réalisé prioritairement et en préalable au démarrage de l’implémentation de la DMP. Avec les délais et les surcoûts que cela va engendrer…

5 – Accompagner le changement

Comme le soulignait Alexandre Azzopardi dans ce billet en Anglais, un projet DMP est souvent considéré – à tort – comme un projet technique. En réalité, il n’en est rien. La composante technique d’une implémentation DMP est quelque chose de bien rôdé et de standardisé.

En revanche, un projet DMP implique généralement des changements dans l’organisation, parce qu’il nécessite de faire collaborer des acteurs qui au préalable ne travaillaient pas ensemble, typiquement la DSI et les agences média, ou le juridique.

Bien que ceci semble être une grosse contrainte, il ne faut pas négliger les aspects vertueux de ces changements d’organisation. Il existe plusieurs témoignages d’entreprises qui ont obtenu des bénéfices inattendus en termes d’agilité et de vitesse d’exécution de leurs campagnes, indirectement du fait de la mise en œuvre d’une DMP.

En conclusion

En synthèse, le point sur lequel je voulais insister à travers ce billet est celui de l’organisation et du partenaire. Dans 9 cas sur 10, une entreprise gagnera à mandater un partenaire (agence média, cabinet conseil, etc) pour l’accompagner sur les aspects de conduite de projet mais aussi de pilotage de la stratégie d’utilisation de la DMP, après sa mise en oeuvre. Bien entendu, ceci représente un coût supplémentaire mais c’est un facteur clé de succès dans la mise en oeuvre d’une DMP, voire le premier facteur clé en termes d’importance.

A suivre

Le prochain billet #6 sera une liste de Do’s and Don’ts à propos de la mise en œuvre et de l’utilisation d’une plateforme DMP. Après réflexion, dans le prochain billet je détaillerai les différentes raisons pour lesquelles la définition des Use Cases en amont d’un projet d’implémentation DMP est quelque chose de crucial. La liste des Do’s and Don’ts est repoussée au billet #7 de la série.


Je suis ingénieur avant-vente spécialisé sur la DMP chez Adobe. Néanmoins, je m’attache ici à présenter le sujet DMP de façon neutre, en restant au niveau des généralités, sauf mention contraire. Ce billet fait partie d’une série de billets consacrés aux DMP. Vous pouvez trouver la liste de ces billets via ce lien.

DMPSeries #4 – Look-alike modeling et données 3rd Party

Dans le précédent billet, j’ai exposé mon point de vue sur la question des avantages et inconvénients respectifs des données 1st Party et données 3rd Party, sans pour autant avoir complètement expliqué ce que sont les données 3rd Party, comment leur utilisation est rendue techniquement possible dans une DMP, ni quels sont ses principaux cas d’usage. Voilà ce que je propose donc de traiter dans ce quatrième billet de la série DMP.

Quatrième billet d’une série consacrée aux plateformes DMP.

Dans le précédent billet, j’ai exposé mon point de vue – très personnel et donc plein de parti pris – sur la question des avantages et inconvénients respectifs des données 1st Party et données 3rd Party, sans pour autant avoir complètement expliqué ce que sont les données 3rd Party, comment leur utilisation est rendue techniquement possible dans une DMP, ni quels sont ses principaux cas d’usage. Voilà ce que je propose donc de traiter dans ce quatrième billet de la série DMP.

C’est quoi, au juste, les données Third Party ?

La définition courte des données Third Party, c’est des données au niveau individu qui sont achetées – ou plus exactement louées à l’utilisation – auprès d’acteurs dont c’est le métier de collecter puis de monétiser ces données : les 3rd party data vendors. En tant que marketeur utilisant une DMP, ces données ne vous appartiennent pas, vous payez souvent à chaque fois que vous les utilisez (avec un pricing soit au CPM, soit un flat fee « all you can eat ») et parfois certains fournisseurs peuvent imposer des restrictions d’usage. Pour citer quelques noms de fournisseurs de données 3rd Party, on peut mentionner les noms de Acxiom, AddThis, Eyeota, eXelate, ou bien encore VisualDNA.

Le besoin

On l’a expliqué dans le premier article d’introduction, la vraie valeur d’une DMP se trouve dans la capacité à enrichir la connaissance d’un visiteur anonyme, et ceci si possible dès la première page visitée, afin que l’on soit en mesure de présenter les contenus et offres les plus susceptibles d’intéresser cette personne.

Concrètement, sur la première page visitée par un internaute, on ne sait presque rien sur cette personne. On peut récupérer des infos techniques (typiquement : est-ce une visite depuis un desktop ou bien depuis un mobile ? quel est son fournisseur d’accès internet ? quelle est la langue du browser ? est-ce que son adresse IP me permet d’avoir une vague idée de sa géolocalisation ? etc.) mais ça reste très faible…

Avant que cette personne ne se profile en créant un compte dans votre site, aucun espoir de savoir si c’est un homme ou une femme, sa tranche d’âge, s’il y a des enfants dans le foyer, quels sont ses centres d’intérêt, ses intentions d’achat, ses habitudes d’achat, ou bien est-ce que cet individu est « in market » pour le genre de produits que je vends, etc.

C’est là qu’interviennent les données 3rd party : En croisant les données socio-démo / intention / intérêt / etc des fournisseurs de données avec les informations de navigation collectées par la DMP dès la première page visitée, on peut commencer à disposer d’un profil assez riche pour pouvoir personnaliser la home page, mettre en avant des promos ou des produits plus en rapport avec les caractéristiques ainsi obtenues sur ce visiteur qui est pour le moment encore totalement inconnu.


Concrètement, on a d’un côté un fournisseurs de données qui possède un ensemble de critères élémentaires (genre ; âge ; pays ; langue ; etc.) ou bien des traits d’intention (Intentionniste achat auto ou bien Intentionniste Nissan ou bien Intentionniste Nissan GTR) ou bien des segmentations prédéfinies (Jeune urbain technophile et gadgetophile), par exemple – et de l’autre côté nous avons notre DMP qui connaît des visiteurs anonymes à travers un identifiant muet déposé dans un cookie. On l’appellera le DMP_ID.

Chez le fournisseur de données, les données sont collectées et stockées au niveau d’un individu (donc pas d’agrégat). La clé de ces données est donc au niveau d’un individu (*) pour le fournisseur de données. On l’appellera DATAUSER_ID.

(*) = Dans les faits, la majorité des fournisseurs de données gèrent l’unicité au niveau d’un device, et n’agrègent pas les profils d’une même personne sur plusieurs devices. C’est ainsi qu’on peut avoir des fournisseurs de données qui annoncent 80 millions de profils pour le marché Français. Mais pour une question de simplification, considérons tous ces profils comme étant des individus.

L’enjeu donc, pour pouvoir utiliser les données 3rd Party dans la DMP, c’est d’être en mesure de dire que l’individu connu de la DMP comme étant DMP_ID = « abcdef » et la même personne (anonyme) que l’individu connu chez le fournisseur de données comme étant DATAUSER_ID = 123456.

Si on est capable de réaliser ce croisement des profils, alors on pourra superposer les données de la DMP (1st party) et les données 3rd party du fournisseur de données.

Question : comment réaliser ceci ? La réponse, c’est un mécanisme très simple mais très malin (dans les deux sens du terme !) et standard au sein des solutions et plateformes de ad-tech : le « cookie sync » ou bien encore « ID sync ».

Parenthèse : le « Cookie Sync » ou « ID Sync »

Vous n’êtes sans doute pas tous et toutes familiers avec la RFC 2109, datant de Février 1997 et émanant de Netscape, et qui décrit les principes de fonctionnement des cookies dans un web browser.

En ce qui nous concerne, l’aspect qui nous intéresse est qu’un cookie ne peut – par design et pour protéger la privacy et la confidentialité – être lu ou modifié que par le domaine qui l’a créé. Ainsi si je vais sur SiteEcommerce.com et que ce site me dépose un cookie de tracking, plus tard en allant sur SiteMedia.fr, ce dernier ne pourra pas lire le contenu du cookie déposé par SiteEcommerce.com, ni même savoir si un cookie existe ou pas.

Pas moyen de me retargeter, dites-donc, c’est dommage non ?

Mais si. Attendez…

Alors voilà, je n’ai jamais vraiment cherché à savoir qui avait en premier mis au point la « ruse technique » du Cookie Sync, mais c’est assez malin, et totalement conforme aux RFC, même si ça va à l’encontre de leur esprit initial. J’ai tenté de représenter visuellement les séquences d’échanges ayant lieu dans un cookie sync sur le graphique suivant.

C’est amusant de constater que tout ceci fonctionne en utilisant uniquement les deux ou trois trucs disponibles dans la boite à outils internet : des requêtes HTTP, des cookies, des redirections HTTP, et des pixels 1×1 transparents. Et en gros, c’est tout.

Ainsi, quand un nouvel internaute visite pour la première fois le site Web de la société Acme.com, le tag JavaScript de la DMP présent dans les pages du site Acme.com va créer un nouveau DMP_ID pour ce nouvel individu, et déposer cet ID dans un cookie sur un nom de domaine appartenant à la DMP (soit un cookie third party, du point de vue du nom de domaine acme.com).

Le tag DMP va ensuite faire un appel server-call vers un pixel transparent chez le fournisseur de données 3rd Party, et va ajouter à la fin de l’URL de l’endpoint la mention du DMP_ID, soit au final une URL qui aurait cette forme :


Le paramètre hypothétique PID serait ici un « Partner ID » informant le fournisseur de données que l’appel provient, dans notre exemple, de la DMP de Adobe.

S’agissant d’une requête HTTP vers le domaine dataprovider.com, s’il existe un cookie de dataprovider.com dans le browser de l’internaute, son contenu est automatiquement envoyé dans les headers HTTP de la requête getpixel.htm. C’est la RFC 2109 qui dit ça. Merci à elle ;)

Ainsi, le fournisseur de données voit arriver une requête sur laquelle il obtient le DMP_ID en paramètre d’URL, et il obtient son propre ID via le cookie dans l’entête HTTP. Le cookie sync est fait du côté du fournisseur de données. Reste maintenant à retourner ça à la DMP.

Or, problème, le endpoint est supposé retourner un pixel transparent 1×1, pas une liste d’IDs. Comment faire ?

Au lieu de répondre à la requête HTTP en renvoyant un contenu, le fournisseur de données va répondre avec un code d’erreur HTTP 302 (=Moved Temporarily) en indiquant une URL… qui est un endpoint vers la DMP Adobe. Et là, de façon symétrique, il suffit à dataprovider.com de rediriger vers une URL telle que :


Dans lequel le PLT serait une indication pour la DMP Adobe de l’identité de la plateforme appelante, soit 999 = DataProvider.com. Et hop le tour est joué, l’échange et la synchro des IDs a bien eu lieu !

Redoutable, non ? :)

Match tables

Ce principe de ID Sync est le même entre les DMP et les fournisseurs de données, mais aussi avec les DSPs, SSPs, AdExchanges, Adservers, etc.

Au final, les DMP gèrent des énormes tables de correspondance pour conserver les valeurs de ID correspondant aux différents profils dans les plateformes externes (DSPs, AdExchanges, 3rd Party data Providers, etc.) Ainsi, quand une DMP envoie un segment d’audience à un DSP tel que AppNexus, elle peut simplement lui envoyer une liste d’ID AppNexus. Le DSP n’a pas besoin de connaitre la correspondance avec l’ID DMP pour pouvoir cibler cet individu. A titre d’illustration, Audience Manager – la DMP de Adobe – gère environ 8,5 milliards de profils actifs au niveau mondial. Ça vous donne une idée de la taille de cette fameuse Match Table.

Comment ça fonctionne, le Look-alike Modeling ?

Passons à autre chose, maintenant que j’ai bien fatigué tout le monde à coup de RFP 2109, d’entêtes HTTP et autres trucs incompréhensibles pour la plupart des marketeurs (ceci n’est pas une critique, c’est normal c’est des trucs relativement assez techniques, quoi !).

Parlons maintenant de Look-alike Modeling. Plus question de cookies et de requêtes HTTP. Non. On va parler ici d’algorithmes et de modèles statistiques. C’est tout. Promis.

Principaux cas d’usage

Le cas d’usage indissociable du Look-alike Modeling c’est celui de l’extension d’audience : une fois qu’on a défini dans la DMP un segment correspondant à une audience particulièrement intéressante, par exemple les individus ayant converti, ou ceux présentant un fort potentiel ou une importante CLV (= Customer Lifetime Value), en tant que marketeur on aimerait pouvoir cibler prioritairement ou exclusivement ce genre de profils, et ne pas dépenser du budget média pour adresser des individus en dehors de cette cible, qui sont a priori moins susceptibles de convertir.

Principe de fonctionnement

Le principe de fonctionnement est d’appliquer un algorithme statistique à un ensemble d’individus, notre segment de référence de prospects à fort potentiel par exemple, afin de pouvoir identifier parmi un ensemble de profils inconnus ceux qui présentent des caractéristiques plus ou moins similaires. En général, on recherchera les individus similaires parmi les profils connus d’un fournisseur de données 3rd Party, et on choisira la taille de l’audience résultante que l’on souhaite obtenir en tant que résultat de la modélisation.

Par exemple, si on est un assureur et qu’on a défini un segment de clients ayant souscrit à des produits d’assurances scolaires, et que ce segment comporte 25,000 individus, on peut soumettre ce segment de référence à une modélisation look-alike, et demander à obtenir en sortie un segment constitué d’une audience de 100,000 ou 500,000 ou 1 million de profils plus ou moins similaires. L’emploi du « plus ou moins similaire » est volontaire, car ceci exprime que plus on souhaitera obtenir un segment large en sortie, plus les individus la constituant seront susceptibles d’avoir des similarités moins fortes avec l’audience de base. C’est un compromis entre le « reach » et la précision par rapport au segment de référence.

Dans le cas de la DMP Adobe – celle que je connais le mieux car c’est celle dont je suis en charge en tant qu’avant-vente – l’algorithme maison nommé TraitWeight est basé sur un algorithme nommé TF-IDF (= Term Frequency / Inverse Document Frequency). Si vous êtes vraiment très curieux, cet algo est décrit ici dans la documentation en ligne de Adobe Audience Manager.

Mais, mais, mais…

Et c’est là que je voulais en venir. Il y a souvent une confusion au niveau de l’intérêt des données 3rd Party entre la qualification des audiences et l’augmentation d’audiences.

Hyper-segmentation = audiences réduites

Plus on ajoute de critères (1st, 2nd ou 3rd Party), et plus on réalise une segmentation fine, alors plus la taille du segment résultant diminue. Un hyper segmentation donnera des segments d’audiences très faibles, qui n’auront que très peu – voire pas du tout – d’impact sur vos objectifs de conversion, acquisition, etc.

Le piège du match-rate

On l’a compris au moment de l’explication du Cookie Sync. Pour pouvoir affiner le profil d’un individu avec des données 3rd Party, il faut que cet individu soit connu à la fois de la DMP et du fournisseur 3rd Party. Concrètement, quand on ajoute un critère de donnée 3rd Party à un segment initialement constitué de données 1st Party (vos visiteurs web), alors de facto on limite la taille de ce segment à l’intersection des individus figurant dans les deux ensembles. Si on a un taux de match de 25% entre notre audience DMP et un fournisseur de données 3rd Party, alors en voulant préciser le profil de notre audience avec des données 3rd Party, on se privera de facto des 3/4 de notre audience. C’est mathématique :)

Et surtout : ne pas confondre Qualification et Extension

In fine, on le comprend bien : si on utilise des données 3rd Party pour qualifier plus finement des profils (ie pour affiner les profils au moyen de données 3rd party supplémentaires), alors on risque de réduire la taille de l’audience résultante. Contrairement à ce qu’on peut lire parfois : Non, la donnée third party n’accroit pas magiquement et d’un seul coup la taille de votre base de données de profils…

En revanche, l’extension d’audience est un mécanisme lié à l’utilisation de modélisations look-alike, en projetant un segment de la DMP vers le cookie pool d’un fournisseur de données 3rd Party, mais dans ce cas, on n’agit pas et on n’améliore pas la connaissance de nos profils dans la DMP.

En conclusion

C’est une confusion qui est assez courante. Il faut avouer que ça n’est pas évident à comprendre de prime abord : il m’a fallu 5 à 6 pages de texte pour l’expliquer relativement clairement. Et il vous aura fallu une bonne dose de patience et de persévérance pour arriver au bout de cet article. Bravo à vous !

A suivre

Le prochain billet portera – peut être – sur les scénarios de données 2nd Party, leur importance et quelques exemples très concrets de case 2nd Party pour les annonceurs. Sauf si d’ici là je choisis de vous parler d’autre chose :)


Je suis ingénieur avant-vente spécialisé sur la DMP chez Adobe. Néanmoins, je m’attache ici à présenter le sujet DMP de façon neutre, en restant au niveau des généralités, sauf mention contraire. Ce billet fait partie d’une série de billets consacrés aux DMP. Vous pouvez trouver la liste de ces billets via ce lien.