Why your platforms and your store disagree about who is a new customer

Meta, Google and my store all report a different number of new customers. Which definition is right?

New customer acquisition cost is the number most ecommerce budgets are actually set against, which makes it uncomfortable that three systems in your stack report three different new-customer counts. The uncomfortable part is not that one of them is broken. It is that all three are right, and the definition is doing more work than anyone told you.

Three systems, three defensible definitions

The ad platform decides new from what it has seen. If this person is not in a customer list you uploaded and has not triggered a purchase event the platform recognised as theirs, they are new to the platform. That is a statement about the platform's memory, not about your business.

Your store decides from its own customer records. Somebody with a prior order attached to their account is returning.

Your analytics decides from whatever identity it managed to link across sessions and devices, which is a third thing again.

None of these is the true one, because they are answering slightly different questions. The problem starts when a number from one is compared against a number from another as if they meant the same thing.

The hard part is identity, not the rule

The rule is easy to state: a customer is new on their first purchase. Almost all of the difficulty is deciding which purchases belong to the same person.

A shopper buys once as a guest, then creates an account and buys again. Two customer records. Another uses one email on desktop and a different one on their phone. Another checks out with their partner's phone number. Another has their email stored with a trailing space in one system and not the other.

If your definition keys on a single identifier, every one of those cases produces a phantom new customer, and the error runs in one direction only: it always inflates new, never returning. That directionality is useful, because it means a new-customer count that looks too good usually is.

The workable approach is to treat identity as a union: the same person is anyone sharing a customer id, an email hash, or a phone hash with an order you already have, followed transitively. It is more work than a group-by and it is the only version that survives guest checkout.

A lookback window turns loyal customers into new ones

This one is worth spelling out because it looks so reasonable when you write it. To decide whether an order is someone's first, you need their order history, and history queries are expensive, so you bound them: look back twelve months, or twenty-four.

The moment you do, a customer whose previous purchase falls outside the window becomes new again. A buyer who orders every Christmas resets annually, not because of anything they did, but because of the size of your window. And the failure is invisible: nothing errors, the number just drifts upward and looks like growth.

We got this wrong in our own pipeline and the fix is the only correct one: compute the sequence over the customer's entire history, with no window at all. If you need a bound for performance, bound the list of orders you display, never the history you use to decide who is new.

The same mistake has a subtler form. If you derive first-order status from a page of results rather than from the full history, every repeat buyer whose first order fell outside that page becomes a new customer. Paging is not a window, but it behaves like one.

Refunds change who is new

If someone's first order was cancelled or fully refunded, is their next order their first? Both answers are defensible. What is not defensible is answering differently in different places, because then the same person is simultaneously new in your dashboard and returning in the audience you uploaded to Meta.

Pick a rule, write it down, and make sure the exclusion lists, the reporting and the lookalike seeds all read the same one.

The comparison trap that manufactures a gap

This is the most common false alarm in the whole subject, and it is worth recognising on sight.

You are comparing what Meta claims against what your store recorded, the numbers are far apart, and somewhere on the page a new-customer filter is switched on. That filter narrows your side to first-time buyers. It does not narrow Meta's side, because Meta is reporting all the purchases it believes it drove. You are comparing a subset against a whole and reading the difference as a discrepancy.

The fix is not subtle: run any platform comparison with the filter off. Then use the filter separately, for the question it is genuinely good at, which is whether your prospecting is bringing in people you did not already have.

A diagnostic you can apply to your own numbers

There is a useful asymmetry hiding in all of this. Merging two identity records can only ever move a customer from new to returning, because adding history to a person can only push an order further down their sequence. It can never do the reverse.

So if your new-customer count rises without a matching rise in traffic or orders, the likely cause is not new customers arriving. It is identities coming apart: records that used to be linked are now separate, and one person is being counted as several. That direction of movement is always the one to distrust, and it is checkable by sampling a few of the new customers and looking for an older order under a different identifier.

Why this costs money and not just accuracy

Three consequences, in rough order of expense.

A value-based lookalike audience seeded with people who are already your customers teaches the platform to go out and find more people like your existing base. You then pay prospecting rates to reach an audience shaped by the customers you already had.

An exclusion list built on a broken definition does not exclude the people you meant to exclude, so the retention budget and the acquisition budget compete for the same person.

And the acquisition cost you report is wrong in the flattering direction, because the denominator is inflated with buyers you already had. That is the number the next budget gets set against.

The version that holds

Define new once: first settled order, computed over the customer's whole history, with identity resolved as the union of every identifier that links two orders to one person. Apply that one definition in the dashboard, in the audiences you upload, and in the exclusions.

Then, when comparing against a platform, either apply the filter to both sides or to neither. A platform can legitimately know things about a buyer that your store does not, but it cannot know about an order that does not exist, and the orders in your store are the only list where new and returning have a fixed meaning.