Standard vs Custom Events on Meta Ads

A standard event is an event name Meta already knows. Meta's developer documentation defines standard events as "predefined visitor actions that correspond to common, conversion-related activities, such as searching for a product, viewing a product, or purchasing a product," and you fire them with the pixel's fbq('track') function or send them as the event_name on a Conversions API payload. The name carries the meaning. Send Purchase and the delivery system knows it just received a bottom-of-funnel commercial signal, with a currency and a value attached, from an advertiser whose behaviour it can compare against every other advertiser sending Purchase. That shared vocabulary is what unlocks the rest of the machinery. Meta's reference page marks currency and value as required on Purchase, and flags required properties on AddToCart, Search and ViewContent for Advantage+ catalog ads. Those requirements exist because product features are wired to specific event names carrying specific parameters. Rename your product-page signal to something clever and the catalog integration has nothing to key off. One name people expect on the list is missing. PageView is not in the standard events table: it lives in the base pixel code, fires on every page automatically, and is the raw material custom conversions are built from rather than a conversion goal you select.

Meta groups nothing formally, but the list falls into recognisable clusters. The browsing and discovery signals are ViewContent ("a visit to a web page you care about (for example, a product page or landing page)"), Search, FindLocation (someone looking up one of your store locations), CustomizeProduct (a person configuring a product) and AddToWishlist. These are cheap, frequent and high-volume, which makes them useful for audience building and early-funnel optimisation but weak as a definition of business success. The purchase path is four events in sequence: AddToCart, InitiateCheckout ("when a person enters the checkout flow prior to completing the checkout flow"), AddPaymentInfo, and Purchase ("when a purchase is made or checkout flow is completed"). Purchase is the only one Meta marks as requiring currency and value, which is the mechanical reason value optimisation and purchase ROAS reporting go blank when a store fires Purchase without them. The relationship and lead cluster is where taxonomy arguments actually happen: Lead ("when a sign up is completed"), CompleteRegistration ("when a registration form is completed"), Contact (someone reaching you by phone, SMS, email or chat), Schedule (booking an appointment at one of your locations) and SubmitApplication (applying for a product, service or program). Rounding out the 17 are StartTrial, Subscribe for a paid subscription, and Donate. The list has shifted over the years, so treat Meta's reference page as the canonical version and re-check it before you finalise a tracking plan.

Meta frames custom events narrowly: reach for one when "our predefined standard events aren't suitable for your needs." You fire it with fbq('trackCustom') under any name you like, provided it is a string of no more than 50 characters, and the Conversions API accepts a custom name in event_name just as readily as a standard one. The honest test is whether a standard event would be a lie. A martial arts studio logging a completed belt grading, a B2B tool logging a workspace invite accepted, a publisher logging an article read to the end: none of those map onto the 17, and forcing them into Lead or CompleteRegistration would corrupt the meaning of an event you also use elsewhere. Those are real custom events. What is not a real custom event is a purchase you decided to call order_complete, or a quote form you decided to call quote_request, where the standard name existed and got skipped for house-style reasons. Skipping it costs you more than tidiness. A custom event carries no shared meaning: there is no cross-advertiser prior for order_complete, no required parameter schema to validate against, and no Meta product feature keyed to that name. Meta's Conversions API best-practice guidance states that "you can use only matched events for ads attribution and ad delivery optimization," so a sparsely parameterised custom event starts at a disadvantage on both counts. In Ads Manager, conversion event selection is built around standard events and the custom conversions you have defined, so a bare custom event sits in Events Manager as a raw signal rather than something a campaign can straightforwardly optimise toward.

A custom conversion is not a third kind of event. It is a rule you define in Events Manager that counts the events matching criteria you set, built on a standard event, a custom event, or a URL pattern. Meta's documentation describes custom conversions as tracking visitor actions parsed from your site's referrer URL off PageView events, which is why a marketer can define one for a /thank-you page without a developer touching the site. The rule works in two directions, and both are useful. Upward, it promotes a custom event into something selectable: define a custom conversion whose rule matches belt_grading_complete and a campaign can now be pointed at it. Downward, it splits a standard event into finer slices without breaking it: purchases above a value threshold, purchases of one product line, leads from one referring domain. The underlying Purchase event keeps its standard name, its currency and its value, so you gain granularity without giving up the vocabulary the delivery system understands. Two caveats before you lean on them. Meta's documentation notes that from 2 September 2025, custom conversions whose definitions suggest specific health conditions or financial status are flagged and prevented from being used to run ad campaigns, so a rule built on a URL like /diabetes-plan can be blocked. And a custom conversion inherits whatever quality its source event has: wrapping a thin, unparameterised signal in a rule does not thicken it. Decide the taxonomy first, map every meaningful action on your site to a standard event where one honestly fits, and reserve custom events plus custom conversions for the actions that genuinely have no standard name.