Channel Configuration and Message Delivery
Core mental model
Channels are configured through surfaces (channel configurations): email, push, SMS, and in-app. Each surface defines the sending infrastructure (e.g., email subdomain/IP pool, push app credentials, SMS provider), and journeys/actions reference a surface plus a message preset and content template.
Concepts candidates must know
- Email: subdomain delegation, IP pools, sender/reply-to, message presets, dynamic content, personalization via Handlebars expressions, tracking (opens/clicks), and suppression/list-unsubscribe handling.
- Push: app platform credentials (APNs/FCM), platform-specific payload, and device token registration.
- SMS: provider configuration, opt-in/opt-out keywords, and message length/encoding.
- In-app: surface configuration and trigger rules.
- Delivery: throttling, send-time optimization, and frequency capping rules; message feedback events feed journey reactions.
Traps
- Confusing a channel configuration (surface) with a message preset - the surface is infrastructure; the preset is reusable send settings.
- Personalization errors: incorrect Handlebars syntax or referencing a field not present in the journey schema.
- Assuming a delivered event means the message reached the inbox - delivered ≠ opened; bounces and failures are separate feedback events.
Worked rule of thumb
When a send fails, check in order: (1) surface/channel configuration is valid and published, (2) the action references the correct preset, (3) the profile has the required identity/contact (email address, push token, phone), (4) personalization fields resolve against the journey schema. Treat "delivered," "bounced," "failed," and "opened" as distinct events.