Feb 12, 2017
Christophe Lauer

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

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 !

Disclaimer

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.

Jan 25, 2017
Christophe Lauer

Data Marketing : Funnel de conversion et Creep factor

Ce billet n’est pas un billet de la DMP Série, juste pour varier un peu les plaisirs. Néanmoins, il parle tout de même de data marketing. Ces réflexions m’ont été en partie inspirées par ce tweet de Tom Goodwin de l’agence Zenith :

La question est pour partie celle d’adapter le contenu des messages en fonction de la progression d’un prospect au long du funnel de conversion, et donc, en fonction de la progression de la proximité entre ce prospect et la marque.

En effet :

° Plus un prospect progresse au long du funnel de conversion, et plus on dispose de données le concernant

° Plus un prospect progresse au long du funnel de conversion, et plus nos messages vont pouvoir évoluer de contenus de type “branding” relativement neutres vers des messages serviciels voire trigger ciblés et basés sur les données de comportement et d’intention de ce prospect

° Plus un prospect progresse au long du funnel de conversion, et plus son acceptation pour des communications “personnalisées” sera grande, et plus il sera en demande de valeur sous la forme d’aide et de service dans son processus d’achat.

A contrario :

Un email retargeting envoyé après une simple première visite sur un site web est généralement mal perçu, même si on était authentifié sur le site en question. Qui n’a jamais vécu ça par exemple sur Amazon, qui (à ma connaissance) utilise les services de Tedemis pour opérer ses email retargeting. “Hello Creepy!”.

SVP mesdames et messieurs les marketeurs, ne perdez pas de vue que vous devez donner envie aux consommateurs finaux, pas les braquer et leur rendre la marque hostile et désagréable. Dans la conception et la mise en place de vos use cases, veillez à les étudier aussi sous l’angle du “Creep factor”.

Idem pour un email de relance reçu quelques heures après un abandon de panier. Merci, on est en 2017. Je sais faire un checkout complet, entrer un captcha, saisir le numéro de ma CB et le code 3D Secure reçu sur mon mobile. Je sais faire ça par coeur. On est en 2017 !

Alors si vous m’adressez un email de relance quelques heures après que j’ai abandonné le processus d’achat, alors que je ne vous ai rien demandé, ma réaction risque fortement d’être la même que vis à vis du célèbre assistant Clippy de Microsoft : merci pour ton aide mais je n’ai besoin de rien et je ne t’ai rien demandé. Et comme avec Clippy, ça me donne envie de te “désinstaller” !

Jan 4, 2017
Christophe Lauer

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

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.

Disclaimer

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.

Aug 24, 2016
Christophe Lauer

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

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

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.

Cookie Sync 101

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 :

http://dataprovider.com/endpoint/getpixel.htm?DMP_ID=abcdef&PID=42

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 :

http://adobedmp.com/sync/endpoint?DATAUSER_ID=123456&PLT=999

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.

Match Table dans une DMP

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 Modeliing ?

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.

Look-alike Modeling

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 :)

Disclaimer

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.

Jul 11, 2016
Christophe Lauer

Histoire sans paroles

May 22, 2016
Christophe Lauer

DMPSeries #3 – Données 1st Party vs données 3rd Party

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

Dans le premier billet de cette série consacrée aux plateformes DMP, on avait défini quelles sont les données classiquement utilisées dans une DMP, et on avait rapidement donné la définition des 3 principaux types de données dans une DMP :

- First Party Data

Les données First Party sont toutes les données qu’une marque ou un annonceur va pouvoir collecter du fait d’une interaction directe avec un individu : via une visite sur le site web de la marque, via l’utilisation d’une appli mobile, via une commande en ligne, via un achat ou la souscription à un abonnement, mais aussi via des contacts « offline » (programmes de fidélisation, couponing, etc.) dont les données se retrouvent généralement dans les bases CRM de la marque.

- Second Party Data

Les données 2nd Party sont essentiellement des données collectées sur des sites web qui n’appartiennent pas à la marque, mais qui sont ceux de sociétés ou d’acteurs avec lesquels la marque aura conclu des accords de partenariat spécifiques comportant un accord – financier ou non – sur l’échange ou le partage de données.

Je consacrerai un prochain billet spécifiquement au sujet des données 2nd Party et à limportance de mener une réflexion en profondeur sur ce sujet dans le cadre dun projet DMP.

- Third Party Data

Enfin, les données Third Party, qui sont collectées et fournies – généralement vendues ou plutôt louées à l’acte et au CPM – par des tiers spécialisés, tels que Acxiom, AddThis, Eyeota, eXelate, VisualDNA, pour ne citer que quelques noms.

Dans les DMP, les données 3rd Party sont généralement accessibles via une marketplace de données, dans laquelle les marketeurs peuvent explorer ces données, observer leur recouvrement ou au contraire leur distance avec leurs propres données et activer ces données, selon leurs besoins et leurs objectifs.

Le paradoxe des données 3rd Party

Il y a un paradoxe certain autour des données 3rd Party : en phase amont des projets DMP, les données 3rd Party sont bien souvent perçues comme étant la « Silver bullet », la solution magique qui va enfin permettre de profiler et de connaître très précisément tous les visiteurs anonymes du site de la marque, et d’avoir donc une « vision 360° de ses audiences » grâce à des profils « enrichis avec de la données 3rd Party ». Avec les données 3rd Party, c’est la promesse de pouvoir qualifier et profiler les internautes inconnus dès leur première visite. Le rêve de tout marketeur.

Aussi, le sujet des données 3rd Party occupe t’il bien souvent une part importante des discussions en amont des projets DMP.

Toutefois, et c’est là tout le paradoxe, l’utilisation de données 3rd Party par les marques exploitant une DMP est finalement minoritaire, pour ne pas dire carrément rare. Mais ce n’est finalement pas étonnant, ni nécessairement une mauvaise chose.

Le fait est que les données 3rd Party tendent un peu à passer de mode, et qu’actuellement les reproches qui leur sont généralement faits sont les suivants :

  • - elles ont un coût, et parfois un coût non négligeable. Or, on se souvient que l’un des principaux objectifs de l’utilisation d’une DMP est l’optimisation des dépenses des budgets média
  • - on peut parfois questionner leur fiabilité et leur fraicheur (*), et donc leur utilité et leur efficacité : lorsqu’un fournisseur de données 3rd Party propose un segment d’intentionnistes achat automobile comptant plus de 7 millions de profils sur le marché Français, on peut se poser quelques questions sur leur fraicheur et leur valeur…
  • - enfin, ces données sont en quelque sorte publiques, et vos concurrents peuvent donc parfaitement y avoir accès au même titre que vous, et effectuer des segmentations similaires. Où se situe alors votre avantage business ?

ASTÉRIX® & OBÉLIX® / © 2016 LES ÉDITIONS ALBERT RENÉ / GOSCINNY-UDERZO

“Pas frais, mon poisson ?”

(*) Edit du 6 janvier 2017 : Un article paru hier sur Digiday traite du sujet de la qualité parfois douteuse des données 3rd Party (en Anglais). A la lumière de tests et d’analyses, ChoiceStream – un organisme indépendant – a trouvé qu’un fournisseurs de données identifiait 84% de ses profils comme étant à la fois de genre masculin et féminin. C’est gênant. Si un Data Provider a déjà autant de mal à fournir des données fiables sur du socio-démo, imaginez ce que ça peut donner sur de la donnée d’intention. Vertige.

Les données 1st Party : un joyau sous exploité

Ce n’est pas une surprise si, selon une enquête publiée par Radar Research / Bluekai (**), la fonctionnalité la plus importante aux yeux des utilisateurs de DMP réside dans la capacité à collecter des données 1st Party (les données 3rd Party n’arrivant qu’en 7ème position).

BlueKai-Most-Valuable-DMP-Features-Dec2012

Source : Radar Research / Bluekai, Décembre 2012

Contrairement aux données 3rd Party, les données 1st présentent les avantages suivants :

  • -       Ce sont des données qui appartiennent à la marque, dont on sait précisément où, quand et comment elles ont été collectées
  • -       Ces données sont collectées – si besoin – avec un opt-in, et elles sont gratuites : vous pouvez ainsi les utiliser autant de vous avez besoin, il n’y a pas de CPM à prendre en compte
  • -       Ces données sont un vrai différenciateur business : par définition, vos concurrents n’y ont pas accès

Mais les données First Party ont un inconvénient de taille : on n’en a jamais suffisamment. Et comme on le disait dans le billet d’introduction, toutes les industries et tous les verticaux ne sont pas à égalité : certains vont bénéficier de visites fréquentes et qualifiées sur leurs sites web (voyagistes, hôtellerie,  banques, opérateurs telco, etc.) alors que d’autres seront moins favorisées (automobile, assurances, et surtout tous les produits vendus par des distributeurs, en particulier les CPG).

Malgré tout, et ceci vient confirmer ma thèse sur la valeur des données 1st Party, même dans le cas des marques CPG, les données 1st et les DMP peuvent représenter des opportunités, comme l’explique parfaitement Chris O’Hara de Krux (**) dans ce billet de blog.

En conclusion

Les données 1st Party sont de première importance (no pun intended) dans le succès d’un projet DMP. Les données 3rd Party sont un “nice to have” qui présentent surtout un intérêt dans certains cas particuliers, et également dans l’utilisation de modélisations « look alike » dans des logiques d’acquisition. Parfois peu considérée ou peu valorisée en interne en début de projet DMP, la donnée 1st Party ne tarde pas généralement à montrer son potentiel et son intérêt, à mesure que le projet et l’équipe opérant la DMP avancent en connaissance et en maturité sur ces sujets.

A suivre

Le prochain billet portera, très logiquement et pour rester dans la continuité, sur les données 2nd Party, leur importance et quelques exemples très concrets de case 2nd Party pour les annonceurs.

Disclaimer

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.

 

(**) Bluekai / Oracle et Krux sont des éditeurs de solutions DMP, concurrentes à celle de mon employeur, Adobe Systems. Je n’ai bien entendu aucune relation avec l’un ou l’autre de ces deux concurrents, et je les cite ici purement dans une démarche œcuménique :)

Pages:1234567...19»

A propos


A propos : Business Director chez Emakina.FR.
Ex-Adobe ; ex-Microsoftee.
Je vis entre Paris et New-York entre Paris et deux avions, et ceci est mon blog personnel.
"Opinions are mine. Best viewed with a brain. Yada yada ..."

More about me...