TL;DR
The Shopify Web Pixels API defines 13 standard events [1]. The seven browse and cart events (page_viewed, product_viewed, collection_viewed, search_submitted, product_added_to_cart, product_removed_from_cart, cart_viewed) never carry customer identity. They report what the shopper looked at and what is in the cart, not who the shopper is. Customer PII (email, phone, name, billing and shipping address, and the customer ID when logged in) only shows up on the six checkout_* events, and only once the buyer has typed it in. As of December 10, 2025, Shopify filters those PII fields at runtime: an app without approved protected-customer-data access receives null for email, phone, name, and address; an approved app receives the full values [2][3]. One more thing most people miss: the browser pixel and the order webhook are separate channels with separate rules. An approved app recovers the full customer record server-side from the order even when the sandboxed pixel sees null.
Key Takeaways
- The Web Pixels API has 13 standard events; only the six
checkout_*events ever carry customer PII, and only after the shopper enters it [1]. - Browse and cart events (
page_viewed,product_viewed,cart_viewed, and four others) carry product and price context with no email, phone, name, or address [1]. - Since December 10, 2025, Shopify sets email, phone, name, and address to null in pixel payloads for apps without approved protected-customer-data access [2][3].
- An approved app keeps those fields; the difference is the app's protected-customer-data approval, not merchant consent [3].
- The browser pixel sandbox and the
orders/createwebhook are independent channels, so an approved app rebuilds the full customer record server-side even when the pixel sees null. - Custom pixels added manually in the admin are out of scope for this runtime filtering [2].
- To confirm what an event carries, watch live events in Settings > Customer events and inspect a
checkout_completedpayload.
What customer data do the browse and cart events carry?
None of the customer-identity kind. The seven non-checkout events (page_viewed, product_viewed, collection_viewed, search_submitted, product_added_to_cart, product_removed_from_cart, cart_viewed) carry product, price, quantity, and page context, and nothing that names the shopper [1].
Walk through what each one actually hands you. page_viewed gives you the page context: the URL, the referrer, the document title. product_viewed gives you the product variant the shopper is looking at, including its price, SKU, and title. product_added_to_cart gives you the cart line that changed, with quantity and line price. cart_viewed gives you the full cart: line items and totals. At no point in this set does the payload contain an email, a phone number, a name, or an address. The shopper has not entered any of that yet, so there is nothing to carry.
This is a design feature, not a gap. An open storefront page can be loaded by anyone, logged in or not, so a pixel that fired customer PII on every page view would be a privacy liability. The practical consequence for marketers: the audience-matching signals that ad platforms want (email and phone for match quality, lookalike seeding, retargeting) do not exist on the early-funnel events. They only appear once the shopper reaches checkout. For the plain-English tour of how the Web Pixels API works and how app pixels differ from custom pixels, see the Web Pixels API guide for marketers.
Which events actually carry email, phone, and address?
The six checkout_* events, and only after the shopper has entered the data. checkout_started, checkout_contact_info_submitted, checkout_address_info_submitted, checkout_shipping_info_submitted, payment_info_submitted, and checkout_completed can all carry contact and address fields [1].
The availability climbs as the buyer moves through checkout. Email and phone become available once contact info is submitted. The shipping and billing address objects (first name, last name, address lines, city, province, postal code, country, and phone) become available once the address step is submitted. By checkout_completed, the full checkout object is present: contact, both addresses, and, if the shopper is logged in, a customer object carrying the customer ID, email, phone, and name. A field that the shopper has not yet entered reads as null even on an approved app, because there is genuinely nothing there yet. A null email on checkout_started for a buyer who has not typed their address is normal behavior, not redaction.
The logged-in case adds one more source. When a returning customer is signed in, a customer object is available across events carrying the Shopify customer ID, email, phone, and name. That ID is the stable join key behind features like new-versus-returning segmentation, which is why a returning-customer flag depends on the customer object being present and unredacted.
The full per-event redaction map
Here is the inventory in one table. "PII present" means the event can carry customer identity once the shopper has entered it. "Redacted since Dec 10 2025" means Shopify nulls those fields when the app lacks approved protected-customer-data access [2].
| Event | Data present | Customer PII present | Redacted since Dec 10 2025 (unapproved app) |
|---|---|---|---|
page_viewed |
Page URL, referrer, title | No | Not applicable |
product_viewed |
Product variant, price, SKU | No | Not applicable |
collection_viewed |
Collection, product list | No | Not applicable |
search_submitted |
Search query string | No | Not applicable |
product_added_to_cart |
Cart line, quantity, price | No | Not applicable |
product_removed_from_cart |
Cart line, quantity | No | Not applicable |
cart_viewed |
Cart items, totals | No | Not applicable |
checkout_started |
Checkout object, line items | Email, phone, address (if entered); customer (if logged in) | Email, phone, name, address null |
checkout_contact_info_submitted |
Contact info | Email, phone | Email, phone null |
checkout_address_info_submitted |
Address objects | Shipping and billing address, name, plus email and phone from earlier steps | Email, phone, name, address null |
checkout_shipping_info_submitted |
Shipping selection, address | Address, plus email and phone from earlier steps | Address, name null |
payment_info_submitted |
Checkout object | Email, phone, address from earlier steps | Email, phone, name, address null |
checkout_completed |
Full checkout object | Email, phone, name, both addresses, customer | Email, phone, name, address null |
| Server-side order webhook | Full order object | Email, phone, name, both addresses, customer | Not affected (governed by app data access) |
The bottom row is the one that changes how you think about the whole table, so it gets its own section below.
What changed on December 10, 2025, and who it hits
Shopify began filtering web pixel payloads at runtime. If the app behind the pixel does not have approved protected-customer-data access, Shopify sets the name, email, phone, and address fields to null before the event reaches the pixel [2][3].
This applies across the storefront, checkout, and customer accounts surfaces [2]. It is an app-approval rule, not a consent rule: an app earns the data by holding approved protected-customer-data access, which Shopify reviews and grants [3]. Custom pixels that a merchant adds by hand in the admin are out of scope for this filtering [2]. The failure mode is quiet, which is what makes it dangerous. There is no error and no broken pixel. A store running an unapproved app sees normal operation for days, then watches ad-platform match quality erode weeks later because the email and phone that fed those matches stopped arriving. The root-cause story and the fix path are covered in why customer email is missing from your Shopify pixel events. WeltPixel Conversion Tracking is approved for the customer data its events carry, so its checkout events receive the full fields rather than null.
Why the order webhook recovers what the pixel redacts
The browser pixel and the orders/create webhook are two independent channels. The pixel runs in a sandbox governed by the December 10 protected-customer-data filtering. The order webhook runs server-side and is governed by the app's own approved data access, with no runtime sandbox in the middle.
That separation is the practical escape hatch. When an order is placed, an approved app receives the full order object server-side: top-level email, the customer object (ID, email, phone, name), and both the shipping and billing address objects with their street, city, province, postal code, and country fields. So even in a context where the browser pixel returned null, the server path still carries the complete customer record from the order. This is why modern conversion tracking leans on the server-side send for match quality: it delivers hashed email, phone, and address from the order regardless of what the sandboxed pixel saw. The server path is the designed complement to browser tracking, not a workaround. For the deeper case on carrying a stable customer identity into your stack, see first-party cookies and customer identity on Shopify, and for how server-side events reach analytics, see the GA4 Measurement Protocol explainer. One note on the browser side: those events respect Shopify's Customer Privacy API signals, so consent governs browser sends separately from the app-approval rule that governs PII redaction.
Verify what your own events carry
You do not have to take the table on faith. Shopify shows you the live payloads.
- In your Shopify admin, go to Settings > Customer events. This is where pixels are registered and where you can inspect activity.
- Open your storefront in a separate tab and load a product page, then add an item to the cart. These fire
product_viewedandproduct_added_to_cart. - Start a checkout and enter a real contact email and address. This fires
checkout_startedand the contact and address submission events. - Inspect a
checkout_completedpayload. If your app is approved, the checkout object carries the email, phone, name, and address you entered. If the fields read null after you entered real values, the app behind that pixel lacks approved protected-customer-data access [2]. - To confirm the server path, check that the same order shows complete customer data in your tracking app's server-side delivery, which is sourced from the order webhook rather than the pixel.
If browse-event payloads carry no customer fields, that is correct and expected, not a misconfiguration.
FAQ
Does the page_viewed event carry the customer's email?
No. page_viewed carries page context (URL, referrer, title) and never customer identity [1]. Email only appears on the checkout events, and only after the shopper has entered it.
Why is the email null on my checkout_started event even for a logged-in customer?
Two reasons are possible. Either the shopper has not entered contact info yet, so the field is genuinely empty, or the app behind the pixel lacks approved protected-customer-data access and Shopify is redacting it as of December 10, 2025 [2]. Inspect a checkout_completed payload after entering real data to tell them apart.
Does the December 10 change affect every Shopify store?
It affects pixels from apps without approved protected-customer-data access. Approved apps keep the fields, and custom pixels added manually in the admin are out of scope [2][3]. It is an app-approval rule, not a store-wide switch.
How can an app still get customer data if the pixel is redacted?
Through the order webhook. The orders/create webhook is a separate server-side channel governed by the app's own approved data access, so an approved app reads the full customer record from the order even when the browser pixel returns null.
Stop guessing which events carry what
Knowing the per-event redaction map only helps if your tracking app is on the right side of it. WeltPixel Conversion Tracking is approved for the customer data its checkout events carry, and it pairs the browser pixel with a server-side send sourced from the order webhook, so match quality for GA4, Meta, TikTok, Google Ads, and Reddit holds even when the sandboxed pixel returns null.
Install WeltPixel Conversion Tracking on the Shopify App Store
Sources
- Shopify Developers. "Web Pixels API standard events." https://shopify.dev/docs/api/web-pixels-api/standard-events
- Shopify Changelog. "Protected customer data scopes required for web pixels." https://shopify.dev/changelog/protected-customer-data-scopes-required
- Shopify Developers. "Protected customer data." https://shopify.dev/docs/apps/launch/protected-customer-data