Créer une audience dans Salesforce Marketing Cloud : les quatre méthodes possibles

‍

Posez la question à cinq praticiens SFMC et vous obtiendrez cinq réponses différentes.

L'un ouvre une Filtered Data Extension. L'autre écrit une requête dans Automation Studio. Un troisième entretient encore un dispositif Audience Builder monté avant son arrivée.

Aucun n'a tort. Chacun optimise simplement une contrainte différente.

‍

Le problème vient plutôt de l'inertie : la méthode est choisie une fois, au démarrage du projet, et plus jamais réexaminée. Or l'org grossit, le modèle de données se complexifie, et ce qui fonctionnait sur 40 000 contacts finit par produire des requêtes de 25 minutes.

Salesforce a par ailleurs déplacé les lignes. Parmi les quatre options décrites ici, l'une est en cours de retrait, et une autre, l'éditeur recommande lui-même de s'en éloigner au-delà d'un certain volume.

‍

Voici donc les quatre façons réalistes de construire une audience dans Marketing Cloud Engagement aujourd'hui, ce que chacune permet réellement, à quel moment elle bloque, et comment arbitrer entre elles.

‍

Ce que veut dire construire une audience dans SFMC

‍

Le résultat est toujours une data extension

Quelle que soit la voie retenue, la sortie a la même forme : une data extension contenant les contacts à adresser.

Email Studio envoie dessus. Journey Builder peut s'en servir comme source d'entrée. Automation Studio la rafraîchit selon une planification.

La vraie question n'est donc pas qu'est-ce qu'une audience, mais par quel mécanisme vous décidez qui atterrit dans cette table, et à quelle fréquence ce calcul est rejoué.

‍

Deux emplacements de données, deux logiques

Vos données sources se répartissent entre deux endroits très différents, et cette séparation conditionne tout le reste.

Les data extensions sendables contiennent ce que vous avez chargé : attributs CRM, historique d'achat, préférences, niveau de fidélité.

Les data views système contiennent ce que SFMC a enregistré : _Sent, _Open, _Click, _Bounce, _Subscribers. Ce ne sont pas des data extensions et elles ne sont pas consultables dans l'interface.

‍

Retenez surtout ceci : tout critère comportemental (ouverture sur 90 jours, deux bounces, aucun clic) vit dans les data views. Et seules certaines méthodes savent y accéder.

‍

Les Filtered Data Extensions : l'option sans friction

‍

Leur terrain de jeu naturel

Une Filtered Data Extension restreint une data extension existante à partir de ses champs ou de ses mesures, ou en appliquant un data filter déjà défini.

Tout se fait au clic. Ni SQL, ni Automation Studio, ni activité à planifier.

Pour un critère porté directement par la table source, c'est le chemin le plus court de la plateforme. Pays égal France, statut fidélité égal Gold, opt-in à vrai : quatre-vingt-dix secondes.

‍

Elles présentent en outre un avantage que le SQL n'a pas : un collègue peut ouvrir le filtre et en lire la logique sans connaître le schéma.

‍

Le plafond, et il arrive vite

La limite se manifeste toujours de la même façon, sous trois formes.

• Aucune jointure possible : une seule data extension source.
• Les critères d'engagement restent hors de portée, sauf si quelqu'un a déjà rapatrié cette donnée dans la table.
• Dédoublonnage, classement et agrégation ne sont tout simplement pas exprimables.

‍

Dès qu'un brief demande « a acheté sur les six derniers mois mais n'a rien ouvert depuis », l'exercice devient impossible. Il faut croiser une table d'achats avec _Open, autrement dit faire une jointure.

‍

Les SQL Query Activities : là où se fait la vraie segmentation

‍

Pourquoi tout le monde y revient

Salesforce présente la query activity comme le moyen de récupérer et d'unifier des données à travers les data extensions et les data views système. Cette seconde partie justifie à elle seule son existence.

C'est le seul mécanisme natif qui lise directement les data views. Toute audience comportementale, toute liste de suppression bâtie sur l'historique de bounces, tout segment de réactivation passe par là.

C'est aussi le seul à savoir joindre, dédoublonner avec une fonction de fenêtrage et classer.

‍

En pratique, la query activity devient donc le réflexe pour tout ce qu'un marketeur jugerait intéressant. D'où la file d'attente qui se forme, dans beaucoup d'équipes, devant une ou deux personnes à l'aise avec SELECT.

‍

Les limites à connaître avant de monter en charge

La query activity n'est pas illimitée, et les recommandations publiées sont plus prudentes qu'on ne le croit.

• Une query activity expire au bout de 30 minutes. C'est un arrêt net, pas un avertissement.
• Si une requête dépasse régulièrement 10 minutes, Salesforce conseille de déplacer ce traitement vers un autre outil, Data Cloud par exemple.
• Une query activity en échec 24 fois de suite est désactivée.

‍

L'éditeur recommande également de borner la plage de dates à environ six mois lorsque c'est possible, et de resserrer le périmètre autant que le brief l'autorise. Sur les grosses org, un balayage non borné de _Open reste la première cause d'exécutions qui dérivent vers le timeout.

‍

Audience Builder et la question du retrait

‍

Ce que Salesforce a annoncé

Audience Builder offrait aux profils non techniques une construction de segments en glisser-déposer, à partir d'attributs et de comportements, sans écrire de SQL.

Salesforce en a annoncé le retrait en novembre 2024. Les abonnements en cours sont honorés jusqu'à leur échéance, après quoi l'application n'est plus utilisable.

Rien ne s'éteint demain matin, mais ce n'est plus une destination.

‍

Ce que cela implique pour votre feuille de route

Si votre org repose encore sur Audience Builder, la vraie question est : qui absorbe cette charge le jour où l'abonnement s'arrête ?

Par défaut, la réponse est « les query activities », ce qui ramène discrètement la segmentation du marketing vers les profils techniques. C'est un changement d'organisation déguisé en changement de licence, et il vaut mieux l'anticiper que le découvrir un mois avant l'échéance.

‍

Data Cloud et la voie entrepôt de données

‍

Le moment où Salesforce vous oriente là

Pour unifier et segmenter des volumes réellement importants, la recommandation de Salesforce est de passer par un entrepôt de données interne ou par Data Cloud, plutôt que de solliciter davantage la base Marketing Cloud.

Les segments Data Cloud peuvent ensuite être exploités dans Journey Builder : l'audience arrive donc bien là où vos campagnes en ont besoin.

‍

La contrepartie

Cette voie règle le problème d'échelle pour de bon. Elle ajoute aussi une plateforme, un modèle de données, une licence et, le plus souvent, une deuxième équipe.

Pour une org qui pilote une trentaine de campagnes par mois sur quelques millions de contacts, c'est souvent la bonne réponse à trois ans et la mauvaise réponse à ce trimestre.

‍

Arbitrer sans réapprendre la plateforme

‍

Faire correspondre la méthode à la question posée

Une grille courte, qui tient dans la plupart des contextes :

• Critères tous portés par une seule table, sans historique : Filtered Data Extension.
• Engagement, jointure, dédoublonnage ou classement : SQL query activity.
• Requêtes régulièrement au-delà de 10 minutes, ou unification multi-systèmes : Data Cloud ou entrepôt.

‍

La plupart des équipes surexploitent l'option du milieu, parce qu'elle ne dit jamais non. Cela fonctionne jusqu'au jour où la file d'attente devant elle devient le vrai goulot d'étranglement de la production des campagnes.

‍

L'hygiène d'automatisation, valable dans tous les cas

Quelle que soit la méthode, quelques recommandations de Salesforce évitent les pannes de production les plus fréquentes.

• Placez les activités qui lisent une data extension après la requête qui l'alimente, dans une étape ultérieure, jamais la même.
• N'exécutez pas une activité d'import et une query activity sur la même data extension dans une seule automation : cela crée de la contention sur la base.
• Décalez vos automations de cinq à quinze minutes au lieu de les regrouper à heure ronde.

‍

Ces points n'ont rien de spectaculaire. Ils expliquent pourtant une bonne part des tickets « l'audience était vide ce matin ».

‍

Découvrir QAiry

‍

Le constat est simple : SFMC propose une méthode réellement flexible et plusieurs méthodes commodes, et la flexible exige du SQL. C'est précisément ce qui crée les files d'attente en segmentation.

QAiry se place sur cette voie flexible en supprimant le prérequis SQL : vous décrivez l'audience en langage naturel et vous obtenez une requête prête pour la production, écrite sur vos propres data extensions et data views. Le fonctionnement est détaillé sur qairy.com/fr/product-demos, et vous pouvez l'essayer sur votre org depuis qairy.com/fr/try-it-free.