Webinaires Replay
Webinaire Qualité des Données 2021 02 25
73 views
Ce que vous allez retirer du replay de cette table ronde virtuelle :
- tracking de l'acquisition des leads
- enrichissement de données
- alertes
- fusion des doublons
- pour l'enrichissement de données (CaptainVerify et Dropcontact)
- pour la détection de doublons et le dédoublonnage automatisé (Cloudingo)
4. Questions - Réponses
View transcript
Bonjour à tous et bienvenue à notre webinaire sur la data quality ! Donc, je suis Sylvain Davril, fondateur de Merlin/Leonard. Si vous souhaitez me contacter, je vous laisse mon adresse ici. Aujourd'hui, je vais vous ouvrir mes solutions et mon marketing automation pour vous montrer ce qu'on a mis en place, chez nous, sur la data quality. Alors, pourquoi la data quality ? J'ai juste une stat toute simple, qui est donnée par Harvard Business Review, qui montre : une tâche effectuée avec une donnée erronée engage un coût 100 fois supérieur à celui d'une tâche réalisée à partir d'une donnée vérifiée ou correcte. Cette simple stat montre, pour moi, que la data quality est vraiment un sujet prioritaire, parce qu'on n'a jamais assez de temps en marketing. On a trop de choses à faire, donc on ne peut pas se permettre de perdre du temps sur des sujets aussi basiques que la mauvaise qualité de données. L'autre point, c'est qu'aujourd'hui, avec les campagnes marketing qui se sont généralisées et l'exposition de nos données internes à l'extérieur, le sujet data quality est devenu un sujet d'expérience client. C'est-à-dire : si vous exposez à l'extérieur de la mauvaise qualité de données, instantanément, ça va se traduire par des gens que vous allez appeler monsieur alors que c'est une femme. Vous allez vous tromper sur les prénoms. Vous allez envoyer plusieurs fois un e-mail à la même personne sur ses différents e-mails. Donc tout ça, c'est autant de mauvaise qualité de données qui va vous faire perdre des leads, du pipe et du revenu. Donc, il faut absolument s'en occuper. Pour adresser ce sujet, j'ai créé ce petit schéma. Alors, chez nous, on a le thème de l'hydre autour de la data quality. C'est vraiment le monstre à plusieurs têtes qu'il faut abattre, avec tous les chantiers autour de la data quality. Et j'ai référencé tous ces chantiers à travers un cycle de vie de la donnée. Donc ici, on a le passage du temps. On va avoir tout ce qu'on peut faire avant que la donnée ne soit présente dans vos systèmes, pour éviter que la mauvaise qualité entre. Tout ce qu'on fait vraiment juste après l'entrée, tout ce qu'on fait peu après l'entrée : l'intégration, enrichissement, dédoublonnage. En cours de vie, on va plutôt avoir les traitements de masse. Et ce qu'il ne faut pas oublier de faire à la fin de la vie de la donnée. Donc, je vous propose, pendant ce webinaire, que je vous montre un peu tout ça. Alors, je ne vais pas forcément tout montrer puisqu'on a que 40 minutes et ça va prendre pas mal de temps. Et je n'ai pas tout mis en place encore chez moi. Il y a tellement de choses à faire que je prends les chantiers un par un et je les fais. Le premier sujet va porter, évidemment, sur : comment faire en sorte d'éviter de faire entrer de la mauvaise qualité ? Et ça va passer, en grande partie, par deux actions : la façon dont vous allez paramétrer vos formulaires pour vos visiteurs et vos prospects de l'extérieur. Et la façon dont vous allez paramétrer votre CRM, qui est une autre grande source d'entrée de données, cette fois-ci plutôt en interne, pour vos commerciaux. Alors, si je prends un exemple, chez moi, d'un formulaire qui ressemble peu ou prou à celui que vous avez dû entrer pour s'inscrire à ce webinaire, ici, on va avoir plusieurs choses : donc, le premier point, c'est que ici, j'ai un Google Recaptcha qui va me permettre d'éviter que des bots, déjà, ne remplissent mes formulaires et ne perturbent la donnée. Donc, ça c'est un premier point à faire : sécuriser ses formulaires pour éviter les attaques par bots. Le deuxième point ici, on va voir que, par exemple, pour le champ pays que j'ai décidé de mettre en place, évidemment, j'ai mis une liste de valeurs. Il fut un temps où je n'avais pas de contraintes sur le pays et je rentrais ce qu'il voulait. Et donc, effectivement, en France, on a peu de chances de l’orthographier incorrectement, si ce n'est que ça peut être France, FR, FR1. Mais voilà, le Royaume-Uni : United Kingdom, UK. Il y a plein de façon de l'orthographier. Donc, une des grandes règles qu'on va mettre en place, à la fois dans le marketing automation et dans le CRM, c'est d'utiliser des listes de valeurs qui sont contraintes et dans lesquelles on ne peut pas sortir. On ne peut pas mettre ce qu'on veut. Donc là, si j'essaie de rentrer une valeur qui n'est pas dans la liste, je ne pourrai pas. Donc, évidemment, c'est important que la liste soit partagée et soit la même entre tous les systèmes, que ce soit le marketing automation, le CRM, les systèmes DAF, l'administration des ventes. Tous les systèmes qui vont utiliser le champ pays doivent avoir ce référentiel. Et donc, ça nous amène au sujet du référentiel : vous devez avoir, quelque part, un dictionnaire de données qui va référencer tous les champs et leur signification métier, et aussi la liste des différentes valeurs autorisées, quand ces champs sont des listes de valeurs. Ça, c'est vraiment important et je le vois assez rarement. Ce qui engendre systématiquement des divergences de données. Donc, on verra juste après comment, éventuellement, corriger la donnée quand il y a quand même de la mauvaise qualité, donnée de qualité qui rentre dans ce champ, par exemple, à travers un import. Ce serait possible. Autre chose qu'on va voir ici : un consentement. Donc là, j'ai un consentement spécifique pour mes événements, qui est : oui, non. Donc, ce n'est pas une case à cocher. C'est vraiment fait exprès. C'est qu'ici, je vais bien différencier la valeur vide, la valeur oui, la valeur non. Ce qui fait que derrière, pour faire mes ciblages des événements suivants, je vais pouvoir utiliser ce consentement. Donc, je ne me trompe pas sur ce que j'utilise. Est-ce que j'ai le droit d'utiliser la donnée, pas la donnée ? Ici, j'ai un champ très précis qui me dit si j'ai le droit d'utiliser cette personne dans mes futures campagnes, événements, webinaires, tradeshows. C'est ce qu'on retrouve sur mon centre de préférences, ici. C'est les mêmes champs. Donc, la personne peut mettre à jour l'ensemble de ses consentements, suivre les événements, la newsletter, les formations, les marketo office hours, le thought leadership. C'est extrêmement pratique et ça permet de gérer correctement la RGPD. Dernier point : alors, je ne l'ai pas mis en place chez moi, mais on pourrait aller jusqu'à ici. Si je tape : M-E-R, On pourrait avoir un système qui serait connecté à une base externe et qui irait chercher toutes les entreprises qui sont dans la base qui commencent par mer. Et on aurait ainsi Merlin/Leonard. Donc, ça, ça permettrait quoi ? Ça permettrait de sécuriser l'entrée des entreprises, qui est une source de qualification, de travail manuel assez important parce que, évidemment, il y a plein de façons d'orthographier, généralement, entre entreprises. Et il y a toujours cette étape, à la transmission entre le marketing et les ventes, où il faut trouver la bonne entreprise. Est-ce qu'elle existe déjà ? Est-ce qu'elle n'existe pas déjà ? Donc, si on contraint le formulaire dès l'entrée avec des entreprises possibles, les entreprises pas possibles, ça permettra de gagner du temps derrière. Alors, il faut que ce soit fait intelligemment parce que, évidemment, il y aura toujours des entreprises qui ne seront pas dans le système. Donc, il faut quand même autoriser qu'on puisse entrer des données non listées. Le dernier point que j'ai mis en place sur mon formulaire, c'est le fait que je puisse bloquer des e-mails personnels. Alors évidemment, il faut que je rentre tous les champs sinon il ne va pas être content. Voilà. Ici, il a détecté que j'ai rempli un gmail.com, mais ce serait pareil avec YOPmail, avec Yahoo, et ainsi de suite. On a mis un script qui protège l'entrée des e-mails avec des domaines personnels parce que là, je considère que je souhaite avoir une adresse e-mail. Alors, si j'allais au bout de l'expérience client, j'aurais dû mettre une petite note qui dit que, si vous tenez vraiment à vous inscrire avec une adresse personnelle, passez par mon tchat bot ici. Je ne l'ai pas fait. Ce sera quelque chose à faire pour plus tard. Donc ça, ça évite l'entrée massive d'adresses e-mail qui ne sont pas forcément faciles à utiliser dans les campagnes marketing derrière. Donc, voilà ce qu'on peut faire pour la partie formulaires, pour la partie CRM. Mais si je vous montre à quoi ressemble, chez moi, une page d'entrée de contact, ce n'est pas très joli. Je suis encore sur la version classique de Salesforce. Mais vous voyez que, quand on doit entrer un contact, on doit entrer ces champs-là plus un champ de contact. Donc, il n'y a pas trop de champs. Et j'ai essayé de faire en sorte que tous les champs qui sont calculés automatiquement, ils aient le petit c. Donc ça veut dire qu'on va rentrer le job title. Et derrière, le rôle, le statut, le lead status. Tout ça, ça va être calculé automatiquement. La salutation aussi, elle est calculée automatiquement. Alors, malheureusement, on ne peut pas changer le libellé ici. Mais je sais que ce champ est calculé, donc je n'ai pas à l'entrer. Donc, en fait, j'ai juste à entrer nom, prénom, account, si je tutoie la personne et son job title. Et puis, un téléphone ou un e-mail et c'est bon. Ici, le service. Donc, par exemple, on le verra juste après : j'ai des campagnes qui vont me déduire le rôle décideur ou le service de la personne en fonction de son job title. Je vais avoir des campagnes qui vont me déduire l'assiduité à partir du prénom. Et je vais avoir les systèmes externes qui vont me remplir, soit les e-mails, soit le profil LinkedIn, soit l'adresse. Là, je vais pouvoir aller chercher des données à l'extérieur qui remplissent automatiquement les champs. Donc, l'idée, c'est de faciliter la vie de vos commerciaux. Il faut avoir conscience que les commerciaux n'aiment pas remplir les CRM. Ce n'est pas possible. Ça n'existe pas, ça. Et donc, plus vous simplifierez la vie de votre commercial, plus il rentrera de données dans le CRM de façon correcte. Mais, c'est dommage de lui faire faire de la saisie de données parce que son temps est précieux. Il a autre chose à faire. Il faut le mettre en face des clients et qu'il signe des affaires, et pas qu'il soit dans le CRM, à passer deux heures à rentrer des contacts, des opportunités. Ça, ce n'est plus possible aujourd'hui. Donc, généralement, il y a un gros travail à faire sur les CRM. Alors, ce n'est pas simple parce qu'il faut discuter avec la direction commerciale, avec la DSI. Ça nécessite des gros projets. Ce n'est pas aussi simple que de travailler, parfois, sur le marketing automation. On a vu les champs verrouillés, les champs liste de valeurs sur le formulaire et dans le CRM, qui sont en miroir, le Google ReCaptcha, les champs obligatoires dans le CRM sur le contact. Mais il ne faut pas trop en mettre. Chez moi, je n'ai vraiment que le nom, le nom du compte. Je crois que c'est tout. Nom, nom de compte. Et au contraire, il faut essayer d'automatiser et d'aller enrichir automatiquement le consentement par objectif sur le formulaire. Donc ça, c'est vraiment les bonnes pratiques préalables sur le formulaire. Juste après l'entrée de la donnée dans la base, alors qu'elle est encore froide, ce qu'on va faire, c'est qu'on va traquer correctement l'acquisition. On va corriger à la volée des listes de valeurs incorrectes. On va pouvoir vérifier l'adresse e-mail : est-ce qu'elle est pertinente, utilisable ? Et on va gérer les e-mails pros/persos. Comment on va faire ça ? Si je prends, par exemple, mon webinaire… Alors là, je suis dans mon Marketo, sur ma campagne d'acquisition de mon webinaire. Donc, celle qui va comprendre que quelqu'un vient de remplir le formulaire et que je dois le passer à la liste d'attente. C'est un déclencheur qui dit : dès que la personne remplit ce formulaire sur cette page, on va faire tout un tas d'actions. Évidemment, on va envoyer un e-mail à la personne. Je vais faire tout un tas d'actions techniques. Mais je vais finir par entrer un programme d'acquisition et une date d'acquisition. Ça, conjugué au fait que sur le formulaire, je vais avoir un champ par défaut, personne source webinaire. Ça va me permettre de traquer correctement l'acquisition des personnes et de répondre à la question toute bête : d'où viennent mes leads ? Si je regarde, ici, les personnes que j'ai acquises dans ce webinaire, par exemple, je vois que, elles ont bien, dans le champ Personne source webinaire, et en détail de ce personne source, j'ai bien un programme d'acquisition qui est le nom du webinaire. Donc, quand je vais vouloir faire des analyses sur : mais d'où viennent mes leads ? D'où vient mon pipe ? D'où vient mon revenu ? J'aurai bien à ma disposition des champs qui sont bloqués en mise à jour. Donc, c'est-à-dire qu'ils peuvent être entrés une fois à l'entrée, mais ils ne pourront plus jamais changer. Ça, c'est paramétré dans Marketo. Donc, j'aurai bien ces champs qui me permettront de savoir d'où viennent ces gens et de faire des analyses pertinentes. C'est complété avec les champs UTM, medium sources campagnes, qui sont à la fois sur la personne dans Marketo, et à la fois sur le membre de campagne, donc à l'intersection de la personne et de la campagne. Ces champs-là sont effacés à chaque nouvelle campagne par laquelle passe la personne. Ces champs-là sont gardés en permanence sur la campagne et la personne. Donc ça, c'est vraiment important. C'est une grande source de mauvaise qualité de données. À un moment donné, quand on a fait pas mal de campagnes marketing et que le directeur marketing ou la direction dit : "Ça marche le marketing ? D'où viennent nos leads ? D'où vient notre revenu ? Qu'est-ce qu'on arrête ? Qu'est-ce qui ne marche pas ? Qu'est-ce qui marche ?" Si on n'a pas ces données de manière fiable, remplie, correcte, exhaustive, on ne pourra pas répondre à la question. Ça, c'est un grand classique de chantier de data quality, faire en sorte que le tracking de l'acquisition soit correct. Si on a bien paramétré toutes ces campagnes d'acquisition comme je vous ai montré avec, d'un côté, sur le formulaire un champ caché qui contient webinaires ; et de l'autre sur la campagne, passage à…, sur la campagne qui track le remplissage du formulaire et les actions de mise à jour du programme d'acquisition et de la date d'acquisition, il n'y a pas de problème. Là, je le montre dans Marketo, c'est adapté sur chacun des systèmes de marketing automation évidemment. Correction des données à la volée. Là, c'est des campagnes qui sont très utiles. Je vais aller dans mes campagnes de data management. Ici, data enrichments. Je vais prendre le champ pays, par exemple. Pour chacun des champs qui vont être soumis à une liste de valeurs - All, Service, Civility - je vais avoir ce type de campagne qui dit : dès qu'une personne est créée avec un pays qui n'est pas dans la liste des 239 pays listés - là, en l'occurrence, Sales force - et qui sont admises, ou que la valeur du pays change et que la valeur est incorrecte. Donc les deux cas, soit à la création, soit au cours de vie de la personne quand le pays change - par exemple, elle vient de déménager, elle a rempli un nouveau formulaire - alors on va avoir une campagne, là, assez longue puisqu'on va pouvoir lister les mauvaises valeurs. Assez souvent quand on regarde la base de données, on trouve - c'est la règle 80/20 -, on trouve assez vite les 20 % de valeurs qui représentent 80 % de la mauvaise qualité de données. Par exemple, la valeur que j'attends pour Tunisie, c'est Tunisia. Si c'est TN ou Tunisie, je vais changer en Tunisia. Si c'est ML, je vais changer en Mali. Si c'est MA, je change en Morocco. India. États-Unis, j'ai plein de valeurs différentes, je les liste là. Évidemment, je vais maintenir cette campagne, donc si j'ai de nouvelles mauvaises valeurs que je constate, je vais pouvoir venir ici les changer, et ainsi de suite. Ça, pour tous les pays ou pour toutes les mauvaises salutations, ou pour tous les mauvais rôles, les mauvais services. C'est des campagnes qu'on pose une fois, qu'on crée une fois, qui vont tourner en tâche de fond et qui vont corriger automatiquement les données en cas d'entrée de mauvaise valeur. Ça peut être assez souvent quand on va faire des imports et que les listes n'ont pas été normalisées, ou qu'un système tiers va pousser de la valeur dans Marketo, et que ce système tiers, je n'ai pas la main sur les pays. Ça m'arrive avec mon système de gestion de rendez-vous, il me pousse plutôt pour l'instant des codes à deux chiffres, et il faut que je corrige avec les valeurs complètes. Ça, c'est assez pratique. Ça permet d'avoir de la correction qui tourne automatiquement. Captain Verify, c'est un petit système qui… j'appelle Captain Verify, je vous montre un schéma. C'est assez technique, je ne vai s pas vous montrer les écrans, ça ne va pas vous parler. L'idée, c'est que dès que quelqu'un rentre dans Marketo, je fais un petit appel chez Captain Verify - c’est une base de données tierce - et il va me remplir en base tous ces champs-là qui vont me dire, par exemple, que l'e-mail est valide ou invalide ; que l'e-mail est un domaine type Gmail, un domaine gratuit ; que c'est un e-mail générique ; que c'est un e-mail jetable ou que c'est un e-mail risqué. Ça, c'est très intéressant parce que, derrière, je vais pouvoir faire des ciblages. Par exemple, je me suis fait une liste des e-mails dangereux que j'exclus systématiquement de mes campagnes. Je vais me faire une liste des e-mails génériques que je vais exclure ou pas des campagnes, en fonction de la campagne que je fais. Il va aussi me normaliser les e-mails. Par exemple, si quelqu'un rentre un e-mail avec un "plus" dans l'adresse Gmail, on va pouvoir enlever le "plus" et reconnaître le bon e-mail. C'est intéressant, parce que ça me permet de garder ma crédibilité auprès de Marketo et des serveurs e-mail, et de ne pas trop envoyer d'e-mails qui sont supposément invalides ou pièges. Gestion e-mail pro perso. Ça, c'est une petite campagne que j'ai qui va me permettre d'historiser quand je détecte que quelqu'un rentre néanmoins avec un e-mail perso. D'ailleurs, j'ai certains formulaires qui ne sont pas sécurisés sur lesquels j'autorise. Si l'adresse e-mail contient un de ces domaines que j'ai listés là ou que Captain Verify m'a dit que c'était un e-mail générique, un e-mail gratuit, pardon, je vais historiser dans le champ e-mail perso que j'ai fait. J'ai créé deux champs e-mail perso : E-mail perso et E-mail perso 2. Je vais faire une sauvegarde de E-mail perso dans E-mail perso 2 et je vais sauvegarder l'adresse e-mail dans l'e-mail perso. Ce qui fait que je vais pouvoir ensuite aller interroger, par exemple, une base comme Dropcontact pour aller chercher l'e-mail pro que je vais stocker dans l'e-mail address. Mais j'aurai gardé dans mon champ E-mail perso, E-mail perso 2, les e-mails perso que j'aurais pu collecter auparavant comme ça je ne perds pas de données. Ça, c'est des choses qu'on peut faire juste après l'entrée de la donnée pour soit la vérifier, soit la corriger instantanément, soit bien la catégoriser. Peu après l'entrée, une fois que cette première étape est passée, qu'est-ce qu'on va faire ? Évidemment, généralement dans Marketo, mais c'est assez souvent le cas dans les autres systèmes, si je rentre une donnée côté CRM ou Marketo, assez souvent au bout de cinq minutes, elle va être échangée avec l'autre système. C'est à ce moment-là que vont se passer éventuellement des problèmes d'intégration. Là, je ne vais pas vous montrer, mais dans Marketo, on peut avoir des notifications en cas de problème d'intégration. Là, on peut s'abonner aux notifications qui listent les problèmes à chaque refus de données, dans un sens ou dans l'autre. Ça, c'est vraiment très pratique. Il faut s'abonner à ces notifications qui sont… est-ce que j'en ai là ? J'en ai une là, par exemple. Là, c'est une erreur sur laquelle je ne peux pas faire grand-chose. Parfois, il nous dit : "J'ai une erreur sur le fait que cette liste de valeur n'est pas acceptée." Là, ça veut dire qu'il faut tout de suite corriger pour éviter de perdre de la donnée. Le Scoring comportemental et démographique va aussi nous servir dans le cadre de la data quality parce qu'on va pouvoir, par exemple, mettre des notes négatives sur le fait que quelqu'un a mal rentré la donnée. Si quelqu'un entre Toto, Titi dans un formulaire, ça veut dire qu'il n'est pas forcément prêt à vous parler tout de suite. Donc, ce qu'on va faire dans le Scoring, ici, dans le Scoring démographique, vous allez voir que j'ai des campagnes qui mettent des points négatifs quand… je vais y arriver, je vais y arriver. More advanced. Voilà. Si quelqu'un remplit de manière erronée son prénom - là, j'ai un listing. On trouve des listes de mauvais prénoms par pays, si vous les cherchez, pour les prénoms français, les prénoms américains ou anglais. Il y a des gens - ça se trouve assez vite sur Internet - qui ont listé plein de chaînes de caractères qui indiquent que le prénom est invalide. J'ai récupéré certaines de ces chaînes de caractères que j'ai mis dans un ciblage, ici, pour les prénoms. Idem pour les noms. Si une personne rentre Toto,Tata,Titi, il va perdre des points sur le scoring. Ça permet aussi d'avoir un impact sur "quelles sont les personnes dont je m'occupe tout de suite ?" Celles qui ont de la mauvaise qualité, je vais m'en occuper peut-être un peu moins vite. Là, je crois qu'on perd trois points sur le Scoring démographique. Enrichissement de données, les données déduites d'autres. C'est ce que je vous montrais dans le CRM tout à l'heure. Je prends un exemple tout bête avec la civilité. Je reviens sur mon data management. Ici, quand une personne est créée ou qu'elle change son prénom, on va déduire - quand elle crée ou elle change son prénom et que la situation n'est pas vide, je ne vais pas modifier. Encore une fois ici, on peut trouver des listes de prénoms masculins français, certains ; des listes de prénoms féminins, certains. Je n'ai pas fait toute la liste, j'en ai fait quelques-uns, il faut que je la complète. Mais si une personne rentre et qu'elle s'appelle Vincent, je vais mettre monsieur ; si c'est Delphine, je vais mettre madame, et ainsi de suite. Ça fonctionne assez bien. Évidemment, ça suppose qu'on a trouvé la bonne liste et qu'elle est assez exhaustive. On peut compléter et regarder sa base pour les prénoms qui n'ont pas de civilité et voir si on peut enrichir ces deux listes à chaque fois. C'est assez bien. Mais on peut déduire la civilité à partir du prénom. On peut déduire de la même façon, ce que je vous ai montré tout à l'heure, le niveau décisionnel d'une personne à partir de son job title, à partir de mots clés qu'il y aurait dans le titre de la personne. Ça aussi, ça fonctionne bien. Ou son service. J'ai trois niveaux, j'ai : décideur, autre et management intermédiaire. Je vais avoir des mots clés pour tout ce qui est décideur. Pareil pour le service, si ça contient marketing, par exemple, je vais pouvoir déduire que la personne fait partie du marketing. Ça, c'est des campagnes qu'on pose une fois, qui tournent et qui ensuite vont en permanence enrichir la donnée. Évidemment, on peut toujours corriger à la main dans le CRM s'il y a une erreur. Là, Marketo ne va pas… si la donnée est changée par vous, il ne va pas forcer la valeur, il va laisser ce que vous avez mis. Ça, c'est aussi intéressant. On peut aller plus loin dans l'enrichissement de la donnée. Je ne l'ai pas encore mis en place, je suis en plein chantier. J'avais quelques soucis avec l'intégration, mais je suis en train d'y voir plus clair. On peut enrichir les données avec des bases externes comme Dropcontact, SocieteInfo.com ou Nomination, où on fait de l'appel unitaire. On va décider que quand la personne soit est créée, soit qu'elle a un score chaud, soit qu'on est sur le point de la passer aux ventes - ça, c'est à nous de décider quand il est pertinent de faire l'appel - on envoie un jeu de données. Ça peut être l'e-mail ; ça peut être nom, prénom, entreprise ; ça peut être le domaine. Les différents services acceptent différentes chaînes de caractères et ces services vont essayer de un, trouver la bonne personne correspondant à soit l'e-mail, soit nom, prénom, entreprise et vont vous envoyer, en retour, beaucoup de champs pour compléter la fiche client. Côté entreprise, ça peut être évidemment le nom de l'entreprise, son adresse complète, son chiffre d'affaires, son secteur d'activité, la date de création - toutes les données "firmographiques" qu'on peut rêver d'avoir -, son Siren, son numéro de TVA éventuellement. Sur la personne, ça peut être où elle est située, son adresse physique - pour l'instant, elle est située chez elle souvent - son téléphone fixe, son mobile, son job title, est-ce qu'elle a été… ? Je sais que chez Nomination, par exemple, la personne qu'elle a remplacée à ce poste ou la personne par laquelle elle a été remplacée - on peut avoir des données comme ça. On peut même avoir, je sais que chez Nomination, on peut même avoir un enrichissement du cercle de décision de l'entreprise. Par exemple, j'ai le directeur ou la directrice marketing d'une entreprise qui est rentré dans ma base, je peux demander à avoir les gens de la direction, les autres personnes du marketing ou les personnes des ventes. Ça va m'enrichir Marketo avec plus de contacts. Ça, c'est des choses qu'on peut faire assez facilement. C'est de petits projets d'intégration qui se font assez facilement maintenant puisque toutes ces bases peuvent être interrogées par API. Les systèmes comme Marketo permettent de configurer sans développement, sans code, un appel API assez facilement grâce au Webhook. Si je vous montre rapidement, j'ai dû en faire un pour Captain Verify. On paramètre quelque chose comme ça. Captain Verify. Captain Verify, c'est celui-là. On paramètre, ici, une URL qui est donnée par le service externe. Là, j'ai mis des données que je vais transmettre. Donc là, je transmets uniquement l'e-mail et en fait, en retour, je vais remplir tous ces champs-là de ma base qui sont remplis par la réponse que me renvoie Captain Verify. C'est toujours le même principe. On fait un appel à l'extérieur en envoyant des données, et on a une réponse qui va nous remplir des champs qu'il faut, évidemment, qu'on crée dans la base. Donc ça, c'est intéressant et ce n'est pas très vieux, donc c'est assez sympa d'avoir ça maintenant. Autre chose qu'on peut faire pour améliorer la qualité et que je ne l'ai pas encore mis en place, c'est un indicateur visuel de la bonne qualité de données. C'est essentiellement utile côté CRM. Vous arrivez sur une fiche contact ici, et ici, je devrais avoir un peu comme Scoring de Marketo - trois étoiles, deux étoiles, une étoile - ou alors un feu vert, un feu orange, un feu rouge, disant que oui, cette personne a une bonne qualité de données. Orange, il faut commencer à s'en occuper. Rouge, il y a un gros problème. Un score qui peut être calculé sur la complétude de la donnée. Est-ce que j'ai tous les champs nécessaires qui sont remplis ? Est-ce que les champs sont justes ? Est-ce que par exemple j'ai bien un numéro de téléphone dans le champ Téléphone ? Est-ce que j'ai bien un e-mail dans le champ E-mail ? Est-ce que j'ai bien les listes valeurs attendues dans les champs Liste de valeurs ? Est-ce que la donnée est récente ? Vous avez compris. Il faut construire ces indicateur, mais ensuite, c'est bien pratique, ça permet de prendre des décisions et de permettre aux gens ou aux utilisateurs du CRM de corriger de la donnée quand ils voient les indicateurs rouge ou orange. Alors, tout ce qui est dédoublonnage, ici on va pouvoir utiliser plusieurs outils. Dédoublonnage à la volée. Évidemment, avec les systèmes marketing automation, ils sont tous paramétrés pour ne pas créer de doublons quand une personne entre plusieurs formulaires avec le même e-mail, ça, c'est de base. Tous les systèmes font ça, il n'y a pas de souci. Par contre, si moi, Sylvain D'Avril, j'entre une fois un formulaire avec mon adresse Gmail, et une fois avec mon adresse Merlin/Leonard, là, le formulaire ne va pas savoir que c'est la même personne, évidemment. Donc là, il faut utiliser… dans le CRM, on a des outils qui vont nous permettre d'identifier à la volée que cette personne a un e-mail qui ressemble, ou a un nom/prénom qui ressemble. Donc là, on va pouvoir verrouiller dans le CRM, pas forcément le marketing automation, l'entrée de la donnée sous réserve que ce qu'on appelle une clé fonctionnelle n'est pas déjà rentrée. Une clé fonctionnelle, c'est qu'est-ce qui va définir de manière unique une personne au sein du système. Donc, ça peut être l'e-mail, c'est assez dangereux parce qu'il faut quand même qu'on puisse entrer assez souvent dans le CRM des personnes avec le même e-mail. Mais ça peut par exemple être nom, prénom, entreprise, sauf pour les Jean Dupont qui travaillent chez Peugeot, je pense qu'il y en a au moins deux, mais ça peut être ça. Et le CRM va nous interdire l'entrée, par exemple, deux Jean Dupont chez Peugeot, et va nous dire : non, j'ai déjà un Jean Dupont, donc, ce n'est pas possible. Il faut l'appeler Jean Dupont 2. Donc, ça peut être une action comme ça. Évidemment, c'est mieux quand on a un système qui va nous détecter des similitudes entre personnes, et qui va proposer des fusions. C'est les systèmes comme Cloudingo que j'utilise. Je me logue. Cloudingo, c'est un système qui est connecté à mon CRM, à Sales Force, qui va scanner la base et qui va avoir des routines de détection de chaînes de caractères similaires. J'en ai plusieurs, j'en ai sur le compte, j'en ai sur les contacts, j'en ai sur les leads, et ça va même pouvoir me permettre de convertir automatiquement des leads en contact si la société est similaire. Donc, c'est vraiment intéressant. Si je prends celui-là, par exemple, que je regarde comment il est fait. Ici, on a dit, le filtre, ça va être le country, plus… j'ai fait une chaîne de caractères avec nom, prénom, e-mail et compte. J'ai préparé cette chaîne dans mon CRM au préalable. Et ici, on a un premier groupement à travers le pays. C'est pour ça que les pays soient vraiment rigoureusement entrés chez moi. Et une fois qu'on a groupé les gens par pays, tous les Français, on va utiliser le Fuzzy mode. Le fuzzy, c'est qu'il va utiliser un algorithme de reconnaissance, de similitude de chaîne de caractères pour voir que Sylvain D'avril Merlin/Leonard et Silvain avec un i, D'Avril avec une apostrophe, Merlin Leonard sans Slash sont à peu près pareils et il va me dire, voilà, ça va être des doublons. Donc ça va reconnaître des doublons similaires. Et on n'est plus dans les doublons exacts. Derrière, je vais pouvoir même automatiser la fusion au-delà d'un certain degré de similitude. Donc ça, c'est assez intéressant parce que ça veut dire que les doublons vont être constamment identifiés et constamment fusionnés. Alors, il faut bien affiner ces règles. On ne lance pas l'automatisation tout de suite, mais une fois qu'on maîtrise bien son périmètre de données, qu'on a exclu tous les contacts ou les comptes qui posaient problème, on peut lancer l'automatisation. Et vous avez la certitude que dès qu'une personne va entrer dans le CRM, ce qui chez moi arrive au bout de 5 minutes, quelque que soit l'entrée dans un système, il va être fusionné et la fusion va être propagée dans les autres systèmes autour, donc dans Marketo pour le coup ou dans d'autres systèmes. Donc, c'est vraiment crucial pour maintenir ces doublons a minima. Vous voyez que chez moi, je n'en ai vraiment pas beaucoup. Je peux un peu travailler sur les leads, lead to account là, je pourrais convertir un petit peu. Mais sinon, j'ai relativement peu de doublons et en fait, ceux qui restent, c'est des cas un peu litigieux que je ne veux surtout pas fusionner. Ça, ça fait à la fois du dédoublonnage à la volée, c'est-à-dire que ça va analyser les personnes qui rentrent et puis je peux lancer… alors ça on le fait surtout en démarrage de projet. Quand on a installé la solution, on peut dédoubler en masse et lancer des programmes batch. Alors, qu'est-ce qu'on a d'autres en cours de vie ? On va avoir effectivement la collecte des consentements fins grâce à un centre de conférences de communication. Une fois que la personne est entrée, on va généralement la mettre dans des campagnes et dans ces campagnes, si on fait proprement le job, on va lui permettre d'accéder au centre de préférence qui va lui permettre de compléter son profil. C'est ce qu'on avait vu ici, je l'ai montré au tout début. Ça, c'est crucial pour avoir une bonne qualité de données autour du RGPD. Le scoring comportemental démographique qui va aussi tourner tout au long de la vie de la personne. Il se peut que la personne rentre une fois et ensuite, elle ne fait pas grand-chose pendant un certain temps. Par exemple, moi j'ai décidé que si la personne refait une action chez moi et que je n'avais pas vérifié ces données depuis 6 mois, je vais refaire un appel dans le contacts pour être certain que j'ai de la donnée fraiche. Et cette donnée fraiche, ça permettra d'améliorer le score de Data Quality, l'indicateur visuel de Data Quality dont on avait parlé ici. L'idée, c'est de garder une donnée fraiche. Je crois que c'est 20 ou 30 % des données qui changent sur les sociétés tous les ans. Donc, c'est important de récupérer de la donnée fraiche également. On peut faire des rapports Data Quality. On peut en faire autant qu'on a deux champs de règles métier, je ne vais pas vous les montrer parce que j'en ai vraiment beaucoup. Et par contre, à la fin de vie de la personne, il y a deux choses qu'il faut qu'on fasse pour être conforme au RGPD. Il faut qu'on permette aux gens qui souhaitent de supprimer les données de votre système. Chez moi, par exemple, quand dans le centre de préférence, vous dites, bah non, je n'accepte pas la politique de confidentialité de Merlin/Leonard, et il y a un texte qui apparait - j'ai un petit problème avec le copyright - qui dit que si vous cliquez sur Enregistrer, on va supprimer les données de nos systèmes, donc ça supprime. Alors ça m'envoie une alerte, et après, j'appuie manuellement sur un bouton pour bien maîtriser le processus, ce n'est pas totalement automatisé, il y a quand même un humain au milieu. Mais ça va supprimer, ça va vider tous les champs de la personne dans Marketo et dans Salesforce. Donc, je vais juste garder son e-mail, la date à laquelle elle a fait la demande, la date à laquelle j'ai exaucé la demande, pour pouvoir prouver que j'ai bien rempli mon obligation de droit à l'oubli pour cette personne. La deuxième chose qu'on peut faire, c'est supprimer le système, les personnes sans activité depuis deux ans. Donc ça, pas forcément les clients, évidemment, parce que vous devez pouvoir éventuellement garder des gens dans votre système qui sont relatifs à la DAF, à la facturation ou au contrat. Mais des personnes qui sont venues plutôt que côté marketing ou qui n'ont pas concrétisé d'affaires avec vous. Le RGPD nous dit que s’ils ne font rien pendant 2 ans, on est susceptible de les effacer de la base. Comment on va faire ça ? Chez nous, on va déjà enregistrer dans la base la date de dernière activité systématiquement. Dès qu'une personne fait une action chez nous, on va enregistrer. Pardon, je cherche, je cherche, je cherche. Excusez-moi, je ne trouve pas. Donc, dès qu'une personne remplit un formulaire, clique dans un e-mail ou un e-mail, ou que participe à une campagne, un webinaire, un salon, un évènement, toutes les campagnes qu'on a, on va historiser dans la date de la dernière activité la date du jour et le type de dernière activité. Qu'est-ce qu'il a fait en dernier chez nous ? Et une fois qu'on a fait ça, c'est assez simple puisque derrière, on a juste à faire tourner une campagne qui dit, si une personne a une date de dernière activité supérieure à 2 ans, avant 1095 jours et qui n'est pas vide, alors elle est candidate à la suppression. Donc, on la met dans la liste. Là, on a mis trois ans, mais on va réduire à deux ans. On l'a mis dans la liste et derrière, régulièrement, on vide cette liste. On jette un œil avant de le supprimer. Et si on est OK, on vide la liste. Ce qui fait que la personne est supprimée à la fois de Marketo et du CRM. Donc là, on respecte notre obligation de vider les bases. Voilà pour l'essentiel des campagnes qu'on a chez nous. Il y en a encore deux ou trois ans, mais je ne vais pas tout dire. On a fait 40 minutes, je vais vous laisser poser des questions et y répondre. Pour finir, je vous donne les liens de ce miro que j'ai parcouru tout au long de la session. Vous le trouverez dans ce slide que je vais mettre juste après. Donc, ça va faire un lien court. m-l.site/data-quality-life-cycle. Donc ça, c'est ce Miro là. Et on vous a préparé un autre Miro avec les 13 campagnes de Data Quality que vous devriez avoir, qui est assez dense, qui reprend peu ou prou tout ce que j'ai raconté, mais mis plus sous une forme de campagne. Si j'en prends une, par exemple, vérification de l'adresse e-mail ; prérequis : avoir une solution de vérification des e-mails tel que Captain Verify, dès que vous recevez un nouvel e-mail dans la base de donnée intégrée, et voilà. Donc, ça vous permet d'avoir un petit plan d'action des principales campagnes que vous devriez y avoir chez vous. Je vous laisse découvrir, c'est cadeau. Et là encore, j'ai mis le lien ici, dans cette slide que j'affiche.