Connecting Email Templates to Neon Blue

Overview

Neon Blue processes structured fields, not flat images. To use a template with Neon Blue, it must contain dynamic variables that Neon Blue can fill during generation and experimentation. Once a template is set up, it becomes reusable across all future experiments.

If your emails are image-based: You must first convert them to standard email templates with structured dynamic fields before connecting to Neon Blue.

For dynamic hero images with text overlays, see [Creating Programmatic Templates (Figma)].

---

Making a Template Neon Blue-Ready

Step 1: Add the Render Hook

The render hook is a tag you add to your email template that tells it to fetch content from Neon Blue at send time. Without this, the template has no connection to Neon Blue — nothing else works until this is in place.

The exact syntax depends on your ESP:

• Braze: A Connected Content block added at the beginning of the template — see [Braze Experiments]

• Klaviyo: A Custom Action in your Flow — see [Klaviyo Flow Experiments]

Step 2: Make Fields Dynamic

Once the render hook is in place, replace the content you want Neon Blue to control with dynamic field references. These are placeholders your ESP resolves at render time using the content Neon Blue returns.

The dynamic fields you define dictate the schema — the set of variables Neon Blue generates or accepts for that template. For example, if you define fields for h1 and body, the schema will include those plus subject and preview (required for every email).

The field reference syntax is ESP-specific (see links above), but the variable naming and types are universal across all ESPs — covered below.

---

Variable Types

Plain Text

Simple string fields for headings, labels, and short copy.

h1
h2
body
cta_text

Images

Image variables must include img in the name. Each image is a grouped object:

Field	Required	Description
src	Yes	Image URL
alt	Yes	Alt text
href	No	Click-through URL

Example field names: block1_img, hero_img, section2_img

HTML

Use the _html suffix for fields that render raw HTML:

body_html
block1_html
section1_body_html

HTML renders exactly as provided — use this only when you need rich formatting (e.g., styled body copy with links).

CTAs

cta_text
cta_url

Static Content

Any content in the template without a dynamic field reference is static. Neon Blue ignores these elements — they remain constant across all variants.

---

Naming Conventions

Related fields should share prefixes so Neon Blue can group them logically during generation:

block1_title
block1_body
block1_img

block2_title
block2_body
block2_img

section1_heading
section1_body_html
section1_img

This naming pattern improves AI generation quality by making field relationships explicit.

---

Best Practices

• Include img in image variable names so the editor recognizes them as image slots.

• Use _html suffix only when raw HTML is necessary.

• Maintain consistent naming across templates for reusability.

• Convert image-heavy emails into standard templates before connecting to Neon Blue.

• For text overlaid on images, use a programmatic template (see [Creating Programmatic Templates (Figma)]) and verify in Figma.

• Avoid rigid line breaks, insufficient padding, and mixed image sources.

---

Next Step

Once your template is Neon Blue-ready in your ESP, import it into the platform → Importing Templates to the Neon Blue App