Why do cart IDs in Web Pixel events differ from the Ajax cart token?

Web Pixels
1

I’m seeing some confusing behavior around carts and the Web Pixel.

  • When a customer adds an item to the cart, the product_added_to_cart event fires in the Web Pixel.

  • The event payload includes an id that doesn’t match the token in the Ajax cart object (/cart.js).

  • Also, each time I query /cart.js, the cart token seems to change.

My assumption was that the Web Pixel’s product_added_to_cart event would only fire when the Ajax cart is updated, but that doesn’t seem to be the case. In DevTools I can see requests to <domain>/a/cart/update with updated cart data, even when the Ajax cart doesn’t appear to change.

So my questions are:

  1. Under what conditions does the Web Pixel trigger a product_added_to_cart event?

  2. Are these events linked to Ajax cart updates, or could they also fire for Storefront API cart updates (which I understand use a separate cart system)?

  3. Why would the cart id in Web Pixel events differ from the Ajax cart token?\

  4. Would we expect to see the

I’m trying to trace a customer’s journey from cart → checkout → order. Since the Web Pixel’s product_added_to_cart event shows an id that doesn’t match the Ajax cart token, I’m wondering which identifier will line up with the cart_token field in the Order webhook. In the past I’ve done this successfully using the cart token found in Ajax cart object, but am finding storefronts (that don’t appear to be entirely headless) utilizing a different cart…any clarification would be really helpful.

2

Hey @Jake_Kopulsky :waving_hand: - some storefronts use the Storefront API for cart operations even if they aren’t fully headless so that might be why you’re seeing this pop up.

In those hybrid setups, the Web Pixel’s product_added_to_cart event can reference a cart ID that won’t match the Ajax cart token from /cart.js. For end-to-end tracing, I’d rely on the checkout token (from checkout_started/checkout_completed pixel events), which should map to the Order’s checkout_token value that can be surfaced via webhooks (more info here).

That said, I know it’s not super ideal, so I’m happy to set up a feature request on my end so we can use your feedback to look into making this a bit easier in the future. Feel free to share any additional info about your use case and I’d be happy to get that sent up to our product team on my end. Hope this helps a little bit.

3

Thanks, @Alan_G , super helpful.

One thing I’m still trying to nail down: is there a reliable way to tell when product_added_to_cart came from a Storefront API cart vs. the Ajax cart? And does anything need to be configured on the storefront for Storefront API cart updates to emit Web Pixel events like product_added_to_cart?

For my use case, I’m mainly trying to connect the dots between cart → checkout → order for attribution. Historically I could rely on the Ajax cart token aligning with the cart_token in order webhooks, but in these hybrid setups the IDs drift, which makes it tricky to maintain a consistent thread.

4

No worries @Jake_Kopulsky, happy to help where I can. You’re right though, there’s not currently a super easy out of the box way to grab that info. One recommendation I have, although it adds a bit of complexity would be to set up an orders/create webhook subscription for your integration as well.

We do surface a source_name there which would tell you if a storefront API client created the order (and likely the checkout) or if it was done via AJAX through the web.

Definitely not the most ideal, so I’m happy to set up a feature request though if you’d like to share more details on your use case. Just ping me here and I can get that done on my end - hope this helps!