Campaign Standard: sending logs mismatch in Profile
In rare cases, Campaign Standard can display sending-log entries in a profile that do not actually belong to that profile. This can create the impression that deliveries or email events were incorrectly associated with a recipient, even though the underlying database records are not corrupted. The issue is typically limited to UI/query behavior when a recipient profile and a test profile happen to share the same internal identifier value in their respective source tables.
Description description
A customer reported that the Sending logs view for a real recipient profile showed email events that belonged to a separate test profile. Some of the displayed events predated the creation of the real profile, which made it clear the records could not legitimately belong to that recipient.
Investigation showed:
- The real profile and the test profile were separate entities and were not functionally linked.
- The real recipient was not actually targeted in the affected deliveries where the unexpected log entries appeared.
- Tracking data remained consistent for the real recipient.
- The unexpected behavior was observed primarily in the Sending logs view and in query preview behavior, not as evidence of broad database contamination.
- This created confusion for the customer because the UI suggested inaccurate delivery history and raised concern that reporting and audience analysis could be affected.
Resolution resolution
Root Cause
The issue was caused by a rare internal ID collision between:
- a recipient profile stored in the profiles/recipients data set, and
- a test profile stored in the seed-member data set.
Both profile types write log data into the broadLogRcp table, which stores the related profile or test-profile identifier in the same profileId column. When the recipient and the test profile happened to have the same internal ID value, queries against sending logs returned entries for both entities.
Why this happened:
- New recipient profiles obtain IDs from the nmsRecipientId sequence.
- Test profiles obtain IDs from the xtkNewId sequence.
- In this case, the recipient was created at a moment when its generated ID happened to match an already existing test-profile ID.
- As a result, the UI and related query paths retrieved all sending-log rows matching that internal ID. Because the displayed email address in the UI is taken from the sending-log address field, users could see the test-profile email in the recipient’s sending-log history even though the underlying recipient data itself was not mixed or corrupted.
Engineering assessed this as a low-probability edge case rather than an issue likely to recur broadly.
Resolution
Recommended resolution options were:
- Delete and recreate the affected test profile. This is considered the cleaner corrective action because the recreated test profile receives a new internal ID. Future deliveries to that test profile will no longer appear under the real recipient’s sending logs.
- Manually clean up historical sending-log rows if required. If historical log visibility is a concern, old rows tied to the obsolete test-profile address can be removed manually. This is only needed if you wants to eliminate the already-written mismatched history before normal retention removes it.