Pourquoi la segmentation manuelle touche à sa fin
La segmentation SFMC repose encore sur le SQL et les data views. Le canevas de segment de Data Cloud et Einstein changent qui peut créer une audience.
Pourquoi la segmentation manuelle touche à sa fin
Depuis plus de dix ans, construire une audience dans Salesforce Marketing Cloud passe presque toujours par une seule voie : écrire du SQL.
Un responsable marketing a besoin d'une liste. Quelqu'un côté technique ouvre une Query Activity, écrit une requête sur plusieurs data extensions, puis l'exécute.
Ce mode de fonctionnement n'a presque pas changé depuis les débuts d'Automation Studio.
Ce qui a changé, en revanche, c'est la visibilité du coût que cela représente.
Les équipes marketing attendent parfois plusieurs jours pour une liste qui ne devrait prendre que quelques minutes. Les équipes techniques, elles, empilent les demandes de segmentation au milieu de tout le reste.
Aucun des deux camps n'est en tort. Le fonctionnement lui-même a simplement été conçu pour une époque où les campagnes avançaient plus lentement.
Salesforce lui-même construit désormais des alternatives à ce fonctionnement, plutôt que de se contenter de le documenter. Cet article détaille ce qu'implique réellement la segmentation manuelle, ce que Salesforce met en place pour en remplacer une partie, et ce qui change une fois que le SQL n'est plus le seul point d'entrée.
Pourquoi la segmentation manuelle repose encore sur le SQL
Le fonctionnement d'une Query Activity
Dans Automation Studio, une SQL Query Activity récupère des données pour du reporting ou pour construire une audience.
La documentation de formation de Salesforce revient toujours sur les quatre mêmes briques :
SELECTpour nommer les champsFROMpour choisir la sourceJOINpour combiner les tablesWHEREpour filtrer le résultat
Maîtriser les types de jointure (inner, left, right, full outer) est présenté comme un prérequis, pas comme une option.
Une fois la requête exécutée, le résultat doit être stocké quelque part. L'activité écrit dans une data extension, et le responsable marketing choisit si cette extension est complétée, mise à jour ou remplacée.
Chacun de ces choix compte pour la suite, car un journey ou un envoi suppose souvent une structure précise dans cette extension de sortie.
Où se situe vraiment le blocage
Rien de tout cela n'est du SQL exotique. Ce sont des jointures et des filtres, les mêmes schémas répétés avec des critères différents à chaque fois.
Le problème, c'est justement cette répétition. Chaque brief de campagne devient un nouveau ticket, et chaque ticket nécessite quelqu'un capable d'écrire et de tester correctement une requête.
La documentation de Salesforce déconseille d'ailleurs les requêtes SELECT *, car récupérer toutes les colonnes d'une data extension volumineuse peut suffire à dépasser le délai maximal de 30 minutes.
C'est un détail technique, mais avec une implication importante : même les personnes qui maîtrisent déjà le SQL doivent l'écrire avec soin pour ne pas faire échouer un job.
Multipliez cette vigilance par des dizaines de campagnes chaque mois, et la file d'attente des requêtes devient un goulot d'étranglement discret bien avant que quiconque ne le remarque.
Les tables système derrière chaque segment
Ce que les data views apportent
Sous la plupart des requêtes de segmentation se trouvent les data views : des tables générées automatiquement par le système, comme _Bounce, _Click, _Open ou _Complaint, qui conservent l'historique d'engagement sans configuration.
Elles existent justement pour éviter aux équipes marketing de construire leurs propres tables de suivi depuis zéro.
Salesforce documente plus d'une vingtaine de ces vues, couvrant l'email, le SMS, les journeys, les automatisations et les partages sociaux.
Ce qu'elles n'apportent pas
Les data views sont figées. Leur structure ne peut pas être modifiée, et une colonne manquante ne peut pas être ajoutée après coup.
Pour les interroger, il faut déjà savoir quelle vue contient quel événement, et comment la relier à une SubscriberKey ou à un identifiant de contact.
Cette connaissance est précisément ce qui transforme une demande d'audience en apparence simple en une tâche que seule une personne précise de l'équipe peut réaliser.
Cela rallonge aussi l'intégration d'un nouveau membre de l'équipe, car les data views elles-mêmes sont rarement bien documentées au-delà des pages de référence de Salesforce.
La réponse de Salesforce : segmenter sans SQL
Le canevas de segment dans Data Cloud et Marketing Cloud Next
Marketing Cloud Next utilise la même interface de segmentation que Data Cloud. Plutôt qu'une requête, un segment y est défini comme un ensemble de règles de filtrage appliquées à une base de données.
Le principe part de l'audience totale, puis la réduit progressivement : on glisse un attribut depuis une bibliothèque vers le canevas, on décide s'il appartient à l'onglet Include ou Exclude, puis on regroupe les conditions liées pour construire une logique plus complexe.
Aucun éditeur de requête n'intervient à aucun moment de ce processus.
Des limites à connaître
Le canevas n'est pas illimité. Salesforce plafonne les segments à 50 filtres sur l'onglet Include et 50 sur l'onglet Exclude.
La fréquence de rafraîchissement est également un choix explicite : une équipe peut ne jamais rafraîchir un segment, le rafraîchir selon un cycle standard de 12 ou 24 heures, ou le rafraîchir rapidement toutes les 1 à 4 heures.
Les segments de campagne doivent par ailleurs s'exécuter sur l'espace de données par défaut et sur l'objet Unified Individual, une contrainte à connaître avant d'envisager une migration.
Rien de tout cela ne remplace tous les usages du SQL dans SFMC. Cela montre en revanche que Salesforce considère désormais un constructeur visuel, fondé sur des filtres, comme une manière à part entière de définir une audience, et non comme une version simplifiée du vrai outil.
La place d'Einstein dans la segmentation aujourd'hui
Einstein Engagement Scoring
Pour Marketing Cloud Engagement, Einstein Engagement Scoring utilise le machine learning pour prédire la probabilité qu'un contact interagisse avec un email ou une notification push.
Salesforce documente des seuils de données minimaux pour que ces scores soient fiables : au moins 7 jours d'historique, 28 jours recommandés, et 90 jours pour les résultats les plus solides.
Ce scoring fait partie de ce que Salesforce appelle Smart Segmentation, l'une des trois catégories Einstein, aux côtés de l'optimisation de l'heure d'envoi et de la sélection de contenu.
Co-créer un segment avec Einstein
Côté Data Cloud, Salesforce a également introduit une option de co-création qui permet à un responsable marketing de décrire une audience et de laisser Einstein participer à la construction du segment correspondant.
C'est la même direction que celle suivie par QAiry depuis le départ : décrire l'audience souhaitée en langage naturel, et laisser le système produire la définition technique derrière.
La différence tient surtout à l'environnement de chacun. L'option de co-création d'Einstein se situe dans Data Cloud et Marketing Cloud Next, tandis que QAiry est conçu pour les équipes qui utilisent aujourd'hui Marketing Cloud Engagement, sur le modèle SQL et data extensions décrit plus haut.
Ce qui change vraiment quand le SQL sort du parcours
La rapidité
Une requête qui restait auparavant plusieurs jours dans une file d'attente peut devenir une conversation qui prend quelques minutes.
Cette différence n'a rien de marginal. Pour une vente flash ou une campagne de réactivation liée à un événement précis, l'écart entre quelques minutes et plusieurs jours détermine si l'audience est encore pertinente au moment de l'envoi.
Qui a le droit de poser la question
Le changement le plus important concerne qui peut définir une audience.
Quand la segmentation ne passe que par le SQL, seules les personnes qui savent l'écrire peuvent tester une idée. Quand l'interface est un canevas de filtres ou une demande en langage naturel, la personne la plus proche de la campagne peut tester cette idée sans attendre une disponibilité dans l'agenda de quelqu'un d'autre.
Cela ne retire pas l'équipe technique de l'équation. Cela change plutôt ce sur quoi elle passe son temps : moins écrire chaque requête, davantage vérifier celles qu'un responsable marketing a déjà préparées.
Ce qui ne change pas
La gouvernance des données ne disparaît pas simplement parce que l'interface est devenue plus accessible. Quelqu'un doit toujours décider quels champs peuvent servir à segmenter, et quelle data extension fait référence.
Le SQL ne disparaît pas non plus de SFMC. La préparation de données complexe, celle qui alimente un segment plutôt que celle qui le définit directement, restera probablement fondée sur des requêtes encore longtemps.
Ce qui change, c'est la place qu'occupe ce SQL dans le processus, pas son existence.
Découvrir QAiry en action
Les outils évoluent plus vite que les habitudes construites autour d'eux. La plupart des équipes SFMC font encore passer chaque demande d'audience par la même file d'attente qu'il y a cinq ans.
QAiry se place précisément dans cet interstice : un responsable marketing décrit une audience en langage naturel, par exemple « les contacts qui ont ouvert au cours des 30 derniers jours mais n'ont pas cliqué », et QAiry génère le SQL puis construit l'audience directement dans SFMC. Découvrez comment cela fonctionne sur qairy.com/fr/product-demos, ou lancez un essai gratuit sur qairy.com/fr/try-it-free.
