Aug 16, 2017
Christophe Lauer

L’analyse de données devient un outil stratégique

shopper-data

Au hasard de ma veille, je suis tombé dernièrement sur cet article qui a retenu mon intérêt, et j’avais envie de vous le partager tout en mettant en lumière certains passages.

Cet article commence ainsi, par le chapeau suivant :

« Hier encore réservée aux statisticiens, l’analyse des données est aujourd’hui à la portée des spécialistes du marketing dans les entreprises. Les outils sont devenus faciles à manier et à peu près compréhensibles pour le commun des mortels. Le procédé a gagné en vitesse. Aujourd’hui, on obtient en quarante-huit heures une segmentation qui demandait plusieurs mois auparavant. »

Et puis cet article démarre en nous expliquant que « l’analyse des données est aujourd’hui au cœur de la chaine de la valeur client ». On peut difficilement être plus d’accord avec ceci, sachant que de nos jours il est quasiment impossible dans le domaine du marketing de ne pas entendre parler de « Data driven marketing », de « Big data » ou bien encore de « predictive analytics » et d’intelligence artificielle.

Cependant, que l’on ne s’y trompe pas, si le principe est séduisant, sa mise en œuvre doit se faire avec méthode parce que « les masses d’informations à traiter sont colossales. Cela inspire une démarche prudente, surtout lorsque l’on prend en compte le retour sur investissement ». Effectivement, si la démarche doit s’inscrire dans la recherche d’un ROI à court ou moyen terme, on prendra garde à évaluer les coûts directs et indirects (plateformes techniques, stockage de données, licences de solutions d’analyse, honoraires de consultants et de data scientists, etc.) en regard des bénéfices induits par la fidélisation ou un meilleur ciblage publicitaire.

Ensuite, l’article cite quelques cas dans plusieurs industries, à commencer par les telco et la finance : « L’opérateur de télécommunications Sprint fait appel à l’analyse des données dans le cadre de son programme de fidélisation pour ses 23 millions de clients. Il aurait réussi à réduire le taux d’attrition en élaborant des offres ciblées pour les clients multiproduits ». Voilà bien un sujet d’actualité : être en mesure de segmenter ses audiences de prospects et de clients, pouvoir proposer des offres adaptées à chaque profils en vue de lutter contre l’attrition, et en cherchant à développer l’équipement multiproduit chez ses clients.

Dans la finance : « Les banques demandent des outils simples et surtout automatisés dans toutes les analyses d’informations sur le comportement des clients (…) Même démarche d’ailleurs que dans la téléphonie : le scoring doit être fait en temps réel ». Grâce aux récentes avancées technologiques, les outils ont gagné en simplicité et offrent des possibilités d’analyse en quasi-temps réel, ainsi, « on peut réagir aux premiers retours d’une campagne test en quarante-huit heures, pour vérifier l’adéquation du message ». J’ai envie de répondre « Alléliua, Welcome to Data Driven Marketing ! », tant ce genre de besoin est présent chez un grand nombre d’entreprises.

Autre sujet abordé par cet article, celui qui se penche sur les préférences et les habitudes des clients afin de maximiser le ROI : « Comment repérer les clients les plus rentables, ceux qui couvrent 80 % du chiffre d’affaires ? Quels types de communication doit-on investir pour toucher ces clients ? Quelle est leur affinité par rapport à tel ou tel canal ? ».

Enfin, l’article aborde un point crucial : celui de la qualité des données. Parce qu’avec des données de mauvaise qualité en entrée, ou incomplètes, les meilleurs outils et les meilleurs algorithmes ne pourront pas faire de miracle. On nous dit ainsi que « l’actualité et la cohérence des données constituent le facteur-clé de la réussite. Il faut savoir traiter une masse d’informations stockées sur différents supports et systèmes. La qualité des données est responsable à 70 % du succès. Le reste dépend de la méthode utilisée pour l’analyse ».

Parce que, n’oublions pas que tout ceci s’inscrit dans une démarche de recherche de performance opérationnelle, et que « chaque somme investie dans une prédiction doit aboutir à une augmentation du taux de fidélité, d’achat ou de réponse. C’est le seul critère de rentabilité d’un programme ».

A ce stade, je pense que vous et moi sommes totalement convaincus par les bénéfices et la nécessité de mettre en œuvre des solutions de collecte et d’analyse des données client dans vos process de marketing.

Je vous invite à lire l’intégralité de cet article, maintenant que j’ai – je l’espère – attisé votre curiosité.

Ah aussi, juste un dernier point. J’allais oublier. L’article en question est daté de décembre 2001. Décembre 2001 !

Plus de quinze ans plus tard, le sujet reste terriblement d’actualité, comme le prouvent ces quelques tweets pris au hasard :

 

 

 

 

 

[Ce billet avait été initialement publié sur le blog Emakina]

Mar 4, 2017
Christophe Lauer

Predictive Analytics, ou le cache-sexe de la donnée

TL;DR

  1. 1 – Les solutions d’Analytics sont au fil du temps devenues très puissantes, mais aussi très complexes
  2. 2 – En entreprise, l’exploitation de l’analytics et du web analytics reste basique, voire parfois quasi inexistante
  3. 3 – Les éditeurs de solutions vendent l’idée que l’IA couplée aux outils de marketing permet d’obtenir des résultats sans besoin d’injecter de l’intelligence humaine
  4. 4 – En l’absence d’intelligence humaine, les solutions de Predictive Analytics sont elles aussi vouées à l’échec
    1. Intro

      2017 : c’est année des bots et de l’IA. En résumé, ce qu’on entend quasiment quotidiennement, c’est : « Si tu n’utilises pas d’intelligence artificielle ou du machine-learning pour piloter ton business, tu vas rater ta target. »

      Et si on avait un doute, les éditeurs de suites marketing enfoncent le clou et nous parlent tous les jours de leurs intelligences artificielles maison.

      Chez IBM, les technologies cognitives s’appellent collectivement « Watson ». Chez Salesforce, on nous parle de « Einstein » – pas besoin de sortir de Polytechnique pour comprendre que Einstein c’est quelqu’un de beaucoup plus intelligent que nous.

      Chez Adobe, c’est « Sensei », ce nom inspire plus la confiance envers un Maître dont les oracles (no pun intended) sont parfois difficiles à interpréter pour un mortel, mais ne devraient jamais être remises en cause :)

      Qu’est-ce que le Predictive Analytics ?

      (c) Dilbert

      Plus sérieusement, le Predictive Analytics, c’est un ensemble de technologies utilisant des données, des algorithmes statistiques et de machine-learning en vue de déterminer la probabilité de l’occurrence de faits futurs par l’observation de faits et données passées.

      On pourrait préciser un peu plus en disant qu’il existe deux grandes catégories : les algorithmes purement statistiques et utilisant diverses sortes de régressions sur des ensembles de données temporelles, et une autre catégorie basée sur les techniques de machine-learning (réseaux de neurones, deep-learning, etc.).

      Predictive Analytics : une idée nouvelle ?

      Non. L’idée n’est pas nouvelle. Simplement de nos jours elle s’appuie sur le big data et le machine-learning.

      Il y a 30 ans de cela, en 1986, alors que j’étais encore étudiant, j’étais en stage chez IBM dans l’entrepôt de préparation de commandes entièrement robotisé de Evry-Lisses, et j’avais travaillé sur un logiciel collectant des données liées au fonctionnement, anomalies et pannes de divers équipements à des fins de maintenance préventive. Par exemple, un chariot autonome filoguidé sur lequel on constatait un nombre d’anomalies de pertes de signal de guidage en augmentation hors-normes, était sorti de la ligne de production et envoyé en maintenance avant d’avoir causé une panne plus profonde, voire une interruption de toute la ligne.

      Plus récemment, vers 1997 j’étais en mission à Evry dans la biscuiterie Belin-LU où le service marketing avait développé un système de prévision des ventes, collectant des données de remontée de tickets de caisse afin de prévoir les ventes par produit, famille de produit, quantités et conditionnement afin de piloter les unités de production. Les biscuits sont fragiles et ont des DLC courtes. Produire de grosses quantités à l’aveuglette sans avoir une idée des niveaux de demande à venir, c’est assurément aller vers des volumes de retours massifs, et de la perte de bénéfices – sans même parler du gâchis de matières alimentaires.

      Egalement, on a toutes et tous déjà entendu parler de GFT : Google Flu Trends. Or, même pour Google, ça n’était visiblement pas aussi facile que la légende le disait : Le service a fermé en 2015.

      Bref, assez d’histoire ancienne…

      Le Predictive Analytics qui marche

      Mon propos ici n’est pas de dénigrer tout le domaine du Predictive Analytics. Il est des domaines – comme celui évoqué précédemment lié à la maintenance préventive des équipements et matériels – qui fonctionnent et donnent de bons résultats. Dernièrement, la SNCF a annoncé utiliser des technologies IBM Watson sur ces mêmes problématiques.

      Marketing et Predictive Analytics

      En revanche, il y a un domaine du Predictive Analytics pour lequel j’ai une approche, disons, plus nuancée, voire carrément critique. C’est le domaine du Predictive Analytics lié aux données marketing et appliqué au marketing digital.

      Il est effarant de constater le nombre d’entreprises, de marques et de business de tous types, dans lesquels la culture de la donnée est encore quasi inexistante, et cela à tous les niveaux : on réalise des campagnes d’affichage en extérieur sur des affiches 4×3 ou sur du mobilier urbain mais… on n’a mis en place aucun processus pour récupérer de la donnée de tickets de caisse afin d’évaluer l’impact de la campagne sur les ventes. Ou bien on a encore des approches de campagnes marketing Print / Online / Social / etc qui sont totalement en silos, sans cohérence et sans aucun souci de répartition ou d’optimisation en fonction de l’attribution des ventes à ces points de contact. Les budgets sont pilotés par des services différents. Ou bien, encore, et de façon plus classique : on a bien mis en place une solution de Web analytics – gratuite ou payante, peu importe à ce niveau –  mais on ne fait quasiment aucune exploitation des données collectées, et les rapports produits en sont encore quasiment du niveau « nombre de visiteurs uniques / nombre de pages vues ». Nous sommes en 2017.

      Ce nom de « Web analytics » est un terme très réducteur, et quasiment plus adapté. Les plus avancées de ces solutions permettent de nos jours en plus des données d’activité sur les sites web de croiser les chiffres du mobile, mais aussi d’y injecter des données et attributs provenant de votre CRM, afin de pouvoir affiner les analyses. Les outils d’Analytics donc sont devenus très complets, et très puissants.

      Trop, peut être ?

      Concrètement, qui dans votre organisation sait se connecter à votre solution Analytics, sait identifier les données intéressantes, peut produire un rapport ad-hoc permettant de comparer les comportements de deux cohortes distinctes ou pourrait analyser les causes d’un pic de trafic en anomalie ?

      Cherchez bien. Peu de gens, certainement. Personne, parfois.

      Predictive Analytics : le cache-sexe de la donnée

      J’imagine qu’à un moment, les grands éditeurs de suites marketing ont été lassés de créer des solutions de plus en plus puissantes, mais de moins en moins bien utilisées par leurs clients. C’est le paradoxe de ces solutions devenues tellement puissantes qu’elles ont développé un côté si intimidant que finalement peu d’entreprises sont en mesure de les exploiter correctement, et n’en ont finalement qu’une utilisation basique.

      Or, parmi ces clients ne réalisant pas la valeur de la solution qu’ils s’étaient offerts, certains étaient tentés de basculer vers le gratuit « good enough » au moment de renouveler le contrat : passer à Google Analytics Standard. Pour suivre leur business. Comme s’il s’agissait de leur blog perso. En 2017.

      Alors, depuis, les éditeurs ont compris la leçon et face à l’alternative entre produire des solutions très puissantes mais complexes, ou bien tenter de simplifier à outrance au risque de produire des outils simplistes, ils ont ouvert une troisième voie : celle de l’intelligence artificielle et du Predictive Analytics.

      Avec Watson, Einstein et autres Sensei, c’est la promesse de plateformes intelligentes, qui sont capables de faire automatiquement tout le travail d’analyse, de diagnostic voire de poser les actions correctives et de lancer les activations, de façon automatique, et sans aucun besoin d’intelligence humaine.

      Bingo. L’argument fait mouche. Le Predictive Analytics est un must have.

      Ce que certains ont oublié, c’est que, peu importe les souches algorithmiques de ces solutions (statistiques, machine-learning, etc.), elles ont besoin de données en quantité afin de produire des résultats. Et que, pour comparer vos chiffres de cette année, à ceux de l’année dernière… il faut au moins 1 an d’historique dans vos données. Damned. Ces solutions n’apporteront pas de réponses magiques overnight. L’an prochain, peut-être. Au mieux. Et d’ici là, vous allez devoir dresser la machine pour qu’elle apprenne que les soldes, les fêtes de fin d’année et la St Valentin sont des anomalies… normales :)

      Reprenez le contrôle de vos données !

      Nous sommes en 2017. Le marketing est définitivement Data Driven. Les expériences qu’attendent vos clients et vos consommateurs sont également construites sur des Insights qui sont tirés de l’analyse de données.

      Reprenez le contrôle de vos données. L’investissement dans des solutions de pointe ne dispense en aucun cas d’investir dans des collaborateurs ou des partenaires qui pourront vous accompagner et sauront en tirer toute la valeur.

      Faites-vous aider. Ces investissements sont payants.

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.

Pages:1234567...19»

A propos


A propos : Head of Customer Intelligence at Emakina.FR.
Ex-Adobe ; ex-Microsoftee.
Je vis entre Paris et New-York entre Paris, un scooter et deux avions, et ceci est mon blog personnel.
"Opinions are mine. Best viewed with a brain. Yada yada ..."

More about me...