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 logs d'envoi. Un enregistrement par destinataire par diffusion. Contient le statut de chaque envoi : envoyé, raté, mis en quarantaine, rebond.
Les logs de tracking. Enregistre les ouvertures, clics, désabonnements et interactions web de chaque destinataire.
Le journal d'audit. Trace toutes les modifications effectuées sur la plateforme : qui a fait quoi et quand. Indispensable pour la gouvernance.
Les logs de workflow. Enregistre l'exécution de chaque activité, les erreurs rencontrées et les transitions entre activités.
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.
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 SMTPtsLastModified — date de dernière mise à jour du statutiMsgId — identifiant unique du message, clé de jointure avec trackingLogiDeliveryId — identifiant de la diffusion parenteC'est la nuance que beaucoup de développeurs Campaign ignorent. Voici ce qui se passe réellement lors d'un envoi :
250 (accepté), 550 (refus définitif), 421 / 450 (refus temporaire)broadLogRcp en conséquence — c'est tout ce qu'il reçoitCe 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é :
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.
💡 Réflexe diagnostic : si iStatus = 4 (raté) et iErrorCode = 0 dans broadLogRcp, consultez les journaux MTA — Campaign n'a pas réussi à interpréter la réponse SMTP du FAI. Pour les problèmes de délivrabilité post-acceptation (email en spam malgré un 250), les outils spécialisés comme Postmaster Tools (Gmail) ou SNDS (Microsoft) donnent une vue côté FAI.
⚠️ Point de vigilance : en V8 avec FFDA, broadLogRcp est stockée dans Snowflake. Les requêtes directes sur cette table depuis Campaign peuvent être lentes sur de gros volumes. Privilégiez les cubes et rapports natifs pour l'analyse, et les activités de requête FDA pour les traitements batch.
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é.
iUrlId — identifiant de l'URL cliquée, jointure avec trackingUrl pour récupérer l'URL réelleiLogType — type d'interaction : 1 (ouverture), 2 (clic), 3 (désabonnement), 6 (page miroir)tsLogDate — date et heure de l'interaction, en UTCiMsgId — clé de jointure avec broadLogRcpuserAgent — chaîne User-Agent du navigateur ou client email au moment de l'interactionsSourceIp — adresse IP source de l'interaction (utile pour détecter les bots)iRecipientId — identifiant du destinataire, clé de jointure avec nmsRecipientPlusieurs limitations importantes à connaître pour interpréter correctement les données de tracking :
⚠️ Interprétation : les métriques de tracking Campaign sont des indicateurs, pas des mesures exactes. Sur un volume important, les tendances sont fiables — mais les chiffres absolus (taux d'ouverture surtout) doivent être interprétés avec recul, particulièrement sur des bases avec une forte proportion d'utilisateurs Apple.
💡 Bonne pratique : les ouvertures email sont de moins en moins fiables depuis iOS 15 (Apple Mail Privacy Protection précharge les pixels de tracking). Pour mesurer l'engagement réel, privilégiez les clics plutôt que les ouvertures dans vos analyses.
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.
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.
💡 Usage clé : quand un workflow s'arrête de fonctionner sans raison apparente, l'audit trail est souvent le premier endroit à consulter — quelqu'un a peut-être modifié un schéma ou une option sans le signaler.
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.
| Log | Quoi | Volume | Rétention | Usage principal |
|---|---|---|---|---|
broadLogRcp | Statuts d'envoi | Très élevé | Configurable | Délivrabilité, quarantaines |
trackingLog | Ouvertures / clics | Élevé | Configurable | Engagement, segmentation |
auditTrail | Actions plateforme | Faible | Long terme | Gouvernance, debug |
wfLog | Exécution workflows | Moyen | Court terme | Debug, optimisation |
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.
broadLogRcp sans vérifier les dépendances avec trackingLog — la cohérence référentielle peut être impactée.⚠️ Attention RGPD : les logs contiennent des données personnelles (adresses email, comportements de navigation). Leur durée de rétention doit être définie dans votre politique de données et alignée avec votre registre des traitements.
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.
Adobe Campaign Classic generates a significant volume of logs for every operation — delivery send, user action, workflow execution. These logs are the platform's memory. Knowing how to distinguish, read and use them is a key skill for any ACC developer or administrator.
Here's a comprehensive overview of the main log types, their differences and how to use them effectively.
Delivery logs. One record per recipient per delivery. Contains the status of each send: sent, failed, quarantined, bounced.
Tracking logs. Records opens, clicks, unsubscribes and web interactions for each recipient.
Audit journal. Tracks all modifications made on the platform: who did what and when. Essential for governance.
Workflow logs. Records the execution of each activity, errors encountered and transitions between activities.
This is the highest-volume table on a mature Campaign instance. It contains one record for every message sent to every recipient. On an active platform, it can reach several hundred million rows.
The table gives a complete view of each send status — but only from Campaign's perspective. Here's what it actually contains:
iStatus — send attempt status: 0 (pending), 1 (sent by Campaign), 2 (ignored), 4 (failed), 6 (quarantined)iErrorCode — error code on failure. Codes 1–9 correspond to known bounce types (full mailbox, unknown domain, invalid address…)iErrorType — error category: 1 (unknown), 2 (undelivered), 3 (unreachable), 4 (unwanted), 5 (refused), 6 (ignored)sFailed — the error label returned by the remote server, often extracted from the SMTP responsetsLastModified — date of last status updateiMsgId — unique message identifier, join key with trackingLogiDeliveryId — identifier of the parent deliveryThis is the nuance many Campaign developers miss. Here's what actually happens during a send:
250 (accepted), 550 (permanent refusal), 421 / 450 (temporary refusal)broadLogRcp accordingly — that's all it receivesWhat Campaign will never see is what happens after acceptance on the ISP side. A 250 code means the ISP accepted the message — not that it was delivered to the inbox. After acceptance, the ISP handles on its own:
This information belongs to the ISP — it never flows back to Campaign. This is why a 100% delivery rate in Campaign does not guarantee that 100% of emails reached the inbox.
Campaign MTA journals (accessible depending on hosting via Supervision → Messages in progress) contain the SMTP dialogue with ISP response codes and verbose messages — useful for diagnosing refusals. But they remain limited to Campaign's view: what happens after acceptance is opaque.
💡 Diagnostic reflex: if iStatus = 4 (failed) and iErrorCode = 0 in broadLogRcp, check the MTA journals — Campaign failed to interpret the ISP's SMTP response. For post-acceptance deliverability issues (email landing in spam despite a 250), specialist tools like Postmaster Tools (Gmail) or SNDS (Microsoft) provide an ISP-side view.
⚠️ Watch point: in V8 with FFDA, broadLogRcp is stored in Snowflake. Direct queries on this table from Campaign can be slow on large volumes. Prefer native cubes and reports for analysis, and FDA query activities for batch processing.
Tracking logs record all recipient interactions with the message after receipt. They are populated by Campaign's tracking server (or Redirect) on every email open or click on a tracked link.
iUrlId — identifier of the clicked URL, join with trackingUrl to retrieve the actual URLiLogType — interaction type: 1 (open), 2 (click), 3 (unsubscribe), 6 (mirror page)tsLogDate — date and time of the interaction, in UTCiMsgId — join key with broadLogRcpuserAgent — User-Agent string of the browser or email client at interaction timesSourceIp — source IP address of the interaction (useful for detecting bots)iRecipientId — recipient identifier, join key with nmsRecipientSeveral important limitations to know for correctly interpreting tracking data:
⚠️ Interpretation: Campaign tracking metrics are indicators, not exact measurements. On large volumes, trends are reliable — but absolute figures (open rate especially) should be interpreted with perspective, particularly on databases with a high proportion of Apple users.
💡 Best practice: email opens are increasingly unreliable since iOS 15 (Apple Mail Privacy Protection pre-loads tracking pixels). To measure real engagement, prioritise clicks over opens in your analyses.
The audit trail is often overlooked on Campaign projects, but is essential on multi-user or regulated environments. It tracks every modification made on the platform: creation, modification, deletion of Campaign objects (schemas, workflows, deliveries, typologies…) and operator actions.
In the Campaign Classic interface: Administration → Audit Trail. Filter by object type, operator, date and action. On V8 instances, the audit trail is accessible via the same paths but stored differently.
💡 Key use: when a workflow stops working for no apparent reason, the audit trail is often the first place to look — someone may have modified a schema or option without flagging it.
Workflow logs are accessible directly from the Campaign interface, in the execution journal of each workflow. They track the execution of each activity, transitions taken and errors encountered.
| Log | What | Volume | Retention | Main use |
|---|---|---|---|---|
broadLogRcp | Send statuses | Very high | Configurable | Deliverability, quarantines |
trackingLog | Opens / clicks | High | Configurable | Engagement, segmentation |
auditTrail | Platform actions | Low | Long term | Governance, debug |
wfLog | Workflow execution | Medium | Short term | Debug, optimisation |
Log retention is a commonly underestimated topic. On a Campaign instance without a purge policy, broadLogRcp and trackingLog can saturate the database within months on high-volume platforms.
broadLogRcp without checking dependencies with trackingLog — referential integrity can be affected.⚠️ GDPR note: logs contain personal data (email addresses, browsing behaviour). Their retention period must be defined in your data policy and aligned with your processing register.
Adobe Campaign logs are far more than a debugging tool — they are the source of truth for everything happening on the platform. Mastering their differences, knowing where to look and how to query them is a skill that saves considerable time on every Campaign project. A good habit to adopt: before investigating an anomaly in code or configuration, always check the logs first.
Je peux vous accompagner sur le diagnostic, l'optimisation et la montée en compétences de vos équipes. Réponse sous 24h.I can support you on diagnostics, optimisation and team upskilling. Reply within 24 hours.
Parlons de votre projet →Let's talk →