Adobe Campaign Classic: understanding and using logs

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.

The 4 log families in ACC

broadLogRcp : delivery logs

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.

What you see in broadLogRcp

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 response
• tsLastModified : date of last status update
• iMsgId : unique message identifier, join key with trackingLog
• iDeliveryId : identifier of the parent delivery

What you do NOT see in broadLogRcp : the SMTP dialogue limit

This is the nuance many Campaign developers miss. Here's what actually happens during a send:

• Campaign's MTA dialogues with the ISP's inbound server (Gmail, Outlook, Orange…) via the SMTP protocol
• The ISP returns a response code at connection: 250 (accepted), 550 (permanent refusal), 421 / 450 (temporary refusal)
• Campaign interprets this code and updates broadLogRcp accordingly, that's all it receives

What 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:

• Internal spam filtering (SpamAssassin, proprietary filters…)
• The decision to deliver to inbox, spam folder, or silently discard
• Its own queue and internal distribution delays

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.

Common use cases

• Analyse the error rate of a delivery by bounce type
• Identify quarantined recipients and understand why
• Replay failed sends after fixing a technical issue
• Audit deliverability performance over a given period

trackingLog : tracking logs

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.

What you see in trackingLog

• iUrlId : identifier of the clicked URL, join with trackingUrl to retrieve the actual URL
• iLogType : interaction type: 1 (open), 2 (click), 3 (unsubscribe), 6 (mirror page)
• tsLogDate : date and time of the interaction, in UTC
• iMsgId : join key with broadLogRcp
• userAgent : User-Agent string of the browser or email client at interaction time
• sSourceIp : source IP address of the interaction (useful for detecting bots)
• iRecipientId : recipient identifier, join key with nmsRecipient

What you do NOT see in trackingLog

Several important limitations to know for correctly interpreting tracking data:

• Opens are not reliable. Since iOS 15, Apple Mail Privacy Protection pre-downloads the tracking pixel for all emails, whether the user opens them or not. An open recorded from an Apple device does not necessarily mean the email was read.
• Security bots generate phantom clicks. Many spam filters and enterprise security tools (Barracuda, Proofpoint, Mimecast…) automatically click all links in an email to verify they are not malicious. These clicks appear in trackingLog as real clicks.
• No scroll or reading time data. trackingLog does not say whether the email was read for 2 seconds or 2 minutes, only whether the pixel was loaded or a link clicked.
• No tracking on image-disabled email clients. If the recipient has disabled automatic image loading and clicks no link, no entry will be created in trackingLog, even if the email was read.

Common use cases

• Calculate real open and click rates for a campaign
• Identify the most clicked links in an email
• Build behavioural segments (clicked X but didn't open Y)
• Analyse open times to optimise send scheduling

auditTrail : the audit log

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.

What it tracks

• Data schema modifications (field additions/removals)
• Workflow creation or modification
• Changes to platform options and settings
• Operator actions: logins, permission changes
• Modifications to deliveries and templates

How to access it

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.

wfLog / wfTask : workflow logs

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 levels

• Verbose, everything is logged, including transitions and sub-activities. Useful for debugging, costly in volume.
• Warning, only warnings and errors. Recommended default in production.
• Error, only blocking errors.

Common use cases

• Diagnose why a workflow paused or errored
• Check the number of rows processed at each step
• Measure execution time per activity to optimise performance
• Trace transitions to understand the data path taken

Summary comparison

Retention management

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.

• The Database cleanup technical workflow manages automatic purging. Verify it runs correctly and configure retention durations according to your GDPR requirements.
• In V8 FFDA, tables are in Snowflake, purging remains important but storage cost is different.
• Never manually delete rows from broadLogRcp without checking dependencies with trackingLog : referential integrity can be affected.

Conclusion

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.