Klaviyo dynamic content: show, hide, and test blocks
Short answer. Start with one reliable profile or event property, define the default experience, then show or hide one block for a meaningful customer state. Use Klaviyo's logic builder for supported profile data and custom code for event, date, or boolean logic the builder does not support. Preview with profiles that match every branch and one profile with missing data.
Dynamic content should reduce the number of irrelevant choices a customer sees. It should not create dozens of fragile versions inside one email.
Klaviyo's current show-hide documentation supports profile data in the logic builder and event variables in metric-triggered flows through custom-coded logic. Supported data types and syntax matter.
Four types of dynamic email content
| Type | Data source | Example |
|---|---|---|
| Personalization tag | Profile or event property | First name with fallback |
| Show-hide block | Profile property or custom logic | VIP benefit block |
| Event content | Trigger event | Viewed product or cart items |
| Product recommendation | Catalog and behavior | Best sellers or predicted interest |
Use the simplest type that solves the problem. A single tag does not require a complex block, and a multi-item cart should use a tested dynamic table rather than manual conditional text.
Start from the data contract
Before editing the template, document:
- Property name and exact case.
- Source system.
- Data type: text, number, date, boolean, or list.
- Allowed values.
- Missing-value behavior.
- Update frequency.
- Owner.
- Example profiles or events.
VIP = true, VIP = "true", and VIP = "True" are different representations. Klaviyo's documentation warns that comparisons fail when the condition expects a number but the profile stores text.
Normalize upstream when possible. Template code is a poor place to maintain many historical spellings.
Profile-property personalization
A basic tag should include a safe fallback. For example, do not let a missing first name create Hi ,.
Use profile properties for relatively durable facts or preferences:
- Language.
- Market.
- Product preference.
- Loyalty tier.
- Size or fit preference.
- Customer type.
- Store or account relationship.
Do not expose sensitive or surprising data simply because it exists on the profile. Personalization should feel helpful and expected.
Show-hide logic with the builder
Klaviyo's logic builder can use supported profile data formatted as text, numbers, and lists. Current documentation says dates, booleans, and event data require custom code for these template conditions.
Example use case:
- Block A shows when
Loyalty Tier equals VIP. - Block B shows when
Loyalty Tier is not set. - A generic base message remains useful for every other value.
When combining conditions, remember that AND is evaluated before OR. Write the logic in plain language and use parentheses or separate blocks where ambiguity is possible.
Avoid stacking show-hide logic on both a section and its child blocks unless the interaction is documented and tested.
Event-based dynamic content
Event variables are available in event-triggered flows, such as Viewed Product, Checkout Started, or Placed Order. The variable path depends on the actual event payload.
Find it through Preview and test:
- Select Event as the preview data source.
- Choose a recent trigger event.
- Inspect available properties.
- Copy the exact tag.
- Test with several events, not only one perfect order.
Use event data for:
- Product name and image.
- Cart or checkout URL.
- Order items.
- Product category.
- Order value and currency.
- Shipping or fulfillment context.
Only the trigger event can be referenced in event-based show-hide logic for that flow message. A later unrelated event is not automatically available inside the original payload.
Product blocks
Klaviyo's current product block documentation supports dynamic product recommendations based on business trends or predicted recipient interest.
Choose the recommendation job:
- Best sellers for a new prospect.
- Recently viewed product.
- Complementary product after purchase.
- Category-specific selection.
- New arrival for a relevant customer.
Add inventory and category exclusions where supported. Do not recommend the product just purchased as a cross-sell unless replenishment is the intended behavior.
Product blocks still need a fallback. If catalog sync, image, inventory, or recommendation eligibility fails, the email should remain coherent.
Dynamic tables for carts and orders
A dynamic table repeats line items from an event. Start from the integration's working default block because event structures differ.
Test:
- One item.
- Several items.
- Variant titles.
- Discounted item.
- Free gift or shipping insurance.
- Missing image.
- Deleted or unavailable product.
- Long product name.
- Currency and localization.
Klaviyo documents custom logic for skipping irrelevant lines, but direct code editing requires technical ownership and is not covered by standard support. Preserve a known-good version before changing it.
Six useful ecommerce patterns
1. Prospect versus customer
Show category education to prospects and ownership support to customers. Use purchase history, not a manual list that never updates.
2. Product preference
Show the relevant category hero based on a form preference or repeated behavior. Keep a generic version for missing or mixed preferences.
3. Loyalty tier
Show available benefits and points only when the property is current. Avoid exposing a points balance if its sync can lag materially.
4. Market and language
Dynamic copy is only one layer. Links, currency, shipping, terms, and landing pages must match the market as well.
5. Purchased category
Use order event or history to provide product care and compatible recommendations. Exclude returns or canceled orders where data permits.
6. RFM group
Klaviyo supports dynamic content based on current RFM group. A Champion may receive early access while an At Risk customer receives a lower-friction route back. The message should respect consent and frequency regardless of group.
Fallback design
Every dynamic element needs a default:
| Dynamic element | Safe fallback |
|---|---|
| First name | Friendly greeting without name |
| Product image | Remove block or show category image |
| Loyalty points | Link to account rather than show stale value |
| Preferred category | Best sellers or category chooser |
| Discount code | Non-code value or support path |
| Market | Do not send until market is known if terms differ |
Do not let the fallback make a false promise. If shipping conditions vary by country, a generic free shipping block is not safe.
Preview matrix
Use real or dedicated test profiles:
- Profile matching branch A.
- Profile matching branch B.
- Profile matching multiple conditions.
- Profile with property missing.
- Profile with wrong historical data type.
- Suppressed or non-consented profile.
- Event with one item.
- Event with several items.
- Event with missing optional property.
Then send the final message to Gmail, Apple Mail, and Outlook. The editor preview verifies data logic, while inbox tests verify final rendering and link rewriting.
Measure dynamic content correctly
If different profiles receive different content based on existing behavior, their performance is not directly comparable. VIPs may outperform prospects regardless of the block.
To test content effect, randomize eligible profiles within the same customer state. Keep offer, audience, send time, and landing experience consistent. Use click, order, net revenue per recipient, and guardrails.
Governance
For every template, record:
- Dynamic properties and sources.
- Allowed values and data types.
- Fallbacks.
- Dependent events and catalog.
- Test profiles.
- Owner.
- Last successful QA date.
Retest after integration, event-schema, catalog, loyalty, or property changes.
Common dynamic-content mistakes
- Building before one real profile or event contains the property.
- Comparing a number with text.
- Omitting a default branch.
- Using event variables in a campaign with no trigger event.
- Personalizing from sensitive or unexpected data.
- Hiding a parent section and child block with conflicting logic.
- Assuming a recommendation block always has inventory.
- Comparing customer segments as if they were randomized variants.
FAQ
What data can Klaviyo show-hide logic use?
The visual builder supports profile data in supported text, number, and list formats. Event, date, boolean, and more complex logic may require custom code. Check the current Help Center and actual data type.
Can I use event data in a campaign?
Campaigns do not have one trigger event for every recipient. Use profile properties, segments, or catalog recommendations instead. Event variables are designed for metric-triggered flow messages.
Why is a block not showing?
Check property name, case, data type, value, AND and OR order, parent-section logic, and preview profile. Convert to code only if someone can own and test the resulting condition.
Should every email use dynamic content?
No. Use it when the data changes a relevant customer decision. Static content is safer when the same message genuinely serves everyone.
How do I test dynamic content performance?
Randomize profiles within the same eligible audience. Comparing VIPs with prospects measures audience difference, not only the content block.
Personalize only what the data can support
Dynamic content creates value when its source, logic, fallback, and measurement are explicit. Deliver helps teams build that system in Klaviyo. Book a Klaviyo and CRM diagnostic.
Want to apply this to your stack?
Spend 30 minutes with Charlotte to review your CRM setup, size the opportunity and leave with a practical action plan.
Book a 30-minute call →