QAiry 3.1 : ce qui change pour vos audiences SFMC
Compréhension fine des métadonnées, quatre types de data extensions, Manual Edit devenu builder, entrée par SQL et chaînage Waterfall : le point sur la 3.1.
QAiry 3.1 : ce qui change pour vos audiences SFMC
QAiry 3.1 est disponible.
En résumé : l'assistant lit bien mieux vos métadonnées SFMC, il atteint davantage de data extensions, et il ne part plus du principe que la conversation est votre seule façon de travailler.
S'y ajoute un nouveau modèle d'automatisation pour rafraîchir dans le bon ordre des data extensions dépendantes.
C'est l'ensemble de changements le plus important depuis le lancement du produit.
Cet article détaille ce qui a été livré, et le problème que chaque nouveauté traite concrètement dans une org Marketing Cloud.
Un espace de travail, trois façons de construire
Chat, Manual Edit et SQL au même niveau
Jusqu'ici, la conversation faisait office de porte d'entrée. Vous décriviez une audience, QAiry rédigeait le SQL, et Manual Edit servait à retoucher le résultat.
Avec la 3.1, les trois onglets sont des points de départ à part entière.
Vous pouvez ouvrir une audience directement dans Manual Edit et en construire la logique étape par étape. Vous pouvez aussi ouvrir l'onglet SQL, coller une requête que vous maîtrisez déjà, et poursuivre à partir de là.
L'objet audience, lui, n'a pas changé : les trois onglets agissent sur la même requête et le même résultat.
Pourquoi une porte d'entrée unique posait problème
Une équipe SFMC est rarement homogène. Le responsable de campagne veut décrire son audience. Le développeur veut voir la jointure. Les deux traitent pourtant le même brief.
Les faire passer par la même porte revenait à en pénaliser un systématiquement.
La réponse n'a pas été d'ajouter un mode, mais de cesser d'en imposer un par défaut.
Le Chat comprend mieux votre modèle de données
Des réponses ancrées dans votre environnement
La principale avancée de la 3.1 n'est pas un nouveau bouton. C'est la façon dont QAiry lit vos Data Extensions, vos champs et leurs relations avant d'écrire quoi que ce soit.
Vos demandes sont interprétées au regard de votre business unit, et non d'un schéma SFMC générique. Le SQL renvoyé s'appuie donc sur des tables et des colonnes qui existent réellement.
Les relations comptent autant que les tables. Savoir que Orders se rattache à Clients en un-à-plusieurs, et que Payments suit en un-à-un, sépare une audience juste d'une audience gonflée.
QAiry suit par ailleurs votre objectif tout au long de l'échange et propose l'étape suivante, au lieu de traiter chaque message isolément.
Connecter une data extension sans quitter la conversation
Auparavant, si QAiry avait besoin d'une table non connectée, l'échange s'arrêtait pendant que vous alliez la paramétrer.
Désormais, vous cherchez, sélectionnez et connectez la data extension manquante depuis la conversation, puis vous reprenez où vous en étiez.
Le détail paraît mineur, mais il supprime l'une des interruptions les plus fréquentes d'une construction d'audience.
Autrement dit, il évite un changement de contexte, et c'est souvent là que les audiences restent à moitié terminées.
Davantage de data extensions accessibles
Quatre types, et non plus un seul
La 3.1 élargit ce que QAiry peut mobiliser dans une audience :
- Les Data Extensions connectées à votre business unit.
- Les Shared Data Extensions, pour travailler entre business units.
- Les Synchronized Data Extensions, qui portent les données du CRM Salesforce.
- Les Salesforce Data Extensions générées par l'intégration CRM.
Ce que cela change dans une org Enterprise
Marketing Cloud Connect et les Synchronized Data Sources rapatrient les enregistrements d'objets CRM Salesforce dans des data extensions. Dans un compte Enterprise 2.0, ces extensions se trouvent par défaut au niveau supérieur du tenant.
La méthode préconisée par Salesforce pour faire descendre ces données vers une business unit consiste à exécuter une query activity qui les copie dans une nouvelle data extension, puis à partager cette dernière.
C'est un pipeline à construire et à maintenir avant même de pouvoir segmenter sur un champ CRM.
Lire ces sources directement supprime une étape qui n'existait que pour déplacer de la donnée.
À garder en tête : Salesforce recommande de ne synchroniser que les champs nécessaires, avec un repère de performance situé autour de 20 champs par objet. Atteindre plus de sources ne change rien à ce conseil.
Manual Edit devient un builder
Cinq étapes, dans l'ordre
Manual Edit était une surface de retouche. Dans la 3.1, c'est un builder structuré qui mène l'audience des sources jusqu'au résultat.
- Sélectionner les data extensions connectées à utiliser.
- Définir la logique de jointure entre elles.
- Ajouter les filtres que le contact doit satisfaire.
- Appliquer les exclusions.
- Vérifier et organiser les champs de sortie.
L'ordre n'est pas anodin. Les exclusions arrivent après les filtres parce que les listes de suppression sont l'endroit où une audience dérape le plus discrètement.
Construire d'abord, demander ensuite
Manual Edit étant devenu un point d'entrée, vous pouvez monter l'ensemble visuellement sans jamais ouvrir le Chat.
Vous pouvez aussi poser la structure à la main et confier à l'assistant la partie que vous préférez ne pas écrire. Les deux modes agissent sur la même audience, le passage de l'un à l'autre ne coûte donc rien.
Partir d'un SQL que vous avez déjà
Coller une requête et continuer
La plupart des équipes SFMC disposent d'un dossier de requêtes qui fonctionnent. La 3.1 permet d'ouvrir l'onglet SQL, d'en coller une, de la valider, puis d'affiner l'audience dans QAiry.
Rien n'est réécrit à votre insu. La requête reste la vôtre et vous pouvez revenir à la version enregistrée à tout moment.
Ce point compte plus qu'il n'y paraît. Une requête relue une fois et fiable au quotidien est un actif, et rares sont les équipes prêtes à la confier à un outil susceptible de la remodeler sans prévenir.
Circuler entre les onglets
Aucun parcours n'est imposé. Le bon est celui qui correspond à la demande du moment.
Commencez en SQL, passez dans Manual Edit pour ajuster visuellement les exclusions, puis demandez au Chat de prolonger la logique.
Ou démarrez dans le Chat et basculez en SQL pour vérifier la jointure avant d'exécuter quoi que ce soit.
Waterfall : rafraîchir les DE dans le bon ordre
Pourquoi l'ordre de rafraîchissement est fragile dans Automation Studio
Automation Studio exécute les activités selon la séquence d'étapes que vous organisez, et une même étape peut en contenir plusieurs.
Cette souplesse est aussi un piège. Salesforce l'indique clairement : une activité qui interroge ou alimente une data extension doit se situer après la requête qui la remplit, et non dans la même étape, faute de quoi elle ne renvoie rien.
Une longue chaîne d'audiences dépendantes devient alors un casse-tête de séquencement, que l'on résout généralement à coups de wait activities et de marges de temps confortables.
Ces marges restent des paris. Dès que les volumes augmentent, le pari ne tient plus.
Enchaîner plutôt que chronométrer
Waterfall enchaîne les rafraîchissements de data extensions dépendantes : chaque étape ne démarre qu'une fois la précédente terminée.
Une chaîne type : construire l'audience de base, l'enrichir avec des données de profil et de comportement, appliquer les règles de suppression, puis publier l'audience finale.
Chaque étape attend la précédente et non une horloge, ce qui allège la pression de timeout sur les longues chaînes de rafraîchissement.
Ces rafraîchissements sont également accessibles via l'API : une chaîne peut donc être déclenchée entièrement en dehors d'Automation Studio.
Découvrez QAiry en pratique
La 3.1 est active pour les installations existantes, et le nouveau builder est la partie la plus rapide à juger par vous-même.
Les démonstrations disponibles sur qairy.com/fr/product-demos montrent les trois onglets et une chaîne Waterfall sur une org réelle, et vous pouvez l'installer sur votre propre business unit via qairy.com/fr/try-it-free.
