What a standard event is
Meta publishes a fixed list of action names it recognises. Purchase, Lead, AddToCart, ViewContent, InitiateCheckout, CompleteRegistration, Contact, Subscribe and Search are among the most used. When your site sends an action using one of these exact names, Meta understands what happened without being told anything else, and the event becomes available for optimisation, audience building and reporting.
The names are case sensitive and must be spelled exactly. Send purchase or Purchased and Meta treats it as a custom event — it will still be recorded, but it loses the built-in meaning. Most standard events also accept parameters: a value and currency on a purchase, a content identifier on a product view. Those parameters are what allow value-based bidding and catalogue matching to work at all.
Why standard events matter
They are the vocabulary the optimisation system speaks. A campaign optimising for Purchase is looking for people whose behaviour resembles that of past purchasers, and it can only do that if purchases are labelled as purchases in your dataset. Mislabelled events force the system to learn from the wrong pattern.
They also make several features possible that custom events cannot reach cleanly: return on ad spend reporting from purchase values, dynamic product ads matched through content identifiers, and lookalike or retargeting audiences built on a specific step of the journey rather than on all site visitors.
Where standard events go wrong
The most common fault is firing on the wrong trigger. A Lead event placed on the contact page rather than on the thank-you page counts everyone who arrived, so the campaign optimises towards people who look at forms instead of people who submit them. Fire the event when the action completes, not when the page that offers it loads.
The second is inventing names that are nearly standard. A team writes Purchase_Complete because it reads better internally, and quietly loses value-based bidding for the account.
The third is duplication. A plugin fires Purchase, a tag in Tag Manager fires it again, and revenue in Ads Manager climbs to a level the accounts do not support. The fourth is sending a purchase value in the wrong currency, or with a currency code missing, which makes reported return on ad spend meaningless — a real risk for businesses in Nepal selling to customers abroad in a second currency.
Getting it right
Write down which real business action maps to which event name before anyone touches code: an enquiry form submission is a Lead, a completed order is a Purchase, a newsletter sign-up is Subscribe. Agree it once, then implement it once, in one place, so no second system fires the same event again.
Then verify rather than assume. Use the Test Events tool in Events Manager to walk through the journey yourself and watch each event arrive with its parameters attached. Check that a purchase carries value and currency, that the event is not firing twice, and that the count in Ads Manager is close to the count in your own order records. That verification is part of any Meta Pixel and Conversions API setup, and it is the step most often skipped.