Shopify LTV Tracking After Migration: What to Reconcile Before You Trust the Number

LTV tracking usually breaks quietly after a migration.

The storefront launches. Orders come in. Klaviyo keeps syncing. Reports start filling again. Then someone asks why a customer who has bought for years looks new, why a VIP segment dropped, why a winback flow picked the wrong people, or why finance and marketing are reading different customer-value numbers.

The issue is rarely one formula. It is usually the inputs behind the formula. Customer identity, historical orders, refunds, discounts, subscriptions, POS purchases, loyalty status, consent, and email events may not survive the move in the same shape. If those records change, LTV tracking changes with them.

The useful question is not "Which dashboard should we use for LTV?" The useful question is "What has to remain connected after the migration for customer value to mean the same thing?"

Start by defining what LTV is allowed to decide

Customer lifetime value is useful only when the business knows what the number is supposed to change.

Shopify's CLV guidance explains the basic customer lifetime value formula as average purchase value multiplied by purchase frequency and customer lifespan. That is a useful starting point, but it is not enough for a migrated Shopify store. A migrated store has history. It has exceptions. It may have a legacy platform, a loyalty app, a subscription app, a POS, and a Klaviyo account that all describe customer value differently.

Before rebuilding LTV tracking, decide what the metric is allowed to influence:

• VIP and high-value customer segments.
• Winback, replenishment, sunset, and post-purchase flows.
• Paid-retention audiences and exclusion lists.
• Service levels, support rules, packaging, or personal outreach.
• Merchandising and product-retention reporting.
• Finance and leadership reporting.

If LTV is only a reporting number, the migration can tolerate more delay. If it changes customer messaging or internal treatment, it needs stronger QA before launch.

Reconcile customer identity before order value

LTV depends on knowing which purchases belong to the same customer.

That sounds obvious until a migration creates duplicate customers, changes email casing, loses old customer IDs, separates POS buyers from online buyers, or imports historical orders without the customer relationship the old platform had. A dashboard may still calculate value, but it may calculate it across split people.

Shopify's Admin API treats customers and orders as structured records, which is helpful because it gives the migration a clear place to inspect identity and purchase history. But the business still has to decide what counts as the same person.

Before trusting post-migration LTV, sample customers across these cases:

• A long-term repeat buyer with a clean email address.
• A customer who has changed email addresses.
• A customer with both POS and online purchases.
• A subscription customer with renewal history.
• A loyalty member with points, tier, or reward status.
• A customer with refunds, cancellations, or returns.
• A wholesale or B2B buyer if those accounts exist.
• A duplicate customer from the old system.

For each case, compare the old system, Shopify, Klaviyo, and finance reporting. The customer does not need to look identical in every tool, but the business meaning has to match.

Keep historical orders useful without treating them as live behavior

Historical orders are important for LTV, but they can be dangerous when they start acting like fresh behavior.

Klaviyo's Shopify data reference shows how Shopify events and customer data can sync into Klaviyo, including order and product activity. That data can power segmentation and flows. During a migration, the team has to know which events are historical context and which events should trigger customer-facing action.

That distinction matters because imported history can distort lifecycle logic:

• A customer may look newly active when the order is old.
• A backfilled order may enter a post-purchase or replenishment rule.
• A subscription renewal may appear without its original contract context.
• POS purchase history may be missing or over-counted.
• Returns and refunds may not offset customer value the same way they did before.

Do not let imported history quietly enter live customer messaging. Tag or document the migration source, define the import window, and test whether Klaviyo flows, Shopify segments, and analytics reports treat that data correctly.

Agree on gross, net, and margin definitions

LTV can mean revenue. It can mean net revenue. It can mean gross margin. It can include discounts, taxes, shipping, refunds, chargebacks, returns, gift cards, and subscription changes in different ways.

That definition has to be settled before the migration readback.

Marketing may care about lifecycle opportunity. Finance may care about net customer contribution. Merchandising may care about product category behavior. Support may care about customer treatment. Those are not always the same metric.

Create a simple value-definition table:

• Which source owns gross sales.
• Which source owns refunds and returns.
• Whether taxes and shipping are included.
• Whether discounts reduce value.
• Whether gift cards count when purchased, redeemed, or both.
• Whether subscription renewals are counted separately from original subscription starts.
• Whether POS and ecommerce orders are combined.
• Whether loyalty rewards change the customer-value view.

If the definition is unclear, do not turn LTV into a campaign rule. Keep it in reporting until the business agrees on the meaning.

Check Klaviyo before predictive and lifecycle rules act on LTV

Klaviyo can use Shopify data for profiles, events, segments, flows, and measurement. That makes it valuable after migration, but it also means bad migrated data can become customer-facing.

Before using LTV in Klaviyo, check:

• Whether the right Shopify store is connected.
• Whether historical purchase events synced as intended.
• Whether old events are excluded from live trigger rules where needed.
• Whether customer profiles merged, split, or duplicated.
• Whether refund, cancellation, fulfillment, and product events are present enough for lifecycle logic.
• Whether consent and subscription status survived the migration.
• Whether VIP, loyalty, subscription, and wholesale tags still mean what they meant before launch.

Klaviyo's conversion tracking documentation is also relevant because post-migration performance readback depends on attribution windows and conversion settings. If conversion tracking changes at the same time as the commerce platform, the team may confuse a tracking definition change with a retention performance change.

Build the first readback around real customer cases

A migration QA pass should not only say that data imported. It should prove that customer value still tells the truth.

Pick 20 to 40 real customer cases before launch. Include simple repeat buyers, high-value buyers, discount-heavy buyers, refunded buyers, subscription customers, POS customers, loyalty members, inactive customers, and duplicate-risk customers. For each case, record the old system value, the Shopify record, the Klaviyo profile, the finance view, and the expected lifecycle treatment.

Then ask:

• Does the customer have the right purchase history?
• Are refunds and returns represented correctly?
• Does the same person remain connected across email, phone, account, POS, and subscription data?
• Do Klaviyo segments include or exclude the customer correctly?
• Would any flow send because of migrated history?
• Does finance agree with the reported value band?
• Can support explain the customer state without inspecting a migration file?

This gives the team a practical readback. It also creates a reference set for post-launch debugging.

What Lake House Group checks first

When Lake House Group helps a Shopify brand preserve customer-value tracking through a migration, we do not start with a new dashboard.

We start with the operating contract:

1. Which systems own customer identity, historical orders, refunds, subscriptions, loyalty, POS behavior, and consent.
2. Which customer-value definition leadership, finance, marketing, and service teams will use.
3. Which old records are context only and which records are allowed to trigger new lifecycle work.
4. Which customer cases must pass before launch.
5. Which post-launch reports will be checked after the first week, first renewal cycle, and first campaign cycle.

That order keeps LTV tracking useful. It protects the team from celebrating a clean dashboard while the underlying customer history is split, incomplete, or acting on the wrong people.

If your Shopify migration touches customer history, Klaviyo, subscriptions, POS, loyalty, or finance reporting, talk to Lake House Group about getting more out of Klaviyo before the cutover. We help Shopify teams keep customer-value tracking connected to the data, systems, and lifecycle decisions it is supposed to guide.

Related reading

• Klaviyo predictive analytics for Shopify
• Klaviyo segmentation with Shopify data
• Shopify customer data migration during replatforming
• Shopify loyalty platform migration