Marketing Office Hours
Data Quality & Marketo - Marketo Office Hours spécial 20210115
144 vues
Cette session était consacrée à la Data Quality. Sylvain nous guide à travers les principales campagnes mises en place chez Merlin/Leonard.
Protection des formulaires marketo contre les emails génériques
On peut décider de n’accepter que les emails avec un domaine professionnel avec un peu de magie (et de script) dans les formulaires Marketo.
Protection des formulaires contre les numéros de tél bidons
Idem, il est possible d’empêcher une personne d’entrer un numéro de téléphone de type “0102030405”, ou tout autre chaine de caractères suspecte.
Gestion des concurrents
Pratique pour que vos concurrents ne téléchargent pas tous vos contenus, ou qu’ils s’inscrivent à vos événements. Ils sont reconnus et gérés d’une manière particulière. A vous de la définir ;-)
Enrichissement des civilités
Il est possible de déduire automatiquement la civilité d’une personne, qui vient d’entrer un formulaire, à partir de son prénom. Cela fonctionne bien pour 75% des prénoms “surs” (pas comme Dominique)
Idem, on peut déduire par exemple le caractère décisionnaire d’une personne à partir de son “job title”, ou encore son service.
Autant de données que l’on a pas à demander au visiteur ou à l’utilisateur du CRM.
Correction des Pays
Eternel sujet, les mauvaises valeurs dans les listes de valeurs. Assez souvent,ce sont les mêmes “mauvaises” valeurs qui reviennent. Identifiez-les dès leur entrée dans Marketo et remplacez-les par la bonne valeur.
Ce type de campagne est valable pour tout champ avec des données “arrêtées” pour lesquelles les valeurs acceptables sont dans une liste fixe.
Gestion Email pro / perso avec CaptainVerify
C’est un système en plusieurs temps que nous avons chez Merlin/Leonard. Lorsqu’une personne entre un formulaire, nous appelons CaptainVerify pour avoir des informations sur la validité de l’email entré (invalide / email piège / email perso / email générique…) puis nous historisons cet email dans un champ Email perso s’il tombe dans ce cas. L’étape d’après ci-dessous, permet d’aller chercher l’email pro.
Enrichissement avec Dropcontact.io
Pour certains contacts intéressants (chauds, ou attachés à certaines campagnes), un appel chez Dropcontact.io va permettre d’enrichir la fiche contact + compte avec beaucoup de données.
L’idée est encore une fois d’éviter de demander des informations au visiteur que l’on peut collecter ailleurs.
Suppression des contacts dans Marketo et Salesforce
Nous avons une campagne qui tourne pour détecter les suppressions de personnes dans Salesforce et les répliquer dans Marketo afin de ne pas avoir d’incohérences.
Dédoublonnage avec Cloudingo
Cloudingo permet de détecter des contacts ou des comptes similaires jusqu’à un certain seuil et d’automatiser la fusion de ces contacts ou comptes. Finis les corvées de la détection de doublons et les dédoublonnages manuels !
Import de contacts dans Marketo ou Salesforce
Je vous montre les bonnes pratiques des imports de listes dans Marketo ou dans Salesforce.
View transcript
Alors, des questions ? Plus générales que sur la data quality ? Oui, bonjour, c'est Aurélie. Moi, j'ai une question. C'est qu'à dire qu'on a les formulaires Marketo. Et moi, j'aimerais bien qu'on évite d'avoir des gens qui remplissent le formulaire avec une adresse Gmail, Hotmail, Yahoo, etc. Et ce n'est pas le cas de l'équipe aux US qui, eux, sont très focus MQL et pas forcément data quality. Forcément, si on fait ce filtre, ça va impacter leur chiffre. J'aimerais savoir comment vous faites. Est-ce que vous avez mis justement des filtres comme ça ou pas du tout ? Vous laissez les gens s'inscrire avec des adresses personnelles ou des adresses avec un domaine comme Gmail ? Voilà, c'est ma petite interrogation. Moi, j'ai demandé à Merlin/Leonard justement de mettre un JavaScript dans mon formulaire. Je n'ai pas implémenté ce script sur tous mes formulaires. C'est justement ce que je m'apprêtais à faire aujourd'hui. C'est-à-dire que j'ai une smart list d'emails non professionnels : tous les trucs qui peuvent exister, Hotmail.com, etc. Ces données-là ont été intégrées dans un JavaScript par Merlin/Leonard et rajoutées dans un rich text dans le formulaire de base qu'on utilise sur notre site web. Ce truc-là, je l'utilise aussi pour mes événements maintenant. Et aussi, du coup, pour les concurrents. Donc, ça oblige à… En fait, je fonctionne avec des noms de domaine, clairement. J'utilise tous les noms de domaine des concurrents, tous les noms de domaine des adresses non professionnelles auxquelles je peux penser. Et c'est intégré dans un JavaScript. Par contre, j'ai identifié un défaut, c'est que c'est case sensitive. Donc, si la personne remplit son adresse e-mail en activant les majuscules, mon filtre ne marche pas. Voilà, c'est juste mon expérience. Il faudrait qu'on update le script pour inclure les versions en majuscules. Oui, tout à fait. En fait, il faudrait tout intégrer, quoi. C'est un peu de travail. Mais c'est super pratique. Du coup, quand la personne remplit un formulaire, elle a un message qui apparaît. Si elle remplit, par exemple, je ne sais pas moi, si c'est un concurrent : you cannot access the content… Un petit message qui indique que, de toute façon, sa demande ne sera pas prise en compte. S'il est en train de taper un gmail.com : please give us your professional email address, un truc comme ça. C'est vraiment super pratique. Ça nous a changé la vie. Notamment, ça m'a permis de limiter les doublons aussi. Puisque parfois des gens se connectent avec… Ils ne font pas gaffe, ils se connectent avec leur adresse personnelle. Or, ils existent déjà dans la base avec une adresse pro. Donc, on limite un peu l'entrée de doublons aussi. Voilà mon expérience. Quelqu'un d'autre souhaite partager son expérience ? Merci. Merci beaucoup. Pour compléter, on a défini effectivement une liste. Je ne sais plus où j'ai retrouvé cette liste de tous les domaines plutôt personnels d'e-mails génériques qu'on peut trouver par pays. On a inclus cette liste de domaines dans le petit bout de code qu'on a mis derrière le formulaire. Effectivement, Aurélie, tu peux avoir tes formulaires pour l'Europe ou pour le UK, pour la France. Et il peut y avoir d'autres formulaires qui ne contiennent pas le script pour les US. Nous, typiquement, on a Pierre qui fait des sessions un peu comme les Office Hours, mais côté plutôt LinkedIn. D'ailleurs, il y en aura une à 13 heures. Là, les gens qui s'inscrivent, ce sont essentiellement des freelance. C'est plutôt LinkedIn orienté recrutement. Ce sont des gens qui sont en recherche de boulot. Ils ont de facto plutôt une adresse avec un domaine générique. Donc, on n'a pas mis le script sur son formulaire. Alors que pour tout ce qui concerne Merlin/Leonard, on a choisi de sécuriser nos formulaires. Par exemple, moi, je pourrais dire : pour les webinars, parce qu'il y a beaucoup plus de valeur, je ne veux que des adresses professionnelles. Et par exemple, pour du contenu qui a moins de valeur ajoutée, je peux vouloir un mix ? Oui, bien sûr, ça se fait par formulaire. Non, excuse-moi, je dis des bêtises. Soit on met le script dans le formulaire, soit on met le script sur un template de landing page. Tu peux très bien dire mes template de webinars, j'embarque le script. Comme ça, tous tes webinars auront le script. Et tu n'as pas à t'occuper à chaque fois que tu refais un webinar de remettre le script. Puis mes template de téléchargement de contenu, on ne le met pas. Et ça passe. Ça marche. Merci beaucoup. Nous, on a remarqué quelque chose en interne : tout ce qui est entreprise publique, notamment les ministères, etc., n'aiment pas trop utiliser leur adresse e-mail pour les téléchargements de contenu. Ils utilisent des Gmail en priorité. Donc, ça dépend si on veut les exclure aussi des formulaires. Mais il faut faire attention que parfois les e-mails, les free e-mails, parfois peuvent être utilisés par certaines catégories de l'entreprise. Justement ce que je voulais faire… Moi, je ne l'ai pas encore mis en place là pour le prochain webinar qu'on est en train de faire. Je voulais mettre une petite note en pied de formulaire, disant : si vous voulez vraiment vous inscrire avec un e-mail à domaine générique, passez par la chat box qui est ici, en fait. Je n'ai pas beaucoup de gens qui s'inscrivent. Donc je peux gérer les gens manuellement. Si quelqu'un souhaite s'inscrire avec un Gmail, il faut vraiment qu'il me donne une bonne raison. Comme ça, je verrai qui c'est. Donc, on peut compléter le formulaire. C'est un cas d'usage où on peut utiliser la chat box en complément du formulaire. En termes de data quality aussi… Là, c'est sympa, on a le script pour les adresses e-mail. Mais pour tout ce qui est numéro de téléphone, je cherche désespérément un script qui m'empêche d'avoir des numéros de téléphone bidon ou au moins forcer les gens à rentrer des numéros de téléphone crédibles. Attends, est-ce qu'il y a Élodie avec toi ? Tu es là Élodie ? Elle n'est pas là. Oui. C'est ce qu'on a fait chez vous, je crois ? Oui. En fait, ça revient un peu à ce que décrivait Aurélie en fin de compte. On a utilisé les extensions. D'ailleurs, pour ton information, Sylvain, tu sais, pour les personnes qui utilisent Gmail ou autres, les gens nous ont écrit pour dire qu'ils étaient bloqués pour les inscriptions de webinars. Parce que ce sont des gens qui sont à leur compte et ils n'avaient pas du tout d'autres extensions possibles. Donc, moi, ce que j'ai fait, c'est que je les ai créés à la mano dans Marketo, pour les rajouter en tant que membres dans le programme. Mais c'est intéressant de voir l'option que tu montres. De notre côté, en fin de compte, ça revient exactement à ce qu’Aurélie a. C'est-à-dire le listing de toutes les extensions d'e-mails que l'on veut bloquer. Que ce soient les concurrents, comme tout ce qui est Hotmail, Outlook, etc. Puis la partie aussi téléphonique. Mais là, la partie téléphonique, c'est un peu plus rébarbatif. Parce qu'il faut mettre exactement les combinaisons qu'on veut bloquer, avec le nombre de caractères, etc. Si, (Amori), on arrive à définir des chaînes de caractères typiques qui sentent le mauvais numéro, on peut exclure ces chaînes de caractères. Donc, en regardant un peu l'historique de ce que les gens ont saisi dans les champs téléphone, on retrouve assez vite des chaînes qui reviennent assez souvent. On peut les… Les 0, 1, 2, 3, 4, 5, 6, 7, 8. Enfin toutes les suites. Et on peut bloquer ces chaînes, effectivement. Pour les chaînes, si vous ne travaillez qu'en France, c'est un petit peu moins embêtant. Parce que le nombre de chiffres est le même. Mais bon. Si on veut bloquer le 0, 0, 0, 0, il faut être sûr de mettre le 00, 0, 0, enfin toutes les combinaisons possibles et imaginables. C'est juste ça qu'il faut anticiper. On va rentrer dans le Marketo, comme d'hab. Où est-ce que j'étais, là ? De mon côté, j'ai un dossier Data Management, ici, dans lequel je regroupe un peu tous mes programmes de gestion de données. Un premier exemple : la gestion des concurrents. Ici, moi, les concurrents, j'ai décidé plutôt de partir de Salesforce. C'est assez dur de détecter les concurrents. J'ai une smart list, évidemment, avec les noms des sociétés concurrentes et les domaines. Mais je tombe dessus plutôt quand j'entre des contacts ou que je navigue dans Salesforce. J'ai un champ dans mon Salesforce qui est le type sur un compte. Ici, j'ai un type : soit client, soit partenaire, soit il y a un type concurrent. C'est un cas où, typiquement, c'est une action dans Salesforce qui doit déclencher des actions dans Marketo. Là, ça rejoint le Marketo Tip que j'ai fait cette semaine, si vous l'avez vu, qui vous montrait le piège du data value change. Quand une société devient concurrente, c'est-à-dire je change le type du compte dans Salesforce, c'est ce trigger qui va intercepter l'action. Par contre, si je crée directement un concurrent dans Salesforce et que je le tague tout de suite en type concurrent, le data value change ne va pas fonctionner. Il faut bien l'avoir en tête. C'est pour ça qu'il faut doubler systématiquement dans les campagnes data quality avec un trigger Person is created. Et ajouter les filtres qui vous permettent de détecter les concurrents. Donc là, le filtre c'est que la personne est concurrente et que ce n'est pas un réseau de confiance. Parce que des fois, j'ai des copains qui sont concurrents. Donc je ne veux pas les exclure. C'est compliqué. Donc là, les filtres s'appliquent surtout pour le Person is created, mais les filtres s'appliquent aussi pour le data value change. Mais ce n'est pas grave. Puisque, comme on dit la même chose, ça passe aussi. C'est clair pour tout le monde, ce sujet du data value change versus le Person is created ? L'un fonctionne pour l'update. L'autre fonctionne pour la création. C'est tout bête. Il faut toujours conjuguer les deux. C'est OK ? Et donc là, ce que je fais, j'utilise le champ standard. Alors je ne sais pas pourquoi, chez moi, il a été renommé Block Listed et pas Black Listed, je ne comprends pas. Ouais, pareil pour moi. Je ne comprends pas. Il y a quelqu'un qui a dû faire une typo dans Marketo et hop, c'est passé en prod. Ce n'est pas grave. Donc l'idée, c'est que c'est un champ standard qui s'appelle Black Listed qui est à notre main. Donc là, c'est un bon moyen de l'initier à true. Et, derrière, dans ma smart list d'exclusion des gens, je vais utiliser le fait que la personne est Black Listed. Enfin j'exclus les Black Listed. Puis, j'ai un statut calculé sur le contact cette fois-ci, où je vais passer les contacts en bloqué. C'est-à-dire que dès que je passe dans Salesforce le compte à concurrent, tous les contacts de ce compte vont passer en statut bloqué. C'est assez pratique. Il ne faut pas oublier de faire l'inverse. Parce qu'il se peut très bien qu'un concurrent ne soit plus concurrent. Ça m'est arrivé il n'y a pas longtemps. Un concurrent qui est passé client en fait. Donc il faut prévoir la sortie. Là, c'est l'inverse. Si quelqu'un était concurrent et n'est plus concurrent, qu'est-ce je fais ? Je le passe à contact connu, puis contact bloqué, j'enlève le Black Listed. Tout bêtement. C'est toi, de ton côté, dans Salesforce qui le met en non concurrent ? Il faut une action de ta part, on est d'accord ? Oui, tout à fait. J'avais essayé de travailler sur les smart list qui contiennent les domaines et les noms de sociétés, mais c'était un peu compliqué. Ça ne marchait pas très bien. Je ne sais plus pourquoi. Il y a aussi le fait qu'il y a un problème dans Marketo, c'est que la Inferred Company ne change jamais. Une fois qu'une personne s'est connectée chez vous et a son Inferred Company, impossible d'effacer ce champ. Sauf si vous avez trouvé un moyen. Typiquement, j'ai eu un problème avec cette personne hier avec qui je discutais, Émilie de My Money Bank. Elle a été détectée comme IBM. Sûrement qu'ils utilisent un VPN ou un réseau IBM qui est en plus en UK. IBM était listé dans mes concurrents. Ce qui fait qu'Émilie s'est retrouvée par erreur dans les concurrents. Elle ne recevait rien de ce que je faisais, forcément. Donc je suis un peu revenu en arrière sur la gestion complètement automatisée des concurrents. Ça suppose que vous ayez des commerciaux ou que vous, au marketing, vous taguiez bien les choses dans Salesforce. C'est la campagne qui déduit des valeurs à partir d'une autre. On a la même chose par exemple sur la civilité. Cette campagne va essayer de mettre la civilité de la personne à partir du prénom. Dès qu'une personne est créée ou que son prénom change… J'ai récupéré la liste. On trouve des listes de prénoms masculins, des listes de prénoms féminins. Et je mets la civilité. Je suis plutôt en France donc ça se passe bien. Mais on pourrait imaginer faire ça pour tous les pays. Après, j'ai une segmentation qui se base sur la civilité et parfois je fais des e-mails qui tiennent compte du fait que c'est monsieur, madame. C'est important. Les prénoms mixtes, comment tu gères ? Je ne gère pas. Là j'ai mis vraiment des prénoms sûrs et certains. Et puis au milieu, c'est plutôt manuel. Ça, c'est plutôt des campagnes de correction de pays. J'ai activé les pays dans Salesforce. Le pays devient obligatoire quand les leads des personnes rentrent dans Salesforce. Il faut absolument qu'il y ait un pays. Là j'ai dit, si une personne est créée ou que son pays change et que le pays n'est pas un des 239 pays autorisés par Salesforce, alors… Là j'ai commencé des campagnes de correction de données avec ce que je trouvais dans la base qui était erroné. C'est souvent les valeurs françaises. Ça, c'est Xeno qui m'envoyait auparavant des valeurs sur deux caractères. C'est des campagnes un peu longues où on peut identifier les valeurs erronées qui reviennent souvent et les transformer en valeurs correctes. Ça, c'est assez utile parce que les valeurs erronées, c'est toujours les mêmes dans 80 % des cas. Donc on peut faire du 80-20 ici et réussir à garder une certaine hygiène de base de données avec ce type de campagne. Moi j'ai mis par défaut la France, mais évidemment parce que je suis en France. Si vous êtes un groupe international, il ne faudra pas mettre de valeur par défaut. Ça vous parle, ce type de campagne ? Oui c'est intéressant parce que là, j'ai demandé à mon service informatique d'harmoniser les valeurs entre ma liste de pays dans Marketo sur les formulaires et la valeur qui est dans leur CRM. Et c'est galère, ça fait des mois qu'ils sont dessus. Là, ça devrait bientôt être fini, parce qu'en fait, il y a plein d'implications dans d'autres systèmes reliés au CRM. Et du coup je me dis que si jamais ça ne marche pas, au moins là j'ai un plan B, je peux corriger ma donnée dans Marketo avant d'envoyer le contact dans le CRM, ça, c'est intéressant. Oui. Et quand on met ça en place, généralement, on… dans l'application, c'est clair. Et même quand on fait un gros import de listes par exemple après un événement, c'est galère aussi de changer les noms des pays manuellement, ça peut être traité de façon automatique par ce biais-là. Exactement. Donc il faut s'embêter une fois, surtout les pays, tu en as 239, donc s'il faut que tu te fasses 239 choices, c'est un peu compliqué. Moi je ne me suis pas allé au bout, vous avez vu j'ai arrêté au 13e parce qu'après, j'ai les occurrences à moins de 1 %, je les ai traitées à la main. Mais quand on met ça en place, évidemment, on fait une campagne Trigger pour le futur et puis une campagne Badge de reprise de données, pour tout ce qui est passé ou qui existe dans la base où on a juste les filtres cette fois-ci. Ah oui, super. Donc ça, ça corrige en masse l'état de la base et puis le Trigger lui, il va travailler pour le futur. Donc comme tu dis, Aurélie, si demain, j'importe une liste et qu'il y a plein de pays erronés, c'est la campagne Trigger qui va essayer de corriger les pays erronés. Oui mine de rien, ça facilite les choses, puis tout le monde ne fait pas attention à ce genre de choses non plus quand on importe une liste. Des fois, on ne fait pas gaffe et après on ne comprend pas pourquoi ça ne passe pas dans le CRM. Hier soir, je suis resté assez tard sur Dropcontact et mes emails perso parce que je suis en train de démarrer l'utilisation de ProspectIn pour ceux qui connaissent. ProspectIn c'est une solution qui va permettre d'automatiser la messagerie de LinkedIn que j'ai reliée à mon Marketo donc forcément je vais avoir pas mal d'emails perso qui vont arriver dans Marketo et je voulais gérer ça proprement. Ce que j'ai fait, c'est que j'ai prévu sur mes leads et sur mes contacts l'email, un email perso 1, un email perso 2, pour que, systématiquement, dès que je reçois un email qui est perso, je le pousse dans les emails perso et qu'ensuite j'essaie de trouver l'email professionnel. Donc il y a plusieurs étapes pour ça. La première, c'est détecter que j'ai reçu un email perso. Donc là ça va se passer dès que cette campagne est appelée et que l'email contient un domaine de la liste que je vous ai montrée tout à l'heure avec les 82 emails génériques, ou que Captain Verify m'a dit que c'était un email générique, on verra le Captain Verify juste après. Alors qu'est-ce que je fais ? J'attends deux minutes que Captain Verify ait fait son travail. Si l'email perso n'est pas vide, je vais sauvegarder l'email perso qui était déjà présent dans l'email perso 2, donc c'est une double sauvegarde, et puis je vais mettre l'email perso dans l'email address. Ce qui fait que là, j'ai sauvegardé l'email perso que j'ai reçu et je vais pouvoir essayer d'aller chercher l'email pro sans perdre l'information de l'email perso, c'était ça l'idée. Si je récapitule, si Emily est arrivée avec son email Gmail, l'email Gmail je vais le copier dans l'email perso et je vais appeler un Dropcontact par exemple pour essayer de trouver l'email professionnel d'Emily et le mettre ici. Bon après est-ce que je peux écrire à Emily sur son email pro alors qu'elle ne m'a pas donné son email pro ? C'est un autre débat, mais en tout cas en termes d'hygiène de base de données, j'essaie d'avoir des emails pro dans l'email et les emails persos dans les deux champs emails perso ici. Des questions sur ce sujet ? Comment tu gères le fait que tu vas aller chercher cet email pro alors qu'elle ne te l'a pas donné au niveau RGPD ? Tu bypasses ou tu envoies peut-être un mail en disant : "J'ai ton adresse pro, est-ce que je peux l'utiliser ?" Je pensais à un email un peu spécial, la première fois que je vais lui écrire, demandant justement si… En fait, le contexte c'est quoi ? J'utilise ProspectIn, donc le début de la conversation va se passer sur LinkedIn de manière totalement automatisée, parce que sinon, ce n'est pas scalable, donc je cible des gens sur LinkedIn et je les mets dans un scénario où je vais leur envoyer un message, par exemple : "Tiens, je fais un webinaire le 28 sur le marketing automation, est-ce que ça peut vous intéresser ?" Alors la difficulté, c'est en prenant garde de surtout pas écrire à mes clients déjà existants et à mes concurrents et ainsi de suite, c'est là-dessus que j'ai passé la nuit. Donc il y a une conversation qui naît sur ProspectIn, donc si la personne répond, c'est là que je me dis que c'est intéressant de l'intégrer dans Marketo, dans une campagne qui va bien et donc la personne va rentrer dans Marketo avec son email lié à LinkedIn, donc sûrement un email perso, donc là, la mécanique de sauvegarde de l'email perso et puis de je vais appeler Captain Verify et Dropcontact pour aller enrichir la personne et puis il y a un moment donné où je vais basculer de la conversation dans LinkedIn à la conversation via email. C'est là où le premier email peut être un peu prudent, en disant tiens, je peux lui proposer par exemple un nurturing d'éducation sur le marketing automation si je vois justement qu'elle était intéressée par le webinaire. Et le premier email évidemment lui dira : "N'hésitez pas à aller sur le centre de préférences pour gérer vos préférences de communication et vos données personnelles." Et comment est-ce que, dans ta base de données, tu étais dans la Salesforce, donc comment est-ce que tu tagues le fait que, par exemple, si moi je suis rentré sur LinkedIn via un mail pro et qu'une autre personne est rentrée par un mail perso, donc est allée chercher les mails pro, est-ce que ça tu le différencies dans Salesforce ? Je ne sais pas si c'est clair, ma question. Est-ce que tu différencies le fait que dans ta case email pro, c'est toi qui es allé le chercher ou c'est la personne qui te l'a donné cet email ? Ah oui. Non je n'ai pas encore réfléchi à ça, c'est un bon point, mais effectivement, comme les systèmes qui permettent d'enrichir comme Captain Verify ou Dropcontact, tu as des champs spécifiques pour gérer ces services, donc ces champs peuvent remonter dans le CRM et tu peux tout à fait avoir une section, alors après ça commence à faire beaucoup, par exemple tous les champs de Captain Verify, je les ai tagués avec CV, donc si, je les ai dans Salesforce, je ne suis pas sûr que je les ai mis sur le layout, par contre. Ils sont dans Salesforce, mais ils sont accessibles dans les rapports, donc je ne peux pas vous montrer. Mais oui je pourrais mettre un flag disant si je l'ai eu… Comme elle va passer dans une campagne Captain Verify et une campagne Dropcontact, je peux aussi mettre un statut qui dit par exemple email enrichi ici, sur Dropcontact, ce qui ferait que tiens, c'est Dropcontact qui a donné l'email. Donc Captain Verify, lui, il va me dire quoi ? S'il arrive dans Marketo, il va me dire si l'email est correct ou pas. Il va me dire si c'est un email valide, invalide ou inconnu, pourquoi il est inconnu, si c'est un email free, domaine générique, si c'est un email de type support@toto.com, si c'est un email jetable, un email risqué, un email piège, si c'est un email sur lequel la personne manifestement s'est trompée et donc il va me proposer le bon email. Donc là, je reçois une alerte, je me suis programmé une alerte si ce champ est rempli et pareil, si la personne a utilisé support plus test@gmail.com, il va me proposer de normaliser l'email. Donc c'est celui que je suis passé en premier et Dropcontact, il y a plusieurs choses, en fait vous passez email, nom, prénom, société, site web et il va essayer de trouver un email professionnel si ce n'est pas un email professionnel et puis il va vous renvoyer beaucoup d'infos sur la personne. Il va vous renvoyer tout ça. Donc il peut nous renvoyer justement l'URL LinkedIn, ça c'est intéressant pour faire le lien avec ProspectIn, le SIREN, le SIRET, le numéro de TVA, le nombre d'employés, pas mal d'informations sur la personne et sur la compagnie, pour enrichir le contact directement. Donc ça, ça s'utilise assez simplement une fois qu'on a configuré les webhooks, donc ça crée les petits webhooks qui vont appeler les services, donc là Captain Verify. Captain Verify nous donne une URL à appeler avec le format des paramètres à passer, donc là il faut passer par exemple l'email address, tout bêtement, puis l'API Key, donc il faudra que je floute ça, et ensuite je peux mapper une réponse. Donc l'attribut que me renvoie Captain Verify, il me renvoie tous ces attributs-là dans sa réponse et je les ai mappés avec mes champs. Et pareil sur Dropcontact, je suis en train de me battre avec leur API parce que, là, on ne passe pas des paramètres, il faut passer à un JSON, et donc j'ai un problème sur l'écriture du JSON, donc je suis en rapport avec leur support pour l'instant, mais ça va venir. Et sur Dropcontact il faut faire deux appels et il faut poster une demande avec les données et il nous envoie : "Est-ce que c'est passé ? Oui, non ?" Et puis un numéro de ticket, et puis ensuite, il faut faire un GET, donc il faut aller chercher avec le numéro de ticket les données qu'ils ont ramenées, donc ça fait deux appels qu'il faut gérer, mais bon ça se fait. Et donc ensuite comment j'utilise ça dans Captain Verify ? Donc là, j'ai fait une campagne qui dit, je vais appeler Captain Verify dans deux cas, à la création et à la modification de l'email address évidemment. Donc à chaque fois que l'email est modifié, je vais appeler le… donc je vais sauvegarder déjà les valeurs existantes de Captain Verify dans les valeurs Sauvegarde, donc ça, c'est la sauvegarde des valeurs existantes, et ensuite ici Sauvegarde, Sauvegarde, Sauvegarde, OK. Là, j'appelle le webhook de vérification de l'email, je le passe en membre, je mets que la dernière date de vérification c'est aujourd'hui, j'attends deux minutes et je bascule sur la détection de l'email perso, donc la campagne que je vous ai montrée tout à l'heure. Et j'ai décidé aussi de déclencher Captain Verify à chaque fois que la personne va faire une activité, mais une fois tous les 90 jours. Donc si le score est changé et que la date de dernière vérification est vide, ou qu'elle est avant 90 jours, alors je refais la même campagne, Sauvegarde plus Sauvegarde, appel webhook, et puis mise à jour de la date de dernière vérification. Donc le Dropcontact ça va marcher à peu près pareil, si ce n'est qu'il faut que je le fasse passer après mon programme de vérification de l'email perso, donc il y a un séquencement à prévoir pour que tout ne se fasse pas en même temps, sinon ça ne va pas marcher. Comme Dropcontact coûte beaucoup plus cher que Captain Verify, je veux aussi exclure de l'envoi à Dropcontact tous les emails pourris, que je ne veux pas, qu'il n'est pas la peine d'aller vérifier. Tiens, une petite campagne dont on ne parle pas souvent, mais qui est bien utile. Quand un lead ou un contact est supprimé dans Salesforce, il n'est pas supprimé dans Marketo. Et on peut se retrouver assez vite avec pas mal de personnes qui existent dans Marketo, et qui n'existent pas dans Salesforce. Moi je trouve ça assez troublant, parce que Salesforce, c'est plutôt le maître, donc si j'ai décidé de supprimer quelqu'un dans Salesforce, a priori, j'ai envie de le supprimer dans Marketo, c'est comme ça. Donc quand une personne est supprimée dans Salesforce, on a ce champ SFDC Is Deleted qui passe à true, et on a aussi un trigger qui s'appelle Person Is Deleted. Donc là, j'ai mis ceinture, bretelles. Si l'un des deux se passe, je supprime la personne de Marketo. Et je n'ai pas mis supprimer du CRM, puisque l'info vient du CRM. Donc ce n'est pas la peine de renvoyer un ordre. Moi, je n'étais pas au courant que lorsque quelqu'un était supprimé de Salesforce, ça ne synchronisait pas automatiquement avec Marketo comme le reste des flow. Donc, il faut obligatoirement avoir ce que tu nous montres. Par contre, dans l'autre sens, si on supprime quelqu'un dans Marketo, il sera supprimé automatiquement dans Salesforce ? Non. Donc, là, il faut faire… OK. C'est vraiment dans les deux sens. Là, tu as l'option manuelle. Ce que ça veut dire : dans l'action Delete Person, tu as le choix de supprimer ou pas du CRM. Donc, c'est toi qui dis en fait. Mais par défaut, Marketo ne le fait pas. OK, je n'étais pas au courant. Comme le reste des choses qui étaient synchronisées, je pensais que ça allait dans les deux. Merci. Ça aussi c'est un truc tout bête, mais alors purée ! Ça pourrait expliquer pas mal de choses. Merci. On a vu de la détection incohérence, l'enrichissement. Bien sûr, le nombre de campagnes qu'on peut faire de ce type-là est infini. Parce qu'il y a toujours des choses à détecter et corriger dans Marketo, dans Salesforce. Surtout quand on a connecté Salesforce. Qu'est-ce que je voulais vous montrer ? Oui, un petit coup de dédoublonnage. J'ai commencé à utiliser Cloudingo. Je vous l'avais montré une fois avant les vacances. Cloudingo est la dernière brique du puzzle. Une fois que l'enrichissement est fait, qu'on a détecté que la personne est… Je suis en train de me demander : est-ce que je déclenche le dédoublonnage avant d'enrichir avec drop contact ou pas ? Parce que ce serait dommage d'enrichir quelqu'un qui à la fin va être fusionné avec quelqu'un qui existe déjà. Donc c'est peut-être plus pertinent d'attendre un quart d'heure que Cloudingo fasse son travail pour ensuite enrichir la personne. Si jamais, on doit encore le faire. Il faudra que je vérifie ça un petit peu. Cloudingo se branche sur Salesforce. Ça veut dire que le travail de dédoublonnage, je vais le baser uniquement sur Salesforce. Je peux le faire parce que moi, j'ai une politique où dès qu'un lead est créé, je l'envoie assez vite dans Salesforce, appartenant à Marketo. Parce que j'ai synchronisé avec une campagne Salesforce quasiment toutes mes campagnes d'acquisition. Un lead qui arrive dans Marketo, chez moi, assez vite, généralement au bout de cinq minutes, il est dans Salesforce. Ce qui fait qu'on peut dire que tout ce qui est dans Marketo est dans Salesforce quasiment. Donc je peux me baser uniquement sur Salesforce pour utiliser Cloudingo. Si ce n'est pas le cas, on peut aussi mapper Cloudingo avec Marketo, quand on a un Marketo qui contient beaucoup plus que Salesforce. Cloudingo fonctionne avec, encore une fois, des trigger que vous paramétrez. Là, j'en ai paramétré 18. Pas mal. Ils vont regarder des cas très précis. Ça, c'est un cas assez simple. Je n'ai pas beaucoup de doublons dans ma base. J'ai tendance à les corriger avant que Cloudingo fasse le job. C'est plutôt bien, mais je n'ai pas grand-chose à vous montrer. Si tu veux, je peux mettre ma base à ta disposition pour un test, parce que moi, j'ai pas mal de doublons. Donc là, un truc très facile. On va regarder si le compte, le nom du compte est le même. C'est tout bête. Là, on dit quel est le type d'opération qu'on veut faire, sur quel objet. Ensuite on définit ici… On a accès à tous les types du compte qui sont en base. On peut baser un dédoublonnage sur tous les champs qu'on souhaite. Là, j'ai choisi l'Account name et j'ai choisi de dire : c'est un dédoublonnage exact. Donc il y a différents types de détections. Alphanumérique. On peut nettoyer le nom de la Company avant. E-mail. web domain, exact. Assez souvent on utilise l'exact. Ensuite, on peut mettre des limites pour que ça aille plus vite. Par exemple, j'exclus les sociétés inconnues, puisque c'est la valeur par défaut que je mets dans le nom du compte quand un lead arrive dans Salesforce sans nom de société. Typiquement, les gens qui s'inscrivent à ma newsletter en mettant juste l'e-mail. C'est possible. Donc, ça ne sert à rien que j'essaie de fusionner ces gens-là. Ça ne sert à rien que je fusionne, pardon, tous les comptes qui s'appellent société inconnue, puisque c'est le même. Ensuite on le lance. Et il va me dire le nom de sociétés qui sont similaires. Là, je n'en ai pas. Après, je peux décider de… Par exemple, si je vais là, Name Cleaned. Je peux décider à la main ou automatiquement de fusionner. Par exemple, il m'a détecté qu'Axa Group solutions. J'ai Axa Group, Axa Group Solutions. Il se dit : "Tiens, ça se ressemble beaucoup. Est-ce que ce ne serait pas deux similaires." Là, ce ne sont pas les mêmes puisque c'est une filiale. Mais ça fonctionne comme ça. Là, c'étaient des détections exactes. Ce qui est intéressant, c'est qu'on peut faire des détections fuzzy. Fuzzy, c'est approximatif. Si je regarde ça, j'ai fait une chaîne de caractères dans Salesforce qui concatène le nom du compte et le pays. Là, on va d'abord grouper… C'est pour ça que j'ai dû mettre les pays obligatoires dans Salesforce. Parce qu'il fallait absolument que j'aie des codes pays pour utiliser Cloudingo. On va d'abord grouper sur le code pays. Ça va être la France principalement. On ne peut pas utiliser le mode fuzzy sans mettre un exact d'abord. C'est la grosse contrainte. Le fuzzy ne peut pas être le premier. Sinon, je n'aurais pas eu besoin de faire ça. Je fais d'abord un regroupement sur les codes pays et ensuite j'utilise le nom. Ah non, c'est le nom plus le website que j'ai fait là. Je regarde s'il trouve des choses qui se ressemblent. Là, il m'en a trouvé un. On va voir ce qu'il a trouvé. Sylvain, il n'y a pas la bonne practice pour dédoublonner uniquement dans Marketo ? Quand on n'a pas Cloudingo et qu'on veut dédoublonner dans Marketo, c'est quoi les meilleures practice ? Tu es obligé de faire à la main. C'est obligatoirement à la main ? Ouais, parce que, dans Marketo, il va détecter des doublons sur la base de champs exacts. Soit l'e-mail exact, soit le full name exact, etc. Ensuite, tu peux les fusionner 2 à 2 ou 3 à 3 dans Marketo. Et ça va être propagé dans Salesforce. La chose à laquelle il faut faire attention, c'est que tu ne peux fusionner dans Marketo que 2 personnes qui sont soit pas connectées à Salesforce, soit 2 personnes qui sont des leads, soit 2 personnes qui sont des contacts dans Salesforce. Tu ne peux pas fusionner ensemble par exemple un lead et un contact Salesforce. Ça ne marcherait pas. En fait, tu peux faire ce que tu peux faire dans Salesforce. Et comme dans Marketo, tu ne vois pas aller un seul coup d'œil ce qui est synchronisé, pas synchronisé, lead et contacts. C'est un peu compliqué. Tu peux commencer dans Marketo. Beaucoup de gens le font. Le problème est que tu le fais à la main. Ce qui est sympa, c'est qu'une fois que tu as bien maîtrisé tes règles, on peut décider de mettre précisément la façon dont on souhaite fusionner à chaque fois les contacts en fonction des cas. Puis on peut lancer l'automatisation de la fusion. Ça se fait quand on a bien maîtrisé ses filtres et qu'on est à 99 % sûr qu'à chaque fois que Cloudingo nous remonte quelque chose, c'est un vrai doublon. Il y a une phase d'observation où on va exclure petit à petit les choses qui remontent et qui sont soit des… Parfois il y a des homonymes. Il peut y avoir deux Paul Dupond. Il y en a plein. On ne va pas fusionner tous les Paul Dupond ensemble. Il faut d'abord commencer par exclure… Les John Doe, on en a pas mal. Ce qui est bien, c'est qu'il y a la 2e vitesse où on peut automatiser la fusion. On dit : fais ça au fil de l'eau ou fais ça massivement, quand on veut le faire. Puis il déclenche. Ça, c'est assez sympa. Comment es-tu sûr, dans les doublons, de supprimer les bonnes infos ? C'est-à-dire que tu as deux numéros de téléphone, deux job title qui sont différents mais tu as le même nom, même adresse e-mail. Comment es-tu sûr à chaque fois de conserver les bons éléments ? Sur quoi il se base ? C'est toi qui vas dire la règle de fusion très précisément pour chaque champ, en fonction des cas. Donc, tu peux dire : je veux garder systématiquement celui qui est le plus à jour, celui qui est créé le plus récemment, celui qui a le champ qui fait ça. Et sur tel champ, tel champ, tel champ, je veux que ça se passe comme ça. C'est ici que tu définis comment la fusion doit se passer. Là, je n'en ai pas mis, mais tu peux ajouter autant de règles que tu veux par champ. Bonjour Sylvain. Bonjour à tous. Je ne sais pas si vous m'entendez correctement. J'ai une question un peu liée, pas forcément aux doublons, mais j'ai un cas de figure un peu similaire. Je voulais avoir les retours de tout le monde sur le cas de figure où j'ai des commerciaux qui m'envoient une liste d'e-mails avec pour objectif d'enrichir leurs comptes client existants dans Salesforce. Et en fait je me posais la question : où est-ce que j'importe cette liste ? Est-ce qu'il vaut mieux l'importer dans Marketo ou alors dans Salesforce ? Sachant que c'est une liste d'e-mails qui devraient être des contacts dans Salesforce liés à des comptes et non pas des lead à proprement parler dans Salesforce. Je voulais savoir si vous aviez un retour d'expérience à partager sur ce sujet. Moi, je peux répondre si tu veux. Je ne sais pas si vous m'entendez, c'est Chloé de Lectra. Salut, Chloé, on t'entend très bien. Salut. En gros, nous, dans ces cas-là, on importe directement dans Salesforce. On rattache à l'ID du compte. On fait importer directement des contacts dans Salesforce. Comme ça, il ne passe pas par l'étape de lead et de conversion à contacts, etc. Mais c'est-à-dire que dans le fichier d'import, il faut que tu aies l'ID du compte ou comment tu fais ? Ouais. On retrouve l'ID du compte. En fait, on demande aux commerciaux de nous mettre les sociétés et tout ça. Ensuite on retrouve l'ID du compte. Et on importe directement dans Salesforce. D'accord. Donc, tu as ton fichier à importer. Tu as exporté les comptes avec leur ID. Tu fais un gros recherche V, c'est ça ? Oui. Pour mettre les ID dans le fichier d'import. Oui, c'est ça. Et ensuite j'importe. Comme ça, ils sont automatiquement attachés au bon Account dans Salesforce. Au moins, on n'a pas toute la partie marketing ready qui se met et tout ça. Ça, ça marche parce que c'est vous, Chloé, qui le faites et vous maîtrisez le process. Mais, ça ne peut pas être un process qui est laissé à la main des commerciaux, ça. Ah non pas du tout. Même nous, on aide à préparer les fichiers. Par contre, après, c'est notre équipe IT qui importe directement dans Salesforce. Parce que nous, on ne peut pas importer dans Salesforce. D'accord. Tu n'as pas le data loader ? Non, pas moi. Je n'ai pas cette chance. C'est la question que j'allais demander. Non, je n'ai pas cette chance. Alors déjà, ne pas avoir le data loader, c'est pas mal. Oui, on est assez content. On prépare juste nos fichiers et puis on les envoie. C'est tout quoi. C'est moi qui fais tout et bon. Des fois, je me fais des soirées data loader, c'est sympa. Donc Lucia, ton cas d'usage, c'est quoi ? Ce sont les commerciaux qui doivent les importer ? Oui, en fait, ce sont les commerciaux qui souvent réussissent à récupérer des adresses e-mails non existantes dans la base. Par exemple, notre chef de projet qui s'occupe du projet. Mais comme ce n’était pas le décisionnaire, il était ni dans Salesforce ni dans Marketo. L'idée est qu'il vienne l'ajouter dans Salesforce pour pouvoir faire le suivi avec la personne directement. C'est plutôt dans une démarche d'ABM. Mais du coup, on a des listes de contacts comme ça qui sont fournies par les commerciaux. Ce n'était pas très clair si on pouvait les importer. Avec toutes les règles de data management, justement, on se posait la question. Mais, du coup, la solution de Chloé me semble assez pertinente. Est-ce que la solution de Chloé te convient ? Oui, exactement. Je trouve que c'est la bonne. Justement, j'hésitais. En fait, nous, au début, on importait dans des programmes de data management genre contact enrichment dans Marketo et tout ça. Sauf qu'en fait, ils étaient tous lead. Du coup, il y avait toujours cette étape de conversion, et surtout cette étape d'attacher au bon account quand l'account était existant. En fait, ça générait vachement de tâches qui du coup devenaient manuelles. Oui, avec une perte de temps énorme. Cloudingo a aussi une autre fonctionnalité assez sympa : il peut convertir des lead automatiquement en contacts quand il détecte que le nom de la société d'un lead est exactement, ou à peu près, la société d'un contact existant en base. Donc, ça, c'est cool. Donc, ça peut aussi régler le sujet de… On importe côté Marketo et on se retrouve avec des lead au lieu des contacts. Ça suppose qu'on arrive à rentrer les noms des sociétés à peu près correctement. Mais on peut tout à fait avoir la conversion automatisée qui se fasse quoi. Ici j'ai une action de lead to contact. Bon, ben, écoutez, j'espère que cette session data quality vous a plu. Elle aura pu vous apprendre des choses.