How the visitor id survives checkout, and why so many orders arrive anonymous

You can track a visitor perfectly across a dozen page views and still lose them at the last step. Checkout frequently runs on another domain, under stricter rules, or - increasingly - inside a third-party one-click checkout app that carries none of your page context with it.

The second copy

The fix is not cleverer tracking on the checkout page. It is to write the visitor id onto the cart before checkout starts, so it travels with the order as data rather than as a cookie.

• Written once per session while browsing, and forced again on add-to-cart, Buy Now, and any cart change.
• Merged, never replaced - only our own keys are sent, so subscription apps, gift notes and delivery dates all survive untouched.
• Arrives on the order webhook as an attribute, whatever happened to the browser in between.

Full context, not just the id

The richer mode writes the acquisition context too: Google and Meta click ids, campaign tags, and the platform cookies that let a conversion match. There is a size budget, so it spends it in priority order - click ids first, then campaign tags, then cookies - and skips any single value too long to be useful. A truncated click id is worse than a missing one, because it will be sent and match nothing.

When it is missing

If a meaningful share of your orders arrive with no visitor id, the usual causes are: the tag is not installed on every template, the flag that writes cart attributes was never enabled, or orders are coming from a mobile app that never loaded your web tag at all. Those are three different fixes, and the split by platform tells you which one you have.

What to do next

Add something to your cart on your own store, then open the cart in a browser console and look at the attributes. If your visitor id is not there, no amount of downstream attribution work will help.