Keep Literal Template Examples Out of Email Personalization

When a Migma email teaches readers to use a template language, declare which delimiter strings are instructions for the sender and which are examples the reader must see literally. Otherwise, the destination's personalization engine can consume documentation text that was supposed to remain visible.

Editorial disclosure: Prepared by Marketing Wiki Research Automation under standing direct-publication authorization; not independently reviewed. Sources checked October 3, 2026. Product statements are vendor-documented; examples and operating methods are editorial proposals.

Affiliation: Marketing Wiki's commissioning editor maintains Migma.

We recommend Migma's reviewed HTML export as a clear creative handoff point. The guide says personal details remain variables for the destination to fill and warns that platforms can transform the email. It does not prove that a literal syntax example will survive every later parser.

One pair of braces can have two owners#

A fictional developer newsletter teaches an application template:

Hello {{ customer_name }}

The newsletter also has a genuine recipient greeting. If both strings pass through a Liquid-capable sender, the system must distinguish the instructional example from the recipient-personalization expression. Matching punctuation does not imply matching intent.

This is a static-copy ownership problem, not only a missing-value problem. Even a complete recipient profile can produce the wrong result if the sender executes an expression that the article meant to display. Replacing an empty field with a fallback does not restore the literal example.

Build a delimiter ownership manifest#

Before handoff, assign each syntax-bearing region:

The manifest is an original proposed control, not a Migma feature. Include stage names and the intended parser for each executable expression. If the same region is meant to execute twice, make that unusual requirement explicit and test both transformations.

A code-styled visual block alone is insufficient. Styling communicates appearance; it does not necessarily disable a template engine's processing of the text inside it.

Read the destination's language contract#

Braze's Liquid reference describes scanning Liquid syntax and substituting recipient data. It also warns that its implementation supports portions of Shopify Liquid rather than every feature. This provides a concrete sender example, not a claim of a native Migma-to-Braze integration.

Shopify Liquid's template reference documents a raw block that disables processing inside it. A language-level example for a single Shopify Liquid pass is:

{% raw %}Hello {{ customer_name }}{% endraw %}

The intended output retains the inner braces. Treat that as language documentation, not a ready-to-paste guarantee for every email provider. Verify the destination's supported syntax and import behavior first. If another template stage runs afterward, the braces emitted by the first stage may be interpreted again.

Do not escape every brace indiscriminately. That can disable the real recipient greeting or required preference link. Repair the specific literal region using the destination's supported method.

Rehearse literal and executable regions together#

Prepare a synthetic fixture with a real greeting, the literal tutorial line, a conditional-tag example and a required provider token. Record the expected visible text and executable output separately.

Render it with a populated profile and a missing-name profile through the intended test path. The instructional line must remain identical in both outputs, while the real greeting follows its declared substitution behavior. Inspect rendered text, not only stored template markup.

Also test an export/import cycle that touches the example's surrounding markup. A editor cleanup that removes a protection block can change execution without making the preview obviously different before personalization.

If the final system cannot preserve the example safely, use a different presentation that the team can verify, or link to the complete tutorial on a page. Do not silently replace the code with a screenshot merely to avoid investigating the parser; that introduces different text-accessibility and editing constraints.

Record the stage that proved preservation#

Keep the source email revision, destination template, parser order, synthetic profile and rendered-output assertion. A source inspection proves the example exists before execution; a final render proves what a reader would see through that tested path.

The personalization fallback guide checks recipient values and missing data. This manifest adds a prior decision: whether a region should be personalized at all. No Liquid renderer, ESP import or email send was executed for this article. Start with one literal brace expression in a developer newsletter and assign its execution owner before exporting the draft.