Klaviyo integrates with Magento and Adobe Commerce through an official extension, but on a Hyva theme it splits in two. Order, customer, and catalog data sync on the server, working on any theme. The onsite browsing events built for Luma need a Hyva compatibility module, or they silently stop firing.
That split is the whole story, and almost no guide draws the line. This article maps exactly which Klaviyo events are server-side and which depend on your frontend, why the browsing tracking breaks on Hyva, which compatibility modules restore it (there are two), and how to load Klaviyo’s script without undoing the Core Web Vitals gains you bought Hyva to get. It is written for merchants running email and SMS on a real Magento and Adobe Commerce storefront.
The two-layer model: server-side events versus onsite JavaScript
Klaviyo’s Magento integration collects data two ways, and the difference decides what breaks on Hyva and what does not. One set of events is generated on the server by the extension and its cron jobs. These fire from order and customer state in the database and never touch the storefront theme, so they work identically on Luma, Hyva, or a headless frontend. The other set is generated in the shopper’s browser by Klaviyo’s onsite JavaScript, which watches behaviour as it happens. Those events depend entirely on the frontend, and the frontend is exactly what Hyva changes.
| Event | Layer | Theme-dependent? |
|---|---|---|
| Placed Order | Server-side (extension) | No |
| Ordered Product (once per line item) | Server-side | No |
| Fulfilled Order | Server-side | No |
| Fulfilled Shipment | Server-side | No |
| Cancelled Order | Server-side | No |
| Refunded Order | Server-side | No |
| Active on Site | Onsite JavaScript | Yes |
| Viewed Product | Onsite JavaScript | Yes |
| Added to Cart | Onsite JavaScript | Yes |
| Started Checkout | Onsite JavaScript | Yes |
The practical read: your post-purchase flows (order confirmations, shipping notifications, win-back, refunds) run on server-side events and are safe on Hyva out of the box. Your pre-purchase flows, the ones that drive the most revenue (browse abandonment, cart abandonment, back-in-stock), depend on onsite events, and those are the ones a Hyva migration can quietly break. The event names above are documented in Klaviyo’s Magento 2 data reference, which is the source of truth for what fires and when.
Why the stock extension’s onsite tracking breaks on Hyva
The official Klaviyo extension injects its browsing tracking through the Luma frontend, which relies on RequireJS and Knockout. Hyva removes that entire stack and renders with Alpine.js and Tailwind instead. So the code paths the extension uses to observe a product view or an add-to-cart click do not exist on a Hyva storefront. The extension installs cleanly, the server-side sync runs, and the browsing events simply never fire.
This failure is silent, which makes it dangerous. Nothing errors. Placed Order still flows, so a quick test looks fine. What is missing shows up weeks later as browse-abandonment and cart-abandonment flows that stopped converting, because they never receive the Viewed Product and Added to Cart signals that trigger them. A store that migrated to Hyva and saw its abandonment revenue drift down often has exactly this cause. The fix is not to abandon Klaviyo or downgrade the theme. It is to add the Hyva compatibility layer that re-implements the onsite tracking in Alpine.
Installing the Klaviyo extension the right way
Before the Hyva-specific work, get the base integration correct. The official module is Klaviyo_Reclaim, installed with Composer rather than from the admin marketplace, which means you need server access or a developer to run it.
- Install with
composer require klaviyo/magento2-extension, then enable and run setup upgrade through the CLI. The official extension repository is the canonical source. - Magento versions below 2.4.0 are not supported, so confirm your platform version first.
- Connect the account with your Klaviyo public and private API keys, then let the initial historical sync run. After that first sync, the integration refreshes on a schedule, roughly every 30 minutes.
Getting this base layer right is ordinary Hyva development work, but do not treat the green checkmark on the setup wizard as proof the integration is complete. On Hyva it proves only that the server-side half works.
The Hyva compatibility modules you actually need
Here is the detail that separates a working Hyva integration from a half-broken one: there are two compatibility modules, not one, and they cover different surfaces.
| Module | What it restores | When you need it |
|---|---|---|
hyva-themes/magento2-klaviyo-reclaim |
Onsite tracking (Viewed Product, Added to Cart, Active on Site) rendered in Hyva without breaking layout | Every Hyva store running Klaviyo |
hyva-themes/magento2-hyva-checkout-klaviyo-reclaim |
Started Checkout tracking and email/SMS consent capture on Hyva Checkout | Stores using Hyva Checkout that want checkout-stage events and consent |
The first module is the one most teams miss. It re-implements the browsing events so they fire from Hyva’s Alpine components, and it is designed not to disturb the theme’s layout. The second is a separate integration for Hyva Checkout, the dedicated checkout that many Hyva stores adopt, and it handles the Started Checkout event plus the consent checkboxes that keep your list compliant. If you run Hyva Checkout and install only the frontend module, you capture browsing behaviour but lose checkout-stage events and consent capture. Confirm which checkout you run and install the matching module. Verifying and adapting third-party modules so they coexist in a Hyva build is the same integration discipline behind Bemeir’s broader technology partner ecosystem, where every add-on has to render in the theme and hold its performance budget.
Placing klaviyo.js on Hyva without wrecking Core Web Vitals
Active on Site tracking turns on the moment Klaviyo’s onsite script loads, and that script has to be on every page. It loads from a per-account URL of the form https://static.klaviyo.com/onsite/js/PUBLIC_API_KEY/klaviyo.js, and it only needs to load once per page. On Luma this is an afterthought. On Hyva, where the entire point is a lean, fast frontend, how you load it matters.
Klaviyo states its JavaScript loads asynchronously and will not block the rest of the page from loading, which is true. But Klaviyo also acknowledges, in its own site-speed troubleshooting guide, that PageSpeed Insights and similar tools may still flag the script as a contributing factor. On a Hyva store measured against a strict performance budget, that flag is not noise; it is a third-party script competing for the main thread that Hyva worked to keep clear. Two practical moves keep it honest:
- Load the snippet directly, not through a tag manager. Klaviyo notes that manual installation can load its JavaScript faster than injecting it through a tag manager, which adds its own layer of blocking work.
- Defer non-critical loading so it does not compete with the hero. The script does not need to win the race with your Largest Contentful Paint element. Keeping heavy third-party JavaScript from stealing main-thread time during the initial render is the same work described in reducing Largest Contentful Paint on a Hyva storefront, and it applies directly to Klaviyo’s script.
The goal is a store where Klaviyo tracks everything you need and PageSpeed still reflects the speed a Hyva build delivered. That is achievable, but only if the script placement is deliberate rather than pasted in the head and forgotten.
Catalog sync at scale
The server-side catalog sync is what powers product blocks in emails (the abandoned item, recommended products, back-in-stock alerts), so it has to represent your catalog accurately. Klaviyo syncs product properties including SKU, price, categories, product ID, parent product ID, and image URLs, and it identifies products with an external_catalog_id. Two catalog realities trip merchants up:
- Configurable and parent products. A shopper views a configurable product, but the purchasable unit is a variant. The parent product ID in the sync is what lets Klaviyo tie a Viewed Product on the parent to the right catalog entry, so verify parent and child relationships resolve correctly in Klaviyo’s catalog, not just in Magento.
- Image URLs and freshness. Product images in emails pull from the synced URLs. If your media URLs change (a CDN move, a URL rewrite change), the catalog has to re-sync or emails render broken images. On a 30-minute sync cadence, plan catalog-affecting changes with that lag in mind.
At large catalog sizes the sync is generally reliable, but treat it like any other data integration: confirm the fields you actually use in flows are populated and current, rather than assuming the initial sync captured everything perfectly.
Wiring browsing events to Alpine.js
For teams doing a custom or partially headless Hyva build, the compatibility module may not cover every bespoke interaction, and this is where the Track API matters. Klaviyo exposes a JavaScript tracking interface, and in a custom frontend, Viewed Product and Added to Cart are fired by calling that interface directly rather than relying on Luma observers. On Hyva that means the add-to-cart Alpine action also has to trigger the Klaviyo track call, because the Luma-based observer the stock extension expects is not present. Klaviyo documents this pattern in its guide to a headless Magento setup, and the same thinking applies to any heavily customised Hyva theme. One version-specific gotcha to note: Added to Cart tracking requires the extension at version 4.0.0 or higher, and the shopper must be cookied and identified for the event to attribute correctly.
Klaviyo is a cross-platform discipline
The two-layer model here, server-side events that are platform-native and onsite events that depend on the frontend, is not unique to Magento. Whether you run Adobe Commerce, Shopify, BigCommerce, or Shopware, Klaviyo captures orders on the server and behaviour in the browser, and the frontend is always where the tracking is most fragile. What changes per platform is how the onsite script is injected and how much of the browsing tracking is handled for you. Bemeir builds and integrates Klaviyo across all of these as part of who we are as a full ecommerce shop. And because deliverability decides whether any of these flows reach the inbox, pair the integration with proper email authentication and warmup so your Klaviyo sends are not undercut by SPF, DKIM, or DMARC gaps.
Frequently asked questions
Does the official Klaviyo Magento 2 extension work with Hyva out of the box?
Partly. The server-side events (Placed Order, Ordered Product, Fulfilled Order, Cancelled Order, Refunded Order) sync regardless of theme, so post-purchase flows work. But the onsite browsing events (Viewed Product, Added to Cart, Active on Site) were built for Luma’s RequireJS and Knockout stack, which Hyva does not load, so they silently stop firing. You need the official Hyva compatibility module, hyva-themes/magento2-klaviyo-reclaim, to restore them.
Which Klaviyo events are server-side and which need the frontend script?
Server-side and theme-proof: Placed Order, Ordered Product, Fulfilled Order, Fulfilled Shipment, Cancelled Order, and Refunded Order. Onsite JavaScript and theme-dependent: Active on Site, Viewed Product, Added to Cart, and Started Checkout. The server-side events power confirmation and post-purchase flows; the onsite events power browse and cart abandonment, which is why losing them on Hyva hurts revenue.
Will Klaviyo slow down my Hyva storefront?
Klaviyo says its script loads asynchronously and will not block the rest of the page, but it also acknowledges that PageSpeed Insights may still flag it. On a performance-first Hyva build, load the snippet directly rather than through a tag manager (Klaviyo says that loads its JavaScript faster) and defer non-critical loading so it does not compete with your hero image for the main thread during the initial render.
Do I need one compatibility module or two?
Potentially two. Every Hyva store running Klaviyo needs the frontend module, hyva-themes/magento2-klaviyo-reclaim, for onsite tracking. If you also use Hyva Checkout, you need a separate module, hyva-themes/magento2-hyva-checkout-klaviyo-reclaim, for the Started Checkout event and email and SMS consent capture at checkout. Installing only the frontend module on a Hyva Checkout store leaves you without checkout-stage events and consent.
How often does Klaviyo sync with Magento?
After the initial historical sync of your existing customers and orders, the integration refreshes roughly every 30 minutes. Server-side events like Placed Order flow through on that cadence, and the product catalog syncs on a similar schedule. Plan catalog changes, such as media URL updates, with that lag in mind so emails do not render stale product data or broken images.
The takeaway
Klaviyo on Hyva succeeds or fails on one distinction: server-side events are theme-proof and onsite events are not. Order and catalog data sync without help, but the browsing behaviour that powers your highest-revenue flows runs through JavaScript built for Luma, so on Hyva it needs the compatibility module (and a second module if you run Hyva Checkout). Install the base extension correctly, add the right Hyva modules, load the onsite script deliberately so it does not tax Core Web Vitals, and verify catalog fields your flows depend on. Do that, and Klaviyo drives browse, cart, and back-in-stock revenue on a storefront that stays as fast as Hyva made it.
