A weblayer is a Bloomreach Engagement overlay injected into a website: a popup, banner, inline block, slider, or any other on-page surface. It's configured as three fields, HTML, CSS, and JavaScript, that Bloomreach renders and delivers to the visitor's page, controlled by segments and scenarios.
Category
Bloomreach Engagement, on-site personalization
Also known as
web layer; weblayers; BR weblayer
A single browser window split into three labeled panes stacked left to right, HTML, CSS, JavaScript, feeding into one rendered example on the page, a personalized banner. Below, a small grid of eight icons labeled Modal, Banner, Slide-In, Inline, Sticky, Exit, Form, Chrome, showing the same three-field module producing eight different surfaces.
What it actually is
The module exposes one underlying capability: render HTML, CSS, and JavaScript on a live page, gated by whatever segment or scenario condition you attach. Everything else, the promo popup, the loyalty pill in the header, the personalized product carousel, the exit-intent form, is a design pattern built on that one capability, not a separate feature.
That’s also why weblayers get mistaken for “just popups.” The name and the most common use case are the same thing, but the module is broader: it can add functional UI that looks like part of the site (a “my contracts” menu item that only renders for logged-in customers with active contracts, a service-data widget showing live account balance) as easily as it can add a discount banner.
The eight design patterns
Sorting weblayers by job, not by platform nomenclature, is what makes frequency capping, priority rules, and measurement work correctly. The eight patterns we use: modal popup, banner, slide-in, inline content block, sticky element, exit-intent layer, form-first layer, and page-chrome element. Full definitions, use cases, and a picking guide are in Types of Weblayers: A Taxonomy of Use Cases in Bloomreach.
Priority and conflicts
Bloomreach has no numeric priority field for weblayers. When two weblayers qualify for the same page view, the platform picks a winner within a group alphabetically by campaign name. Naming prefixes (01_, 02_, or A_, B_) are how teams control which weblayer wins. Without a group assignment, all eligible weblayers display simultaneously, which is the single most common cause of a catalog that visitors learn to ignore.
Testing before it reaches real users
Bloomreach’s Preview mode doesn’t run the full server-side Jinja substitution that live delivery does, so tracking fields render as placeholder strings in Preview rather than real values. Verifying a weblayer’s tracking payload requires testing in the live environment, scoped to a testers segment plus a URL parameter. The full pattern is in How to Test Bloomreach Experiments and Weblayers Without Polluting Production.
In practice
The three-field structure trips teams up: the HTML is a server-rendered Jinja template, while the JavaScript runs client-side and has to inject its own markup. Keep the two models separate, since a value that renders fine in the HTML field can arrive undefined in the JavaScript, and expect both fields to be scanned for Bloomreach syntax before they save. A weblayer is not just a popup; it is production code on the storefront, so QA it like production for targeting, rendering, performance, consent, and XSS risk.Weblayer Builder tool for previewing and designing them without writing code first. The three-field structure has its own rules: the HTML is a server-rendered Jinja template, the JavaScript runs client-side and has to inject its own markup, and both fields get scanned for Bloomreach syntax before they’re saved. More on how we approach this.