Les alternatives au SQL manuel pour segmenter dans SFMC

‍

Dans Salesforce Marketing Cloud, une audience commence presque toujours par une requête SQL.

Quelqu'un ouvre une Query Activity dans Automation Studio, écrit un SELECT sur quelques data extensions et data views, le dirige vers une data extension cible, puis le planifie.

Cela fonctionne, et cela fonctionne depuis des années.

‍

Ce n'est toutefois pas le seul chemin possible. Pour beaucoup d'équipes, ce n'est même plus le plus rapide.

Salesforce a ajouté plusieurs voies de segmentation au fil du temps, et chacune arbitre différemment entre souplesse et accessibilité.

‍

Cet article passe en revue les alternatives réalistes au SQL écrit à la main dans SFMC, ce que chacune apporte réellement, et le moment où chacune atteint ses limites.

‍

Ce que recouvre la segmentation SQL manuelle

‍

Le parcours par défaut dans Automation Studio

Une Query Activity extrait des données et écrit le résultat dans une data extension cible, qui alimente ensuite un envoi ou une entry source dans Journey Builder.

La requête interroge vos data extensions ainsi que les data views système : _Sent, _Open, _Click, _Job.

‍

Tout ce qui suit dépend de l'exactitude de cette unique instruction.

Une condition de jointure erronée produit une audience fausse, le plus souvent sans le moindre message d'erreur.

‍

Là où la friction apparaît

Salesforce applique des limites strictes et des limites souples pour préserver les performances de la base. Dépasser une limite stricte entraîne le rejet de la requête ; dépasser une limite souple la rend simplement plus lente.

Les query activities expirent par ailleurs au bout de 30 minutes, et le risque augmente avec le volume traité.

‍

S'y ajoutent des contraintes de syntaxe. Il est impossible de combiner un JOIN et un SELECT * : chaque colonne doit être nommée explicitement.

Salesforce déconseille également les types nvarchar(max) et varchar(max), et rappelle qu'une Import Activity réalise plus vite, et à plus grande échelle, la même opération d'ajout ou de mise à jour.

‍

Rien de tout cela n'arrête un développeur SFMC expérimenté.

En revanche, personne n'apprend ces règles entre deux briefs de campagne.

‍

Filtered data extensions et data filters

‍

Segmenter sans écrire une ligne

Une filtered data extension cible un ensemble d'abonnés plus restreint : elle filtre une data extension source sur ses champs ou ses mesures, ou applique un data filter créé au préalable.

Le filtre se construit en glisser-déposer, sans aucune intervention en SQL.

‍

Au déclenchement de la filter activity, ou lors d'un rafraîchissement manuel, la logique définie est appliquée et l'extension filtrée est repeuplée.

Pour des critères simples et stables, c'est l'option la moins coûteuse de la plateforme.

‍

Le moment où les filtres ne suffisent plus

Un filtre travaille sur une seule source à la fois. Dès qu'il faut croiser historique d'achat et historique d'engagement, le SQL revient.

‍

Des limites structurelles existent aussi. Un data filter créé à partir d'une filtered data extension ne peut pas être appliqué lors d'un glisser-déposer de segments, ce qui surprend les équipes qui tentent d'empiler les filtres.

‍

Le schéma est classique. Les filtres absorbent les demandes les plus simples, et tout le reste retourne dans la file d'attente de la personne qui écrit le SQL.

‍

Bibliothèques de requêtes et automatisations modélisées

‍

Transformer des requêtes ponctuelles en briques

Beaucoup d'équipes SFMC matures ne quittent jamais le SQL. Elles cessent simplement de le réécrire à chaque fois.

La méthode consiste à maintenir une petite bibliothèque interne de requêtes éprouvées (ouvreurs récents, acheteurs inactifs, contacts au consentement valide) et à composer les campagnes à partir de ces briques.

‍

Les motifs récurrents sont écrits une fois, relus une fois, puis réutilisés. Les délais se réduisent parce que la plupart des demandes sont des variantes de l'existant.

‍

Le coût de maintenance que personne ne budgète

Une bibliothèque se dégrade. Des champs sont renommés, une business unit change son modèle de consentement, quelqu'un ajoute une data extension qui aurait dû figurer dans la logique d'exclusion.

‍

Comme les requêtes sont copiées et non référencées, un correctif appliqué à un endroit ne se propage presque jamais aux onze autres.

Cette approche achète de la vitesse. Elle ne supprime pas la dépendance à quelqu'un qui lit le SQL couramment.

‍

Segments Data Cloud et Einstein

‍

Construire les segments en dehors d'Email Studio

Data Cloud permet de créer des micro-segments à partir des comportements, des données démographiques, des préférences et des interactions cross-canal, puis d'activer ces segments vers Marketing Cloud Engagement, où ils apparaissent dans Contact Builder.

‍

La segmentation remonte d'un cran. Elle quitte le modèle des data extensions pour un profil unifié.

Le bénéfice est réel : une définition unique du client, réutilisable sur tous les canaux.

‍

Ce que cela suppose en amont

La segmentation Data Cloud ne vaut que ce que vaut le modèle de données sous-jacent, et mettre ce modèle au propre relève du projet, pas de la tâche.

‍

Einstein ajoute par-dessus une couche prédictive. Einstein Engagement Scoring s'appuie sur le machine learning pour attribuer à chaque contact un score de probabilité d'engagement avec les emails, ce qui permet de filtrer sur un score au lieu d'écrire des conditions d'engagement à la main.

‍

Einstein Segment Creation va plus loin et accepte le langage naturel, les résultats étant affinés par Einstein Data Prism adossé à Data Cloud. Salesforce recommande de relire dans Metadata Studio les descriptions générées pour les objets et les champs afin d'obtenir des résultats exploitables.

‍

Ces capacités sont solides. Elles supposent en revanche un investissement déjà réalisé dans Data Cloud, ce qui n'est pas le cas de nombreuses organisations limitées à Engagement.

‍

L'IA conversationnelle qui génère le SQL

‍

Décrire l'audience plutôt que la coder

La dernière alternative en date laisse la Query Activity exactement où elle est. Elle change simplement qui peut produire l'instruction qui va dedans.

‍

Un marketeur décrit l'audience en langage courant, par exemple les contacts français qui ont ouvert dans les 30 derniers jours mais n'ont pas acheté depuis juin, et l'assistant renvoie du SQL écrit sur les data extensions et les data views réelles de la business unit concernée.

‍

Aucun nouveau modèle de données, aucune migration, aucun changement dans la façon dont les envois sont exécutés.

‍

Pourquoi le SQL reste au centre

La sortie n'est pas une boîte noire. C'est une requête lisible, qu'un développeur peut inspecter, corriger et versionner comme n'importe quelle autre.

‍

C'est décisif pour la gouvernance. Vous conservez la traçabilité qu'un outil purement visuel fait disparaître, et l'étape de relecture reste disponible pour les campagnes qui la méritent.

‍

La dépendance change de nature. Les profils techniques passent de l'écriture de toutes les requêtes à la relecture de celles qui le justifient.

‍

Choisir entre ces approches

‍

Adapter l'outil à la demande, pas à l'organisation

La plupart des équipes n'ont pas à trancher une fois pour toutes. Elles ont besoin d'un réflexe par défaut pour chaque type de demande.

‍

• Critères simples sur une source unique : filtered data extension.
• Campagnes récurrentes à logique connue : modèle de requête validé.
• Audiences cross-canal sur un profil unifié : Data Cloud.
• Ciblage prédictif de l'engagement : scores Einstein.
• Demandes ponctuelles, multi-sources et urgentes : génération conversationnelle du SQL.

‍

La bonne question à se poser

L'indicateur utile n'est pas le nombre de requêtes écrites par votre équipe. C'est le délai entre l'idée d'un marketeur et l'audience disponible.

‍

Quand ce délai se compte en jours, le frein n'est presque jamais la maîtrise du SQL. C'est la file d'attente.

‍

Découvrez QAiry en pratique

‍

QAiry relève de la dernière catégorie. Vous décrivez l'audience, et l'assistant écrit un SQL SFMC prêt pour la production sur vos propres data extensions et data views.

‍

Pour voir ce que cela donne sur une org réelle, les démonstrations disponibles sur qairy.com/fr/product-demos sont le chemin le plus court, et vous pouvez l'essayer sur votre propre logique de segmentation via qairy.com/fr/try-it-free.