Skip to content
Home » DMPSeries #6 – De l’importance d’avoir défini les Use Cases DMP

DMPSeries #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.