Omnichannel Attribution With Klaviyo in the Stack

Klaviyo credits orders it can associate with its own messages, inside a lookback window you configure, usually triggered by an open or a click. Meta and Google credit the same orders under their own rules and their own windows. All three are behaving correctly and their totals still cannot all describe distinct sales, because a customer who met an ad and later opened an email is a real customer who appears in several systems at once.

Where the overlap is largest

Email and SMS sit close to the purchase and are triggered by behaviour, which is the combination most likely to produce credit for sales that were already going to happen. An abandoned-cart flow reaches someone who put an item in a cart. A back-in-stock alert reaches someone who asked to be told. A post-purchase flow reaches someone who has already bought.

These are excellent programmes and the automation is genuinely useful. They are also the flows where the gap between claimed and caused is widest, because the trigger is itself a strong signal of intent. The message did not create the intent; it arrived because the intent was already visible.

The number that sizes it

Sum what every platform claims for one month, email and SMS included, and divide by the orders your store actually shipped. Above 1.0, the platforms collectively claim more orders than exist, and at least the excess share cannot each be a distinct sale.

Most brands run this arithmetic with paid platforms only and stop there. Adding the email and SMS claims is what usually pushes the ratio well past one, which is why leaving them out makes the reporting look more coherent than it is. The one-hour claim ratio audit is the procedure, and what your email platform is claiming covers the email side specifically.

What the lookback setting does to your numbers

The window is a configuration choice, not a property of the world. Widen it and attributed revenue rises without a single additional sale. Narrow it and the same programme looks worse. That means two brands running identical campaigns can report very different email revenue purely from a settings difference, and it means your own year-over-year comparison is invalid if anybody touched the setting in between.

Write the window down beside the number, the same way you would name an attribution model. A figure without its window is not comparable with anything, including itself.

The test that settles it

Randomly withhold. Take a slice of the list chosen at random rather than by engagement, exclude it from a campaign or a flow for a fixed period decided in advance, and compare revenue per recipient across the two groups. That difference is what the campaign added.

Three things make it valid. The slice must be random, because selecting by engagement rebuilds the bias you are trying to remove. The window must be fixed before you start, because stopping when the gap looks good manufactures the gap. And the list has to be large enough that the design could detect an effect worth acting on, which is worth checking before you run it rather than after. Incrementality testing for ecommerce covers the arithmetic.

Flows are harder to hold out than campaigns, because withholding an abandoned-cart email has a real cost. Start with a campaign, and hold out one flow per quarter at most.

What to run in between

A causal read on a GA4 export estimates each channel's contribution from the variation already in the data and reports an interval on each estimate. It will not resolve a single customer's journey and does not claim to; it states its coverage instead. Omnichannel attribution: one sale, every channel claiming it covers the wider stack.

What to do this week

• If you own the budget: add email and SMS claims to your claim-ratio arithmetic. Most brands leave them out and get a comfortable answer.
• If you have to defend the number: put the lookback window next to every email revenue figure in the deck.

The interactive demo shows the read on a sample store, no signup.

Platform behaviour described here is general to lookback-window attribution and is configurable per account; check your own settings. Claim-ratio material is from The Price of Being Found (Edition 2.10), Chapter 9, with the book's caveats.