J'ai préparé pas mal de points ce matin, issus des workshops que je fais en ce moment avec vous et des petits pièges que je vois à droite, à gauche. J'ai 12 campagnes qu'on va passer en revue ce matin sur les bonnes pratiques des Smart Lists et des Flow. Ok ? La première, un petit piège assez classique sur les filtres sur les dates. Ici, j'ai pris un champ de ma base de données qui est un champ Date, qui est la date d'enregistrement du consentement sur le consentement (Événement). Dès que quelqu'un me donne le consentement sur les événements, soit dans un formulaire, soit sur le centre de préférence, je trace la date. Là, je suis dans une situation où j'ai envie de faire une requête sur cette date. J'aimerais trouver les gens qui vont donner leur consentement sur l'année. Est-ce que le filtre que j'ai fait, là, va fonctionner ? Comment vous interprétez ce filtre, vous ? C'est une session où je vais vous faire parler. Essayez de jouer le jeu et lancez-vous. Je ne sais pas. Quelqu'un tend sa chance, non ? Je ne sais pas dire. Élodie, on ne l'a pas vu ensemble, celui-là ? Celui-ci, je ne crois pas qu'on l'avait vu ensemble, mais il me semble que sur la (inaudible) que tu nous avais fait, la façon d'interpréter juste le (in past ou one year), pour moi, c'est à partir du 30 avril et les 365 jours dans le passé, à l'année écoulée, à partir d'aujourd'hui. Ça, et par exemple, (in past) de 365 days, ça fera la même chose ? Oui, mais vu ce que tu dis, c'est que ce n'est pas ça. C'est le piège. Quand on utilise le mot-clé "year" ou "année" en français dans Marketo, il va se baser sur l'année civile. Pour Marketo, je choisis les gens qui ont ce champ Date dans l'année écoulée, du 1er janvier 2020 au 31 décembre 2020. D'accord ? Ce n'est pas l'année glissante. Si on veut l'année glissante, il faut mettre 365 jours. Il faut avoir en tête que même quand je prends "jour", c'est "jour" pour Marketo au sens jour de minuit à minuit. Ce n'est pas jour glissant. Donc c'est important d'avoir ça en tête parce qu'assez souvent on met… (Je vais mettre) les gens qui ont fait ça sur les deux ans précédents. Et on va mettre 2 years, mais 2 years, ça ne va pas comprendre la période de temps qui va du début de l'année à maintenant. Donc gros piège, là, attention. C'est pour ça que je vous invite, quand vous avez des filtres sur les dates à mettre, c'est plutôt utiliser au moins les jours. On ne va pas descendre aux minutes, mais généralement, le jour, ça suffit. Parce que quand on utilise "year" ou "month". "Month", c'est pareil, le "month", ça commence du 1er du mois au à la fin du mois. Ça ne contient pas le nombre de jours qu'il y aura du début du mois en cours jusqu'à maintenant. Pareil pour "week". "Week", ça commence… "Week", c'est une bonne question. Ça commence le dimanche ou ça commence le lundi ? Je ne sais plus. Je pense que ça commence le lundi. Ok ? Ça, c'est un gros piège. Premier point. Tout le monde a compris ? Oui. Deuxième petit piège. Je dis que c'est un piège, donc c'est trop facile. J'ai une situation où j'ai pas mal d'événements qui peuvent se passer et j'aimerais déclencher une action sur un des événements. Là, j'ai pris l'exemple de… Qu'est-ce que j'ai pris ? J'ai pris encore mes consentements de centre de préférence et j'aimerais… Je regarde si ces trois consentements sont modifiés dans mon Marketo et j'aimerais changer la valeur d'un champ sur la base. Si c'est le premier, si c'est Événements, j'aimerais mettre la valeur 1. Si c'est Formations, j'aimerais mettre la valeur 2. Si c'est Newsletter, j'aimerais mettre, dans le même champ, la valeur 3. J'ai fait cette action, ce flow. Si le champ Abonnements est Oui, j'aimerais mettre dans Type de dernière activité Événement, par exemple. Si c'est Séminaires, je mets Séminaires et si c'est Newsletter, je mettrai Newsletter, par exemple. Est-ce que j'ai bien fait ? Est-ce que ça va marcher ? Mais là, si la personne choisit les trois. Oui, premier point, comment ça se lit ça ? Trois triggers. Est-ce que les trois peuvent se déclencher en même temps ? Il va chercher si soit le premier, soit le deuxième, soit le troisième sont actifs. Oui, effectivement. Les triggers, on peut les empiler. Rappelez-vous, ça, ça ne s'applique pas aux triggers, ça ne s'applique aux filtres. Il y a forcément des "ou" entre les triggers. Puisqu'un trigger, c'est un processus qui attend qu'il se passe une action dans le futur, soit que ce champ change, soit que celui-là change, soit que celui-là change. Donc, cette campagne va se déclencher dès que l'un des trois se déclenche et dans le futur, il y aura toujours un moment donné où il y aura une milliseconde d'écart, même si la personne fait les trois en même temps. Ça ne se passera jamais au même temps. Donc, il y aura forcément un des trois qui va se déclencher. Ok, ça, c'est le premier point à avoir en tête. On peut empiler les triggers, il n'y a pas de souci, mais ça va se lire. Déclenche-moi la campagne dès que soit (PF_ABO_Événements) est changé ou (PF_ABO_Formations Séminaires) est changé ou (PF_ABO_Newsletter) est changé. Mais on ne peut pas dire dès que les trois changent. Ça ne peut pas se lire comme ça. Et sur le flow ici, le piège, c'est qu'il n'y a pas de lien vraiment pour Marketo entre la smart list, ce qui se passe ici, et le flow. C'est qu'on a beau avoir mis les mêmes champs. Pour Marketo ici, il va dire : "Je vais faire un Change Data Value" et je le fais complètement indépendamment de ce qui s'est passé dans ma smart list. Donc, je vais regarder ici si au moment où je passe dans cette action, pour la personne en question, le champ (PF_ABONNEMENT) est égal à Oui. Mais ça peut très bien être du fait que, effectivement, ce champ vient d'être changé, donc juste à l'instant. Mais ça peut être du fait que ce champ est égal à Oui depuis un an. Il n'y aura pas de corrélation entre cette action dans la smart list et le flow ici. Donc ça, c'est souvent un piège dans lequel on tombe. On a tendance à croire que si on a mis une action ici, on va pouvoir filtrer ici. Oui, il y a des cas où ça marche, mais il y a des cas où on va être pris au piège parce que le champ aura été mis à la valeur qu'on souhaite, bien avant le trigger ici. Ça, ce n'est pas évident à comprendre. Mais il faut l'avoir en tête. Il n'y a pas de lien entre ce qui se passe dans la smart list et dans le flow. C'est Anne. Comment tu le vois ? C'est parce qu'il manque quelque chose ? Si on voulait dire, je change Type de dernière activité si c'est (PF_ABO_Événements) qui vient de passer à Oui, il faut que (inaudible) à une smart list préalable. Si je fais une smart list qui dit (PF Événements vient de passer à Oui), je cherche les gens pour qui la valeur vient de changer. Je vais utiliser le Data Value Changed sur le champ (PF_ABO_Événements). (In past), ici, je vais mettre 5 minutes. New value, Oui. Et je vais pouvoir utiliser cette smart list dans mon flow. Ici, à la place du champ, je mettrai ma smart list. Pardon, il faut que j'utilise Member of Smart List. Ma smart list. Là, ça marcherait. D'accord. Est-ce que dans ce cas-là, il est possible et il vaut mieux mettre un (wait) au début pour s'assurer que quand la valeur est changée, il y ait le temps que tous les changements potentiels soient pris en compte ? Parce qu'on sait que des fois, les actions ne se passent pas exactement, les mises à jour des valeurs ne se mettent parfois pas dans le sens qu'on espérait. Est-ce que dans ce cas-là, il vaut mieux mettre un (wait) avant pour s'assurer que quand le flow est lancé, les mises à jour des champs relatifs au lead ont bien été prises en compte ? Oui, c'est plus prudent. Là, on attend que le champ change. Si on regarde l'Activity Log, on va attendre une ligne qui s'appelle Change Data Value avec l'attribut (PF_ABO_Événements) et l'attribut Nouvelle Valeur, Oui. Comme là, on va se baser sur… On fait une smart list qui se base sur le changement du de l'attribut, normalement, on n'a pas besoin du (wait). On peut le faire pour mettre un peu ceinture et bretelles mais il n'y a pas de risque qu'on regarde une action qui ne s'est pas écoulée puisque là, pour le coup, notre action ici dépend du trigger qui se passe là, donc les deux s'enchaînent bien. Je vais faire justement, un de ces quatre, on va voir cette histoire d'enchaînement d'actions. Là, si vous voulez enchaîner une action sur un champ qui se passe dans la smart list, pensez à utiliser ça parce que si on met juste ça, ça peut marcher mais pas forcément. Encore un autre exemple sur le même sujet, un lien trompeur entre (Smart Lists et Flow), qu'on fait assez souvent. Je vais déclencher une action sur le fait qu'une personne clique sur un lien dans un de ces cinq emails. Là, ce sont les cinq derniers emails d'appel du vendredi matin sur le mois d'avril. J'aimerais faire une action sur le fait que dès que la personne clique sur l'un de ces cinq emails. C'est comme ça que ça se lit mais je ne sais pas lequel. Et on va dire, je vais faire un Change Data Value. Je n'ai pas mis l'attribut, on imagine que je veux changer la valeur d'un champ quelconque. Si j'ai cliqué dans l'email du 2 avril, on va faire ça. Si j'ai cliqué dans l'email du 9 avril, on va faire ça. Dans l'email du 16 avril, du 23 avril. Là, même sujet, ça peut marcher mais il n'y aura pas de corrélation entre le fait que j'ai cliqué ici et cette action-là. C'est-à-dire qu'ici, il va regarder quand il va arriver là, est-ce que la personne dans le passé a cliqué sur l'email du 2, que ce soit à l'instant ou que ce soit il y a une semaine ou que ce soit il y a trois semaines. Donc si quand j'ai envoyé mon email du 2 avril, la personne a cliqué dedans, à chaque fois qu'elle va repasser dans cette (campagne) parce qu'elle aura cliqué sur les emails suivants, l'email du 9, du 16, du 23 ou du 30, dans le Flow, elle s'arrêtera toujours ici. Parce que dès que Marketo va rentrer dans cette action, il va voir que la personne a cliqué effectivement dans l'email du 2 et il ne passera jamais sur les suivants. Là encore, si on voulait bien faire la campagne, il faudrait préparer une smart list préalable qui dit : "Je cherche les personnes qui ont cliqué dans les cinq dernières minutes sur l'email du 2 ou les personnes qui ont cliqué…" Je ferai cinq smart lists et je mettrai mes cinq smart lists ici, avec Member of Smart List. Et là, ça fonctionnerait. Ok ? Ça, ce sont des choses qu'on voit assez souvent comme piège. Toujours dans les actions un peu concomitantes, on a souvent à déclencher des actions sur le fait qu'une personne remplit un formulaire, et que dans le formulaire, elle va remplir tel champ. C'est ce que (Laetitia disait). Ici, par exemple, j'ai utilisé un de mes formulaires de (Webinar) dans lequel il y a ce champ de consentement Événements et ici, j'aimerais déclencher une action si la personne a rempli mon consentement, si elle vient de remplir mon consentement Événements. Je l'ai fait comme ça. Ça, est-ce que ça va marcher ? À votre avis ? Non, il manque la smart list. Il manque quelle smart list ? De ceux qui viennent de remplir le champ. Oui. Les autres, qu'est-ce que vous en pensez ? On va aller voir sur un Activity Log comment ça se passe concrètement quand on remplit un formulaire. Je vais prendre Léonard. Je vais me trouver un formulaire que j'ai rempli, le 25 mars. Où est-ce qu'il est ? Il est juste après. Il ne doit pas être loin. Il est là. Ici, j'ai rempli un formulaire d'inscription, ce webinaire en replay, et effectivement j'ai cette ligne dans l'Activity Log qui s'appelle (Fills Out Form) et il faut bien avoir en tête que ce trigger est déclenché parce qu'à un moment donné, il y a cette ligne qui s'écrit dans l'Activity Log, pas autrement. C'est-à-dire, tant que cette ligne n'est pas écrite dans l'Activity Log, le trigger ici ne va pas s'activer. Donc il y a vraiment un lien entre les triggers que vous utilisez et les actions qu'on lit dans l'Activity Log. Si Marketo n'inscrit pas cette ligne à un moment donné dans l'Activity Log, jamais ce trigger ne se déclenchera. Et inversement, si cette ligne s'écrit, forcément, ce trigger va se déclencher. Maintenant, quand je remplis le formulaire, j'entre des champs. Est-ce que Marketo va écrire les champs avant ou après le (Fills Out Form) ? On voit qu'ils sont là, les champs. On voit… ####voit qu'il y a des change data values, là, juste avant cette ligne-là. On voit qu'il y a le prénom, le nom, le captcha, l'EPF abonnement qui passe de "non" à "ou", (inaudible), blablabla. Il y a même le changement du programme Status qui se fait avant le (inaudible). On voit que l'enchaînement des actions quand je remplis un formulaire, c'est, un, j'écris en base les champs avant même d'écrire le (inaudible). Dès qu'une personne soumet le formulaire, Marketo écrit tout de suite en base les champs et déclenche des actions qui s'appellent les change data values. Il détecte que les valeurs sont changées et il inscrit ça tout de suite. Ensuite, il écrit en base les champs sur Programme Members Data, et ensuite seulement il remplit (inaudible). Cette smart list va être déclenchée par le trigger. Ce n'est pas par le filtre, elle va être déclenchée par le trigger. Elle va être déclenchée dès que cette ligne-là s'inscrit dans l'Activity Log. Au moment où cette ligne est inscrite dans l'Activity Log, j'ai bien, on l'a vu, ce champ qui a été passé à "oui", avant. Là, il n'y a pas de souci. C'est-à-dire que même si le champ vient de changer à "oui" juste avant, dans les quelques millisecondes avant, les deux vont marcher. Parce que c'est un champ qui est porté par le formulaire et qui n'est pas déclenché par un trigger qui va être changé par un champ qui va être changé dans le formulaire. C'est un champ qui est porté directement dans le formulaire. Ça s'écrit tout de suite avant que Marketo écrive le (inaudible). Quand vous posez des questions, c'est important de revenir à l'Activity Log, de regarder comment ça s'enchaîne, et en fonction de comment ça s'enchaîne, vous pouvez décider que oui, je peux poser le filtre, parce que le champ aura bien été écrit en base avant que le trigger se déclenche. Si ce n'est pas le cas, il faudra passer par ce qu'on a fait tout à l'heure, mettre le filtre plutôt dans le flow, avec un (weight), avec une smart list ici, comme on a fait tout à l'heure. Là, c'est un cas où ça fonctionne bien. Est-ce que c'est clair pour vous ? Oui. Tu n'as pas besoin de repasser par la liste des gens, alors que l'autre, tu avais besoin. Oui. Encore une fois, si ici, mon champ… Là, ce que je ne sais pas, c'est est-ce que le (inaudible) est passé à "oui" juste avant, grâce à ce formulaire, s'il est à "oui" depuis une semaine. Ça, je ne le sais pas. Parce que quand le trigger va se déclencher, Marketo va juste regarder qu'au moment où cette ligne s'inscrit dans l'Activity Log, en base, j'ai ce champ qui est égal à oui. Que ce soit dans la milliseconde précédente ou que ce soit une semaine avant ou un an avant. Je n'avais pas cette contrainte de "je veux que l'action se passe juste avant". Si j'ai cette contrainte, je pourrai utiliser, ici, plutôt un Data value was changed, avec le PF abonnement, événement, date d'activité. Je peux mettre (inaudible) five minutes. Je ne sais pas si c'est glissant pour les minutes. Je pense que les minutes, ça marche. On n'est pas sur l'horloge mondiale calendaire. Je pense que les minutes, ça marche. Mais sinon, on pourrait mettre (inaudible) secondes. Voilà. Et là, je suis sûr que ça se déclencherait uniquement si la personne a rempli le formulaire et que le PF abonnement vient de passer à "oui". C'est des petites subtilités, mais qui font parfois une grande différence dans les campagnes. Deux petites campagnes, si vous n'avez pas de questions. Des idées pour votre Marketo. Un petit coup de refresh. Pensez que vous pouvez enrichir votre Marketo avec vos propres activités. Ici, par exemple, chez nous, on s'est connectés avec la plateforme vidéo TwentyThree, celle que vous connaissez par cœur maintenant. TwentyThree m'a fait créer deux custom activities, qui s'appellent Watches video et Sign up on video, qui sont alimentées par TwentyThree, par les API, et qui enrichissent l'Activity Log de nouveaux types d'activités, de type "la personne a regardé cette vidéo pendant tant de temps, pendant tel pourcentage". J'ai tout un tas d'attributs ici qui sont envoyés par TwentyThree et qui ne sont pas des activités natives de Marketo. On peut tout à fait, soit en connectant une appli qui s'intègre nativement, comme TwentyThree, soit en créant votre propre custom activity et en enrichissant par une intégration (custo), on peut enrichir Marketo. Un cas d'usage assez classique : pour toutes les sociétés et les entreprises qui ont un espace client, c'est tracer qu'une personne soit s'enregistre, soit se passe dans l'espace client pour que derrière, on puisse déclencher une action s'il rentre dans l'espace client ; ou, à l'inverse, qu'on puisse détecter un risque de churn si la personne ne s'est pas loguée dans l'espace client depuis trois mois, par exemple. Dans Marketo, vous pouvez créer dans (inaudible) vos propres activités, et ensuite, les remplir grâce à… Alors, ça se fait par les API, ça nécessite de travailler avec l'IT. Ici, j'ai créé, par exemple, une activité de type "visites espace client", et je pourrais remplir les activity logs avec cette activité par API. C'est assez intéressant quand vous avez des (appli) tierces et que vous souhaitez capturer cette information dans Marketo pour déclencher des campagnes, des filtres, ainsi de suite. Ça vous parle, ça ? Oui, totalement. Par exemple, mon chatbot (Xeno) m'envoie des interactions, des événements. Quand vous prenez rendez-vous avec moi, hop, dans Marketo, il y a une interaction (Xeno) de type meeting qui est créée et je peux filtrer là-dessus. Idem, quand on connecte son CRM ou un dataware ou n'importe quel API, on peut cette fois-ci non plus juste avoir des activités, mais carrément embarquer des objets métiers, des objets (custo) de votre CRM ou de votre dataware dans Marketo. Par exemple, dans mon CRM, moi, j'ai une notion de projet et de membres du projet. Par exemple, si je fais un projet chez (inaudible), dans mon CRM, j'ai un projet (inaudible) et Anne est membre du projet. Je peux déclencher des actions, ici, sur le fait qu'une personne ait ajouté un projet ou est ajoutée en tant que membre du projet avec tel rôle, par exemple. C'est excellent pour le marketing client et déclencher des campagnes d'up sell ou de cross sell, parce que pour faire ce type de campagne, il faut nécessairement savoir qu'on a vendu quelque chose, que ce soit un bien ou un service. Et que ce service, c'est tel produit. Pour que derrière, si on a vendu le produit A, on puisse proposer le produit B. Si on veut faire ce type de campagne assez fine en termes de marketing client, il faut nécessairement avoir de l'information métier qui revient généralement du CRM. Ça encore, on peut créer des objets (custo). Si on a Dynamics ou Salesforce, ça s'intègre nativement et on récupère les objets assez facilement grâce à ce type d'écran, ici. Si on a un CRM qui est connecté en (custo) avec Marketo, on crée ses propres custom objects, ici, et on va travailler avec l'IT pour, encore une fois, créer une intégration qui va pousser l'information. Généralement, en lecture seule. C'est toujours en lecture seule dans Marketo. Là, par exemple, j'avais pris le cas de Beneteau qui gère les bateaux achetés par ses clients. On peut créer un objet "bateau", puis remplir, depuis le CRM ou le ERP, les bateaux vendus aux clients pour, derrière, si tu as acheté le bateau A, je vais te vendre peut-être le contrat de maintenance pour le bateau. Voilà. C'est intéressant, parce que nous, on a des clients, des gens dont on sait que ce sont des clients, mais on ne sait pas de quoi ils sont clients. On ne sait pas si ils ont acheté chez nous. Mais si on rentrait cette donnée, on pourrait faire des campagnes là-dessus ? Bien sûr. Tu peux créer une table Services, puis dire "tel client, ça peut être soit la société et/ou la personne, a acheté tel, tel, tel services." Tu peux en avoir plusieurs, évidemment. Avec, par exemple, si c'est des contrats, date de début, date de fin de contrat. Puis tu peux faire des triggers sur le fait que ton contrat arrive à échéance dans trois mois, par exemple. Ah oui. Ça donne des idées. Oui. D'accord. Intéressant. OK. Ici, par exemple, mes bateaux, si la personne a acheté un bateau de marque Beneteau, que c'était le modèle Truc, et que la date de commande était dans les derniers 60 jours, je peux déclencher "Welcome pack", par exemple. Intéressant. Un petit piège pour ceux qui sont justement connectés à un CRM, comme moi. Là, j'ai fait une campagne vraiment bête, où je dis "si une personne est créée et que le nom de la société fait partie des noms des noms de société pharma que je suis, j'aimerais changer le champ Industry, secteur d'activité, sur la personne et mettre : Pharma". Est-ce que quelqu'un peut m'expliquer quel est le piège, là ? Est-ce que tu peux répéter pour moi ? Je veux, quand une personne est créée et qu'elle appartient au secteur pharma… Que je reconnais, parce que le nom de société qu'elle a mis dans le formulaire, c'est une des sociétés pharmaceutiques que j'ai identifiées. J'en ai mis quatre, je peux en mettre 15, 20, 90. J'aimerais changer son champ Industry et mettre Secteur d'activité pharma. Ça dépend de la valeur, si elle n'est pas correctement orthographiée par le (inaudible) quand il remplit le formulaire. Effectivement, premier point. Comme ça va être un champ synchronisé avec le CRM, il y a une liste de valeurs arrêtée. Il faut que je mette une valeur qui est dans la liste. Premier point. Le deuxième point, c'est que là, quand la personne est créée, c'est facile, puisque ça va être un (inaudible). La personne n'existe que dans Marketo. Là, ça va marcher. Mais si la personne est synchronisée ensuite avec Salesforce ou Dynamics… Tous les champs de la société sont en lecture seule, désormais, dans Marketo. Je ne pourrai plus changer l'industrie pharma. C'est plus piégeux que ça. Je peux le changer dans Marketo, mais ce ne sera pas poussé dans Salesforce. Si, ici, je mets un data value changes sur Company Name, et que je dis "si la nouvelle valeur, ça fait partie des quatre"… Je ne suis plus en mode création, mais imaginons que la personne change de société et arrive ici, si le nom de la société de la personne change et qu'elle intègre une société du pharma, j'aimerais modifier l'industrie. Le changement va pouvoir s'opérer dans Marketo, mais quand le (inaudible) va être poussé dans Salesforce, il va me dire : "Non, je suis désolé. Industry, c'est un champ de (inaudible) dans Salesforce. Et la personne que tu essaies de pousser, elle a été synchronisée avec un contact dans Salesforce. Je ne peux pas mettre à jour industry." On va avoir un décalage de valeur, ici, entre Marketo d'un côté, qui va avoir pharma, et puis Salesforce de l'autre côté, qui aura une valeur peut-être différente pour la personne sur la société. La prochaine fois qu'il y aura une mise à jour de la société de la personne, le champ Industry dans Marketo va être écrasé, puisque c'est Salesforce qui a la main sur les sociétés. Attention, quand vous voulez modifier des champs, qui sont des champs de type "société", tant que la personne n'est pas synchronisée, ça va fonctionner, mais dès que la personne est synchronisée et convertie, surtout, dans le CRM, en tant que contact et compte, ça ne fonctionnera plus. Vous aurez l'impression que ça fonctionne, mais les données ne seront pas passées à Salesforce. Exercice suivant : tracer les actions dans le temps pour savoir que telle action a eu lieu avant telle autre. Je fais un petit schéma, parce que ce n'est pas évident à comprendre. Je suis là, et j'aimerais envoyer un email 1 aux personnes qui ont vu une page web avant de s'inscrire à mon webinaire, et un email 2 ceux qui sont inscrits au webinaire et qui, ensuite, ont vu ma page Projets. J'aimerais baser ma décision et les actions que je vais faire aujourd'hui sur des choses qui se sont passées dans le passé, mais avec un séquencement qui est important dans le temps. Vous voyez ce que je veux dire ? Est-ce que c'est possible de faire ça dans Marketo ? Oui. Comment on fait ? Je ne sais pas, mais j'imagine que oui. Potentiellement, en créant des smart lists, et en les combinant en fonction des activités demandées. Ou du séquençage. En définissant une date d'activité, non ? Si je suis vos idées, on a du visited page web, puisque c'est dans le passé. J'aimerais baser ma campagne sur le fait que j'ai visité une page web si c'est l'offre projet, et que la personne s'est inscrite à mon webinaire, qu'elle a rempli un formulaire. Comment il faudrait que je fasse ? Quel filtre il faudrait que j'ajoute pour que je puisse dire "je veux les gens qui ont d'abord visité la page web et ensuite rempli le formulaire" ? Il faut mettre un timing entre les deux, non ? Je ne sais pas comment on fait ça, mais… Le timing, tu peux le mettre dans le flow. Mais pas dans la smart list. Ce n'est pas avec le reféreur qu'on pourrait utiliser comme contrainte, non ? Ce ne serait pas très précis. Je pense qu'il faut faire… C'est conditionnel. La smart list, c'est… Je ne sais pas le faire. Ça tombe bien, parce que####Parce que ce n'est pas possible. Une fois que le temps s'est écoulé entre la date 2 et là, ce n'est plus possible de faire ça sans préparation préalable. C'est un des pièges de Marketo. On ne peut pas baser de décision sur un enchaînement d'actions dans le passé. C'est pour ça que, Laëtitia, par exemple, les campagnes de reprise de données sur le tracking de l'acquisition sont aussi compliquées. Tu te souviens ? On ne peut pas savoir qu'une personne, quand elle est entrée dans Marketo, elle l'a fait d'abord par le webinaire ou par l'infographie ou par ceci. Il y a quand même des champs systèmes dans Marketo qui s'inscrivent, "original source" et "original (inaudible)". Mais en dehors de ce cas-là, il n'y a pas de filtre dans Marketo qui permette de dire… Ici, il faudrait que, dans Date et Activity, on puisse dire : "(langue étrangère). Ici, on ne peut mettre que des jours ou des dates. Et si dans la Smart List, tu mets Visited Page et dans le flow, tu mets la condition (inaudible)… Du coup, ça se déclenche juste après, parce que je ne peux pas avoir un (inaudible). C'est possible si on était au moment du webinaire. Mais là, comme il s'est passé du temps, ce n'est plus possible. Le seul moyen de faire ça, c'est d'anticiper et de se dire : "OK, si je veux, demain, prendre cette décision, il faut d'abord qu'ici, je remplisse une liste." Il faut que je fasse ta liste des gens qui s'inscrivent en ayant vu la page. Je fais une static list. Là, à chaque fois que vous voulez faire ça, il faut penser static list, parce que la static list, c'est le moyen de tracer dans le temps qu'il s'est passé quelque chose. Là, dans mon webinaire, je vais faire une action spéciale qui, dans mon (inaudible), dit : "Dès que la personne s'inscrit, si elle a visité, dans le passé, ma page, je vais la mettre dans une static list des gens qui sont inscrits en ayant vu la page." Ce qui fait que quand je serai ici, je pourrai baser ma requête sur cette static list, puisque c'est les gens que je souhaite. Mais si on ne prépare pas son coup, si on ne prépare pas son action, on est bloqué. Enfin, on n'a plus l'info. Par exemple, si tu dis "je voudrais faire une campagne sur les gens qui ont vu ce webinar, ce webinar, ce webinar", tu ne peux pas. Tu peux, mais tu ne sauras pas le dire dans quel sens. Ah oui, tu ne sais pas faire le conditionnel. D'accord, OK, j'ai compris. Tu ne pourras pas dire le 1 avant le 2 ou le 2 avant le 1. Tu pourras dire qu'ils ont vu le 1 et le 2 et le 3, mais pas dans quel sens. D'accord, OK. C'est important à avoir en tête quand vous voulez faire des campagnes où, pour vous, l'ordre des actions est important. Imaginez que vous faites un customer de journée, que vous réfléchissez bien à votre funnel, et vous dites : "J'aimerais que les gens fassent ça, puis ensuite ça, puis ensuite ça. S'ils ont fait ces trois actions dans l'ordre, alors j'aimerais déclencher l'action numéro 4." Le seul moyen de pouvoir déclencher l'action numéro 4 correctement, c'est de tracer, au fur et à mesure des actions, que ça s'est bien enchaîné avec des static lists. Effectivement, dans l'activity log, quand on va regarder une personne, nous, humains, on va voir qu'il s'inscrit au webinaire, puis je vois bien dans l'activity log qu'avant, il avait visité une page web. On a l'info mais, on n'a pas les moyens de requêter dessus. Peut-être que ça viendra un jour, je ne sais pas. Exemple suivant. J'avais peur, j'en ai passé, mais je pense que je vais tenir l'heure. Cibler un comportement dans une campagne passée. Justement, on est un peu sur le même sujet. Est-ce que vous pouvez me dire quelle est la différence entre ces deux filtres, qui portent tous les deux sur les personnes qui ont fait un no show sur un webinaire ? Ici, j'ai un programme Status was changed, avec le programme webinaire et le new status "inscrit pas venu". Ici, j'ai (inaudible), le même webinaire et le même programme status. Dans quel cas je vais en utiliser un, dans quel cas je vais utiliser l'autre ? Tu utilises le premier quand tu as besoin d'identifier le changement de statut et de pouvoir déclencher quelque chose. Alors que le deuxième, c'est un état de fait. Si tu veux cibler spécifiquement ces personnes-là. Oui, c'est ça, exactement. Celui-ci, (inaudible), c'est les gens qui sont membres de ce programme et qui, aujourd'hui, ont ce statut no show. Ce qui est important, c'est aujourd'hui, c'est leur dernier statut. Alors que là, c'est des gens qui, dans le passé, ont eu ce statut, mais peut-être que depuis, ils sont passés à un autre statut. C'est une subtile différence, mais c'est assez important. "Inscrit et pars venu", c'est souvent des statuts de fin, mais si je veux voir les gens que j'avais refusés, par exemple… Il y a des gens que j'ai pu refuser, puis que j'ai pu accepter derrière, parce qu'on a discuté et, finalement, je les ai acceptés. Ils m'ont supplié de venir à mon webinaire et j'ai été d'accord. Je veux les gens qui, à un moment donné, ont été refusés, mais qui, aujourd'hui, peuvent être au statut "a assisté au webinaire, par exemple. Ça, ça va me permettre de détecter un changement de statut dans le passé même si ce n'est pas le dernier changement de statut. En plus, je vais pouvoir, ici, ajouter une date d'activité. Attention, on est limité à 25 mois, toujours, sur ce type de date. Je peux dire dans les derniers 60 jours. Alors que là, c'est les gens qui sont aujourd'hui membres de ce programme et qui ont aujourd'hui ce statut. Même si ils l'ont eu dans le passé et qu'ils ne l'ont plus, je ne prendrai pas ces gens-là. Il y a quelqu'un qui a parlé ? Non, je me mets en mute. Pardon, c'était loin. Détection d'inactivité, j'ai vu ça il n'y a pas longtemps, je ne sais plus chez qui. Quelqu'un faisait cette campagne pour dire : "Tiens, je vais supprimer les gens qui n'ont pas cliqué sur ma web page dans les trois dernières années, qui n'ont pas rempli de formulaire, qui n'ont pas été créés dans les trois dernières années, qui n'ont pas de (inaudible) et qui n'ont pas visité de web page". Qui ont enchaîné toutes les actions un peu comportementales comme ça avec leur version inactivité. Le premier point, vous savez que dans Marketo, toutes les actions existent sous forme inactivité. C'est très pratique, il n'y a pas beaucoup de plateformes qui ont ça. Le deuxième point, c'est toujours le même sujet sur les three years. Là, on est sur les années civiles, on n'est pas sur les années glissantes. Attention, premier piège. Et le troisième piège, c'est quoi ? Je viens juste d'en parler, en plus. C'est qu'on n'a pas les données. C'est que tu n'as pas les données, effectivement. Marketo a décidé que les données… C'est un peu subtil, parce qu'on ne peut pas requêter dessus, elles sont toujours dans l'activity log. Alors ça, je ne sais pas trop comment ça marche, parce qu'elles sont dans l'activity log, les données, mais on ne peut plus requêter dessus au-delà de 25 mois ou 90 jours, en fonction des données. Ça, c'est vraiment un article à avoir en tête. Avoir en tête les durées de rétention d'informations pour ces activities. Le change data value, attention, c'est 90 jours, ça va très vite. Pareil, visit web page et, désormais, send email et email delivered. Même si vous faites un filtre qui dit "les personnes qui n'ont pas eu d'email, à qui je n'ai pas délivré d'email dans les trois dernières années…" Imaginons que je fasse 365 jours. Vous avez l'impression que Marketo ne vous a pas bloqués, mais il va regarder uniquement les 90 derniers jours. C'est extrêmement piégeux, parce qu'on peut croire que la requête marche, mais non, ça ne va pas marcher. Et il y a d'autres données, c'est 25 mois, tu dis ? Quatre-vingt-dix jours. Et tout le reste, à part Person is created, c'est 25 mois. D'accord. Mais person is created, c'est 90 jours aussi ? Non, c'est ever, ça ne disparaît jamais. Vous pouvez augmenter ça au support. Sachez que si vous le souhaitez, vous pouvez passer à 36 mois, mais par défaut, c'est 25 mois. Comme ils ont ajouté ces deux-là il n'y a pas très longtemps, je me dis que ça va continuer. Oui, c'est GDPR, c'est logique. Je crois que c'est surtout pour alléger la donnée dans les serveurs marketo et une question de performance. D'accord. Parce que 90 jours, pourquoi ? Oui, 25 mois, je comprends. Après, 90 jours, il n'y a pas de RGPD qui me dit ça. Du coup, si on ne peut plus avoir ces donnée, on n'en est pas là, mais ça a un impact sur ce qu'il faut qu'on mette en place pour faire des listes statiques ? C'est ça que ça veut dire ? Soit vous pouvez garder l'info dans des listes statiques. Par exemple, dans le cas qui nous intéresse, qui est "j'aimerais détecter les personnes que je peux supprimer parce qu'il n'y a pas eu d'activité pendant deux ans ou trois ans", il faut passer par une étape intermédiaire qui est… Nous on a créé une date de dernière activité. C'est un peu ce que je vous disais, on prépare le truc. Dès que quelqu'un fait une activité qui prouve qu'il est venu à nous, n'importe laquelle, on va tracer dans un champ "date de dernière activité" la date du jour et le type de dernière activité. Vous voyez, je trace la date du jour, et puis j'utilise des smart lists pour dire "si la personne vient de faire une action, c'est ça". C'est un peu pénible à faire. Première étape, je trace dès qu'une action est faite, surtout avec ça, la date de dernière activité. J'ai une deuxième étape qui est : je détecte ensuite, grâce à cette date de dernière activité qui, elle, n'est jamais effacé. Les gens qui ont une date de dernière activité avant trois ans (inaudible) et qui est valide. Et là, je les mets dans une liste statique pour dire qu'ils sont candidats à la suppression. Voilà. Il faut travailler en deux temps, mais si vous faites ça, ça marche. Deux petites dernières, ça va aller assez vite. Petit tip. Ça peut être intéressant de mettre en copie vos commerciaux, quand vous les avez dans Marketo, quand, par exemple, quelqu'un s'inscrit à un webinaire. Si quelqu'un remplit le formulaire, vous lui envoyez l'email, et dans cet email, sachez que vous pouvez ajouter une personne ou des personnes en copie grâce à cette propriété Carbon Copy, ici. Il faut au préalable définir les champs qui contiennent une adresse email que vous pouvez ajouter en Carbon Copy. Dans Salesforce, on a automatiquement le lead owner email address. Je l'ai mis dans (inaudible). Ce qui fait que dès que quelqu'un va s'inscrire, le commercial aura l'info en live qu'une personne qui m'appartient vient s'inscrire au webinar. Dernier point. J'ai vu ça il n'y a pas longtemps, je ne sais pas quand c'est arrivé. Vous savez, on a parlé de la possibilité de créer des champs maintenant sur Program Members. Sachez qu'il y a les triggers et les filtres pour détecter les changements qui se passent sur ces champs. On a un filtre qui a été ajouté : Program Members Data is Changed. Là, je peux indiquer dans le programme quel attribut, par exemple (inaudible), et qu'il y a une nouvelle valeur. C'est un peu le Change Data Value du Program Members. On est obligé d'utiliser un trigger spécial. Pareil, on l'a en filtre et on l'a en inactivité. Dans le flow, on a l'action correspondante : Change Program Members Data. On peut, dans un flow, changer la valeur d'un champ Program Members. Là, par exemple, je voulais modifier les valeurs LinkedIn vers Google. C'est n'importe quoi, mais c'est possible désormais. Ils enrichissent tout ça. Est-ce qu'ils ont activé la partie report sur ces éléments ? Je ne pense pas. Je n'ai toujours pas vu, en tout cas. Pour moi, la seule façon de faire du reporting, c'est à travers ton onglet Membres. Il faut que tu sois dans un programme. Si on essaie de faire un report et qu'on prend le truc sur le… On n'a pas de programme Data Performance, par exemple. Si on prend (inaudible) performance, est-ce qu'on pourrait faire apparaître… Non, je ne pense pas qu'au niveau reporting, ils aient encore prévu le truc. D'accord. Parce que c'est vrai que ça pourrait être intéressant. On utilise comme toi pour les UTM liés à la campagne. Du coup, c'est vrai que ça permettrait de tracer, d'avoir un report sur les UTM, à la fois les channels et les mediums qu'on aurait mis liés à cette campagne. Pour voir la performance selon les canaux. Tout à fait. Peut-être que ça va venir. Ils enrichissent petit à petit, je vois, quand même. OK. On reste soit au niveau des membres, soit en créant des smart lists sur la base de ces valeurs. Oui. Voilà, il est 11 heures. Impeccable. J'avais bien dimensionné les exemples. Est-ce qu'il vous reste des questions à ce stade ? Non, merci beaucoup, Sylvain. Merci beaucoup. Super intéressant. Très bien. Je vais monter ça, puis le mettre sur mon video hub, ça fera une vidéo de plus. Je vous souhaite une bonne journée, puis un bon week-end. Bonne journée. Bonne journée, bon week-end. Au revoir.