Membership Required
You need to sign in and have a Premium subscription to access this content.
- 01 The custom pixel sandbox cannot read Liquid metafields. Cart attribute is the native bridge: it is functional data, persists into checkout, and is accessible via event.data.checkout.attributes.
- 02 Theme.liquid writes metafield values to cart attributes via
/cart/update.js. A read/compare guard upfront prevents unnecessary updates. - 03 Pixel consent has two layers: the Customer privacy setting in Admin is the loading gate, and
init.customerPrivacyis the runtime state inside the pixel. - 04 For consent state snapshotting, read
Shopify.customerPrivacyand bridge it into a cart attribute. The permission state at order time is what Flow conditions use. - 05 Underscore-prefixed attributes (
_b2b,_customer_id) hide the cart attribute from the checkout UI. Do not write PII to the cart; non-sensitive flags and IDs are appropriate.
+ Can a Shopify custom pixel directly access customer metafields?
It cannot. The custom pixel sandbox is an isolated JS environment with no access to Liquid {{ customer.metafields... }}. The right path is to read the metafield in theme.liquid, write it to a cart attribute, and have the pixel read it via event.data.checkout.attributes.
+ Why is the localStorage workaround often suggested by Shopify staff insufficient?
Two critical weaknesses: a consent gate (using localStorage when analytics_storage is denied is problematic) and a cross-domain disconnect (localStorage is not shared once the checkout domain differs). Cart attributes solve both; they fall under the functional data category and persist natively into checkout through Shopify's infrastructure.
+ Are cart attributes visible in the checkout UI?
Underscore-prefixed attributes (_b2b, _customer_id, _analytics_consent) are not shown to the customer; they are only accessible from Shopify admin and on the pixel/Flow side. Keys without an underscore appear in the Additional details section of checkout.
+ What is the difference between the pixel Customer privacy setting and `init.customerPrivacy`?
The setting is a loading gate: if the visitor has not granted consent for the Required purposes (Marketing / Analytics / Preferences), the pixel never loads. init.customerPrivacy, in contrast, is the layer that reads the visitor's detailed consent state after the pixel has loaded: analyticsProcessingAllowed, marketingAllowed, preferencesProcessingAllowed, saleOfDataAllowed boolean values. It is used for event-level routing in mixed-purpose pixels.
+ Why is it necessary to write consent state into the cart?
The pixel client-side already inherits Shopify's config-level permission enforcement. However, server-side Flow workflows (GA4 Measurement Protocol, Klaviyo Track Event, Meta CAPI) run outside the sandbox and must enforce their own consent gate. Bridging the output of Shopify.customerPrivacy.getVisitorConsent() into a cart attribute provides the snapshot at order time; a Flow condition then reads it from order.customAttributes with a key comparison such as _analytics_consent == "granted".
