The Bloomreach Engagement implementation playbook: Part 4
Part 4: Catalogs, weblayers, and omnichannel experience
Email is the obvious Bloomreach use case. It’s also the narrowest one. The platforms that earn back their cost quickly are the ones that orchestrate across channels, site experiences, push notifications, in-app messages, SMS, all from the same customer profiles and scenarios. This part covers the infrastructure and design patterns that take Bloomreach from “email platform” to “omnichannel engagement hub.”
Catalogs: turning events into product data
Events capture what a customer did with a product. Catalogs capture what the product is. The two together unlock experiences that neither could produce alone.
A catalog in Bloomreach is a structured dataset, usually imported from a product feed, database export, or headless commerce API, containing items and their attributes. The canonical e-commerce catalog stores:
Product ID, name, description.
Current price, original price, currency.
Category, subcategory, brand.
Stock level, availability.
Image URL, product URL.
Ratings, review count.
Any custom attributes relevant to recommendations (color, size range, seasonal flag).
Catalogs update on a schedule, typically hourly for stock-sensitive properties, daily for the rest. Set up the import once, and every downstream scenario, weblayer, and recommendation block gets fresh data without changes.
The catalog lookup pattern. Events should be minimal, enough to identify the product, not enough to describe it. On a product_viewed event, send only product_id. Then in any downstream message, look up the full product data at render time:
This pattern has three benefits. Events stay small and cheap. Product data reflects current reality at the moment of send, not at the moment of event capture. And when product metadata changes, a renamed product, a new image, no scenarios need to be updated.
Product recommendations
Bloomreach offers several recommendation models out of the box:
Best sellers. Top products by sales volume over a time window.
Most viewed. Top products by view count.
Similar products. Items similar to a reference product based on category, price, and co-view behavior.
Personalized. Items predicted to appeal to a specific customer based on their history and similar customers’ behavior.
Each model is configured once and then embedded in emails or weblayers via a Jinja2 recommendation block. Scalero’s default for most e-commerce clients: use “personalized” for logged-in customers and fall back to “best sellers” for anonymous ones.
For clients with existing recommendation engines (Algolia, Constructor, Bloomreach Discovery itself), the decision is whether to integrate those into Bloomreach or use Bloomreach’s native models. We usually recommend native models for email personalization (the data is already in Bloomreach and latency is zero) and external models for on-site search, which handles a different job.
Weblayers: the on-site channel
Weblayers are dynamic content overlays rendered on your own website: popups, banners, embedded blocks, exit-intent modals. Because they share the same customer profile and segmentation as emails, they can deliver coordinated experiences, a customer who ignored the welcome email sees the welcome offer as an on-site banner instead.
Weblayer types and when to use each:
Modal popup. High attention, high interruption. Use sparingly, for decisive moments (exit-intent offer, newsletter signup for first-time visitors).
Banner (top or bottom). Persistent, low-friction. Good for announcements, shipping promotions, loyalty callouts.
Inline block. Rendered in a designated slot on the page. Good for personalized homepage hero, category page recommendations.
Slide-in. Appears in a corner. Medium attention; works well for secondary offers and social proof.
Targeting and frequency. Every weblayer should be scoped by segment, page URL, and frequency. Showing the same popup every visit to an already-converted customer is the fastest way to damage the on-site experience.
💡Scalero’s default frequency rule: no weblayer shown more than once per session, no more than three weblayers per customer per day.
A/B testing weblayers. Bloomreach’s Experiments feature makes weblayer A/B testing trivial, define a variant, set the split, let Loomi allocate traffic optimally (or hold it at 50/50 for strict testing). The metrics that matter are conversion lift on the page where the weblayer rendered, not weblayer click-through rate; a high CTR with no downstream conversion lift is a sign of an offer that’s distracting rather than compelling.
Mobile push and in-app messages
For mobile apps, Bloomreach supports both push notifications (sent when the app is closed) and in-app messages (rendered when the app is open). The implementation requires the mobile SDK (iOS or Android) and a platform-specific push credential (APNs for Apple, FCM for Google).
The design patterns parallel email: scenario-driven, profile-personalized, Jinja2-templated. A few mobile-specific considerations:
Push notifications have one-line content budgets. A truncated 40-character title and 70-character body is what users actually read. Jinja2 personalization still applies, but the content budget forces brevity.
In-app messages are closer to weblayers than push. They render in the app UI, can be full-screen or inline, and have no character limits. Use them for onboarding, feature announcements, and contextual offers.
Silent push. A special push type that doesn’t display to the user but wakes the app and can trigger server-side logic (refreshing catalog data, running a sync). Powerful but easy to abuse, use sparingly.
SMS: high attention, high cost, high risk
SMS is the most attention-getting channel Bloomreach supports, open rates routinely exceed 95%, and the most expensive per message and most tightly regulated. Treat it as a last-resort channel, reserved for:
Transactional messages users explicitly want (shipping updates, 2FA, appointment reminders).
Genuine time-sensitive offers where email wouldn’t be read in time.
High-value customer segments where the CAC:LTV ratio supports the channel cost.
Consent matters here more than anywhere. SMS opt-in must be explicit and separate from email opt-in, never assume a marketing email consent covers SMS. Most jurisdictions require a specific SMS consent checkbox and a working STOP keyword that Bloomreach handles automatically.
Cross-channel orchestration
The highest-value scenarios aren’t single-channel; they coordinate across channels intelligently. A well-designed win-back campaign might:
Day 1: Email, “We miss you, here’s 15% off.”
Day 3: On-site banner, “Welcome back! Your 15% is waiting.”
Day 5: Push notification, “Final day for your 15% off” (only if mobile app installed).
Day 7: SMS, “Last chance: 15% off ends tonight” (only if SMS consent and high-value segment).
Throughout: Exit if purchased. Exit if unsubscribed from any channel.
Each channel reinforces the others without being redundant. The customer’s profile carries their state (have they seen the weblayer? clicked the push?) across the whole journey, and the scenario routes around the channels they’ve opted out of.
This kind of orchestration is what Bloomreach is built for. It’s also where teams most often underinvest, channels get built as separate scenarios that don’t know about each other, and the customer experience fragments. Design the orchestration layer first, then build the individual channels into it.
With the channel layer in place, Part 5 introduces the AI layer that makes all of it smarter.
