Connecting Email Templates to Neon Blue
If You Use Images as Your Emails
If your emails are built as screenshots or full-image designs created in another tool (such as Figma), they must first be converted into standard email templates before they can be used with Neon Blue. These templates can live in your existing ESP or email system (for example, Klaviyo, Braze, or custom HTML).
This is required because Neon Blue’s AI does not generate or edit entire emails as flat images. Instead, it generates content into structured template fields (text, images, CTAs, HTML) so that content can be previewed, tested, personalized, and optimized over time.
To work with Neon Blue, image-based emails need to be:
Broken into sections (for example: header, body, image blocks, CTAs)
Implemented as standard email templates (not screenshots)
Connected to dynamic variables so AI-generated content can be inserted
Once a design exists as a template, Neon Blue can generate content for it, swap images, run tests, and personalize sections dynamically. Without this structure, AI generation and experimentation are not possible.
Overview
Neon Blue supports fully dynamic image, text, and HTML variables in email templates. These variables act as the interface between your template and Neon Blue’s AI — allowing the system to generate content, populate it into specific parts of the email, and preview how it will render in production, all while preserving layout and brand control.
Mental model: Think of an email as a set of sections. Each section may include:
A heading
Body copy (plain text or HTML)
An image
A CTA
Dynamic variables let each of these pieces change independently and allow Neon Blue’s AI to generate content for each section in a structured, predictable way.
Neon Blue supports fully dynamic image, text, and HTML variables in email templates. These variables are defined under event.extra and are parsed at preview and generation time to simulate how the template will render in production. Variables are referenced directly in the template using {{ }} syntax.
This page explains how to correctly structure image, text, and HTML variables.
Variable Namespace (Required)
All dynamic template inputs must live under:
This namespace is what Neon Blue’s AI reads from and writes to when generating content. Only variables within this namespace are detected and surfaced in the template preview UI. Variables must be referenced directly in the template using handlebar-style {{ }} syntax.
Core Principle: Variable Naming and Section Relationships
Dynamic variables should clearly encode which fields belong together. This applies to headings, body copy, images, and CTAs that form a single conceptual section.
Clear relationships improve:
Template readability for humans
AI understanding of how content fits together
Generation quality and editability over time
Neon Blue’s AI interprets variables as structured content and generates content specifically for those fields. If relationships are not encoded in the variable names, the AI is forced to guess how pieces fit together, which reduces output quality and consistency.
Recommended Pattern: Shared Prefixes
Variables that belong to the same section should share a common prefix.
Examples:
With this structure:
The heading introduces the body
The image belongs to the same section
Each section is an independent content unit
This principle applies across all variable types described below.
Fixed (Static) Fields and Images
Not every part of an email needs to be generated or changed by AI.
Templates can include fixed (static) content alongside dynamic variables. Static content is hard-coded directly into the template and is not modified by Neon Blue’s AI.
Common examples include:
Brand taglines or legal copy
Discount codes
Interview images and quotes
Fixed images
Static fields and images do not use {{ }} syntax, do not live under event.extra and are ignored by Neon Blue’s AI during generation.
Dynamic variables should only be used for content you want Neon Blue’s AI to generate, personalize, or test. Mixing static and dynamic content within the same template is expected and common.
Plain Text Variables
Plain text variables are simple string values, commonly used for headings or short labels.
Examples:
Dynamic Image Variables
Image variables are defined as grouped objects that include standard image fields:
src- image URLalt- alt texthref- click-through URL (optional)
The variable name must include img so the editor knows this is an image section and can surface the image selector.
Example
This pattern is used consistently across headers, body blocks, and multi-image sections.
Dynamic HTML Variables
For rich text content, use the .html suffix. Content is rendered as raw HTML exactly as provided.
Examples
These variables are ideal for paragraphs, inline links, emphasis, and more complex formatting.
Image Slots and Image Pools
Each image variable defines an image slot in the template. Any image in the image pool can be used in any of these slots.
For example, if the template references:
Then any image uploaded to the image pool can be selected and assigned to header_img during preview or testing.
Image assignment is determined by the variable name in the template, not by the image itself.
Common image variable names
h1_imgblock1_imgblock2_imgblock3_imgblock4_img
Each image section is treated independently and can be previewed with different assets.
CTA Variables
CTAs are typically defined as paired fields for text and destination.
Example
This allows copy and destination URLs to be swapped independently during preview and testing.
Best Practices
Always keep dynamic variables under
event.extraso Neon Blue’s AI can reliably generate and populate content.Include
imgin image variable namesUse
.htmlonly when HTML rendering is requiredKeep naming consistent across templates to simplify reuse and automation
This structure enables predictable preview behavior, clean template authoring, and safe dynamic rendering at scale.
Last updated