QAiry face au SQL manuel : créer ses audiences dans SFMC

‍

Dans la plupart des équipes Salesforce Marketing Cloud, le scénario ne varie jamais beaucoup. Un brief arrive, quelqu'un ouvre Automation Studio, et une Query Activity finit par être écrite.

Cette habitude fonctionne depuis des années. Elle a aussi un coût que plus personne ne remarque vraiment.

QAiry déplace le point de départ : vous formulez l'audience en langage naturel, puis vous relisez le SQL généré.

‍

L'objectif de cet article n'est pas de désigner un vainqueur, mais de comparer honnêtement deux façons de travailler.

Le SQL écrit à la main garde des domaines où il reste supérieur, et il vaut mieux les nommer que les passer sous silence.

‍

Ce que représente vraiment une requête SQL dans SFMC

‍

Le SQL n'est que la partie visible

Rédiger un SELECT sur une data extension prend quelques minutes. Tout ce qui entoure cette rédaction prend beaucoup plus de temps.

Il faut d'abord identifier la bonne data extension parmi des centaines. Il faut ensuite vérifier les noms de champs, s'assurer que SubscriberKey est alimenté de façon homogène, puis choisir la data view qui contient réellement le signal d'engagement demandé.

‍

Vient enfin la création de la table cible, l'intégration de la requête dans une automation, l'exécution, puis le contrôle du volume obtenu.

Le goulot d'étranglement n'est donc presque jamais le SQL. C'est le contexte autour du SQL.

‍

Cela explique pourquoi les estimations des équipes techniques paraissent absurdes aux marketeurs. Une requête de vingt lignes mobilise bel et bien une demi-journée.

‍

Les contraintes que personne ne documente

Le SQL de SFMC s'appuie sur les capacités de SQL Server 2016 sans y correspondre exactement, et seules les instructions SELECT sur des data extensions ou des data views de votre compte ou du compte parent sont acceptées.

Les data views d'engagement comme _Sent, _Open, _Click et _Bounce conservent en général six mois d'historique. Au-delà, la donnée doit venir d'ailleurs.

‍

Les Query Activities s'interrompent par ailleurs au bout de 30 minutes, et Salesforce recommande de basculer vers un autre outil dès qu'une requête dépasse régulièrement 10 minutes d'exécution.

Rien de tout cela n'apparaît dans l'éditeur de requêtes. Ces règles vivent dans la mémoire des deux ou trois personnes qui en ont déjà fait les frais.

‍

Deux points de départ opposés

‍

Partir du besoin, pas du modèle de données

Le SQL manuel commence par la structure. Vous parcourez l'arborescence, vous tentez de vous rappeler le nom exact d'une table, et vous construisez à partir de là.

L'approche conversationnelle commence par la demande. Vous écrivez les clients français qui ont ouvert un email depuis 60 jours mais n'ont pas acheté depuis janvier, et la résolution du modèle se fait en arrière-plan.

‍

Cette inversion profite surtout à la personne qui maîtrise le contexte campagne sans maîtriser le SQL.

Elle apporte nettement moins à l'analyste qui sait déjà quelles trois tables joindre.

‍

Relire plutôt qu'écrire

La compétence attendue change de nature : on passe de la rédaction à la relecture. Vous devez toujours juger si la jointure tient et si la fenêtre temporelle correspond au brief.

Or relire une requête pour valider sa cohérence reste bien plus accessible que la produire depuis un éditeur vide.

‍

C'est une barrière que beaucoup plus de profils marketing franchissent sans formation préalable.

‍

D'où vient réellement le gain de temps

‍

La fin de la recherche à l'aveugle

Dans une construction manuelle, l'essentiel du temps passe à chercher. Quelle data extension, quel champ, quelle data view, laquelle des quatre tables aux noms voisins est encore alimentée.

Lorsque cette recherche est prise en charge, il ne reste que deux gestes : décrire l'audience et vérifier le résultat.

‍

Le gain ne vient donc pas d'une exécution plus rapide. Il vient de la disparition des vingt minutes de fouille.

‍

Moins d'allers-retours entre équipes

Dans les organisations importantes, le point le plus lent n'est pas l'exécution. C'est l'attente entre le moment où le marketeur rédige son brief et celui où un profil technique se libère.

Une demande qui représente 20 minutes de travail effectif peut ainsi consommer quatre jours de calendrier.

‍

Supprimer le passage de relais supprime l'essentiel du délai, ce qui n'a rien à voir avec le fait de rendre la requête plus rapide.

‍

Fiabilité : ce que chaque approche apporte

‍

La valeur du SQL écrit à la main

Une requête rédigée par quelqu'un qui connaît l'org embarque une somme de jugements implicites. Cette personne sait qu'une data extension contient des SubscriberKey en doublon, ou qu'un champ historique n'est alimenté que pour une seule business unit.

Ce savoir est réel, coûteux à acquérir, et il mérite d'être préservé.

‍

Aucun outil de génération sérieux ne devrait faire comme si cette couche de contexte n'existait pas.

‍

Ce qu'une requête générée doit démontrer

Un système qui écrit du SQL à votre place doit rester transparent sur ce qu'il produit. Si la requête reste invisible, l'erreur le reste aussi.

C'est la raison pour laquelle QAiry affiche l'instruction complète au lieu de la masquer derrière un bouton.

‍

La position honnête consiste à dire qu'une requête générée se relit, exactement comme celle d'un analyste qui vient d'arriver.

La différence tient au temps : la relecture se compte en minutes, la rédaction en heures.

‍

Les limites de la plateforme restent les mêmes

‍

Le plafond des 30 minutes

Une requête générée s'exécute dans le même environnement, avec les mêmes contraintes. Elle peut donc expirer au même titre qu'une requête écrite manuellement.

Salesforce conseille de limiter les volumes appelés, de ne sélectionner que les champs utiles, et de privilégier des prédicats capables d'exploiter les index.

‍

Si 24 heures de données suffisent, en extraire 30 jours reste un problème de performance que l'on s'inflige seul.

‍

Les bonnes pratiques à conserver

Les recommandations de Salesforce portent aussi sur la couche automation, pas seulement sur l'instruction :

• Une seule Query Activity par étape d'automation.
• Des automations décalées, pour éviter la concurrence sur les mêmes ressources.
• Des jointures multiples découpées en tables intermédiaires, réunies par une requête finale.
• Un extract suivi d'une import activity pour les copies massives, plutôt qu'une requête.

‍

Ces règles valent quel que soit l'auteur de la requête. La génération conversationnelle n'affranchit personne des limites de la plateforme.

‍

Quand le SQL manuel reste le bon choix

‍

Les transformations complexes

La préparation de données en plusieurs étapes, la déduplication avec des règles d'arbitrage inhabituelles et tout ce qui remodèle la donnée au lieu de la sélectionner relèvent toujours d'un profil technique.

Il en va de même pour les requêtes qui alimentent une intégration, où le format de sortie compte autant que les lignes produites.

‍

Tout ce qui engage votre responsabilité

Les logiques de suppression sensibles, la gestion du consentement et les requêtes qui nourrissent un reporting réglementaire méritent un auteur identifié, capable de défendre chaque clause.

‍

Le partage se fait donc assez naturellement. L'approche conversationnelle absorbe les constructions d'audience courantes, qui composent l'essentiel de la file d'attente hebdomadaire, et l'expertise technique se concentre sur le reste.

‍

Découvrir QAiry en conditions réelles

‍

Cette comparaison devient beaucoup plus parlante avec une requête réelle sous les yeux.

Vous pouvez suivre une construction complète sur qairy.com/fr/product-demos, ou tester l'outil sur l'un de vos propres briefs via qairy.com/fr/try-it-free.