Adobe Campaign Classic : comprendre et exploiter les logs

Adobe Campaign Classic génère une quantité importante de logs à chaque opération, envoi de diffusion, action utilisateur, exécution de workflow. Ces logs sont la mémoire de la plateforme. Savoir les distinguer, les lire et les exploiter est une compétence clé pour tout développeur ou administrateur ACC.

Voici un tour d'horizon complet des principaux types de logs, leurs différences et comment les utiliser efficacement.

Les 4 familles de logs dans ACC

broadLogRcp : les logs d'envoi

C'est la table la plus volumineuse d'une instance Campaign mature. Elle contient un enregistrement pour chaque message envoyé à chaque destinataire. Sur une plateforme active, elle peut atteindre plusieurs centaines de millions de lignes.

Ce qu'on voit dans broadLogRcp

La table donne une vue complète du statut de chaque envoi, mais uniquement du point de vue de Campaign. Voici ce qu'elle contient réellement :

• iStatus : statut de la tentative d'envoi : 0 (en attente), 1 (envoyé par Campaign), 2 (ignoré), 4 (raté), 6 (mis en quarantaine)
• iErrorCode : code d'erreur en cas d'échec. Les codes 1–9 correspondent à des types de bounce connus (boîte pleine, domaine inconnu, adresse invalide…)
• iErrorType : catégorie d'erreur : 1 (inconnu), 2 (non délivré), 3 (non joignable), 4 (indésirable), 5 (refusé), 6 (ignoré)
• sFailed : le libellé de l'erreur retournée par le serveur distant, souvent extrait de la réponse SMTP
• tsLastModified : date de dernière mise à jour du statut
• iMsgId : identifiant unique du message, clé de jointure avec trackingLog
• iDeliveryId : identifiant de la diffusion parente

Ce qu'on ne voit PAS dans broadLogRcp : la limite du dialogue SMTP

C'est la nuance que beaucoup de développeurs Campaign ignorent. Voici ce qui se passe réellement lors d'un envoi :

• Le MTA de Campaign dialogue avec le serveur entrant du FAI destinataire (Orange, Gmail, Outlook…) via le protocole SMTP
• Le FAI retourne un code de réponse à la connexion : 250 (accepté), 550 (refus définitif), 421 / 450 (refus temporaire)
• Campaign interprète ce code et met à jour broadLogRcp en conséquence, c'est tout ce qu'il reçoit

Ce que Campaign ne verra jamais, c'est ce qui se passe après l'acceptation côté FAI. Un code 250 signifie que le FAI a accepté le message, pas qu'il l'a délivré en boîte de réception. Après acceptation, le FAI gère de son côté :

• Le filtrage antispam interne (SpamAssassin, filtres propriétaires…)
• La décision de délivrer en boîte de réception, en spam ou de supprimer silencieusement
• Sa propre file d'attente et ses délais de distribution interne

Ces informations appartiennent au FAI, elles ne remontent jamais vers Campaign. C'est pourquoi un taux de délivrance de 100% dans Campaign ne garantit pas que 100% des emails sont arrivés en boîte de réception.

Les journaux MTA Campaign (accessibles selon l'hébergement via Supervision → Messages en cours) contiennent le dialogue SMTP avec les codes de réponse FAI et les messages verbeux, utiles pour diagnostiquer les refus. Mais ils restent limités à la vue Campaign : ce qui se passe après l'acceptation reste opaque.

Cas d'usage courants

• Analyser le taux d'erreur d'une diffusion par type de rebond
• Identifier les destinataires en quarantaine et comprendre pourquoi
• Rejouer les envois échoués après correction d'un problème technique
• Auditer les performances de délivrabilité sur une période donnée

trackingLog : les logs de tracking

Les logs de tracking enregistrent toutes les interactions du destinataire avec le message après réception. Ils sont alimentés par le serveur de tracking Campaign (ou Redirect) à chaque ouverture d'email ou clic sur un lien tracké.

Ce qu'on voit dans trackingLog

• iUrlId : identifiant de l'URL cliquée, jointure avec trackingUrl pour récupérer l'URL réelle
• iLogType : type d'interaction : 1 (ouverture), 2 (clic), 3 (désabonnement), 6 (page miroir)
• tsLogDate : date et heure de l'interaction, en UTC
• iMsgId : clé de jointure avec broadLogRcp
• userAgent : chaîne User-Agent du navigateur ou client email au moment de l'interaction
• sSourceIp : adresse IP source de l'interaction (utile pour détecter les bots)
• iRecipientId : identifiant du destinataire, clé de jointure avec nmsRecipient

Ce qu'on ne voit PAS dans trackingLog

Plusieurs limitations importantes à connaître pour interpréter correctement les données de tracking :

• Les ouvertures ne sont pas fiables. Depuis iOS 15, Apple Mail Privacy Protection pré-télécharge le pixel de tracking de tous les emails, que l'utilisateur les ouvre ou non. Une ouverture enregistrée depuis un appareil Apple ne signifie donc pas forcément que l'email a été lu.
• Les bots de sécurité génèrent des clics fantômes. De nombreux filtres antispam et outils de sécurité d'entreprise (Barracuda, Proofpoint, Mimecast…) cliquent automatiquement sur tous les liens d'un email pour vérifier qu'ils ne sont pas malveillants. Ces clics remontent dans trackingLog comme des clics réels.
• Pas de données de scroll ou de temps de lecture. trackingLog ne dit pas si l'email a été lu 2 secondes ou 2 minutes, uniquement si le pixel a été chargé ou un lien cliqué.
• Pas de tracking sur les clients email sans images. Si le destinataire a désactivé le chargement automatique des images et ne clique sur aucun lien, aucune entrée ne sera créée dans trackingLog, même si l'email a été lu.

Cas d'usage courants

• Calculer les taux d'ouverture et de clic réels d'une campagne
• Identifier les liens les plus cliqués dans un email
• Construire des segments comportementaux (a cliqué sur X mais pas ouvert Y)
• Analyser les horaires d'ouverture pour optimiser les envois

auditTrail : le journal d'audit

L'audit trail est souvent négligé sur les projets Campaign, mais il est indispensable sur des environnements multi-utilisateurs ou réglementés. Il trace chaque modification effectuée sur la plateforme : création, modification, suppression d'objets Campaign (schémas, workflows, diffusions, typologies…) et actions des opérateurs.

Ce qu'il trace

• Modifications de schémas de données (ajout/suppression de champs)
• Création ou modification de workflows
• Changements sur les options et paramètres de la plateforme
• Actions des opérateurs : connexions, modifications de droits
• Modifications sur les diffusions et templates

Comment y accéder

Dans l'interface Campaign Classic : Administration → Audit Trail. Il est possible de filtrer par type d'objet, opérateur, date et action. Sur des instances V8, l'audit trail est accessible via les mêmes chemins mais stocké différemment.

wfLog / wfTask : les logs de workflow

Les logs de workflow sont accessibles directement depuis l'interface Campaign, dans le journal d'exécution de chaque workflow. Ils tracent l'exécution de chaque activité, les transitions empruntées et les erreurs rencontrées.

Les niveaux de log

• Verbose, tout est tracé, y compris les transitions et sous-activités. Utile pour le debug, coûteux en volume.
• Warning, uniquement les avertissements et erreurs. Mode par défaut recommandé en production.
• Error, uniquement les erreurs bloquantes.

Cas d'usage courants

• Diagnostiquer pourquoi un workflow s'est mis en pause ou en erreur
• Vérifier le nombre de lignes traitées à chaque étape
• Mesurer le temps d'exécution de chaque activité pour optimiser les performances
• Tracer les transitions pour comprendre le chemin emprunté par les données

Tableau comparatif

Gestion de la rétention

La rétention des logs est un sujet souvent sous-estimé. Sur une instance Campaign sans politique de purge, broadLogRcp et trackingLog peuvent saturer la base de données en quelques mois sur une forte volumétrie.

• Le workflow technique Nettoyage de la base (Database cleanup) gère la purge automatique. Vérifiez qu'il s'exécute bien et configurez les durées de rétention selon vos besoins RGPD.
• En V8 FFDA, les tables sont dans Snowflake, la purge reste importante mais le coût de stockage est différent.
• Ne supprimez jamais manuellement des lignes dans broadLogRcp sans vérifier les dépendances avec trackingLog : la cohérence référentielle peut être impactée.

Conclusion

Les logs Adobe Campaign sont bien plus qu'un outil de debug, ils sont la source de vérité sur tout ce qui se passe sur la plateforme. Maîtriser leurs différences, savoir où chercher et comment les interroger est une compétence qui fait gagner un temps considérable sur chaque projet Campaign. Un bon réflexe à adopter : avant de chercher une anomalie dans le code ou la configuration, consultez toujours les logs en premier.