Adobe Campaign Classic Business Practitioner Expert: The Personalization Block That Leaked the Wrong Name

The Personalization Block That Leaked the Wrong Name

A financial services firm sends a monthly newsletter to 900,000 subscribers. The delivery uses a shared template with a personalization block that greets the recipient by first name and references their 'account tier'. The tier is stored in a custom field cus:tier on the recipient, populated by an enrichment join to a cus:accounts table during the workflow. Last month, 3,000 recipients received a greeting addressed to a different person's first name, and some showed a tier belonging to another customer. The enrichment activity was recently moved in the workflow to run after the delivery preparation step, and an operator had edited the personalization block to use a targetData expression instead of the recipient field. Complaints included a regulator inquiry because tier data is considered sensitive.

1. Identify the root cause of the mismatched names and tiers, and explain the role of the enrichment ordering and the expression change.

Read the worked answer

Two changes compounded:

Enrichment moved after delivery preparation. Personalization fields must be resolved on the recipient/target before the delivery is prepared, because preparation is when Adobe Campaign renders and freezes each message's content against the target data. If the enrichment that populates cus:tier runs after preparation, the delivery renders with stale or absent tier values - and if the enrichment was also the source of the name mapping, the rendered content can reflect whatever the target row held at preparation time, which after a re-run or a shifted join can be a different row.
Expression changed to targetData. targetData refers to the delivery's target data set as resolved at preparation. If the personalization block references targetData.firstName/targetData.tier but the target was built or enriched inconsistently (e.g., a join that expanded or mis-ordered rows), the expression can resolve to a neighboring row's values. The recipient-field reference (recipient.firstName) is bound to the actual recipient and is far harder to misalign.

The mismatch is a data-binding and ordering defect, not a template typo. The regulator issue makes it a data-protection incident: sensitive tier data was disclosed to the wrong data subject.

2. Specify the corrected workflow ordering and personalization design, and describe the controls you would add before the next send.

Read the worked answer

Corrected design:

Ordering: enrichment and any tier joins must complete before the delivery activity and before preparation. Sequence: target the audience → enrich with tier → (optional) approval → delivery → preparation. Never enrich after preparation.
Binding: revert the personalization block to reference the recipient-level field (recipient.firstName, and the tier via the recipient custom field once enriched onto the recipient), not targetData, unless there is a deliberate, tested reason. If targetData is required, verify the target is one-row-per-recipient with no fan-out join.
Proofing: send a proof to an internal seed list and also render a sample of real records (a small controlled test delivery to internal addresses) to confirm name/tier alignment before the full send.

Controls before next send:

Add a validation/test step in the workflow that samples N recipients and checks that firstName and tier are non-null and consistent with the source account record.
Lock the personalization block and require change review; the operator edit that introduced targetData should have gone through approval.
Confirm the enrichment join produces exactly one row per recipient (dedupe or use a 1:1 join) - fan-out is the usual cause of cross-row leakage.
Document the incident and notify the data protection officer; the tier disclosure may trigger breach-assessment obligations depending on jurisdiction.