Pourquoi les marketeurs dépendent encore de l'IT dans SFMC

‍

Vous savez déjà quelle audience vous visez. Les contacts qui ont ouvert récemment mais n'ont rien acheté depuis quatre-vingt-dix jours.

La décrire tient en une phrase. La construire dans Salesforce Marketing Cloud demande un ticket, une file d'attente et quelqu'un qui écrit du SQL.

C'est cet écart qui oblige tant d'équipes marketing à attendre l'IT pour livrer un segment.

‍

Il ne s'agit pas d'un manque d'effort ni d'ambition. C'est une caractéristique structurelle de la façon dont SFMC stocke et expose ses données.

Dès que l'on voit où se situe la couche technique, la dépendance cesse d'être un mystère. Les moyens d'en sortir aussi.

‍

En pratique, la dépendance n'est pas un mur unique. C'est une suite de petites étapes techniques qui, chacune, réclament discrètement du SQL.

‍

Cet article détaille ce dont les marketeurs dépendent réellement dans SFMC, pourquoi une demande simple devient un travail d'ingénierie, et ce qui commence à changer.

‍

À quoi ressemble cette dépendance au quotidien

‍

La file de demandes derrière chaque audience

Un marketeur choisit un segment. Un développeur ou un spécialiste ops transforme cette intention en requête.

La demande rejoint un backlog, se retrouve priorisée face au reste de la feuille de route, puis revient quelques jours plus tard.

Entre-temps, la fenêtre de campagne a souvent déjà changé.

Le schéma se répète pour presque chaque audience non standard, si bien que la file ne se vide jamais vraiment.

‍

Pourquoi une demande simple devient un ticket

Formulée en langage courant, la demande paraît anodine. Ce qu'elle implique techniquement ne l'est pas.

Il faut savoir quelles tables contiennent les données, comment elles s'articulent, et comment exprimer la logique en SQL accepté par SFMC.

Rares sont les marketeurs formés pour cela, si bien que le travail est renvoyé à ceux qui savent.

Ce transfert, répété sur une année de campagnes, c'est la dépendance dans sa forme la plus nette.

‍

La couche technique que les marketeurs voient rarement

‍

Data extensions et data views

SFMC conserve les données de contact et d'engagement dans des data extensions et dans des data views système.

Les data extensions sont des tables que vous créez et maîtrisez. Les data views sont des tables système en lecture seule, gérées par SFMC.

Des data views comme _Sent, _Open et _Click conservent l'historique d'engagement derrière chaque envoi.

Selon l'aide Salesforce, on les exploite en créant une data extension pour stocker le résultat, puis en construisant une requête qui lit la vue et écrit dans cette extension.

Ce chemin indirect, de la vue à la requête puis à une nouvelle extension, reste invisible dans le brief marketing mais inévitable à la construction.

‍

L'activité SQL Query dans Automation Studio

L'outil qui relie tout cela, c'est l'activité SQL Query d'Automation Studio.

Elle permet d'écrire une requête, de la lancer immédiatement ou selon une planification, et de déposer le résultat dans une data extension cible.

La configurer, c'est nommer la requête, choisir l'extension cible et décider comment le résultat s'écrit.

Vous choisissez si les données sont ajoutées, mises à jour puis ajoutées, ou écrites en écrasement complet de l'extension.

‍

Là où la maîtrise du SQL devient le point de passage obligé

‍

Joindre les données d'engagement entre plusieurs vues

Les segments utiles vivent rarement dans une seule table.

Une audience non engagée suppose de joindre les données d'envoi aux données d'ouverture et de clic, souvent sur des clés comme JobID, ListID, BatchID et SubID, puis d'apparier les contacts sur SubscriberKey.

Écrire cette jointure correctement, c'est la différence entre une audience propre et une audience qui exclut discrètement les mauvaises personnes.

Une clé erronée n'empêche pas la requête de s'exécuter : elle renvoie simplement les mauvais contacts, ce qui est plus difficile à repérer qu'une erreur franche.

C'est là que l'intention marketing et le détail technique s'éloignent, et là qu'un second relecteur prend toute sa valeur.

‍

Les règles qui font trébucher

Le SQL de SFMC repose sur SQL Server 2016 sans y correspondre exactement, si bien que les habitudes venues d'autres bases ne se transposent pas toujours.

Quelques contraintes piègent le plus souvent les nouveaux venus :

• Les requêtes expirent au bout de trente minutes.
• Un SELECT trop large sur une grande extension peut ralentir tout le compte.
• Salesforce conseille de limiter les plages de dates, souvent à environ six mois.

Rien d'insurmontable une fois connu, mais chacune de ces règles est un endroit où un marketeur sans formation SQL se bloque et ouvre un ticket.

‍

Le vrai coût de la dépendance

‍

Des campagnes plus lentes et des fenêtres manquées

Chaque audience qui exige une requête ajoute un passage de relais entre deux personnes.

Ces relais ajoutent des jours, et les jours transforment une campagne opportune en campagne tardive. Le délai vient rarement de la requête elle-même, mais de l'attente qui la précède.

Les envois saisonniers, les relances de réactivation et les réactions rapides à un comportement sont les campagnes qui souffrent le plus de cette attente.

‍

Un goulot d'étranglement réduit à une ou deux personnes

Quand seules une ou deux personnes savent écrire du SQL dans SFMC, elles deviennent un point de défaillance unique pour toute l'équipe.

Un congé, un départ ou un sprint chargé peuvent bloquer tous les segments du calendrier.

Le savoir reste dans leur tête plutôt que dans un système partagé, et il part avec elles.

Documenter les requêtes courantes aide, mais la documentation vieillit vite à mesure que les data extensions et les conventions de nommage évoluent.

‍

Ce que les marketeurs peuvent s'approprier dès aujourd'hui

‍

Apprendre à lire une requête, pas à l'écrire

Nul besoin de rédiger du SQL de zéro pour desserrer la dépendance.

Savoir lire une requête, vérifier quelles tables elle touche et confirmer la logique raccourcit déjà la boucle et réduit les allers-retours.

Cette lecture fait aussi de vous un meilleur relecteur, si bien que les requêtes venues de l'IT sortent justes du premier coup.

Même un vocabulaire de douze termes SQL change la façon de cadrer une demande et la vitesse à laquelle elle revient.

‍

Constituer une bibliothèque de modèles réutilisables

La plupart des audiences sont des variantes de quelques schémas : ouvreurs récents, acheteurs inactifs, listes de suppression.

Enregistrer les requêtes qui fonctionnent comme modèles permet de les réutiliser avec de légères retouches plutôt que de repartir de zéro.

Les rôles et permissions dans SFMC déterminent qui peut exécuter ces activités, d'où l'intérêt de décider tôt qui possède quoi.

‍

Là où l'IA conversationnelle change la donne

‍

Du ticket à la phrase

La dépendance existe parce qu'une personne doit traduire le langage courant en SQL.

L'IA conversationnelle supprime cette étape de traduction. Vous décrivez l'audience voulue, et la requête est générée pour vous.

La demande qui devenait un ticket devient une phrase que vous exécutez vous-même.

Les étapes techniques ont toujours lieu : elles se déroulent simplement pour vous au lieu de vous bloquer.

‍

Garder un humain dans la boucle

Le SQL généré reste du SQL : il peut donc être inspecté avant la moindre exécution.

Le marketeur voit l'audience qu'il a demandée, et un profil technique peut toujours relire la requête sous-jacente.

Résultat : moins de tickets et moins d'attente, sans renoncer au contrôle. Montre-moi les ouvreurs qui n'ont pas acheté depuis quatre-vingt-dix jours devient une action directe.

‍

Découvrez QAiry en action

‍

QAiry transforme des demandes en langage courant en audiences SFMC prêtes pour la production, pour que les marketeurs avancent sans rester coincés dans une file de requêtes.

Voyez-le à l'œuvre sur de vrais segments sur qairy.com/fr/product-demos, ou essayez-le directement sur qairy.com/fr/try-it-free.