Browse Abandonment Email Templates: Product View, Category View, and Recommendation Blocks

Browse templates are useful only when the event behind them is explicit. The same block system can support product, category, and recommendation emails, but the trigger and copy should not be interchangeable.

Shared variables

Variable	Required?	Fallback
Customer name	Optional	“There”
Viewed product or category	Yes	Stop if missing
Product URL	Yes for product view	Use category URL
Product image and price	Optional	Hide the block
Recommendation reason	Recommended	“You may also like”
Consent and frequency state	Yes	Do not send if unknown

Template A: exact product view

Subject: Take another look at {{product_name}}

You recently viewed {{product_name}}. Here is the information you may want before deciding:

{{product_image}} {{price}} {{proof_point}}

[View product]

Use this when the product is still active and the customer has not added it to a cart.

Template B: category exploration

Subject: More from {{category_name}}

You were exploring {{category_name}}. Start with these options:

{{category_product_grid}}

[Browse all]

Use a category template when no single product represents the customer’s interest.

Template C: repeated interest

Subject: Need help choosing {{category_name}}?

You’ve looked at {{category_name}} more than once. Compare {{comparison_dimension}} or see answers to common questions:

{{guide_or_comparison_link}}

[Continue exploring]

Repeated interest is a reason to offer help, not proof that a discount is required.

Timing and exits

Define:

• minimum event threshold;
• delay after the last view;
• maximum sends per customer and category;
• cart and purchase suppression;
• product availability fallback;
• expiry after the customer stops engaging.

If the customer creates a cart, stop browse messaging and let cart recovery own the next email. If the product sells out, replace it with a category or waitlist path.

QA checklist

• Product and category fallbacks render safely.
• The email never says “cart” for a browse event.
• Prices and availability are current.
• Frequency caps cover overlapping ecommerce flows.
• The template works with images blocked.
• Consent and regional rules are enforced before enqueueing.

For examples with full copy, see the browse abandonment examples.

A template is a decision tree

Keep the copy modules separate from the eligibility rules. This lets a team change a headline without accidentally changing who receives it.

Decision	Rule	Module
Exact product still available	Product event is recent and no cart exists	Product card and proof point
Product unavailable	Product retired or sold out	Category, waitlist, or substitute
Category interest only	No product has enough signal	Category grid or guide
Cart created	Cart event exists after the view	Exit browse flow
Purchase completed	Order event exists	Exit browse flow and enter post-purchase

Put these rules in the workflow layer. The template should receive an approved content model and render the correct fallback.

Add a reason for every dynamic block

If the product grid is generated, store the selection reason: viewed category, compatible with a purchased item, in-stock alternative, or editorial collection. That reason can be an internal field even when the email displays only a short label. It makes relevance review possible and discourages a generic “recommended” block from becoming a dumping ground.

For prices, availability, ratings, and delivery claims, set a freshness window. If data is older than the window, hide the claim or re-query it before rendering. A broken product link is worse than a shorter email.

Timing examples

• Fast-moving retail: wait until the session has ended, then send one message within the same buying window.
• Considered purchase: wait longer and link to a comparison or buying guide.
• Seasonal collection: use an editorial follow-up only while the collection is active.
• Repeat browsing: increase the help content before increasing frequency.

These are starting points, not universal delays. Use the customer’s buying cycle and measure against a holdout.

Acceptance tests

Render the template with a missing name, missing image, unavailable price, an out-of-stock product, several viewed categories, a purchase immediately before send, and images blocked. Confirm that every fallback still has one useful action and that the email never calls a browse event a cart.