By the Digital Empire Regulatory Research Team (PixelProof Analysis Team) · Reviewed by Andy Gaber, Founder, Digital Empire Holdings LLC · Published August 21, 2026 · Last updated August 21, 2026
Meta's tracking API splits every event a Shopify DTC store can fire into two categories: 17 named standard events that Meta's optimizer, reporting, and Aggregated Event Measurement framework understand natively, and an open set of custom events the merchant invents and fires with trackCustom. Choosing the wrong category for a given user action corrupts the optimizer, inflates or hides ROAS, and can silently starve the iOS-opted-out cohort of attribution. This guide walks the 2026 state end to end: the full 17-event standard list and what each is for, when to reach for a custom event instead, which parameters each standard event actually requires, how custom conversions layer on top of both categories, how the browser Pixel and Conversions API must agree on event_name and event_id for deduplication to work, how the AEM 8-event cap shapes the tradeoff, how the Shopify pixel extension behaves after the August 2026 checkout upgrade, and how PixelProof surfaces standard-vs-custom event distribution drift.
A standard event is one of a fixed set of event names Meta reserves and understands out of the box. When the browser Pixel fires fbq('track', 'Purchase', {value: 49.00, currency: 'USD'}), Meta's ingestion pipeline treats that as a Purchase in every part of the system: optimization, reporting columns, custom audience rules, Dynamic Product Ads, Advantage+ Shopping's objective menu, and the Aggregated Event Measurement priority list. The optimizer knows what Purchase means without any additional configuration. The same is true for AddToCart, InitiateCheckout, ViewContent, and every other event on the reserved list.
The full 2026 standard-event list, per Meta's Pixel reference documentation, contains 17 names: PageView, ViewContent, AddToCart, InitiateCheckout, AddPaymentInfo, Purchase, Lead, CompleteRegistration, Contact, CustomizeProduct, Donate, FindLocation, Schedule, StartTrial, SubmitApplication, Subscribe, and Search. Each of them has a documented intent, a documented set of expected parameters, and a default place in Meta's optimization and reporting surfaces. Firing a standard event with the wrong intent -- Purchase on a newsletter signup, for example -- does not throw an error; it silently corrupts the campaigns downstream of it.
PageView. Fires on every page load. This is the baseline event and is emitted automatically by the Pixel base code when it initializes. It is not a conversion event and should never be used as an optimization objective, but it is the denominator for site-wide reach and frequency reporting.
ViewContent. Fires on a product-detail page view. Required parameters are content_ids, content_type, value, and currency. This event powers Dynamic Product Ads retargeting and product-based lookalike audiences; without content_ids and content_type set correctly it cannot drive DPAs.
AddToCart. Fires when a shopper adds a product to cart. Required parameters are content_ids and content_type; value and currency are strongly recommended. This is the most common mid-funnel optimization event on DTC and is heavily weighted in AEM defaults.
InitiateCheckout. Fires when a shopper enters the checkout flow. Required parameters are value, currency, and content_ids. Meta uses InitiateCheckout as a bottom-funnel signal for prospecting campaigns that are still learning and cannot yet optimize on Purchase directly.
AddPaymentInfo. Fires when a shopper submits payment credentials. Required parameters are value and currency. It sits between InitiateCheckout and Purchase in the funnel and is optional for most Shopify installs -- Shopify's checkout upgrade does not emit it by default and it usually requires a custom pixel to instrument.
Purchase. The bottom-of-funnel conversion event. Required parameters are value and currency. Purchase is the default optimization objective for every conversion campaign, the default column in every ROAS report, and the highest-priority AEM slot on almost every DTC domain. A Purchase event firing without value is one of the most common silent failures a monitoring tool catches -- the event counts, but ROAS reads as zero.
Lead. Fires on a form submit that generates a lead -- a demo request, a quote request, a whitepaper download. There are no strictly required parameters but content_name and value help downstream reporting. Lead is the primary optimization objective for lead-gen accounts and is common on B2B storefronts that use Shopify as a marketing site.
CompleteRegistration. Fires when a user creates an account. Required parameters are none strictly, but content_name and status are commonly used. This event is often confused with Lead; the distinction is that CompleteRegistration is an account creation, Lead is a submission of interest.
Contact. Fires when a user initiates contact with the business -- a chat opened, a Contact Us form filled, a phone-click event on mobile. Strictly optional parameters; primarily used by service and local businesses.
CustomizeProduct. Fires when a shopper configures a product -- picks a color, a size, a monogram, a subscription cadence. Content_ids and content_type help but nothing is strictly required. It is a mid-funnel intent signal for configurable-product categories.
Donate. Fires when a donation is completed. Required parameters are value and currency. This is the nonprofit analogue of Purchase and functions the same way inside the optimizer.
FindLocation. Fires when a user searches for a physical location -- a store locator, a pickup search. Used by omnichannel retailers with physical stores; largely irrelevant for pure-DTC.
Schedule. Fires when an appointment is booked. Common on service businesses and beauty verticals with in-person consultations attached to online storefronts.
StartTrial. Fires when a shopper starts a free trial of a paid product. Required parameters are value, currency, and predicted_ltv when available. Subscription DTC brands commonly optimize prospecting on StartTrial and retargeting on the eventual Subscribe.
SubmitApplication. Fires on submission of an application -- a credit application, a loyalty program application, a wholesale application. Used across finance, education, and B2B DTC.
Subscribe. Fires when a paid subscription is created or renewed. Required parameters are value, currency, and predicted_ltv when available. Subscription-native DTC brands weight Subscribe higher than Purchase in the AEM priority list because it represents the recurring-revenue commitment.
Search. Fires when an on-site search is performed. Required parameters are search_string and, when relevant, content_ids and content_category. Useful for retargeting shoppers who searched but did not view or add-to-cart.
A custom event is any event name the merchant invents. It is fired with fbq('trackCustom', 'SampleRequest', {flavor: 'matcha', source_form: 'pdp-inline'}) from the browser Pixel, or with the equivalent server-side payload via the Conversions API. Meta stores the event under the custom event name the merchant chose. Nothing in Meta's optimizer natively knows what SampleRequest means -- the merchant has to tell it, either by building a custom conversion on top of the event or by wiring it into a lookalike audience or a retargeting rule.
The trackCustom API is intentionally permissive. Custom event names can be any string; custom parameters can be any key-value pair. That permissiveness is where the discipline has to come from the merchant side: without a naming convention documented and enforced, the browser tag manager will fire SampleRequest, the server-side handler will fire sample_request, Meta will treat them as two entirely separate events, deduplication will fail, custom audiences built on one name will silently exclude users tagged with the other, and no error will surface anywhere. This is the failure mode a monitoring tool catches most often on custom events.
The right question is not "standard or custom?" -- it is "does this user action match the documented intent of any of the 17 standard events?" If yes, use the standard event. If no, use a custom event.
Actions that clearly match a standard event: a product-detail-page view is a ViewContent, an add-to-cart is an AddToCart, an order placement is a Purchase, a subscription start is a Subscribe, a trial start is a StartTrial, an account creation is a CompleteRegistration, a form submit that captures a lead is a Lead. There is no advantage to renaming any of these as a custom event, and there are real disadvantages -- the optimizer loses the tuning it has for that name, AEM defaults do not apply, and reporting columns do not populate.
Actions that do not match a standard event: a sample-request form submission on a beverage brand, a waitlist-join for an out-of-stock product, a quote-request on a wholesale storefront, a subscription-pause action on a subscription DTC brand, a size-selector interaction where the merchant needs to attribute cohorts by picked size, a product-review submission. These are all legitimate custom events. The rule of thumb: if the intent is meaningfully different from any of the 17 standard events, invent a custom event with a clear PascalCase name and a documented parameter contract, and be prepared to build the corresponding custom conversion for optimization.
A custom conversion is a rule inside Events Manager that lets the merchant optimize a campaign against a specific slice of an event -- either a URL match, or a match on parameters of an existing event. Custom conversions do not require any code changes on the site; they operate on the data already flowing in via the Pixel and CAPI.
The common pattern: fire a broad Lead event on every form submission across the site, then build custom conversions on top of Lead -- one for wholesale-inquiry (Lead where source_form equals wholesale-inquiry), one for sample-request (Lead where source_form equals sample-request), one for consultation-booking (Lead where source_form equals consultation-booking). Each custom conversion becomes selectable as an optimization event in Ads Manager, and each populates its own reporting column. The underlying Lead event fires exactly once per form submit; the custom conversions are pure downstream rules.
Custom conversions built on custom events work the same way. Fire a SampleRequest custom event with a flavor parameter, then build custom conversions on top -- one for matcha samples, one for chai samples, one for oolong samples. Each becomes independently optimizable and reportable. The limit on custom conversions per ad account is generous (100+ on most accounts) and the constraint is almost never the number of custom conversions; it is the AEM 8-event cap that shapes what any of them can do for iOS-opted-out traffic.
Aggregated Event Measurement, per Meta's AEM documentation, caps each verified domain at 8 prioritized conversion events for the iOS-opted-out cohort. The verified domain is set inside Meta Business Manager under Brand Safety then Domains. The 8 events are prioritized in Events Manager and apply per-domain -- adding more than 8 pushes lower-priority events out entirely for iOS-opted-out traffic.
Standard events sit at the top of the priority list by Meta's defaults and by every published best-practice guide. On a typical DTC storefront, the 8 AEM slots should be filled first with Purchase, InitiateCheckout, AddToCart, ViewContent, and Lead (if lead capture matters), then optionally Subscribe or StartTrial (for subscription DTC), then any custom events that map to genuinely important business actions.
Custom events can occupy AEM slots but they compete with standard events for the same 8 slots. Adding a custom event named QuizCompletion to the AEM priority list at position 3 pushes the event that was previously at position 8 out of AEM entirely; that event is now invisible for iOS-opted-out attribution. Merchants who load the priority list with too many custom events lose iOS-opted-out attribution on the events that actually drive revenue, then wonder why their prospecting ROAS collapsed. The fix is to keep the AEM slots concentrated on the events most tied to revenue, and use custom events off the AEM priority list for audience-building and reporting only.
The optimizer only rewards standard events with the parameters it expects. Missing parameters do not throw errors; they silently degrade signal quality until someone catches it in a scan or in a downstream ROAS anomaly.
The high-frequency failure modes on Shopify: Purchase events firing with value as a string rather than a number ("49.00" instead of 49.00), which Meta may or may not parse depending on the format; Purchase events firing with currency missing entirely, which zeros the ROAS calculation; ViewContent events firing with content_ids as a single string rather than an array of strings, which breaks Dynamic Product Ads retargeting; AddToCart events firing with content_type omitted, which prevents the event from being usable for catalog-based retargeting; InitiateCheckout events firing with value present but currency missing, which produces the same zero-ROAS outcome as on Purchase. Every one of these is caught by a scan of the events as they actually fire, and every one of them is invisible in the Ads Manager UI because Meta counts the events but not their value.
The server-side Conversions API exists to backstop the browser Pixel against ad-blockers, ITP, and iOS ATT. For each user action, both the browser Pixel and the CAPI handler should fire the event, and Meta should collapse the two into a single counted conversion via the deduplication contract. That contract requires both events to share the same event_name string and the same event_id string. Meta does not do fuzzy matching; the comparison is exact-string on both fields.
For standard events, this is usually straightforward -- both the browser Pixel and the CAPI middleware fire Purchase with the same event_id, and Meta collapses them. For custom events, it is where merchants get burned. The browser tag manager fires SampleRequest with a UUID event_id; the server-side handler fires sample_request (snake_case) or SampleRequestEvent (with a suffix) with a different event_id; deduplication fails; Meta counts both. Reporting inflates. Nothing errors. The fix is a documented naming convention enforced on both sides plus event_id generation in one place and passed through to the other side rather than generated twice.
The same rule applies to any custom parameters that flow through both channels. If the browser Pixel sends flavor as "Matcha Green" and the CAPI handler sends flavor as "matcha-green", custom conversions built on the flavor parameter will match one but not the other, and cohort audiences will drift over weeks in ways that are impossible to trace without a monitor that snapshots the actual payload.
The current Shopify pixel extension, especially after the August 2026 checkout upgrade, emits the core standard events -- PageView, ViewContent, AddToCart, InitiateCheckout, Purchase -- automatically from Shopify's own checkout and browsing telemetry. That coverage handles the top of the AEM priority list for most DTC storefronts without any custom instrumentation.
What the extension does not do is fire any custom events. Custom events have to be added via the pixel API inside a Shopify custom pixel (App Pixel or Web Pixel, depending on the app model), or via a tag manager (GTM, Segment) running on the storefront. Shopify treats custom events as separate from its own analytics event stream -- they do not automatically populate Shopify's built-in analytics dashboards, they do not flow to Shopify's customer-events surface for other apps to consume, and they are subject to the merchant's own consent-mode configuration on top of Shopify's default consent handling.
The practical implication for a Shopify DTC merchant: the standard-event side of the stack is likely working out of the box (with the notable exception of Purchase-value parameter issues on customized checkouts); the custom-event side is entirely the merchant's responsibility and is the surface most likely to have naming-convention drift, missing CAPI backstop, or complete absence when the merchant assumed Shopify was firing them.
PixelProof does not change which events fire -- that is a code and configuration decision the merchant owns. What PixelProof does is scan the storefront and the CAPI event stream, then surface the standard-versus-custom event distribution as a diagnostic on every scan.
The scan produces four categories of finding relevant to standard-vs-custom events. First, standard events firing without their required parameters -- Purchase without value, ViewContent without content_ids, AddToCart without content_type -- flagged per event with the exact page URL and event payload. Second, custom event names that appear only in the browser Pixel or only in CAPI, which is the deduplication-breakage signal; the scan pairs them by user action and highlights the naming mismatch. Third, custom events that have been added to the AEM priority list while high-revenue standard events have dropped off it, which is the iOS-opted-out attribution starvation pattern. Fourth, standard event names being used for actions that do not match the documented intent -- a Purchase event firing on a newsletter signup, a Lead event firing on every PageView -- which is the optimizer-corruption pattern.
The output is a per-event map that shows which category each active event on the storefront falls into, whether it has a CAPI counterpart, whether the two agree on event_name and event_id, and whether the AEM priority list is aligned with the events that actually carry revenue. The fixes live in the tag manager, the theme, or the CAPI middleware -- the merchant or their agency ships them -- but the merchant no longer has to guess whether the events firing are the right events with the right parameters.
For the full server-side Conversions API walkthrough on Shopify 2026, including the deduplication contract in code, see Meta Conversions API Setup for Shopify (2026 Deep Dive). For the 2026 state of Meta attribution windows and how they interact with the events fired into them, see Meta Attribution Window Changes 2026. For the iOS 14.5 ATT deep dive on how the opted-out cohort constrains everything above, see iOS 14.5 ATT Impact on Shopify Tracking (2026). For how Klaviyo and the Meta Pixel co-exist on Shopify with dual-fire and monitoring, see Klaviyo + Meta Pixel Integration Guide 2026.
Not sure whether your standard events are firing with the right parameters, or whether your custom events dedupe against CAPI? Run a free scan of your tracking stack → or read the Meta CAPI setup deep dive for the deduplication contract these events rely on.
A standard event is one of the 17 event names Meta reserves and understands out of the box -- PageView, ViewContent, AddToCart, InitiateCheckout, AddPaymentInfo, Purchase, Lead, CompleteRegistration, Contact, CustomizeProduct, Donate, FindLocation, Schedule, StartTrial, SubmitApplication, Subscribe, and Search. Firing one with fbq('track', name, params) lets Meta's optimizer, reporting, and Aggregated Event Measurement framework treat it as a first-class conversion. A custom event is any event name the merchant invents and fires with fbq('trackCustom', name, params). Meta stores it and lets you build a custom conversion on top of it, but the optimizer does not natively know what it means, and it does not automatically inherit the reporting columns or AEM prioritization a standard event does.
No. The 17 standard events cover the most common e-commerce and lead-generation flows, and Meta's optimizer is best tuned for them, but real DTC stacks routinely have flows the standard list does not cover -- a sample-request form, a waitlist-join, a quote-request, a size-selector interaction, a subscription pause. Fire those as custom events with trackCustom, then build custom conversions on top of them when you need Meta to optimize against them. Reserve the 17 standard names for events that actually match their Meta-defined intent; using Purchase for a newsletter signup, for example, corrupts the optimizer and inflates ROAS reporting until someone catches it.
Aggregated Event Measurement caps each verified domain at 8 prioritized conversion events for iOS-opted-out traffic. Standard events sit at the top of the priority list by default in the Events Manager UI, and Meta's own documentation and defaults nudge advertisers to fill those 8 slots with standard events first. Custom events can occupy AEM slots, but if the merchant loads the priority list with too many custom events at the expense of Purchase, InitiateCheckout, and AddToCart, the iOS-opted-out cohort loses attribution on the events that actually drive revenue. The optimizer then bids toward whatever it can still measure, which is often not the highest-value action.
Purchase requires value and currency at minimum -- without both, Meta cannot compute ROAS and treats the event as low-signal. AddToCart requires content_ids and content_type. ViewContent requires content_ids, content_type, value, and currency to be useful for Dynamic Product Ads and retargeting. InitiateCheckout expects value, currency, and content_ids. Passing a Purchase without a value field is one of the most common silent failures a monitoring tool catches: the event fires, Meta counts a conversion, but ROAS is zero because the value never made it into the payload.
Custom events must be sent with matching event_name from both the browser Pixel and CAPI, and every event pair -- browser and server for the same user action -- must share the same event_id. Meta's deduplication is exact-string on event_name and event_id; a browser Pixel firing SampleRequest and a CAPI payload firing sample_request will not deduplicate and both will count, inflating reported conversions. This is the single most common CAPI failure on custom events: the naming convention drifts between the front-end tag manager and the server-side handler, and the merchant sees inflated numbers with no obvious cause.
A custom conversion is a rule built inside Events Manager on top of either a URL match or an existing event -- standard or custom -- that lets the merchant optimize a campaign against that rule. For example, a merchant can fire a standard Lead event on any form submit, then build a custom conversion that only counts Lead events where the source_form parameter equals wholesale-inquiry. The custom conversion becomes selectable as an optimization event in Ads Manager. Custom conversions do not require code changes on the site -- they are pure rules on top of the data already flowing in -- but they are limited by the underlying event's own fidelity.
No. The Shopify pixel extension, especially after the August 2026 checkout upgrade, emits the core standard events -- PageView, ViewContent, AddToCart, InitiateCheckout, Purchase -- automatically from Shopify's own checkout and browsing telemetry. Custom events are not emitted by Shopify's own analytics stream. They have to be added via the pixel API inside a custom pixel or via a tag manager that runs on the storefront, and they are treated as separate from Shopify's built-in analytics events for reporting purposes. That separation is why merchants who rely only on Shopify's default pixel install often have no custom events at all.
PixelProof does not change which events fire -- that is a code and configuration decision the merchant owns. What PixelProof does is surface the standard-versus-custom event distribution on the storefront on every scan, flag standard events firing without their required parameters, flag custom event names that drift between browser and CAPI so deduplication silently breaks, and highlight when the AEM priority list has drifted away from the events that actually carry revenue. The output is a diagnostic map, not an auto-fix -- the fixes live in the tag manager, the theme, or the CAPI middleware, and the merchant or their agency ships them.
Standard-event parameters and custom-event naming conventions are the surface that determines whether your ROAS numbers reflect reality. PixelProof scans them continuously.