SignalBridge
Why isn't my Klaviyo browse abandonment flow working?
A Klaviyo browse abandonment flow starts only when Klaviyo records a Viewed Product event for an identified profile. When the flow stays quiet, the cause is almost always one of three things: the shopper was never identified, the Viewed Product event never reached Klaviyo, or the flow's filters, timing, or consent rules removed the shopper afterward.
This is worth fixing. According to Klaviyo's own data, browse abandonment emails convert at 0.96%, which is 9.6x the 0.10% of the average email campaign. Across all ecommerce brands, flows generate nearly 41% of email revenue from just 5.3% of sends. A silent browse flow means you paid to attract a shopper, watched them look at a product, and never followed up.
Whether your Klaviyo Viewed Product tracking is failing completely or only for part of your traffic, use this table to match what you see to the most likely layer before reading the details:
| What you see | Most likely layer | Start with |
|---|---|---|
| The Viewed Product metric is empty or flat | Tracking (klaviyo.js, app embed, consent) | Causes 1, 5, 6 |
| Viewed Product exists, but only for a small share of your traffic | Identification and blocking | Causes 2, 3, 4 |
| Events appear on profiles but nobody enters the flow | Flow trigger and filters | Cause 7 |
| People enter the flow but no emails go out | Eligibility, Smart Sending, status | Causes 8, 9 |
| Emails send but the product block is blank | Template variables | Step 4 below |
How the Klaviyo browse abandonment trigger actually works
Every browse abandonment email depends on a chain of seven links. A failure at any one of them looks identical from the outside: the flow simply does not send.
Shopper opens a product page
1. klaviyo.js loads (on Shopify: the Klaviyo app embed)
2. The __kla_id cookie identifies the browser
(Klaviyo form, email or SMS click, or checkout)
3. Klaviyo records "Viewed Product" on that profile
4. The profile passes the trigger filters
5. The flow's time delay elapses (Klaviyo recommends at least 1 hour)
6. The profile is eligible and not skipped
7. The email sends
Two facts from Klaviyo's documentation explain why this flow breaks more often than your abandoned cart or checkout flows:
- Klaviyo only tracks browsing for identifiable browsers. Browsers that have not been cookied (by submitting a form, clicking a Klaviyo email, or going through checkout) generate no Viewed Product events.
- Viewed Product depends on Klaviyo's own snippet. In the Shopify data reference, Active on Site and Viewed Product are the two events Klaviyo tracks through its installed snippet. Events such as Placed Order and Started Checkout sync through Shopify's integration instead. That is why your checkout flow can run perfectly while your browse flow stays silent.
9 reasons your Klaviyo browse abandonment flow isn't triggering
Cause 1: Viewed Product tracking or the app embed is switched off
On Shopify, Klaviyo adds Viewed Product tracking only when the Klaviyo app embed is toggled on and the Viewed Product setting is checked in the integration, per Klaviyo's troubleshooting guide. Theme changes, theme swaps, and republishing can quietly switch the embed off.
Check: Open your theme editor, go to App embeds, and confirm Klaviyo onsite tracking is on. Then open the Shopify integration settings in Klaviyo and confirm the Viewed Product option is checked.
Cause 2: The shopper was never identified
Klaviyo records onsite activity for identifiable browsers only. A browser becomes identifiable when the visitor:
- Submits a Klaviyo signup form
- Clicks a link in a Klaviyo email or SMS
- Goes through checkout (with anonymous activity tracking enabled, earlier browsing is then added to the profile)
A cold visitor who never does any of those is not a failure of your setup. Nobody knows their email address, so there is nobody to email. This is a major reason Viewed Product counts look low next to your analytics page views, and no tracking method changes it.
Cause 3: The Klaviyo cookie expired or was blocked by the browser
When a shopper is identified, Klaviyo stores the identity in the __kla_id cookie. How long that cookie survives depends on the browser. These are the lifetimes from Klaviyo's cookie documentation:
| Browser | Standard __kla_id lifespan | With First Party ID |
|---|---|---|
| Safari | 24 hours if the URL has query parameters or fragments and Safari treats Klaviyo as a known tracker; otherwise 7 days | Up to 7 days |
| Brave | Blocked, unless Shields Down mode is on (then 7 days) | Same |
| Firefox | 45-day limit, but purged by daily tracker-classification checks | Same |
| Chrome | 400 days | Up to 400 days |
| Edge | Up to 2 years (Klaviyo's setting, not an Edge restriction) | Up to 2 years |
Paid landing pages almost always carry query parameters (UTMs, gclid, fbclid), so the stricter 24-hour Safari window can apply to exactly the shoppers you paid to acquire. Once the cookie expires, a returning shopper is anonymous again until something re-identifies them.
Klaviyo offers two mitigations. Extended ID re-identifies returning visitors using identifiers other platforms already placed in the browser. First Party ID serves the cookie from a subdomain of your store (it needs a DNS CNAME to Klaviyo) and refreshes it on every visit. Neither creates new profiles, neither works after a visitor clears all cookies, and both need an existing Klaviyo profile to re-identify.
Cause 4: An ad blocker or privacy browser blocks klaviyo.js
If the script never loads, no Viewed Product event can fire. Klaviyo says so directly in its funnel analysis troubleshooting article: even fully identified shoppers "may use different devices and browsers, use ad blockers that prevent onsite tracking from firing", which creates a gap between onsite tracking and the server-side events your ecommerce integration reports.
The scale is not small. An estimated 1.1 billion people use ad blockers worldwide, and 29.5% of internet users aged 16 and over say they use one at least sometimes. The share of your own visitors who block depends on your audience and devices. Every one of those shoppers can browse your catalog without ever producing a Viewed Product event.
Cause 5: Consent rules suppress onsite tracking
Klaviyo notes that, depending on your Shopify Customer Privacy settings, it may not track onsite events for visitors in the EU, EEA, UK, and Switzerland unless they consent. Those shoppers never enter your browse flow. A consent management platform that blocks Klaviyo's script until the visitor opts in has the same effect.
This one should not be "fixed" by working around consent. The right response is to check that your banner is configured correctly, that Klaviyo's cookies are categorized the way your legal counsel advises, and that consenting visitors are tracked properly.
Cause 6: A theme update, app conflict, or duplicate script broke the snippet
Klaviyo documents that a BigCommerce store connected to multiple Klaviyo accounts can end up with duplicate klaviyo.js, which can break Viewed Product tracking. Theme edits, new apps, and platform migrations can cause similar breakage, and Klaviyo's guidance is to contact support if tracking stops after you change your site.
Check: Open a product page in a clean browser profile, open DevTools, switch to the Network tab, and filter by "klaviyo". You should see klaviyo.js load once with a successful status. No request means the snippet is missing or blocked. Multiple requests suggest duplicate installs.
Cause 7: The flow's trigger filters exclude the shopper
Klaviyo's recommended filters for a browse abandonment flow are:
- Placed Order zero times since starting this flow
- Started Checkout zero times since starting this flow
- Has not been in this flow in the last 30 days
- Added to Cart zero times since starting this flow (only if you also run a cart-triggered flow)
Problems start when extra filters pile on (for example, requiring several product views), when a product-specific trigger filter is too narrow, or when you test the flow with your own profile. If you ordered recently or went through the flow in the last 30 days, you are filtered out, and you conclude the flow is broken when it is working as designed.
Cause 8: The profile is skipped or cannot receive email
A profile can enter the flow and still never get the email. In the flow message, open the Skipped dropdown. Klaviyo lists the reasons, including:
- Smart Sending: the profile received another email too recently. The default email window is 16 hours.
- Fails flow filters: the profile no longer met the criteria at send time.
- Missing email: the profile has no email address.
Unsubscribed or suppressed profiles also cannot receive flow emails unless the message is transactional. Never-subscribed profiles can still receive flow emails, which you can restrict with the "Person can receive email marketing" filter if your compliance rules require it.
Cause 9: The message is not Live, or the delay hides it
Flow messages in Draft status send nothing and do not queue anyone. Messages in Manual status queue profiles under Needs Review but never send until you approve them. Klaviyo also recommends a time delay of at least one hour, so testing by browsing a product and waiting ten minutes proves nothing. Set the message to Live and test with a longer window.
Which of the 9 causes can server-side tracking fix?
Server-side delivery changes one thing: how the Viewed Product event reaches Klaviyo. Instead of depending on klaviyo.js running in the shopper's browser, SignalBridge sends the event to Klaviyo's Events API from its own servers. That fixes some causes and cannot touch others:
| # | Cause | Fixed by server-side delivery? | Why |
|---|---|---|---|
| 1 | App embed or Viewed Product tracking off | Yes, once the flow is re-triggered | The event no longer depends on the embed |
| 2 | Shopper never identified | No | Klaviyo needs an email, phone, or ID; no server can invent one |
| 3 | __kla_id cookie expired or blocked | Yes, for shoppers who can be identified | Identity travels with the event instead of living in the cookie |
| 4 | Ad blocker blocks klaviyo.js | Yes | Klaviyo's script is no longer a single point of failure |
| 5 | Consent not granted | No, by design | Events are forwarded only when marketing consent allows |
| 6 | Theme update or duplicate script | Yes, as a safety net | Delivery is independent of the theme (still fix the embed) |
| 7 | Flow filters exclude the shopper | No | Configuration problem |
| 8 | Profile skipped or suppressed | No | Configuration and consent problem |
| 9 | Message in Draft or delay too short | No | Configuration problem |
The identification requirement, stated plainly
Server-side delivery helps only when the event itself carries an email address or phone number. SignalBridge does not forward Viewed Product events for anonymous browsers, because Klaviyo's Events API requires at least one profile identifier.
On Shopify, SignalBridge's Web Pixel attaches the customer's email and phone when Shopify exposes them: a logged-in customer account, or contact details submitted during checkout. On a product page, that means logged-in customers. For sites using the SignalBridge script, identity comes from details the visitor entered earlier in the same session.
So how much you gain depends on how many of your product views come from identifiable shoppers: customers with accounts, returning buyers who sign in, subscribers who log in. Measure that gap (Step 5) rather than assuming it.
What a server-side Viewed Product event looks like
SignalBridge maps its ViewContent event to a Klaviyo metric named Viewed Product - SignalBridge SS and sends it through the Events API. Here is an abridged example of the payload:
{
"data": {
"type": "event",
"attributes": {
"properties": {
"$value": 89,
"Currency": "USD",
"URL": "https://example.com/products/merino-crew-sweater",
"ProductName": "Merino Crew Sweater",
"ProductID": "8123456789",
"SKU": "MCS-NAVY-M",
"ImageURL": "https://cdn.shopify.com/s/files/merino-crew.jpg",
"Price": 89,
"Brand": "Example Co",
"Categories": ["Sweaters"]
},
"metric": {
"data": {
"type": "metric",
"attributes": { "name": "Viewed Product - SignalBridge SS" }
}
},
"profile": {
"data": {
"type": "profile",
"attributes": { "email": "shopper@example.com" }
}
},
"time": "2026-10-08T14:03:22.000Z",
"value": 89,
"unique_id": "a1f3c9e2-7b4d-4c1a-9e55-0d2f8b6a7c31"
}
}
}
Three details matter for your flow:
- The property names match Klaviyo's documented Viewed Product snippet (
ProductName,ProductID,SKU,ImageURL,URL,Brand,Price,Categories), so product blocks have the data they expect. - The
unique_idmakes retries safe. Klaviyo deduplicates on the combination of profile, metric, andunique_id, so a retried delivery is recorded once. - Delivery is durable. Events go into an encrypted outbox and are retried on rate limits and provider errors, instead of being lost if Klaviyo is briefly unavailable.
How to fix a silent browse abandonment flow: 5 steps
Step 1: Run Klaviyo's official tracking test
Before changing anything, find out which layer is failing. This takes about five minutes.
- Open a private window (or a browser profile with no cookies).
- Visit your store with
?utm_email=you@yourdomain.comadded to the URL. Klaviyo's team recommends this as the way to identify yourself for testing, because Viewed Product tracking only records browsers that have been cookied. - Browse two or three product pages.
- In Klaviyo, open your test profile's activity feed, or go to Analytics, then Metrics, and search for Viewed Product.
Read the result like this:
| Result | What it means | Go to |
|---|---|---|
| Viewed Product appears | Tracking works in a clean browser; real shoppers fail on identification, blockers, or flow setup | Steps 2–4 |
| Nothing appears | The snippet or consent setup is broken | Causes 1, 5, 6 |
| Appears normally, but vanishes with your ad blocker on | Confirmed Cause 4 | Step 4 |
As a control, also check Started Checkout in your metrics. Klaviyo's troubleshooting guide suggests this comparison for WooCommerce and Magento: if Started Checkout tracks but Viewed Product does not, the problem is in onsite tracking rather than the whole integration.
Step 2: Audit the flow configuration
Open the flow and compare it to Klaviyo's recommended setup:
| Setting | What to check |
|---|---|
| Trigger | Viewed Product metric |
| Profile filters | Placed Order, Started Checkout (and Added to Cart if relevant) zero times since starting this flow; not in this flow in the last 30 days |
| Time delay | At least one hour |
| Message status | Live (not Draft or Manual) |
| Smart Sending | On, as Klaviyo recommends for browse abandonment emails |
| Skipped dropdown | Review the skipped reasons for every message |
Also confirm the product block in your email is set to Static. Klaviyo notes that browse abandonment messages need a static block, while abandoned cart messages use a dynamic one, and copying the cart template across is a common mistake.
Step 3: Close the identification and consent gaps
This step covers Causes 2, 3, and 5, which no tracking tool can fix for you:
- Add identification points. Signup forms, email and SMS links, and checkout all identify visitors. Enable anonymous activity tracking so earlier browsing is added to the profile once the visitor is identified.
- Turn on Extended ID (available on all Klaviyo plans, no DNS changes) and consider First Party ID (needs a CNAME). Update your cookie notice when you do, as Klaviyo advises.
- Review consent. Check your Shopify Customer Privacy settings and how your consent banner categorizes Klaviyo's cookies. See our guide to server-side tracking and GDPR for how consent applies to server-side events.
Step 4: Add server-side Viewed Product delivery
This covers Causes 1, 3, 4, and 6. The full walkthrough is in our Klaviyo server-side tracking setup guide. In short:
- In Klaviyo, go to Settings, then API Keys, and create a Private API Key with Events: Write and Accounts: Read access.
- In your SignalBridge dashboard, open Pixel Settings, find Klaviyo, and paste the key. SignalBridge validates it automatically.
- Browse a product while logged in to a test customer account, then confirm Viewed Product - SignalBridge SS appears in that profile's activity feed.
- In Klaviyo, clone your browse abandonment flow and change the trigger to Viewed Product - SignalBridge SS. Keep the same filters and delay.
- Check the email template, then set the cloned flow to Live.
Watch the template tags. Klaviyo's build-your-own walkthrough uses {{ event.Name }} for the product name. SignalBridge events carry ProductName, matching Klaviyo's documented Viewed Product snippet, so if a cloned email shows a blank product name, change the tag to {{ event.ProductName }}. The reliable method is to open a real event in the activity feed and copy the exact property names.
Step 5: Run both flows and measure for 14 to 30 days
Because the metric names differ, your original flow keeps running untouched and the new one runs beside it. After two to four weeks, compare in Klaviyo Analytics:
- Event counts: Viewed Product versus Viewed Product - SignalBridge SS for the same period. The extra events SignalBridge captured are your recovered trigger volume.
- Flow entries: how many more shoppers entered the cloned flow.
- Revenue per recipient and total revenue for each flow.
To avoid emailing one shopper twice, keep Smart Sending on in both flows. You can also add a filter to the cloned flow using Klaviyo's "has received email from flow" condition, so shoppers who already got the native browse email are skipped.
What to expect: the revenue math
Take Klaviyo's average 0.96% browse abandonment order rate. Every 1,000 additional shoppers who receive the flow produce about 10 extra orders. At an $80 average order value, that is roughly $770 in recovered revenue per 1,000 shoppers.
The unknown in that formula is how many extra shoppers server-side delivery adds, and that varies by store. High desktop traffic raises ad-blocker exposure. Lots of logged-in repeat customers raises the identifiable share. A large EU audience means consent decides more of the outcome. One server-side vendor's published case study reports Klaviyo missing 77% of product-view events on one store. Treat that as an upper-end example, not a forecast. Your own A/B comparison in Step 5 is the number that counts.
Troubleshooting after you add server-side events
| Symptom | Likely cause | Fix |
|---|---|---|
| No "- SignalBridge SS" events on any profile | Visitor not identified or consent denied | Test while logged in to a customer account with marketing consent granted |
| SS events appear but the cloned flow never starts | Trigger still points at the native metric, or the flow is not Live | Re-check the trigger and status |
| Product name shows blank in the email | Template uses event.Name | Use {{ event.ProductName }} |
| Shoppers receive two browse emails | Both flows are live | Keep Smart Sending on and add a "received email from flow" filter |
| SignalBridge asks you to reconnect Klaviyo | API key revoked, or missing Events: Write | Create a new key with the right scopes and reconnect |
FAQ
Why is my Klaviyo browse abandonment flow not triggering?
Check seven links in order: the Viewed Product event must be recorded, for an identified profile, that passes your trigger filters, waits out the time delay, is eligible to receive email, and is not skipped. Start with Klaviyo's ?utm_email= test to see whether the event is being recorded at all, then audit the flow's filters, status, and Skipped reasons.
Does Klaviyo browse abandonment work for anonymous visitors?
No. Klaviyo records Viewed Product only for identifiable browsers, meaning visitors who submitted a Klaviyo form, clicked a Klaviyo email or SMS link, or went through checkout. Anonymous visitors cannot be emailed because no address is known. With anonymous activity tracking enabled, their earlier browsing is added to the profile once they are identified.
How do I test Klaviyo Viewed Product tracking?
Open a private window and visit your store with ?utm_email=your@email.com appended to the URL, then browse a few product pages. In Klaviyo, check your profile's activity feed or the Viewed Product metric under Analytics. If the event appears, tracking works in a clean browser and the problem lies with identification, blockers, or flow setup.
Why are my Viewed Product events lower than my product page views?
Because analytics tools count every visitor while Klaviyo counts only identified ones. Anonymous visitors, shoppers with ad blockers, Safari and Brave users whose __kla_id cookie expired or was blocked, and EU visitors who have not consented all produce page views without Viewed Product events. Klaviyo itself says these behaviors create a gap between onsite tracking and server-side data.
Can server-side tracking fix Klaviyo browse abandonment?
Partly. Server-side delivery fixes blocked scripts, a missing app embed, theme conflicts, and cookie expiry for shoppers who can be identified, because the event no longer depends on klaviyo.js. It cannot fix anonymous visitors, missing consent, flow filters, or suppressed profiles. It only sends events that carry an email address or phone number.
How long should the delay be in a Klaviyo browse abandonment flow?
Klaviyo recommends a time delay of at least one hour. Because viewing a product signals less intent than adding to cart, Klaviyo also suggests making browse abandonment messages a lighter touchpoint than your abandoned cart flow. Test different delays with a flow split and compare revenue per recipient.
Does server-side tracking bypass Klaviyo's consent requirements?
No. SignalBridge forwards events to Klaviyo only when the shopper's marketing consent allows it. Server-side delivery changes how an event travels, not whether you have permission to use it. Consent denials remain a limit on your audience, which is why Cause 5 appears in the "not fixed" column above.
Related reading
- How to Set Up Klaviyo Server-Side Tracking with SignalBridge — the full setup walkthrough for the server-side events used in this guide
- Ad Blocker Usage Statistics 2026 — how many shoppers never load klaviyo.js
- Shopify Facebook Pixel Not Working? Here's How to Fix It — the same blocked-pixel problem on the ad side
- What is Ad Blocker Tracking Loss? (And How to Fix It) — what blocked scripts cost you beyond email
- Server-Side Tracking and GDPR: Complete Compliance Guide — how consent applies to server-side events
- Client-Side vs Server-Side Tracking: Complete Guide (2026) — where each approach breaks
- Server-Side Tracking for Shopify: Complete 2026 Guide — the Shopify Web Pixel and server-side delivery explained
- How to Build a First-Party Data Strategy for E-Commerce — the bigger picture behind identified shopper data
- What is Server-Side Tracking? — the foundational guide
Related Articles
How to Set Up Klaviyo Server-Side Tracking with SignalBridge
Set up Klaviyo server-side tracking in 1 minute. Recover browse and cart abandonment events that ad blockers hide from Klaviyo's native snippet — no code required.
Facebook Conversions API Setup for E-Commerce: Complete Guide (2026)
Learn how to set up Facebook Conversions API for your e-commerce store. Step-by-step setup guide covering Shopify, WooCommerce, and custom stores with server-side event delivery.