7 Ways to Deliver Dynamic Content with Braze Campaigns

Dynamic content is useful when it changes a customer's next decision. Choose a Braze content mechanism by where its data lives, how fresh it must be and whether it should remain linked across messages. The seven patterns below separate content choices from delivery timing and channel targeting, with explicit fallbacks for failure.

1. Profile-based content with Liquid

Use available profile facts such as an approved language preference or membership tier to select useful wording. Write the generic message first, then specify outcomes for missing, blank and unexpected values.

For an illustrative membership email, a known tier selects its benefit description while an unknown tier receives neutral wording. Test each message field separately; variable scope can differ between subject and body.

2. Fresh values through Connected Content

Use a render-time lookup when staleness would make the message wrong. Agree endpoint ownership, request load, acceptable data age and failure behavior before writing the call.

A tracking-link fallback may be suitable for an unavailable delivery estimate. A statement that would become misleading without its response may need to abort. The business owner should approve that distinction.

3. Structured non-user data in Catalogs

Use maintained catalog records for product, location or other non-user information. Choose stable identifiers and assign ownership for titles, availability and destinations.

Test a missing item and a removed offer. A successful data lookup does not prove the content is still appropriate for the recipient.

4. An in-product surface with Content Cards

Content Cards can present relevant information inside the app without relying on a one-time interruption. The customer experience depends on the app integration, targeting and configured lifecycle.

For a fictional learning app, a card can suggest the next lesson. Define appearance, destination and expiry, then test the real app behavior and interaction logging.

5. Shared modules with Content Blocks

Use shared blocks for content that needs centralized maintenance. Confirm insertion behavior: linked Liquid usage and a copied editor row do not carry the same update semantics.

A shared footer needs an owner and dependency list. Retain its previous version and preview representative consuming messages before an edit. Reuse only reduces rework when the dependencies remain understandable.

6. Item recommendations for a defined placement

Choose rules or AI recommendations according to the decision, interaction history and freshness needed. A replenishment rule and a discovery placement need not use the same method.

Test cold-start users, recent purchases, unavailable items and duplicate recommendations across sections. Compare a predefined outcome with the existing placement rather than treating more clicks as proof of value.

7. Transaction-specific event or journey context

An order confirmation or reservation update needs the context of the intended action, not simply the most recent unrelated transaction on the profile. Agree the fields accessible to the chosen delivery type.

Use a stable transaction identifier and verify supported context variables in the workspace. Test two recent actions from the same user; each message must refer to the correct one.

Keep timing and channel choices separate

Intelligent Timing helps choose when to deliver; Intelligent Channel supports targeting by a user's historically strongest supported channel. Neither replaces the content logic above.

Configure the appropriate routing and fallbacks, including insufficient-history and unreachable-channel cases. Investigate rendered content, reachability and send timing as separate questions.

Release a content pattern with test evidence

Record the source, owner, allowed age and fallback for every value. Preview fictional profiles covering edge cases, inspect every destination and verify that each record belongs to the intended recipient.

A template rendering correctly is a technical pass, not proof of incremental business impact. Measure the chosen customer outcome with a suitable comparison and monitor inaccurate content and opt-outs.

Combine content patterns without hiding failures

For a fictional replenishment email, use the purchase event for context, a maintained catalog for product copy and a linked Content Block for shared information. Add a live lookup only where freshness materially changes the message. Keep delivery timing and channel selection separate from content selection.

Test missing fields, unavailable products, failed lookups and two recent orders for the same customer. Record which source supplies each value, its owner and allowed age. Use the simplest design that reliably supports the intended action.

The worked example and test cases are illustrative editorial guidance, not measured client outcomes or a claim that a live integration has been tested.

Frequently asked questions

Should every campaign use all seven patterns? No. Use the smallest reliable combination that supports its purpose.

Should every value be fetched live? No. Live dependencies introduce latency and failure considerations. Use them when freshness materially changes the answer.

How should results be reported? Separate rendering and delivery reliability from customer outcomes, and avoid treating attribution as proof of causal lift.

Implementation references

• Braze: Liquid
• Braze: Connected Content
• Braze: Catalogs
• Braze: Content Cards
• Braze: Content Blocks
• Braze: Item recommendations

Related implementation guides

• Personalization at Scale: Using Braze Liquid Tags
• Using Braze Connected Content for Personalized Campaigns
• Tracking User Events for Better Campaigns in Braze

CustomerIK helps teams implement Braze data and lifecycle programs. Discuss your audience, data sources and intended customer outcome with the team.