Overwrite, Update ou Append dans une requête SFMC

Votre requête fonctionne, et Automation Studio vous demande maintenant de choisir une action sur les données : Overwrite, Update ou Append. Un mauvais choix et vous videz une data extension que vous vouliez garder, ou vous accumulez des doublons qui coûteront une semaine de nettoyage.

La réponse courte pour une activité de requête SFMC en mode overwrite, update ou append : choisissez Overwrite quand la cible doit refléter exactement le dernier résultat, Update quand vous voulez ajouter des lignes et mettre à jour les existantes via la clé primaire, et Append quand vous ne faites qu'ajouter des lignes, comme dans un journal d'événements.

Cet article détaille le comportement de chaque mode, donne un exemple SQL par mode avec la data extension cible et sa clé primaire, puis se termine par une liste de contrôle à copier. Pour ne pas écrire le SQL vous-même, vous pouvez aussi générer vos requêtes SQL SFMC à partir d'une phrase.

‍

Overwrite, Update ou Append : le comportement de chaque mode

‍

L'action sur les données est le paramètre d'une activité de requête qui indique à SFMC quoi faire des lignes renvoyées. Salesforce propose trois options : Append, Update et Overwrite (voir le module Trailhead sur les requêtes SQL).

‍

Overwrite remplace tout

Overwrite vide la data extension cible puis y écrit le nouveau résultat. Après l'exécution, la cible contient exactement ce que la requête a renvoyé. C'est le bon choix pour une audience, car elle doit refléter qui est éligible aujourd'hui et non le mois dernier.

Attention : un résultat vide vide aussi la cible. Si la requête ne renvoie aucune ligne un jour donné, votre audience d'envoi est vide.

‍

Update ajoute les nouvelles lignes et actualise les existantes

Update rapproche chaque ligne renvoyée de la cible grâce à la clé primaire. Une nouvelle clé crée une ligne, une clé existante met à jour les valeurs. Les lignes déjà présentes que la requête ne renvoie pas restent inchangées.

Cela suppose que la data extension cible ait une clé primaire et que la requête renvoie cette colonne. Le mode convient aux tables maîtres et aux tables de scoring qui évoluent dans le temps.

‍

Append ajoute uniquement

Append ajoute chaque ligne renvoyée à la suite de la cible sans toucher à l'existant. C'est le mode des journaux et des historiques, où chaque exécution apporte une nouvelle tranche de données.

Comme Append ne dédoublonne rien, exécuter deux fois la même requête peut charger deux fois les mêmes lignes, ou provoquer une erreur si la cible a une clé primaire et qu'une ligne entre en collision avec une ligne existante. Prévoyez une fenêtre de dates distincte pour chaque exécution.

‍

Requête SQL SFMC en Overwrite : exemple d'audience quotidienne

‍

Un cas fréquent est l'audience glissante, par exemple les clients ayant commandé ces 30 derniers jours. Elle change chaque jour, donc Overwrite est l'action adaptée.

SELECT
    c.SubscriberKey,
    c.EmailAddress,
    c.FirstName,
    MAX(o.OrderDate) AS LastOrderDate
FROM Customers_Master c
INNER JOIN Orders o
    ON o.SubscriberKey = c.SubscriberKey
WHERE o.OrderDate >= DATEADD(day, -30, GETDATE())
GROUP BY c.SubscriberKey, c.EmailAddress, c.FirstName

Data extension cible : Recent_Buyers. Clé primaire : SubscriberKey. Action : Overwrite. Voici le rôle de chaque partie :

• SELECT liste les quatre colonnes attendues par la cible : SubscriberKey, EmailAddress, FirstName et la date de la dernière commande.
• FROM et INNER JOIN relient la table clients à la table Orders sur SubscriberKey, ce qui ne garde que les clients ayant au moins une commande.
• La clause WHERE utilise DATEADD et GETDATE pour ne garder que les commandes des 30 derniers jours. Relative à aujourd'hui, l'audience suit le calendrier.
• GROUP BY avec MAX regroupe plusieurs commandes en une ligne par client, ce qui protège la clé primaire des doublons.

Pour construire d'autres audiences de ce type, consultez aussi notre article sur comment repérer les contacts inactifs dans SFMC.

‍

Exemple Update : garder une table de scoring à jour

‍

Imaginez une data extension qui stocke une ligne par client avec le nombre de commandes et le chiffre d'affaires récents. Vous voulez actualiser les clients ayant commandé récemment sans supprimer les autres. C'est un cas pour Update.

SELECT
    o.SubscriberKey,
    COUNT(*) AS Orders90d,
    SUM(o.OrderTotal) AS Revenue90d
FROM Orders o
WHERE o.OrderDate >= DATEADD(day, -90, GETDATE())
GROUP BY o.SubscriberKey

Data extension cible : Customer_Scores. Clé primaire : SubscriberKey. Action : Update. Ligne par ligne :

• SubscriberKey est renvoyé pour que SFMC rapproche chaque ligne d'un enregistrement existant de la cible.
• COUNT et SUM calculent le nombre de commandes et le chiffre d'affaires sur 90 jours, écrits dans Orders90d et Revenue90d.
• La clause WHERE limite l'analyse à 90 jours, ce qui réduit le temps d'exécution.
• GROUP BY donne une ligne par client, donc chaque clé apparaît une seule fois par exécution.

Un piège à connaître : les clients sans commande sur 90 jours ne sont pas renvoyés, leurs anciennes valeurs restent donc dans la table. Si ces valeurs périmées faussent un segment, utilisez Overwrite avec une requête qui renvoie tous les clients, ou ajoutez une étape de remise à zéro.

‍

Exemple Append : constituer un historique d'engagement

‍

Les data views comme _Open ne conservent qu'une fenêtre limitée d'historique, c'est pourquoi les équipes copient les événements dans leur propre data extension. C'est un cas typique d'Append. Pour mieux connaître ces tables, lisez le guide pour interroger les data views SFMC en SQL.

SELECT
    o.SubscriberKey,
    o.JobID,
    o.EventDate,
    GETDATE() AS LoadedAt
FROM _Open o
WHERE o.IsUnique = 1
    AND o.EventDate >= DATEADD(day, -1, GETDATE())

Data extension cible : Open_History. Clé primaire : aucune, ou une clé composite SubscriberKey, JobID et EventDate si vous voulez rejeter les collisions. Action : Append. Explications :

• La requête lit les ouvertures uniques de la data view _Open, le champ IsUnique écartant les réouvertures.
• EventDate avec DATEADD ne garde que la dernière journée, donc une exécution quotidienne ajoute un jour de plus à chaque fois.
• GETDATE enregistré dans LoadedAt indique quand chaque ligne a été copiée, ce qui facilite les audits.
• Planifiez l'automation une fois par jour. Deux exécutions le même jour chargeraient cette journée deux fois.

‍

Réponse rapide : quel mode choisir ?

‍

Servez-vous de ce tableau avant de configurer l'activité. Il couvre les questions qui décident du choix.

Et une courte liste de contrôle à parcourir à chaque fois :

1. Décidez si la cible doit refléter le résultat de la requête ou s'accumuler dans le temps.
2. Vérifiez que la data extension cible a la bonne clé primaire et que votre requête la renvoie.
3. Assurez-vous que la requête renvoie une seule ligne par clé primaire.
4. Choisissez l'action, lancez la requête une fois à la main et contrôlez le nombre de lignes.
5. Planifiez-la, et évitez qu'une autre automation lise la cible pendant son écriture.

‍

Pièges courants avec les actions sur les données

‍

‍

Délais d'exécution et mises à jour lourdes

Une activité de requête s'arrête au bout de 30 minutes, selon Salesforce Trailhead. Les gros volumes et les jointures larges rendent cette limite plus facile à atteindre : sélectionnez uniquement les champs utiles plutôt que SELECT * et filtrez tôt avec une condition de date.

En pratique, Update est souvent plus long qu'Overwrite sur de grandes tables, car chaque ligne doit être rapprochée de la cible. Si une mise à jour lourde dépasse le délai, voyez si Overwrite sur une data extension plus petite et dédiée ferait l'affaire.

‍

Colonnes et types de données incompatibles

Les colonnes renvoyées par la requête doivent correspondre à la data extension cible par le nom et par un type compatible. Un alias renommé, un texte écrit dans un champ numérique ou une valeur plus longue que le champ sont les causes habituelles d'échec. Nommez vos alias exactement comme la cible.

Pour de bonnes habitudes de nommage et de structure, lisez notre article sur la création d'audiences dynamiques dans SFMC.

‍

Questions fréquentes

‍

‍

Quelle différence entre Overwrite et Update dans SFMC ?

Overwrite supprime le contenu de la cible et charge le résultat de la requête, la cible devient donc identique au résultat. Update conserve les lignes existantes, ajoute les nouvelles clés et actualise les clés correspondantes. Les lignes que la requête ne renvoie plus restent avec Update et disparaissent avec Overwrite.

‍

Update nécessite-t-il une clé primaire dans SFMC ?

Oui. Update rapproche les lignes grâce à la clé primaire de la data extension cible : la cible doit en avoir une et la requête doit renvoyer cette colonne. Sans clé, il n'y a rien à rapprocher.

‍

Quand utiliser Append dans une activité de requête SFMC ?

Utilisez Append pour les tables d'événements où chaque exécution ajoute de nouveaux enregistrements, comme l'historique des envois, des ouvertures ou des clics. Gardez une fenêtre de dates distincte à chaque exécution pour ne pas charger deux fois les mêmes lignes.

‍

Overwrite peut-il vider mon audience par erreur ?

Oui, si la requête ne renvoie aucune ligne : la cible est vidée et remplacée par un résultat vide. Testez la requête avant de planifier, et évitez qu'un envoi s'exécute sur une cible tout juste vidée.

‍

Créez cette audience en quelques secondes avec QAiry

‍

Choisir l'action sur les données est une petite décision, mais elle ne vient qu'une fois le SQL correct. QAiry transforme une demande en langage courant en SQL SFMC prêt pour la production et en data extensions, directement dans votre Marketing Cloud, pour que vous vous concentriez sur la logique d'audience plutôt que sur la syntaxe.

Envie d'essayer ? Installez QAiry gratuitement ou regardez une démo produit pour le voir construire une audience à partir d'une simple phrase.