Server-Side Tracking and Identity Reconciliation
Most Shopify webhooks contain no PII, so server-side tracking doesn't solve identity. Here's why the browser is critical and what durable identity requires.
Let’s talk about server-side tracking. A lot of ecommerce businesses now use server-side tracking apps as an intermediary between their Shopify or WooCommerce stores and platforms such as Klaviyo and Meta.
But server-side tracking is often misunderstood, particularly when it comes to identity reconciliation. The basic architecture looks like this: you’ve got server-side events coming from Shopify, browser events, and in the middle sits your server-side tracking app, which then passes events to destinations such as Klaviyo or Meta through a server connection.
What is a server-side event?
One common source of server-side events in Shopify is a webhook. A webhook is a JSON payload originating from a server, such as Shopify. For example, Shopify supports checkout-related webhook topics that can send data when a checkout is created or updated. Depending on the event and available customer data, a checkout payload can include personally identifiable information (PII), such as an email address or phone number. That information can then help platforms such as Meta or Klaviyo identify the customer associated with the event.
But not every payload coming from Shopify has PII. Some events may arrive without an email address, phone number, or other direct customer identifier. For identity reconciliation, a server-side event is only as useful as the identifying information you can connect to it.
If an event contains no PII, the payload alone does not tell you who triggered it. The key point is that the event itself does not provide enough information to identify the user.
If we’re just looking at the server event and the payload, and it doesn’t contain customer information or another usable identifier, the payload alone is not enough to identify who initiated that event.
When contact details are present, a checkout webhook can look like this. Highlighted fields are personally identifiable information (PII) that platforms can use for identity matching:
{
"id": 981820079255243537,
"token": "123123123",
"cart_token": "eeafa272cebfd4b22385bc4b645e762c",
"email": "example@email.com",
"phone": "+1-555-123-4567",
"buyer_accepts_marketing": false,
"created_at": "2021-12-31T19:00:00-05:00",
"currency": "USD",
"total_price": "421.88",
"subtotal_price": "398.00",
"line_items": [
{
"product_id": 632910392,
"variant_id": 808950810,
"title": "IPod Nano - 8GB",
"quantity": 1,
"price": "199.00",
"sku": "IPOD2008PINK"
}
],
"billing_address": {
"first_name": "Bob",
"last_name": "Biller",
"address1": "123 Billing Street",
"city": "Billtown",
"province": "Kentucky",
"zip": "K2P0B0",
"country": "United States",
"phone": "555-555-BILL"
},
"shipping_address": {
"first_name": "Steve",
"last_name": "Shipper",
"address1": "123 Shipping Street",
"city": "Shippington",
"province": "Kentucky",
"zip": "K2P0S0",
"country": "United States",
"phone": "555-555-SHIP"
},
"customer": {
"id": 603851970716743426,
"first_name": "John",
"last_name": "Smith",
"email": "john@example.com",
"phone": null,
"default_address": {
"address1": "123 Elm St.",
"city": "Ottawa",
"zip": "K2H7A8",
"phone": "123-123-1234"
}
}
}email, phone, name, and address can identify the customer.
Adapted from Shopify’s documented checkouts/create sample; truncated for readability.
The cart event example
A Shopify cart update is a useful example.
Shopify’s standard carts/update webhook payload includes cart and line-item data, but its documented payload does not include customer email or phone fields. Dynamic data can be incorporated into the payload, but it is not part of the standard cart webhook payload itself.
Looking only at that standard payload, you don’t have an email address or phone number telling you who initiated the cart event. To connect that event to a known customer, the tracking system needs another identity signal or a way to reconcile the event with an existing browser or customer session. Many high-volume behavioral events won’t carry an email address or phone number in the event payload itself.
{
"id": "exampleCartId",
"token": "exampleCartId",
"line_items": [
{
"id": 704912205188288575,
"properties": null,
"quantity": 3,
"variant_id": 704912205188288575,
"key": "704912205188288575:3abdf474dce81d0025dd15b9a02ef6bf",
"discounted_price": "19.99",
"discounts": [],
"gift_card": false,
"grams": 200,
"line_price": "59.97",
"original_line_price": "59.97",
"original_price": "19.99",
"price": "19.99",
"product_id": 788032119674292922,
"sku": "example-shirt-s",
"taxable": true,
"title": "Example T-Shirt - Small",
"total_discount": "0.00",
"vendor": "Acme"
}
],
"note": null,
"updated_at": "2022-01-01T00:00:00.000Z",
"created_at": "2022-01-01T00:00:00.000Z"
}carts/update payload has cart tokens and line-item data only—no email, phone, or customer object.
Adapted from Shopify’s documented sample; money-set fields omitted for readability.
Receiving the server-side event alone, therefore, doesn’t solve the identity-resolution problem. Page views, product views, and add-to-cart activity needs to be matched to an existing identity or session before they can be tied to a known customer. This information is going to come from browser data -- not a server-side event.
Different systems can know different things
The bigger issue is that different systems in the stack can have different information about the same visitor. Just because Klaviyo or another third-party app may know who the user is, it doesn’t mean that Shopify knows who the user is. One system may therefore have identity information that another system doesn’t.
If one system recognizes the user and another doesn’t, you need a way to reconcile the information between them. When the server-side payload doesn’t contain identity, the browser session can become an important part of connecting the event to a known user.
That makes browser recognition an important part of how some server-side tracking systems reconcile unidentified events. Take the add-to-cart example again: a server-side tracking app can receive the event, but receipt alone doesn’t establish the customer’s identity. For customer-level marketing, it needs a way to match the event to an identity or session.
And it’s assuming that the browser event has the correct identifying information on it. For identity reconciliation, access to the event is only one part of the job. In other words, if a server-side tracking app doesn’t have its own robust browser recognition layer, then much of its identity-resolution value is lost.
Routing data is not the same as resolving identity
Without identity reconciliation, the platform may simply pass unidentified events through to another destination. If that’s all the platform does, it’s functioning mainly as a relay. That doesn’t mean routing has no value, but routing alone doesn’t solve the identity problem.
Server-side tracking isn’t automatically cookieless
Around the rollout of iOS 14.5 and other privacy changes, server-side tracking was often discussed as part of the move toward a “cookieless” future. The simplified pitch was that moving tracking server-side would solve the browser-cookie problem.
In reality, many behavioral events still need to be connected to an identity through information outside the event payload itself. So you still need a way to utilize those server-side events that contain no PII.
In many implementations, browser or session identifiers remain part of that reconciliation process. Server-side tracking, therefore, shouldn’t be treated as automatically “cookieless.”
Presenting server-side tracking as a complete solution to identity loss is an oversimplification.
What should the intermediary actually do?
A server-side tracking app can receive events and pass them to third-party platforms throughout the marketing stack. But event routing alone doesn’t address the identity gap. You can hook Klaviyo directly to Shopify and get event routing.
The additional value comes when the intermediary can reconcile identity instead of simply routing the event. So the job isn’t just routing data. It’s about identity. A pass-through system that only relays fields doesn’t, by itself, close an identity gap.
The problem with depending on someone else’s cookie
Popular tracking systems rely on browser identifiers created by platforms such as Shopify or Google products.
A system can use available first-party identifiers as part of an identity graph. Those identifiers can help connect activity across a user’s session or return visits. But that doesn’t really address the full scope of the problem.
The identity graph is then dependent on those browser identifiers. And if a cookie is blocked, expires, is cleared, or otherwise becomes unavailable, then that continuity can be disrupted. If your identity graph depends heavily on identifiers controlled by another platform, changes to that platform can affect your ability to maintain identity over time.
Browser privacy controls also make long-term dependence on client-side identifiers less reliable. So there needs to be something more robust than simply leveraging an existing cookie in the browser.
Put simply, a recognition system built entirely on someone else’s cookie is only as durable as that cookie. A more resilient system reduces its dependence on third-party identifiers. That can include a first-party identity layer that combines available customer data and identifiers rather than relying on one platform’s cookie.
Building a more durable identity graph
The goal is to preserve as much identity continuity as possible even when one platform loses or changes the identifier it previously relied on. A more durable identity graph can connect PII collected through sources such as checkout, account activity, or a popup with other first-party identifiers and behavioral events. The tracking platform then needs a reliable way to maintain and reconcile that identity graph.
That identity layer is the part that simple event-routing integrations lack.
A more complete tracking platform also needs its own way to connect browser activity with the identities it has already collected. That infrastructure should not depend on Shopify, Google, Klaviyo, or another single platform being able to recognize the user. And it should be able to pass that data to all of your connected apps like Klaviyo or Meta.
If one connected platform loses an identifier while the identity layer still has another valid way to recognize the customer, it can help fill that gap and provide more complete context to the rest of the marketing stack. Getting the server-side event is the easier part. The harder question is: how is identity maintained when it isn’t present in the payload? That is fundamentally an identity-reconciliation issue that involves the browser.
Simply saying “we send the data server-side” doesn’t explain how the platform handles identity when the event itself isn’t identifiable.
Again, you can hook up Shopify directly to Klaviyo. If you’re adding another platform between them, it should provide value beyond basic event routing or dependence on a single browser identifier.
The stronger model is an identity layer that can reconcile what different systems know, so information available in one part of the stack can improve the context available elsewhere. That identity layer becomes the connective tissue between the apps in the marketing stack.
Conclusion
For identity-focused server-side tracking, much of the value comes from how the platform handles identity and session continuity, not simply how many events it can relay. That’s what we’re doing at Kluvos. If identity reconciliation is the gap in your current stack, Kluvos is built to address it.