Quick Answer: Before a shopper shares an email, you can track their on-site behavior and recognize a returning browser, but you can't know who they are across devices. The goal isn't identifying a stranger, it's capturing clean behavioral signals so that the moment they do provide a durable identifier, like an email at checkout, their entire prior history connects to it. That connection point is the linkage moment, and most tracking setups fail specifically at that step.

Key Takeaways

• Before identification, you can track behavior, sessions, and returning browsers using first-party signals. You cannot reliably recognize the same person across different devices, or assume client-side tags are firing for every visitor, ad blockers and browser restrictions affect a significant share of traffic by default.
• Three things have to work together: high-quality events with consistent properties, an identifier system that can retroactively attach a durable identifier to earlier anonymous events, and continuity that survives ad blockers and browser restrictions.
• First-party cookies help but aren't sufficient alone, Safari's ITP shortens their lifetime, users clear them, and ad blockers can prevent them from being set at all.
• The linkage moment, when an anonymous browser ID gets tied to a durable identifier like an email, is the step that gets the least attention and causes the most failures when it's missing.
• First-party server-side architecture is a real, meaningful privacy advantage over third-party tracking, but it doesn't make a setup automatically compliant on its own. Consent handling and disclosure are still the merchant's responsibility either way.

Most Shopify stores have a familiar problem.

Lots of traffic, plenty of product views and add-to-carts. Fewer tracked conversions than you expect. A large share of shoppers who browse multiple times before buying.

You look at your data and see a wall of anonymous sessions. No email. No customer ID. No way to connect the dots.

Even when a visitor has not typed an email address, they are still generating signals you can use, behavioral signals, session signals, and first-party signals that, handled correctly, can be connected to a real customer profile the moment that person identifies themselves. The purchase that looks anonymous today was not made by a stranger. It was made by someone who viewed your product three times, added to cart on a Tuesday, and came back on Saturday to buy.

The goal is not to identify a person out of thin air. The goal is to recognize continuity, that looks like the same browser returning, and later, this known customer's purchase connects back to their earlier browsing and the ad that drove them here in the first place.

If your tracking setup cannot do that, you are losing attribution credit, under-triggering lifecycle flows, and optimizing your ad spend against an incomplete picture of how your customers actually behave.

What can and can't you do before you have an email address?

I want to be precise here because this is where a lot of bad advice circulates.

Before a shopper shares an email or logs in, you can: track on-site behavior consistently, page views, product views, add to cart, checkout steps. Group those events into sessions. Recognize a returning browser or device using first-party storage when it is available. Pass conversion signals to Meta, Google, and TikTok using privacy-safe, first-party event data that does not depend on third-party cookies.

Before a shopper shares an email or logs in, you cannot: know who the person is across different browsers or devices without a durable identifier. Depend on third-party cookies for consistent cross-device recognition. Assume your client-side tags are firing reliably. Ad blockers and browser restrictions are not edge cases. They are the default behavior of a significant share of your traffic.

Capture strong first-party behavioral events now, before the shopper identifies themselves, and be ready to link those events to a durable identifier the moment they do. The linkage moment is where anonymous becomes known. Everything before that moment is infrastructure you are building for a connection that may come later.

What three things have to work together to make this possible?

To recognize "anonymous" shoppers effectively, you need three things working together.

1. High-quality events. You must capture exact user actions like view_item, add_to_cart, begin_checkout, and purchase. But the event names aren't enough, you need the specific event properties attached to them, such as product IDs, variant IDs, value, currency, and quantity. If your events are inconsistently named, missing required fields, or firing at the wrong moment, that behavioral data becomes completely useless for attribution or lifecycle triggering.
2. Identifiers. You need a reliable way to tie those events together across a single session, and eventually, across multiple sessions. At the anonymous stage, you rely on a first-party browser ID or session ID. Once they identify themselves, you transition to a known identifier like an email address or authenticated customer ID. The critical design requirement here is that your system must be able to retroactively attach that known identifier to the existing anonymous events without losing the history that came before.
3. Continuity. Your event collection has to remain consistent across different browsers, ad blockers, and longer customer journeys. This is where most standard setups fail. Client-side tracking is not continuous by default because it relies entirely on browser scripts executing, which frequently gets blocked. Moving to server-side event collection is what transforms best-effort tracking into a reliable, consistent data stream.

If any one of these is weak, you see the same symptoms: missing add-to-cart events in Klaviyo, purchases that do not connect to earlier sessions, conversion gaps between Shopify and your ad platforms.

How do you actually recognize returning shoppers without a form?

Solving this compliantly relies on four core techniques.

1. First-party cookies. Very useful but insufficient on their own.

Setting a first-party cookie lets you recognize a returning visitor on the same device, tie multiple sessions together, and build better on-site behavioral data. It helps you recognize the same browser when it comes back, but you can't rely on them as your whole "identify returning shoppers" plan because they often stop working or get erased. Safari's Intelligent Tracking Prevention automatically deletes or limits how long certain cookies last, making returning shoppers look "brand new" after just a few days. If a user clears their browser data, your tracking ID vanishes. Privacy tools often block the actual tracking scripts from executing, meaning the cookie never gets set or read in the first place.

2. Server-side event collection. Where reliability actually comes from.

Client-side tracking is flaky because it's at the mercy of the browser. Between ad blockers, privacy settings, and page load issues during checkout, you're bound to lose data. Moving to server-side event collection routes key events through a controlled server endpoint instead. This cuts out browser-level data loss, ensures steady conversion signals reach Meta and Google, and feeds clean data to tools like Klaviyo. It doesn't replace browser tracking, it gives it a backup that doesn't depend on the browser cooperating.

3. Durable identifiers, the hard evidence.

Until a shopper logs in or fills out a form, your identifiers are "soft" browser-level signals. They work for basic session continuity, but they can't handle cross-device tracking. The strongest, most durable identifiers appear at key milestones: logging into an account, entering checkout details, or completing an order. At that moment, you finally capture an email address or a Shopify customer ID. The result depends entirely on whether your data pipeline is designed to use that durable identifier to map backward.

4. The linkage moment, when anonymous becomes known.

This is the most critical step in the process, yet it gets the least attention. It breaks down into three phases. Phase A, anonymous: you capture clean behavioral events tagged with a temporary first-party browser ID or session ID. The shopper is a mystery, but their footprint is saved. Phase B, known: the shopper inputs their email at checkout or logs in, and your system instantly associates that new durable identifier with the old browser ID. Phase C, activation: you use this newly enriched timeline for better segmentation, accurate attribution, and targeted lifecycle messaging. Once the email appears, you can connect all three phases to the same customer without needing any form submission on day one. That is the system working correctly.

The Four Techniques Compared

How does Aimerce handle this automatically and compliantly?

When you do this manually, ensuring compliance is a legal and technical challenge. You have to write custom scripts to check if a user accepted cookies, manually halt server tracking if they opted out, and ensure data is hashed correctly before sending it to Meta or Google.

Aimerce pixel tracking automates both the tracking and the compliance groundwork. Here's how.

It honors Consent Management Platforms (CMPs) automatically. Aimerce doesn't just track everyone by default. If a visitor rejects tracking, Aimerce respects that choice at the server level. If they accept, the server-side engine engages. You don't have to write manual code to bridge your cookie banner to your server pipeline.

First-party data architecture, a real advantage, not a shortcut around obligations. Aimerce routes data through your own custom domain (for example, tracking.yourstore.com) rather than a third-party endpoint, so the data stays within your own first-party context instead of being visible to an outside company tracking users across sites it doesn't own. That's a meaningfully different posture than third-party tracking, and it's part of why first-party architecture is treated favorably under frameworks like GDPR and CCPA. It doesn't make the setup automatically compliant on its own, though. Consent handling, data retention, and disclosure in your privacy policy stay your responsibility regardless of architecture.

Automatic server-side hashing. When it's time to send data to Meta CAPI or Google Enhanced Conversions to get credit for your ads, you can't send raw emails or phone numbers. Aimerce automatically hashes this sensitive data into secure strings using SHA-256 before it leaves the server.

Zero browser fingerprinting. Many manual "anonymous tracking" workarounds use fingerprinting techniques, tracking a device type, battery level, and screen resolution to guess who someone is. Regulators are increasingly skeptical of this approach. Aimerce avoids it entirely, relying on clean, temporary first-party session tokens that upgrade to deterministic matches only when the customer willingly provides their information.

Where do most Shopify stores mess this up?

Trying to identify anonymous visitors immediately. You shouldn't force a pop-up or try to guess exactly who a visitor is the second they land on your site. Focus on cleanly tracking their behavior in the background first. As long as you keep their temporary history organized, your data pipeline can stitch everything together later when they finally buy or log in, the linkage moment.

Too many events with inconsistent naming. More data isn't better data. Start with the five core events, page_view, view_item, add_to_cart, begin_checkout, and purchase, and get them right before expanding.

Treating the browser pixel as the only source of truth. Standard client-side browser pixels are fragile. Relying only on a pixel to track sales means ad blockers and privacy settings will constantly create data gaps.

Assuming one tool fixes everything. You can't install one tool and assume attribution is magically fixed. Accurate tracking is a team sport, every piece has to work together. If you have strong server-side tracking but a broken identity strategy, your data is incomplete. If you have a brilliant identity strategy but flaky event collection, your system has no data to work with in the first place.

FAQ

Can I recognize a shopper across devices before they share an email? Not reliably. Cross-device recognition requires a durable identifier, typically an email address or an authenticated account login, or a platform-level identity graph you don't control. The practical approach is to capture strong first-party behavioral events with a browser or session identifier, and link them to the customer profile when the durable identifier appears. Build for the linkage moment, not for pre-identification.

Do I still need browser pixels if I use server-side tracking? Yes, in most cases. Browser pixels contribute on-site audience signals and certain platform features that server-side events don't replace. The more important shift is not treating the browser pixel as the only source of truth for conversion events. Server-side collection for purchases and checkout events is the reliability layer. The pixel is a complementary signal.

What is the biggest practical win from improving how I handle anonymous traffic? Better event continuity. Fewer missing add-to-cart and checkout events in Klaviyo. More complete conversion signals reaching Meta and Google for campaign optimization. More purchases connected back to the ad exposures and browsing sessions that preceded them. The individual improvements compound into significantly more complete measurement of how customers actually behave before they buy.

Is this compatible with privacy-forward data practices? Yes, if the implementation is first-party, purpose-limited, and aligned with your consent approach. Collecting first-party behavioral events on your own storefront and linking them to customer profiles using identifiers the customer provides at checkout is different from fingerprinting or third-party tracking. The distinction matters legally, operationally, and for the long-term trust of your customers. Build on first-party signals and keep collection proportionate to what you actually need.

Why do my Klaviyo abandoned cart flows fire less than my actual cart abandonment rate suggests they should? Almost always because Add to Cart events are either not reaching Klaviyo reliably or are arriving without a customer identifier that Klaviyo can match to a profile. Anonymous cart events cannot trigger a flow. Server-side event collection that captures add-to-cart signals reliably, combined with session stitching that links those events to a known email at checkout, is the architecture that closes the gap between actual abandonment and triggered flows.

Does first-party server-side architecture automatically make my tracking GDPR or CCPA compliant? No. It's a genuine advantage, since the data isn't visible to an outside company tracking users across sites it doesn't own, but compliance still depends on consent handling, data retention practices, and disclosure in your privacy policy, regardless of whether the architecture is first-party or third-party.

What's the difference between server-side event collection and a durable identifier? Server-side collection is about reliability, making sure an event reaches its destination even if the browser doesn't cooperate. A durable identifier, like an email, is about identity, connecting that event to a specific person across sessions and devices. You need both. Reliable delivery of an event with no identity attached still can't power cross-device attribution.

Sources

[1] WebKit.org, Apple's Intelligent Tracking Prevention documentation (script-writable cookie lifetime cap

Related reading

• Is Server-Side Tracking Legal Under GDPR, CCPA, and Similar Privacy Laws?
• Why Your Klaviyo Abandoned Cart Flow Is Under-Triggering and How Server-Side Tracking Fixes It)
• How To Track Customer Journey Across Multiple Devices