Adobe Commerce customer segments group shoppers by behavior and attributes, such as order history or cart contents, then show each group different content and promotions. On a Hyva storefront that content cannot render server-side, because full page cache serves the same HTML to everyone, so it renders client-side through Hyva section data after the page loads.
If you run Adobe Commerce and want the homepage, a category page, or a promotional banner to change based on who is looking at it, customer segments are the native tool. The catch is that personalization and caching pull in opposite directions, and a Hyva theme resolves that tension differently than the legacy Luma frontend did. This guide covers how segments work, how the personalized output actually reaches a Hyva page, what it costs in performance, and the failure modes that catch teams out.
What customer segments actually are
A customer segment is a dynamic group. You define the rules, and Adobe Commerce continuously evaluates every shopper against them. Because segment membership is refreshed as people shop, a visitor can join a segment when they add a product to the cart and leave it when they remove it. This is the difference between segments and static customer groups, which change only when someone is manually reassigned.
You create them under Customers, then Segments. Segments are scoped by website, and you can target registered customers, visitors who are not logged in, or both. The conditions draw on real data: shopping cart contents and value, order history and lifetime spend, customer address and region, the customer group, and product-related behavior. A common example is a segment for shoppers whose cart value is over a threshold, used to trigger a free-shipping message.
The single most important fact to plan around: customer segments are part of Adobe Commerce and are not available in Magento Open Source. If you are weighing the two editions, segment-driven personalization sits firmly on the Adobe Commerce side of the comparison, alongside B2B and Live Search.
How segments, dynamic blocks, and cart price rules connect
Segments do nothing on their own. They are the targeting layer that two other features consume.
Dynamic blocks are content blocks driven by logic. You build one under Content, then Elements, then Dynamic Blocks, attach it to one or more customer segments, and place it on a page or category through Page Builder. A dynamic block can hold a banner, a promo, or any rich content, and Adobe Commerce shows it only to shoppers in the matching segment. This is how the same category page can carry different hero messaging for a first-time visitor and a returning wholesale buyer.
Cart price rules can also be limited to a customer segment. This lets you run a discount that applies only to shoppers who meet the segment conditions, rather than to everyone with a coupon code. The rule and the message stay consistent, because both point at the same segment.
The typical workflow is: create the segment under Customers, then Segments; build a dynamic block under Content, then Elements, then Dynamic Blocks; place it with Page Builder; and, when there is a promotion attached, scope a cart price rule to the same segment. Adobe’s customer segments documentation and its dynamic blocks documentation cover the admin steps in detail.
The full page cache problem
Here is the tension that shapes every personalization decision on Magento and Adobe Commerce. Full page cache exists to serve a pre-rendered HTML page to every visitor without re-running PHP. That is what keeps a storefront fast. But personalized content is, by definition, different for each shopper. You cannot bake per-shopper content into a page that is cached once and served to thousands of people.
Magento solves this with private content. Blocks that hold shopper-specific data are replaced with placeholders in the cached HTML, and the real content is fetched after the page loads. The browser makes an AJAX request to the customer section load endpoint, stores the result in local storage under the mage-cache-storage key, and the client-side code swaps the placeholder for the personalized content. The cached shell stays fast; the personal layer arrives a moment later.
This is why a segment-driven banner does not appear instantly in the raw HTML. It is delivered through the private content path so the page can still be cached. Dynamic blocks are built to work with full page cache and Varnish through this mechanism, which is what makes per-segment content viable at scale rather than a reason to switch caching off. If you want the full picture of how the cache layer behaves, our guide to full page cache and Varnish on Hyva goes deeper.
How personalization renders on a Hyva storefront
Hyva keeps the same private content concept but implements the frontend differently, and the difference is worth understanding before you build anything.
Customer section data is how Magento exposes server-side session data to browser JavaScript on cached pages. On Luma, sections were handled piecemeal through Knockout and a web of UI components. Hyva takes a cleaner approach: it loads all customer section data together as a single data structure, and once that data is available it dispatches a JavaScript event named private-content-loaded. Every piece of section data lives in the event detail object, keyed by section name.
To personalize on Hyva, you write an Alpine.js component that subscribes to that event, usually with @private-content-loaded.window, reads the data it needs, and renders accordingly. A promotional banner, a customer-specific message, a cart-aware call to action: each is an Alpine component that stays hidden or generic until the section data confirms which segment the shopper belongs to, then updates in place. Hyva’s section data documentation is the reference for the event and its payload.
The practical upshot is that personalization on Hyva is fast and predictable when built with Alpine and section data, and fragile when someone tries to force server-rendered personalized blocks into cached pages. Keep the cached shell generic, and let Alpine paint the personal layer after private-content-loaded.
Luma versus Hyva personalization
| Aspect | Luma frontend | Hyva frontend |
|---|---|---|
| Section data loading | Piecemeal via multiple UI components | All sections loaded together as one structure |
| Framework | Knockout, RequireJS, jQuery | Alpine.js and native JavaScript |
| Personalization trigger | Knockout bindings on section updates | private-content-loaded event, Alpine listeners |
| Dynamic block rendering | Private content placeholder | Private content placeholder, Alpine renders the swap |
| Typical failure | Layout flicker, heavy JS | Component not subscribed to the event |
| Speed of the cached shell | Slower base theme | Faster base theme |
The mechanism is conceptually the same on both. What changes is that Hyva’s lighter frontend and single section-data payload make the personal layer arrive with less overhead, and its component model makes personalized blocks easier to reason about.
The hidden performance cost of segments
Personalization is not free, and customer segments are the part that quietly taxes your store. Segment membership is evaluated dynamically, and depending on configuration that evaluation can run on many requests, including some anonymous ones. Each segment can fire one or more SQL queries as Magento works out whether the current shopper qualifies. A store carrying twenty to thirty active segments can add twenty to thirty queries to page processing, which shows up as slower response times and heavier database load, especially at traffic peaks.
This does not mean avoid segments. It means treat them as a budget:
- Keep the active segment count deliberate. Retire segments you no longer use in campaigns rather than leaving dozens evaluating on every request.
- Prefer specific conditions over broad ones. A tightly scoped segment evaluates faster and matches more predictably than a vague one.
- Watch the database under load. If response times climb during promotions, segment evaluation is a prime suspect. Instrument it the way you would any other query cost.
- Do not confuse segments with recommendations. For product-level personalization at scale, Adobe Sensei product recommendations offload the work rather than adding SQL to each request.
Because the personal layer is client-side, the other cost to manage is interactivity. Alpine components that do heavy work when section data lands can hurt responsiveness, so keep the interaction cost low by doing the minimum in each listener.
What breaks
- Personalized content appears then vanishes on logout. Adobe has shipped patches for dynamic blocks that behave incorrectly when a shopper logs out and segment membership changes. If a segment banner lingers or disappears wrongly after sign-out, check that your instance carries the relevant quality patch.
- The banner never appears on Hyva. The most common cause is a component that is not subscribed to
private-content-loaded, so it never receives the section data that tells it which segment applies. - Personalization is baked into a cached block. If someone renders segment content server-side into a full-page-cached template, every visitor sees the same shopper’s content. Personalized output belongs in private content, not the cached shell.
- Segment sprawl slows the store. Dozens of unused segments keep evaluating. Prune them.
- Expecting segments in Open Source. They are not there. This is an Adobe Commerce capability.
Frequently asked questions
Are customer segments available in Magento Open Source?
No. Customer segments, dynamic blocks driven by segments, and cart price rules limited to segments are Adobe Commerce features. Magento Open Source has static customer groups but not dynamic segment evaluation.
Why does personalized content load a moment after the page on Hyva?
Because the page is served from full page cache as generic HTML, and the personal layer is delivered separately through customer section data. Hyva loads that data and dispatches the private-content-loaded event, after which Alpine components render the shopper-specific content.
Do customer segments break full page cache?
No. Dynamic blocks and segments are designed to work with full page cache and Varnish by routing personalized content through the private content mechanism. Caching stays on; only the personal layer is client-side.
How many customer segments is too many?
There is no fixed limit, but each active segment adds evaluation cost, potentially one or more SQL queries per request. Many stores feel the impact somewhere in the range of a few dozen active segments. Retire segments you are not actively using.
Can visitors who are not logged in be segmented?
Yes. Segments can target registered customers, guest visitors, or both, and they are scoped by website. Cart-based conditions work for anonymous shoppers because cart data is available before login.
How do I show different content to a segment on a Hyva page?
Build an Alpine.js component that listens for the private-content-loaded event, reads the relevant section data, and conditionally renders the content. Keep the cached template generic and let the component paint the personalized state.
Building personalization that stays fast
Customer segments are one of the strongest reasons mid-market and enterprise merchants choose Adobe Commerce, and they reward teams that respect the caching model instead of fighting it. Bemeir is the USA’s leading official Hyva partner and a full-service Magento and Adobe Commerce agency, and we build personalized Hyva storefronts where segment-driven content renders through Alpine and section data without slowing the page underneath it. You can read more about how we work and the technology partners we integrate for personalization, search, and analytics. When Adobe Commerce is not the right fit, we also deliver on Shopify, Shopware, and BigCommerce. If your storefront personalization is slow, inconsistent, or silently broken after a migration, that is exactly the kind of problem we fix. Learn more about our Hyva development work and how we approach performance-first personalization.
