5.1 The Email Designer & Multi-Channel Canvas Structure
Key Takeaways
Email authoring combines a channel configuration, required headers, body content, links, tracking choices, and responsive preview.
Email, push, and SMS use different address data, content fields, provider configuration, and proof workflows.
SMS length depends on encoding: GSM-7 supports 160 characters in one message and Unicode reduces a single message to 70 characters.
Consent, subscription, suppression, and provider keyword handling must be configured and verified; do not assume a universal transport behavior.
Preview, test-profile proofing, accessibility, link checks, and fallback testing are required before publication.
5.1 Email Designer and Multi-Channel Authoring
Journey Optimizer offers a shared content workflow, but each channel has its own payload, addressing, provider, and rendering constraints. The exam tests whether a practitioner selects the right authoring surface and verifies the fields that matter.
Email structure
An email action uses a channel configuration that controls sender and delivery settings. The author supplies required message properties such as subject and body, and may configure preheader, reply-to, tracking, and unsubscribe behavior according to the organization's setup.
The Email Designer supports drag-and-drop structures and components: text, image, button, divider, social links, and multi-column layouts. Responsive behavior should be previewed rather than assumed. Columns may stack or resize on small screens, images need appropriate alternative text, and long personalized values can disrupt a layout that looked correct with sample text.
A safe email checklist includes:
- recognizable sender and reply handling;
- meaningful subject and preheader;
- valid required postal and unsubscribe elements;
- text hierarchy and accessible contrast;
- image alternative text;
- link destination and tracking review;
- personalization fallback;
- desktop and mobile preview;
- test delivery to representative clients.
Uploading HTML is useful when approved content was authored elsewhere, but the imported document still needs validation in Journey Optimizer. External CSS, unsupported elements, and missing tracking or unsubscribe requirements can behave differently after import.
Push
Push requires a configured mobile application and valid push tokens. iOS delivery uses APNs and Android delivery uses the configured Android push service. The message typically includes a title and body, with optional media, deep link, action, badge, sound, or custom data depending on channel and app implementation.
A push author cannot assume the app handles every custom field. The mobile application must implement the deep-link route and custom-data behavior. Test a current app build on actual supported devices, including permission denied, stale token, and missing deep-link destination cases.
Push permission is managed at the operating-system/app level. Audience membership does not override device permission or token validity.
SMS
SMS uses a configured provider/channel setup and an address in the expected format. Content is plain text with optional personalization and supported links.
Encoding affects billing and readability:
- A GSM-7 message supports up to 160 characters as one SMS.
- A message containing a character outside the GSM-7 set uses Unicode/UCS-2 and supports only 70 characters as one SMS.
- Longer messages are segmented; concatenation metadata reduces the characters available in each part.
An emoji can therefore change a short GSM message into Unicode and create multiple billed segments. Use the authoring counter and provider result rather than counting by eye.
Consent and opt-out handling depend on Journey Optimizer configuration, subscription and consent data, the selected provider, and applicable requirements. Providers commonly support keywords such as STOP, but do not claim that every reply universally writes the same suppression object without verifying the implementation. Test opt-out, help, and resubscription workflows end to end.
Match content to channel
| Channel | Address | Main content risk | Required proof |
|---|---|---|---|
| Email address | Client rendering, links, required elements, fallback | Desktop/mobile preview and inbox tests | |
| Push | App push token | Permission, token, app route, truncation | Real devices and current app build |
| SMS | Phone number | Encoding, segments, provider and opt-out behavior | Provider test numbers and keyword workflow |
A design that works in email should not simply be pasted into SMS. Adapt the call to action, length, destination, and accessibility to each channel.
Personalization and fallback
Insert profile or context data with the supported personalization editor. Optional fields need a safe fallback or condition. A blank first name is visually awkward; a missing URL can make a button unsafe. Preview with complete, missing, long, and non-Latin values.
Never place sensitive data in a subject line, lock-screen push, or SMS merely because the field is available. Apply labels, policy, consent, and channel-specific privacy review.
Operational readiness
Before publication, verify channel configurations are active, sender identities and domains are approved, provider credentials are healthy, and volume fits throughput. Use seed or test lists for proofs. Confirm suppression/allow-list behavior and distinguish a proof from production delivery.
Warning
Journey authoring does not guarantee telecom or app behavior. The provider configuration, device permission, app implementation, consent model, and message encoding remain part of the end-to-end design.
Deliverability is separate
Correct content does not guarantee inbox or device delivery. Domain reputation, warming, authentication, provider acceptance, token health, and carrier filtering sit outside the visual message. Review delivery metrics and provider responses after proofs. A rendering defect, a suppression, and a provider rejection require different remedies even when all three appear to the marketer as “no message.”
A 60-character SMS gains an emoji and the authoring counter shows Unicode. What is the important effect?
The single-message limit drops from the GSM-7 limit to the Unicode limit of 70 characters.
It becomes email HTML.
The phone number is removed.
Journey Optimizer converts the emoji to a push token.
What must be true for a push deep link to work?
Every profile must have an email address.
The mobile app must implement and test the destination route.
The message must be exactly 160 characters.
A content fragment must be detached.
Which is the best multichannel practice?
Copy identical email HTML into SMS.
Assume provider opt-out behavior is identical everywhere.
Proof each channel with its real configuration, address type, rendering, and consent path.
Skip fallback testing if the audience is large.
Sections you finish are checked off in the contents.