Source d'entrée Journey Builder : créer la data extension
Comment construire la data extension sendable d'une source d'entrée Journey Builder en SQL, choisir la planification et éviter les pièges.
Votre segment est prêt, et Journey Builder vous demande maintenant de choisir une source d'entrée. Si vous retenez une data extension, c'est la qualité de cette table qui décide qui entre dans le parcours, à quel rythme, et si quelqu'un reçoit deux fois le même e-mail.
Une source d'entrée de type data extension dans Journey Builder est une data extension sendable que Journey Builder lit selon un calendrier pour faire entrer des contacts dans un parcours. La méthode la plus fiable consiste à alimenter une data extension dédiée avec une requête SQL (activité de requête), puis à planifier son évaluation.
Ce guide détaille les prérequis de la documentation Salesforce, une requête SQL complète, le choix de la planification et les pièges qui provoquent des échecs silencieux.
Source d'entrée Journey Builder : de quoi parle-t-on exactement ?
L'essentiel en deux minutes
La source d'entrée de type data extension fait entrer des contacts dans un parcours à partir d'une data extension existante, selon un calendrier. Vous pouvez filtrer les enregistrements à l'entrée ou tous les admettre.
Elle convient aux envois en lot, aux programmes récurrents et aux segmentations complexes. En revanche, elle n'est pas adaptée aux messages unitaires en temps réel, comme une confirmation de formulaire : une entrée par API ou par événement est alors plus appropriée.
Concrètement, la plupart des équipes pointent Journey Builder vers une table entretenue par une activité de requête. La logique d'audience reste ainsi visible en un seul endroit, elle se teste facilement, et vous pouvez modifier les règles sans toucher au canevas du parcours.
Ce que Salesforce vous demande de préparer
Les recommandations de Trailhead pour préparer la source d'entrée sont courtes et méritent d'être suivies à la lettre :
- Utilisez une data extension sendable.
- Incluez tous les champs nécessaires à la personnalisation ou au contenu dynamique.
- Si vos données sont réparties dans plusieurs data extensions, regroupez-les en une seule grâce à une activité de requête dans Automation Studio.
- Pré-filtrez la data extension dès que possible pour accélérer le traitement.
- Reliez la data extension au modèle de données dans Contact Builder lorsque c'est pertinent.
Gardez aussi en tête que les données d'entrée sont une photographie des attributs du contact au moment de son entrée. Elles ne changent plus pendant le parcours. Source : Trailhead, préparer la source d'entrée.
Construire l'audience avec une requête SQL
Exemple complet : une table d'entrée pour un parcours de réactivation
Imaginons que vous vouliez faire entrer dans un parcours de réactivation les clients dont le dernier achat date de plus de 180 jours, qui sont toujours abonnés actifs et qui n'ont jamais été admis auparavant. La requête ci-dessous construit cette table.
SELECT
c.SubscriberKey,
c.EmailAddress,
c.FirstName,
c.LastPurchaseDate
FROM Customers_Master c
INNER JOIN _Subscribers s
ON s.SubscriberKey = c.SubscriberKey
WHERE s.Status = 'active'
AND c.LastPurchaseDate < DATEADD(DAY, -180, GETDATE())
AND NOT EXISTS (
SELECT 1
FROM Winback_Journey_Entry e
WHERE e.SubscriberKey = c.SubscriberKey
)Data extension cible : Winback_Journey_Entry, sendable, avec SubscriberKey comme clé primaire. Type de mise à jour : Append (ajout).
La requête ligne par ligne
- Les quatre colonnes sélectionnées sont la clé, l'adresse e-mail et les champs de personnalisation dont les e-mails du parcours auront besoin.
- La jointure avec la data view des abonnés ne conserve que les contacts au statut actif : les désabonnés et les adresses en erreur n'atteignent jamais la table d'entrée.
- La condition de date retient les clients dont le dernier achat remonte à plus de 180 jours. Consultez notre guide sur les fonctions de date SQL dans SFMC pour gérer les fuseaux horaires.
- Le bloc NOT EXISTS compare avec la table cible elle-même : une personne déjà admise n'est jamais ajoutée deux fois.
- Append n'ajoute que les nouvelles lignes, ce qui rend sûre une évaluation des nouveaux enregistrements uniquement. Les arbitrages sont détaillés dans Overwrite, Update ou Append.
Si vous préférez ne pas l'écrire à la main, vous pouvez générer du SQL SFMC à partir d'une phrase en langage naturel et relire le résultat avant de l'exécuter.
Un dernier choix de conception vaut la peine d'être fait tôt : gardez la table d'entrée étroite. Ne conservez que la clé, l'adresse e-mail et les champs réellement utiles au parcours. Les tables larges ralentissent l'évaluation, et chaque colonne en trop peut se désynchroniser de vos données source.
Choisir la planification : une fois, récurrente ou automation
Les trois types de planification
Run Once admet les contacts à l'activation du parcours, ou à la date et l'heure que vous définissez. Recurring les admet à l'intervalle choisi. Automation les admet lorsqu'une automation Automation Studio sélectionnée se termine.
Automation est le meilleur choix lorsqu'une requête réécrit régulièrement la data extension, car le parcours n'évalue les enregistrements qu'une fois les données à jour. L'automation doit contenir une activité d'import, de filtre ou de requête qui modifie directement la data extension. Source : aide Salesforce, Data Extension Entry Source (en anglais).
Nouveaux enregistrements uniquement ou tous les enregistrements
Avec une planification répétée, vous choisissez comment les enregistrements sont traités. « Evaluate new records only » n'examine que les contacts ajoutés depuis l'exécution précédente. Cette option est prévue pour les sources où les lignes sont ajoutées sans supprimer ni écraser les existantes, et elle est en général plus rapide.
« Evaluate all records » vérifie chaque ligne à chaque exécution. Réservez-la aux sources dont les enregistrements sont mis à jour en continu. Salesforce déconseille expressément de combiner une data extension filtrée avec l'option des nouveaux enregistrements, car l'actualisation d'une data extension filtrée écrase tous les enregistrements.
Réponse rapide : la checklist de votre source d'entrée
- Créez une data extension sendable dédiée, avec une clé primaire sur SubscriberKey et un champ EmailAddress.
- Ajoutez tous les champs de personnalisation nécessaires au parcours.
- Écrivez une seule activité de requête qui joint vos sources, filtre l'audience et exclut les personnes déjà admises.
- Choisissez Append si vous comptez évaluer les nouveaux enregistrements uniquement, sinon Overwrite.
- Placez la requête dans une automation et planifiez-la avant l'évaluation du parcours.
- Dans Journey Builder, sélectionnez la data extension, la planification et l'option d'enregistrements, puis définissez une adresse e-mail par défaut.
- Vérifiez le paramètre de réentrée avant d'activer le parcours.
| Situation | Type de mise à jour | Option d'évaluation |
|---|---|---|
| Lignes uniquement ajoutées | Append | Nouveaux enregistrements |
| Table reconstruite à chaque exécution | Overwrite | Tous les enregistrements |
| Lignes modifiées sur place | Update | Tous les enregistrements |
Les pièges qui provoquent des échecs silencieux
Exécutions ignorées et compteurs trompeurs
Si l'évaluation des enregistrements n'est pas terminée quand la prochaine exécution planifiée arrive, cette exécution est ignorée et les enregistrements sont traités à la suivante. Les grosses tables associées à des intervalles courts en sont la cause habituelle.
La tuile Record Count affiche aussi le contenu actuel de la data extension, qui peut différer des enregistrements évalués pour l'entrée si les données ont changé après la planification. Utilisez View Event Results pour voir ce qui est réellement entré durant les 30 derniers jours.
Réentrée et clé de contact
La réentrée est un paramètre au niveau du parcours, avec trois options : pas de réentrée, réentrée uniquement après la sortie, et réentrée à tout moment. Un parcours d'accueil n'autorise généralement aucune réentrée, alors qu'un programme récurrent de réactivation peut exiger une réentrée après la sortie.
À l'entrée, le système crée un contact en utilisant le Subscriber ID comme Contact Key. Assurez-vous que vos valeurs de SubscriberKey sont cohérentes entre vos sources, sinon la jointure écartera des personnes sans vous prévenir. Notre guide pour créer une audience de réactivation détaille la logique d'audience.
Tester avant d'activer
Exécutez l'activité de requête une fois et ouvrez la data extension cible. Vérifiez que le nombre de lignes est plausible, comparez quelques valeurs de SubscriberKey avec votre source et assurez-vous qu'aucune adresse EmailAddress n'est vide. Cinq minutes de contrôle évitent un parcours rempli de contacts qui ne peuvent rien recevoir.
Avec une planification récurrente, lancez l'automation deux fois et confirmez que la seconde exécution n'ajoute que de véritables nouveaux contacts. C'est la preuve la plus rapide que votre logique d'exclusion fonctionne.
Les requêtes trop longues
Si la requête qui alimente votre table d'entrée dure trop longtemps, toute la chaîne se bloque. Filtrez tôt et évitez de parcourir intégralement les data views. Voir pourquoi les requêtes SQL SFMC expirent et comment les corriger.
Questions fréquentes
La data extension de la source d'entrée doit-elle être sendable ?
Salesforce recommande d'utiliser une data extension sendable. Une telle data extension possède une relation d'envoi qui associe l'un de ses champs au Subscriber Key, ce qui permet à Journey Builder d'écrire aux contacts qu'elle contient.
Peut-on utiliser une data extension filtrée comme source d'entrée ?
C'est possible, mais pas avec l'option des nouveaux enregistrements uniquement. Une data extension filtrée est écrasée à chaque actualisation, donc Salesforce déconseille cette combinaison. Une activité de requête avec Append est plus prévisible.
À quelle fréquence la source d'entrée peut-elle être évaluée ?
Une planification récurrente vous laisse choisir l'intervalle, et une planification Automation évalue les données à la fin de l'automation. Choisissez le rythme que l'actualisation de vos données permet réellement.
Pourquoi personne n'est entré dans mon parcours ?
Vérifiez que le parcours est activé, que la planification a démarré, que la data extension contient bien des lignes après l'exécution de votre requête, et que le paramètre de réentrée ne bloque pas les personnes déjà entrées.
Créez cette audience en quelques secondes avec QAiry
La requête ci-dessus est simple une fois le schéma connu, mais la jointure, l'exclusion et le bon type de mise à jour sont faciles à rater quand les délais pressent. QAiry transforme une demande en langage naturel en SQL et en data extensions SFMC prêts pour la production, installé comme une application dans votre propre Marketing Cloud, pour que vous puissiez relire la requête avant de l'exécuter.
Envie d'essayer ? Installez QAiry gratuitement ou découvrez une démo produit.
