TL;DR
Klaviyo flows are triggered by events. If those events arrive from a browser, then every ad blocker, tracking prevention rule, and abandoned tab is a flow that silently never fires. The Klaviyo API Addon (weltpixel/module-ga4-klaviyoss) moves ten of those events to a server-to-server call that runs whether or not the browser cooperates [1]. This guide covers the install, the private key that people mix up with the public one, and the three configuration choices that shape what actually reaches Klaviyo: logged-in-only sending, whether to also fire the frontend pixel for the same events, and customer-group scoping. The addon sends events. It does not sync or enrich profiles, and that boundary matters when you plan segments.
Key Takeaways
- The addon is server-side by default and covers ten events: Placed Order, Selected Payment Method, Checkout Started, Added to Cart, Added to Wishlist, Product Searched, View Page, Viewed Product, Viewed Category, and Created Account [1].
- It requires the Google Analytics 4 PRO extension. The addon is a module inside that stack, not a standalone Klaviyo connector [1].
- Two different Klaviyo keys are involved. The server-side addon takes the private API key; the client-side Klaviyo pixel in GA4 PRO takes the public one. The addon authenticates against Klaviyo's API endpoints, which take a private key, so a public key there is not a working credential.
- "Send events only for logged in users" is a profile-count decision, not a privacy toggle. Left off, Klaviyo creates a profile for anonymous browsers that later resolve to nothing [1].
- Multi-account sending needs a private API key per account, and each additional account also needs its public key in the pixel section if you want page views reaching it [1].
- Klaviyo's current stable API revision is
2026-07-15, and that release added a top-levelbackfillflag so historical events can be recorded without firing flows [4].
Why email events belong on the server in the first place
Ad platform teams have argued about server-side tracking for years, mostly in terms of attribution and match rates. Email and SMS automation has a sharper version of the same problem that gets discussed far less.
An ad platform losing a slice of its browser events loses some optimization signal. A marketing automation platform losing the same slice of Checkout Started events loses that share of the abandoned checkout flow, one of the flows merchants rely on most. The event is not delayed or degraded. It never exists, so the flow never enters, and nothing in Klaviyo shows an error, because from Klaviyo's side that shopper simply did not start a checkout.
That is the case for moving flow-triggering events off the browser. Not accuracy in a reporting sense, but the fact that a missing trigger is a missing send. Server-side delivery originates in Magento, from the order data the store already has.
Worth separating clearly: the addon sends events. Klaviyo profile attributes, list membership, and enrichment are not part of what the addon documents [1]. If your segmentation depends on custom profile properties arriving from Magento, plan that separately.
Installing the addon
The addon requires GA4 PRO installed and configured first, and composer has been the only supported installation method across all WeltPixel products since v1.16.0 in January 2026 [1]. From your Magento root, with the WeltPixel repository already configured:
composer require weltpixel/module-ga4-klaviyoss
php bin/magento setup:upgrade
php bin/magento setup:di:compile
php bin/magento setup:static-content:deploy -f
php bin/magento cache:flush
Compatibility runs Magento 2.3.x through 2.4.9 across all editions, with multiple store views supported; PHP 8.5 and 2.4.9 support arrived in v1.17.0 on May 18, 2026 [1]. If the store is in production mode, drop to developer mode first and switch back afterward.
The addon first shipped as v1.10.1 on April 7, 2025, and required GA4 PRO 1.14.17 or higher at that point [1]. Upgrade an older PRO release before the addon goes anywhere near production.
The two keys people mix up
Configuration lives at Admin → WeltPixel → Google Analytics 4 Ecommerce PRO → Klaviyo API Settings, and the first field that matters is the private API key, generated in Klaviyo under Settings → API Keys [1].
Here is the part that costs people an afternoon. GA4 PRO also has a client-side Klaviyo pixel section, at Admin → WeltPixel → Klaviyo Pixel Tracking, and that section takes Klaviyo's public site key [2]. Two Klaviyo integrations, two different key types, in the same admin. The addon authenticates against Klaviyo's API endpoints, which take a private key, so a public key there is not a working credential. Requests fail at Klaviyo's door, which you will see in the log file and nowhere else, if the file log is enabled.
The pixel section is not optional decoration either. The addon's own guide directs you to set Enable Klaviyo Pixel Tracking to Yes, with the public key in place, before configuring the server-side events [1].
Three decisions that shape your Klaviyo account
Everything after the key is a choice, and each one has a downstream consequence you will live with.
Should events fire only for logged-in users? Klaviyo automatically creates a new profile when it receives an event for a browser it cannot resolve to an email address [1]. Set "Send events only for logged in users" to Yes and the addon does not send those events at all: lower event volume, cleaner profile count. Set it to No and you capture guest behavior at the cost of profiles that may never resolve. Stores watching their Klaviyo profile count usually want Yes; stores running heavy guest checkout with browse abandonment flows usually want No.
Should the same events also fire through the frontend pixel? There is an advanced option to send enabled events via the frontend Klaviyo tracking as well, framed in the documentation as data enrichment in some cases [1]. Treat it as a deliberate exception rather than a default, because two paths for one event is the shape that produces duplicated flow entries.
Which customer groups count? The addon can be restricted to selected customer groups, added in v1.15.3 on June 20, 2025 [1]. Wholesale, staff, and internal test groups are the usual exclusions, cheap to configure now and annoying to backfill later.
For the wider question of what the server-side layer changes across the whole GA4 stack, the Magento 2 GA4 server-side tracking setup guide covers the Measurement Protocol side that this addon sits alongside.
What multi-account setups actually require
Sending the same Magento event stream to more than one Klaviyo account has been supported since v1.15.7 on September 2, 2025 [1]. Agencies running a shared Magento instance across brands hit this immediately, and so do merchants who split regional marketing between accounts.
The mechanics are plain, with one trap. Each additional Klaviyo account needs its own private API key added under the multiple-endpoints setting, and adding an account there only sends the enabled ecommerce events. Page views, which Klaviyo uses to stitch data and attribute revenue, come from the pixel section, so each additional account also needs its public key added to the Klaviyo pixel tracking field as a comma separated entry [1]. Configure only the addon side and the second account receives orders with no browsing context attached to them.
Multi-store views are supported at the platform level [1]. If you want the full documented event list behind the GA4 stack this addon sits in, the reference on which ecommerce events the GA4 extension tracks is the right page.
How do you verify events are landing?
Turn on the file log before you turn on anything else. The addon writes pushed event data to var/log/klaviyo-api.log in your Magento root [1]. Since v1.15.7 all data for a single event sits on one line rather than being spread across several, which makes grepping for an order increment ID a one-command operation [1]. Since v1.15.11, released November 25, 2025, there is also an admin interface over that log, so a marketer can inspect payloads without server access [1].
The verification sequence that catches the most problems, in order:
- Place a test order on a store view with the addon enabled, logged in as a customer in a tracked group.
- Grep the log for the order. A payload written means Magento built and sent the event.
- Open the profile in Klaviyo and check the activity feed for Placed Order. Arrival there means authentication and formatting are both fine.
- Only then look at whether a flow entered. A flow that does not trigger on an event Klaviyo clearly received is a flow filter problem, not a tracking problem.
Most tickets die at step two or three. When the log is empty, check the enabled events multiselect and the customer group restriction first, since both silently exclude traffic by design. One release worth knowing if match quality matters to you: since v1.16.1 on March 6, 2026, hashed customer data sent with the purchase event (email, phone, address) is persisted and sent alongside other triggered events for returning customers [1].
What is new on Klaviyo's side
Two changes from Klaviyo's own developer documentation matter before you plan a migration or a bulk load. The current stable API revision is 2026-07-15 [4]. Klaviyo versions by date, revisions are passed per request in a revision header, and each revision is supported for two years from release before it is retired [3], so integrations do not break when a new one publishes.
That revision added a top-level backfill flag to Create Event and Bulk Create Events, recording historical events without triggering flows [4]. Klaviyo names CRM migrations and bulk replay as the intended use. If you are moving to Klaviyo with years of Magento order history, this is the difference between a clean historical dataset and every customer receiving a two-year-old post-purchase sequence overnight. The flag applies to events you push through the API yourself, so it belongs in your migration script, not in the addon's settings.
FAQ
Do I need the Google Analytics 4 PRO extension to use the Klaviyo addon?
Yes. The addon is documented as requiring GA4 PRO to be installed and configured, and its settings live inside the GA4 PRO configuration area. The initial release also required PRO version 1.14.17 or higher [1].
Which Klaviyo API key does the addon need?
The private API key, generated under Settings → API Keys in Klaviyo, entered at Admin → WeltPixel → Google Analytics 4 Ecommerce PRO → Klaviyo API Settings [1]. The public key belongs in the separate client-side pixel section at Admin → WeltPixel → Klaviyo Pixel Tracking [2]. The two are not interchangeable.
Will server-side events duplicate my existing Klaviyo pixel events?
Only if you enable the advanced option to also send the selected events through the frontend Klaviyo tracking. By default the addon sends the selected events server-side and the Klaviyo pixel handles client-side tracking [1].
Does the addon sync customer profiles to Klaviyo?
No. The documented feature set is event tracking across ten events. Profile syncing and attribute enrichment are not part of it, so plan those through Klaviyo's own integrations or your own API work [1].
Can I send the same events to more than one Klaviyo account?
Yes, since v1.15.7 (September 2, 2025). Each account needs its own private API key, and if you want page view events for attribution in the additional account, add its public key to the Klaviyo pixel tracking field as well [1].
If your Magento store already runs GA4 and you want the same server-side reliability behind your email and SMS automation, the WeltPixel Google Analytics 4 PRO extension is the prerequisite the Klaviyo addon plugs into, and the addon adds ten server-side events on top of it. Start with the private key and the logged-in toggle, then check var/log/klaviyo-api.log before you trust a single flow.
Sources
- WeltPixel, "Klaviyo API Addon for Google Analytics 4 PRO User Guide", https://docs.weltpixel.com/KlaviyoAddon/User-Guide-WeltPixel-Klaviyo-Addon.html
- WeltPixel Google Analytics 4 User Guide, https://docs.weltpixel.com/GA4/User-Guide-WeltPixel-Google-Analytics-4.html
- Klaviyo Developers, "API versioning and deprecation policy", https://developers.klaviyo.com/en/docs/api_versioning_and_deprecation_policy
- Klaviyo Developers, "API changelog" (2026-07-15 revision: backfill flag on Create Event and Bulk Create Events), https://developers.klaviyo.com/en/docs/changelog_