What you can recover after attribution data is lost, and what you can't

The first question after fixing a tracking gap always arrives in the same shape: can we go back and fix the months we lost?

Some of them. The lost data sits in three layers, and confusing them is what makes teams spend weeks on something that was never rebuildable.

Layer one: data you already own

Anything that comes from your store's database survives, because it never depended on the browser:

• Orders, their values, dates and products
• Customer records, and therefore new versus returning
• Repeat rate, cohorts and lifetime value
• Identity resolution across those same records

That's more than it sounds. Run identity resolution over your historical orders and your repeat rate and customer count change straight away, without recovering a single lost event. Those numbers come out of your store's records, not out of events that never arrived.

Layer two: source, wherever a signal was stored

If the source was written down anywhere at the time, it can usually be reattached to the order. What settles it isn't how much effort you spend, it's whether a signal survived at all:

You can check this in ten minutes. Open twenty orders from the period you want back and look for a stored field carrying a source. If it isn't in the twenty, it won't be in the two thousand.

Usually the last row covers the largest share of your orders. The ones you most want back are the ones sitting in "direct". They're also the ones with no stored signal, which is why they landed there in the first place.

Layer three: events that never arrived

An event the browser never sent left no trace anywhere. There's no log to mine, no export to reprocess, and nobody who can fetch it for you. A blocked pixel doesn't record that it failed. It just doesn't run.

Same for a cookie that expired. Once it's gone, there's nothing left linking that returning visitor to their original source.

Time on this layer comes out of the time you'd spend closing the gap going forward, and the gap stays open while you work on it.

Four steps instead of a rebuild

1. Close the gap forward. Send server-side, and write the source onto the order at checkout. From that day the data is right.
2. Run identity resolution over history. Accuracy you gain on repeat rate, cohorts and customer value without recovering any event.
3. Mark the boundary. Record the date the fix went live, and don't compare a period before it to a period after it without saying so in the report. That comparison will show a large improvement, and the improvement is in measurement rather than performance.
4. Keep the old numbers. Don't overwrite historical reports with corrected versions. The old numbers are what past decisions were built on, and you'll want them when you review those decisions.

Identity resolution in Flowfy runs over your existing order history, so repeat rate and customer count correct retroactively. Order source is written from the day you connect the store, and past orders aren't changed. That's the usual reason the "direct" share drops sharply in the first full month after connecting.

Common questions

Can I import historical orders? Yes, and they'll resolve into customer identities. What you won't gain is a source that was never recorded.

Will the ad platform give me back the missing conversions? No. The platform only knows what reached it, which is the same set you're missing.

Is it worth backfilling UTMs from server logs? Only if the logs actually retained referrers and query strings for that period, and only if the order volume justifies the work. Open the logs and look before you size the job.

When do my reports become comparable again? After a full attribution window, so 90 days. After that you can compare periods without the boundary skewing them.

Start with one check

Before you open a rebuild project, check one thing: whether any source signal is stored on the old orders. If there isn't one, move the whole effort to closing the gap forward and running identity resolution over history.