Subscriber Key : pourquoi un désabonné continue de recevoir vos emails

Une cliente se désabonne, reçoit la confirmation, et retrouve la newsletter dans sa boîte la semaine suivante. Personne n'a touché au paramétrage, le lien de désabonnement fonctionne en recette, et pourtant la réclamation arrive au service client avec le mot CNIL dedans.

Dans Marketing Cloud Engagement, ce scénario n'est presque jamais un bug. C'est une conséquence du modèle de données, et plus précisément d'une valeur : la Subscriber Key.

Deux clés, deux personnes

La Subscriber Key identifie un abonné. Deux lignes qui portent la même adresse email mais deux clés différentes sont, pour la plateforme, deux personnes distinctes. Tout le reste en découle.

D'ou viennent les cles en double

L'origine du problème est presque toujours la même : une data extension d'envoi reliée aux abonnés par l'adresse email, parce que le fichier source ne contenait pas l'identifiant client. Un import de fidélité, une liste d'un prestataire, un export d'un site événementiel, et la base se dédouble sans le moindre message d'erreur.

Mesurer, en deux requêtes

La data view système _Subscribers expose All Subscribers en SQL. Première requête, le volume : combien d'adresses existent sous plusieurs clés.

SELECT
    s.EmailAddress,
    COUNT(*)          AS NbCles,
    MIN(s.DateJoined) AS PremiereInscription
FROM _Subscribers AS s
WHERE s.EmailAddress IS NOT NULL
GROUP BY s.EmailAddress
HAVING COUNT(*) > 1

Quelques dizaines de lignes relèvent du nettoyage. Plusieurs milliers signalent une source d'alimentation mal reliée, qui continue de produire des doublons à chaque exécution.

Trouver les actifs desabonnes ailleurs

Deuxième requête, les cas à risque : les abonnés encore actifs alors que la même adresse est désabonnée sous une autre clé. Ce sont eux qui déclenchent les réclamations.

SELECT
    actif.SubscriberKey,
    actif.EmailAddress,
    MAX(desab.DateUnsubscribed) AS DateDesabonnement
FROM _Subscribers AS actif
INNER JOIN _Subscribers AS desab
    ON  desab.EmailAddress  = actif.EmailAddress
    AND desab.SubscriberKey <> actif.SubscriberKey
WHERE actif.Status = 'active'
  AND desab.Status = 'unsubscribed'
GROUP BY actif.SubscriberKey, actif.EmailAddress

Le GROUP BY évite d'écrire deux fois la même clé active quand l'adresse a été désabonnée sous plusieurs autres clés, ce qui ferait échouer l'écriture dans une data extension dont SubscriberKey est la clé primaire.

Bloquer avant de corriger

La correction de fond prend des semaines. En attendant, un script d'exclusion empêche les envois vers ces adresses. C'est une expression AMPscript évaluée pour chaque destinataire au moment de l'envoi : si elle renvoie vrai, le destinataire est écarté.

RowCount(LookupRows("Desabonnes_Autre_Cle", "EmailAddress", emailaddr)) > 0

Ce que couvre le script d'exclusion

Le test porte sur l'adresse et non sur la clé, pour couvrir tous les doublons d'un coup. LookupRows ne tient pas compte de la casse, ce qui évite de laisser passer une adresse saisie avec des majuscules. Salesforce prévient en revanche qu'un script d'exclusion complexe ou appliqué à une grande table ralentit l'envoi : sur un gros volume, mieux vaut filtrer l'audience avant son entrée dans le parcours.

Corriger à la source

Tant que l'alimentation reste reliée par l'email, les doublons reviennent. Trois étapes, dans cet ordre :

1. enrichir le fichier source avec l'identifiant client, ou le retrouver par une requête de rapprochement avant l'envoi ;
2. relier la data extension d'envoi aux abonnés par ce champ, jamais par l'adresse ;
3. appliquer le désabonnement à toutes les clés d'une même adresse, puis supprimer les contacts créés en double avec le processus de suppression de contacts.

Choisir la bonne clé dès le départ

Salesforce déconseille l'adresse email comme Subscriber Key. Une bonne clé est unique, stable dans le temps, indépendante du canal et partagée avec vos autres systèmes. En pratique, c'est l'identifiant client de votre système maître, ou l'identifiant du Contact ou du Lead quand Marketing Cloud Connect est en place. La Contact Key doit porter la même valeur.

Changer de Subscriber Key apres coup

Changer de clé après coup n'est pas une opération de maintenance : Salesforce indique qu'une migration se prépare avec votre interlocuteur commercial et peut immobiliser les envois et les imports plusieurs jours. Autant la choisir correctement avant la première alimentation.

Si vous venez d'Adobe Campaign

Dans Adobe Campaign, la clé technique d'un destinataire est générée par la base, et la réconciliation se fait avec les clés que vous choisissez à chaque import. Dans Marketing Cloud, la Subscriber Key joue les deux rôles à la fois : c'est vous qui la fournissez, et elle ne se corrige pas facilement.

Le mécanisme du désabonnement est en revanche familier : une liste noire posée sur une fiche destinataire ne protège pas une seconde fiche portant la même adresse. La différence tient à la déduplication, que Campaign peut appliquer sur l'adresse au moment de préparer une diffusion, alors que Marketing Cloud s'appuie sur la clé.

Le réflexe à garder

Avant de chercher un bug dans un parcours ou dans un lien de désabonnement, lancez la première requête. Si NbCles dépasse 1 sur des milliers d'adresses, le problème n'est pas dans l'envoi : il est dans le modèle de données, et aucun réglage d'interface ne le corrigera.

Questions fréquentes