Créer des audiences SFMC prêtes pour la production avec QAiry

‍

Dans la plupart des outils de segmentation, tout s'arrête une fois la requête écrite.

C'est pourtant l'étape la plus simple. Le vrai travail commence après : transformer un jeu de lignes en une data extension depuis laquelle une campagne peut réellement partir.

‍

Une audience est prête pour la production lorsqu'elle s'exécute à l'heure prévue, alimente la bonne cible, respecte la send relationship et ne se dégrade pas dès que le volume de données augmente.

Dans Salesforce Marketing Cloud, y parvenir suppose en général plusieurs allers-retours entre le marketeur qui formule le besoin et la personne qui maîtrise le SQL.

‍

Voici comment QAiry comble cet écart : ce qu'il analyse avant d'écrire la moindre ligne, les contraintes SFMC qu'il intègre d'emblée, et les arbitrages qui vous appartiennent toujours.

‍

Ce que « prêt pour la production » signifie dans SFMC

‍

L'audience doit tenir le jour de l'envoi

Une requête qui remonte les bonnes personnes n'est pas encore une audience qu'Email Studio acceptera.

Une data extension sendable exige une send relationship reliant un champ de l'extension à un abonné, et la présence de SubscriberKey pour que cette relation fonctionne. Sans elle, les lignes existent mais l'envoi reste impossible.

‍

Cette relation est aussi ce qui rattache chaque ligne à All Subscribers, où le statut d'abonnement est maintenu pour l'ensemble des envois e-mail.

L'omettre revient à constituer une liste qui ignore vos propres désabonnements.

‍

L'audience doit tenir le mois suivant

Le second mode de défaillance est plus lent et coûte plus cher.

Une requête confortable sur 200 000 lignes ne se comporte plus de la même façon sur dix millions. Salesforce indique d'ailleurs que le temps d'exécution des query activities en add ou update augmente à peu près linéairement avec le volume traité.

‍

Par ailleurs, les requêtes s'interrompent au bout de 30 minutes, et la base applique deux types de plafonds : des limites strictes, qui rejettent la requête, et des limites souples, que vous pouvez dépasser au prix de la performance.

Une audience robuste est donc écrite en tenant compte de ces plafonds, plutôt que découverte à leur contact un dimanche soir.

‍

Partir du besoin exprimé, pas du schéma

‍

Comment QAiry interprète une demande en langage naturel

Le point de départ est une phrase qu'un marketeur formulerait spontanément. Par exemple : « les clients ayant acheté ces 90 derniers jours mais sans ouverture depuis 60 jours ».

QAiry en isole les composants : une population, une ou plusieurs règles d'inclusion, une ou plusieurs règles d'exclusion, et une fenêtre temporelle pour chacune.

‍

Chaque composant est ensuite rattaché à un objet réel de votre org. « Acheté » correspond à une table et à un champ de date. « Ouvert » renvoie à la data view _Open, jointe sur SubscriberKey. « 90 derniers jours » devient une expression bornée, jamais une date figée dans le code.

‍

Là où l'ambiguïté se lève

Le langage naturel comporte des zones floues que le SQL ne tolère pas. Autrement dit, mieux vaut les exposer que les deviner.

Trois questions reviennent systématiquement :

• « Clients » désigne-t-il toute la master extension ou seulement les contacts encore abonnés ?
• La fenêtre de 90 jours part-elle de la date d'exécution ou d'une date de campagne fixe ?
• Un contact sans aucun historique d'engagement doit-il être compté comme inactif ?

‍

QAiry vous les repose en langage courant avant toute génération. L'échange dure quelques secondes et supprime l'essentiel des reprises ultérieures.

‍

Ancrer la requête dans votre modèle de données

‍

Data extensions, champs et types

Un SQL rédigé sans visibilité sur votre schéma relève de la supposition. Il paraît correct dans l'absolu et échoue dans votre org, le plus souvent sur un nom de colonne ou un type incompatible.

QAiry s'appuie sur vos data extensions réelles : les noms de champs tels qu'ils existent, leurs types, leurs longueurs, et le champ qui porte l'identifiant abonné.

‍

C'est cet ancrage qui produit une requête exécutable du premier coup, au lieu d'une requête à corriger pendant vingt minutes.

‍

Les data views et leur fenêtre de rétention

Les questions d'engagement passent presque toujours par les data views système : _Sent, _Open, _Click, _Bounce et _Subscribers.

Elles sont interrogeables, mais ne constituent pas un archivage complet. Elles exposent une fenêtre de rétention glissante : une requête portant sur un comportement d'il y a deux ans renverra un résultat vide, et non une erreur.

‍

Un résultat vide qui ressemble à une réponse valide est la sortie la plus dangereuse en segmentation. QAiry signale donc les fenêtres demandées qui dépassent ce que les data views peuvent réellement couvrir, avant l'envoi et non après.

‍

Écrire un SQL accepté par Automation Studio

‍

Le sous-ensemble SQL supporté dans SFMC

Marketing Cloud exécute un dialecte contraint. Assez proche du T-SQL standard pour sembler familier, assez différent pour poser problème.

Les requêtes se limitent au SELECT, et toute une série de constructions disponibles ailleurs restent inaccessibles dans une Query Activity.

‍

QAiry génère nativement à l'intérieur de ce périmètre : logique de dates bornée avec DATEADD() et GETDATE(), exclusions écrites en NOT EXISTS plutôt qu'en longues listes NOT IN, et jointures sur des clés indexées.

‍

Dédoublonnage et règle du SubscriberKey

Les doublons constituent le bug le plus discret de la segmentation SFMC, et les jointures sur les data views d'engagement en produisent sans effort. Un contact avec quatre ouvertures devient quatre lignes.

L'audience affiche alors un volume gonflé et peut, selon la configuration de la cible, adresser plusieurs fois la même personne.

‍

QAiry dédoublonne sur SubscriberKey par défaut, via SELECT DISTINCT ou une numérotation de lignes fenêtrée lorsque vous devez conserver un enregistrement précis plutôt qu'un enregistrement quelconque.

‍

Choisir la cible et l'action sur les données

‍

Overwrite, append ou update

Une Query Activity alimente une data extension cible selon l'une des trois actions possibles, et ce choix modifie la nature même de l'audience.

• Overwrite remplace le contenu à chaque exécution, adapté à un segment recalculé.
• Append ajoute des lignes sans rien supprimer, adapté à un journal d'événements.
• Update s'appuie sur la clé primaire et rafraîchit les lignes existantes.

‍

Un mauvais choix explique souvent une audience juste en semaine 1 et doublée en semaine 3. QAiry déduit l'action de l'intention exprimée, puis vous indique laquelle il a retenue et pourquoi.

‍

Rendre la cible réellement sendable

Une extension cible n'a d'utilité que si la campagne peut en partir, ce qui suppose une send relationship configurée et un SubscriberKey conservé tout au long de la requête.

QAiry maintient l'identifiant abonné dans la sortie par défaut : l'extension obtenue est donc une extension qu'Email Studio reconnaît.

‍

Pour les opérations d'add ou d'update à très gros volume, Salesforce recommande de passer par une extension intermédiaire et de confier l'écriture finale à une Import Activity, plus rapide à cette échelle.

‍

Ce qui se passe après la première exécution

‍

Planification et alertes d'échec

Une Query Activity peut s'exécuter ponctuellement ou selon une planification dans Automation Studio. C'est sur les audiences récurrentes que se concentre le risque opérationnel.

Une automatisation qui échoue de façon répétée sur une période prolongée finit désactivée par la plateforme, avec une notification envoyée à l'adresse renseignée dans Runtime Error ou Skipped Run.

‍

Cette adresse mérite d'être configurée sérieusement. Sans elle, une automatisation désactivée reste muette, et le silence ressemble beaucoup à une réussite sur un tableau de bord.

‍

Itérer sans tout reprendre

La segmentation réelle est itérative. La première version va dans la bonne direction, puis quelqu'un demande d'exclure une région, d'élargir la fenêtre ou d'ajouter une catégorie de produits.

Comme QAiry conserve la définition de l'audience dans une conversation plutôt que dans un fichier que personne ne relit, une demande de modification tient en une phrase.

‍

En pratique, la personne qui connaît la campagne redevient celle qui ajuste l'audience.

‍

QAiry en conditions réelles

‍

Rien de tout cela ne dispense de gouvernance. Quelqu'un reste responsable du modèle de données, des conventions de nommage et de la définition même d'un client.

Ce qui change, c'est la file d'attente. Une demande qui patientait trois jours côté équipe technique se traite en quelques minutes, et cette équipe passe de la transcription à la relecture.

‍

Le meilleur test reste votre propre modèle de données, avec un segment que vous avez déjà eu à construire.

Vous pouvez suivre une démonstration sur qairy.com/fr/product-demos, ou partir directement de votre org SFMC sur qairy.com/fr/try-it-free.