Delivery Configuration and Execution
Delivery configuration and execution
A delivery is created from a delivery template, which supplies the mapping, target schema, content structure, routing, typology, and default options. The delivery mapping is especially important: it determines the target schema and the fields available for personalization. Routing selects the external account that actually sends the message, such as a mid-sourcing or message-center account. Typology rules are applied during analysis and preparation, producing the final target and exclusion logs.
The delivery lifecycle runs through targeting, analysis, preparation, approval where configured, sending, and tracking. Proofs use test profiles and do not consume the target population. Seed addresses are added for rendering and delivery checks. The broadlog records sends, while exclusion logs explain why a recipient was removed. Batch versus continuous mode, scheduling, and wave periods change when and how often the delivery executes.
Traps and rule of thumb
Changing a template after creating a delivery does not necessarily change the existing delivery. A proof is not a small send to the target. Control groups are excluded from the send by design. Approval must be granted before the send proceeds when the typology requires it.
Worked example: for a weekly newsletter, create a recurring delivery from a template with a recurring scheduler, set the target mapping, attach a filtering typology rule for quarantined addresses, and require approval. Rule: validate mapping, routing, typology, and approval before debugging content.