Delivery Configuration and Personalization
Delivery configuration
A delivery inherits from a template, which fixes the target mapping, routing or external account, typology and content defaults. Properties control typology rules (pressure, contact fatigue, control group), seed addresses for proofs, wave scheduling, retry and IP affinity. Personalization uses the delivery context: recipient.firstName or @firstName depending on context, with <%= %> to output and <% %> for logic. Dynamic content and conditional blocks let one delivery carry variants; the mirror page and unsubscribe link are generated from the template.
Traps
Questions often swap proof and preview: preview renders with sample data, proofs actually send through the routing. Personalizing the subject line requires encoding and a fallback for empty values. targetData is needed in recurring or transactional contexts where the recipient is not the main target. Typology rules can exclude a recipient silently, so a missing send may be a pressure rule, not a delivery failure. Changing a template after a delivery is created does not retroactively change that delivery.
Rule of thumb
Always test with a seed address that exercises the worst case: missing first name, non-Latin characters, and an unsubscribe link. Keep business rules in typologies, not in JavaScript blocks.
Worked example: Hello <%= recipient.firstName != "" ? recipient.firstName : "customer" %> avoids a blank greeting. For an offer block, wrap conditional content in <% if (recipient.loyaltyTier == 2) { %> ... <% } %> and always provide a default branch.