Dynamic Content
Dynamic content is email or web content that automatically changes based on a contact's attributes, behavior, or segment, so different recipients see different blocks from the same template.
Key takeaways
- Conditions evaluate in declared order, so the first match wins and ordering carries logic.
- Build the default block first and treat every variant as an override of it.
- Blocks multiply: three blocks with three variants each produce twenty-seven possible renderings.
- Aggregate click reporting blurs when recipients in one send saw different offers.
- The plain-text alternative is often left unconditional and contradicts the rendered version.
In depth
A dynamic block is stored as a set of variants plus a default. At render time the engine walks the conditions in the order they were declared and stops at the first one that evaluates true, which makes ordering part of the logic rather than a cosmetic detail. In email the expansion happens once per recipient during sending, so a heavily conditional template takes longer to process. On a web page the same swap happens either on the server or in the browser, and that choice determines what a crawler sees.
Complexity grows multiplicatively. Three blocks with three variants each produce twenty-seven possible renderings, and every one of them needs copy, images and a check before the send goes out. That is the real cost, not the tooling. The counterweight is fewer templates to maintain, which is why one conditional template usually beats five near-duplicate campaigns until the branches start diverging in structure. At that point separate templates are easier to reason about than a single deeply nested one.
The workable pattern is to build the default first and treat each variant as an override of it, so a missing rule degrades into something publishable rather than something empty. Keep each block conditioned on one field where possible, since compound conditions are the hardest to debug later. In a scorecard funnel the result page is the natural home for this: one template with the recommendation, the headline and the call to action switching on the tier the respondent landed in.
The technique quietly damages measurement. When every recipient sees a different offer, an aggregate click rate for the campaign describes no single email that anyone received, and comparing this month's send against last month's confounds content changes with shifts in who matched which branch. Conventional split testing is also awkward, because the variant a person sees is already determined by their data. The plain-text alternative is another blind spot, since it is frequently left unconditional and contradicts what the styled version says.
Example in practice
How to measure it
Report engagement per variant rather than per campaign, so each branch has its own click and reply figures. The comparison that matters is each variant against the default block on the same send, because that isolates whether the conditional logic added anything at all. A variant that consistently trails the default is a candidate for deletion rather than for another round of copy tuning.
Record how many recipients resolved to each branch. A branch catching almost everyone means the conditions are too loose; a branch reaching a handful of people cannot be evaluated and should be merged into its neighbour. Watch the share falling through to the default over time, because a rising fallback proportion usually signals that an upstream field stopped being populated.
Common mistakes
Rules are frequently written so that two branches can both be true at once. Because the engine renders the first match, the later branch never appears for anyone, and the symptom is a variant with no engagement rather than a visible error. Draw the conditions as mutually exclusive ranges, or finish with an explicit catch-all. Reviewing which branch each contact resolved to after a send exposes branches that are unreachable in practice.
The other habit is previewing only the default. Teams check the email as the fallback recipient sees it, ship it, and then discover the enterprise variant carries a broken image or copy left over from a previous campaign. Send a seed to a test contact for every branch instead of one generic test. Where blocks display numbers such as a score, check the edge values, since zero and the maximum are usually the unstyled cases.
Frequently asked questions
How is dynamic content different from a merge tag?
A merge tag inserts a single data value like a first name, while dynamic content swaps entire blocks such as images, offers, or CTAs based on rules. Dynamic content is conditional and structural, whereas merge tags are simple field substitutions.
What do I need before using dynamic content?
You need clean, well-populated data for the fields your rules depend on, plus a sensible default block for contacts missing that data. Without both, some recipients will see empty or broken sections.
Where does dynamic content help in a quiz funnel?
It is most powerful on the result page and in follow-up emails, where you can show tier-specific copy and offers based on the score. One template can serve a tailored experience to every score band.
What is the difference between dynamic content and a personalisation token?
A token substitutes one value into a fixed sentence, so the structure of the message never changes. Dynamic content swaps whole blocks, meaning the layout, image, offer and call to action can differ between recipients. Tokens are a text-level operation; dynamic content is a structural one, and it needs a fallback for the block rather than just a default word.
Can you A/B test an email that uses dynamic content?
Yes, but test inside a branch rather than across the whole send. Because each recipient's variant is determined by their data, a campaign-level split mixes two effects at once. Pick one branch with enough recipients, split that group, and change a single element. Comparing branch against branch tells you about the audiences, not about the copy.
How many dynamic blocks are too many in one email?
The practical limit is what you can verify before sending. Every additional block multiplies the combinations, so two or three conditional blocks in one email is usually the point where checking becomes a project. If you need more than that, the branches probably differ enough in structure to justify separate templates instead.
Does dynamic content affect deliverability or rendering?
It rarely affects deliverability directly, since the mailbox provider receives one finished message. Rendering is the real risk: conditional blocks often produce nested tables or inconsistent widths that break in older desktop clients. Test each branch in the clients your audience actually uses, and keep the fallback simple enough to render everywhere.
What happens when a contact matches none of the rules?
They receive the default block, which is why the default should be a complete, sendable message rather than a placeholder. Contacts land there more often than teams expect, usually because an optional field was never filled in. Treat the default as the version most people will see until your data proves otherwise.
Should page content be swapped on the server or in the browser?
Server-side rendering gives the visitor and any crawler the same finished page, avoiding a visible flash while the browser replaces content. Client-side swapping is easier to wire to live signals such as a score just calculated. For a result page that must be indexable or shareable, prefer the server; for logged-in, session-specific views the browser is fine.