Every Klaviyo guide for D2C email personalization lists the same tactics: segment by payment method, target frequent returners differently, send loyalty tier nudges, align content to buying stage. The problem isn't the tactics — it's that none of them work until the underlying data is in Klaviyo. On a Shopify + Odoo stack, most of that data isn't there by default. You can build the segment, configure the flow, and set it live, and it will fire on an empty audience for months while you assume the strategy isn't working. The real issue is that five specific data properties were never wired up.
TL;DR: Email personalization on Shopify + Odoo fails at the data layer. BNPL segmentation, return targeting, loyalty tier nudges, and buying stage alignment all require Klaviyo customer properties that don't sync automatically. Audit these five gaps before building any new flow. If you want our integration map for your specific stack, book a 30-min call with Mayur — no SDR layer.
Why the Data Layer Is Where Personalization Actually Breaks
A martech blog will tell you to implement BNPL segmentation by creating a Klaviyo segment for customers who used buy-now-pay-later and sending them different post-purchase content. That advice is correct. What it skips is that Klaviyo needs a customer property called something like payment_method_type with a value of "BNPL" before that segment has any members. That property doesn't exist in Klaviyo by default. Shopify sends payment_gateway on order creation, but it doesn't automatically land as a Klaviyo customer property — it needs an explicit mapping step.
This gap is specific to the integration layer, not the Klaviyo configuration. The same pattern repeats across return history, loyalty tiers, cross-channel orders, and browse behavior. Each tactic assumes Klaviyo has data it was never given. Our Odoo and Shopify integration work surfaces this consistently: brands build sophisticated Klaviyo flows on customer properties that simply don't exist in their account yet.
Running this audit before building flows is the difference between a personalization program that sends revenue-generating emails and one that silently fires on zero subscribers for a quarter.
Gap 1 — Payment Method (BNPL vs. Full-Price)
The tactic: segment customers who used ShopPay Installments, Afterpay, or Klarna and send them content that acknowledges the installment context — no urgency language around cost, payment plan reminders if relevant, different cross-sell framing.
What Klaviyo actually has: the Placed Order event includes a payment_gateway property with values like shopify_payments, shop_pay_installments, afterpay-paymentsense, or klarna. But Klaviyo's native segmentation works on customer-level properties, not event properties alone — and the event property alone doesn't let you build a persistent segment of "BNPL customers."
The fix: a Shopify Flow automation on order creation that checks payment_gateway and calls the Klaviyo v3 profiles API to set a custom customer property payment_method_type to "BNPL" or "full_price." Takes 90 minutes to configure, runs automatically on every subsequent order, and retroactively populates for historical orders via a one-time API script. Once the property exists, the segment is immediate.
A $6M fashion D2C brand we work with built a BNPL-specific post-purchase sequence in Klaviyo, set it live, and saw zero sends for six weeks. The segment had zero subscribers. The property had never been created. After the Shopify Flow fix, the segment had 2,400 subscribers within 48 hours of the retroactive backfill, and the flow started sending on the next order cycle.
Gap 2 — Return History (Odoo → Klaviyo)
The tactic: identify customers who've returned one or more products and send them pre-purchase content that addresses fit, formulation, or compatibility concerns — the information that would have prevented the return in the first place.
What Klaviyo actually has: nothing. The native Klaviyo–Shopify integration tracks refunds at the order level (a Refunded Order event), but physical return processing happens in Odoo — the inventory return, the quality check, the restock. Those Odoo events don't reach Klaviyo. The Shopify refund and the Odoo return are often not even triggered at the same time, especially for brands that process refunds proactively before the return arrives at the warehouse.
The fix: an Odoo automation rule triggered on stock return validation that calls the Klaviyo v3 profiles API to update return_count and last_return_date on the customer profile. For brands using Make or Zapier as an integration layer, a trigger on the Odoo stock.return.picking model validation event achieves the same result. Once the property is being written, the Klaviyo segment for "has returned at least once" becomes reliable — and the return-targeted educational flow stops sending to customers who've never had a return issue.
Each of these gaps takes 1-3 hours to close once identified.
We run this audit as part of Shopify + Odoo integration scoping. If you want our full data-flow map for your stack — including which Klaviyo properties are populated, which are empty, and which flows are silently firing on zero subscribers — grab 30 minutes with Mayur. Written brief inside a week.
Gap 3 — Loyalty Tier (Odoo → Klaviyo)
The tactic: send precise loyalty progression nudges — "You're $18 away from Gold status" — triggered by tier proximity, not just generic points reminders.
What Klaviyo actually has: depends entirely on which loyalty platform is in use. Brands using Smile.io or LoyaltyLion with their native Klaviyo integrations get loyalty tier data pushed automatically — those integrations are built for this. The problem appears for brands that manage loyalty tiers in Odoo's loyalty program module (common in brands that have migrated from a standalone loyalty platform, or that use Odoo's built-in points system for operational simplicity).
Odoo's loyalty module updates point totals and tier assignments but doesn't push those changes to Klaviyo. A customer crossing from Silver to Gold in Odoo stays at Silver in Klaviyo until someone manually updates it or an integration fires. The tier-nudge email — the "you're $18 away" message — fires against stale tier data, sending Gold nudges to customers who are already Gold and missing customers who are genuinely close to the threshold.
The fix: an Odoo automation rule on loyalty card tier update that calls the Klaviyo profiles API to sync loyalty_tier and loyalty_points. For the proximity nudge specifically, a scheduled Odoo action that runs nightly, checks customers within a defined points range of the next tier, and updates a Klaviyo property points_to_next_tier — then Klaviyo's trigger fires on property change rather than a schedule.
For the broader picture of what Odoo data should flow into email and marketing channels, our post on marketing automation running on broken data covers the upstream problem — when Odoo itself has data quality issues, fixing the integration doesn't help.
Gap 4 — Browse and Buying Stage (Shopify Pixel Accuracy)
The tactic: align email content to where the customer is in their decision process — browsing, comparing, deciding. Send educational content to browsers, comparison guides to customers who've viewed multiple variants, conversion-focused content to repeat visitors who haven't purchased.
What Klaviyo actually has: Klaviyo's browse abandonment flow relies on the Viewed Product event, which the Shopify–Klaviyo web pixel fires when a product page loads. The issue: for logged-in Shopify customers, the pixel initializes before the customer session cookie is fully restored on page load. This means the Viewed Product event fires without an associated customer identity — it's an anonymous event, not tied to the Klaviyo profile, and the browse abandonment flow never triggers.
The scope of this problem varies by store: brands with fast-loading product pages on good CDNs see smaller gaps (10-15% of eligible sessions missed) while stores with slower page loads or heavy apps blocking pixel initialization see 30-40% gaps. Check it by comparing Klaviyo's Viewed Product event volume against Shopify's product page session count for logged-in users over the same period. If Klaviyo is capturing less than 70% of those sessions, the pixel timing is off.
The fix: add an explicit Klaviyo identify call in the Shopify theme's customer-section rendering, before the pixel fires, to ensure the customer identity is established before any behavioral events are sent. Klaviyo's implementation guide covers this, but it's not the default configuration and most Shopify themes don't include it out of the box.
Gap 5 — Cross-Channel Purchase History (Shopify + Odoo as Unified Source)
The tactic: segment by true customer knowledge level — first-time buyer vs. repeat buyer vs. brand advocate — and match email content to that relationship depth accordingly.
What Klaviyo actually has: only Shopify orders. For D2C brands selling across Shopify, a B2B wholesale channel, and potentially Amazon or retail, Odoo is the unified order management system — but Klaviyo only sees the Shopify side. A customer who has placed eight wholesale orders through Odoo and one direct Shopify order looks like a first-time buyer in Klaviyo. They receive new-customer welcome content, first-purchase upsell sequences, and educational emails that a genuine first-time buyer needs but they find condescending.
The fix is a Klaviyo customer property sync from Odoo: a nightly scheduled action that calculates total_order_count_all_channels, total_lifetime_value_all_channels, and customer_segment (first-time / repeat / advocate based on defined thresholds) and pushes them to Klaviyo profiles. Klaviyo segments and flows then use these Odoo-sourced properties rather than Klaviyo's native order count, which is Shopify-only. For brands with significant multi-channel volume, this single property sync produces more accurate segmentation than any other change in the stack.
For Shopify-specific email automation implementations, our post on AI-powered email automations for Shopify covers the flow architecture — this data audit is the prerequisite that makes those automations send to the right people.
Frequently Asked Questions
Does Klaviyo automatically receive payment method data from Shopify?
No. Klaviyo receives order data from Shopify through the native integration, but payment_gateway is not automatically mapped to a Klaviyo customer property. The order placed event in Klaviyo includes order-level metadata, but to use payment method for segmentation you need to explicitly create a custom customer property and populate it through either a Shopify Flow automation (on order creation, update Klaviyo custom property via API) or a webhook listener. Without this mapping, any Klaviyo segment built on payment method — BNPL vs. full-price, ShopPay Installments vs. credit card — will have zero subscribers regardless of how many qualifying orders exist in Shopify.
What's the fastest way to get Odoo return data into Klaviyo?
The most reliable path for most D2C stacks is an Odoo automation rule triggered on stock return validation that calls the Klaviyo v3 profiles API to update a custom property (return_count and last_return_date) on the customer record. Alternatively, if you're using Make or Zapier to bridge Odoo and Klaviyo, a trigger on Odoo's stock.return.picking model validation event can push the update. The native Klaviyo–Shopify integration does not see Odoo returns because the refund in Shopify and the physical return in Odoo are often disconnected — Odoo processes the inventory, Shopify processes the refund, and Klaviyo sees neither unless explicitly wired.
How do I check whether Klaviyo's browse abandonment events are firing correctly for logged-in users?
Open Klaviyo's Activity Feed for a test customer, log in to your Shopify store as that customer in a separate browser tab, and browse 3-4 product pages. Within 30 seconds you should see Viewed Product events appearing in Klaviyo's Activity Feed for that customer. If you don't see them, the most common cause is the Shopify web pixel not resolving the customer session before firing the event — this happens when the pixel initializes before the Shopify customer session cookie is restored on page load. The fix is adding a Klaviyo JS identify call in the theme's customer-section rendering to establish the customer identity before behavioral events fire.
About the author
Founder & Odoo Practice Lead, Braincuber Technologies
Founder of Braincuber. Has scoped and shipped 500+ Odoo implementations for US mid-market and global brands. Takes every founder call personally — no SDR layer between buyers and the people building the system.