---
name: set-up-pixel-and-standard-events
description: >-
  Installs the base Meta Pixel on every page and wires the standard event vocabulary - PageView,
  ViewContent, AddToCart, InitiateCheckout, AddPaymentInfo, Purchase, Lead, CompleteRegistration, Subscribe
  - with the parameters delivery and reporting read: value, currency, content_ids, content_type. Covers
  locating the pixel via mads_list_pixels, placing the base code on every page, not only conversion pages,
  firing each standard event at the right funnel step with typed parameters, naming custom events only when
  no standard fits, enabling advanced matching (hashed em/ph on every pixel fire) for a near-free Event
  Match Quality lift, and verifying every event in Events Manager Test Events. Reach for it first - before
  any conversion campaign, before CAPI, before attribution. It ends at verified browser events firing on
  every relevant page - the server-side twin is implement-conversions-api; catalog feed parameters belong to
  launch-advantage-plus-catalog-ads.
---
# Set Up the Meta Pixel and Standard Events

## Purpose
The pixel is the foundation everything else in measurement stands on: campaigns can't optimize
for a conversion Meta can't see, CAPI has nothing to mirror, and attribution has nothing to
attribute. This skill gets the base pixel firing everywhere and the standard event vocabulary
wired with the parameters (value, currency, content_ids, content_type) that drive delivery
optimization, dynamic-ad matching, and ROAS reporting, plus advanced matching, which raises match
quality using data the browser already has, for close to zero engineering cost.

## When to run
- A new domain or account has no pixel installed yet.
- A Sales/Leads campaign is being planned (`select-campaign-objective`) and pixel signal is
  missing or incomplete.
- A standard event fires without required parameters (e.g., Purchase with no value/currency),
  silently breaking value optimization and ROAS reporting.
- Advanced matching is off and EMQ is capped by browser-side match quality alone.

## When NOT to run
- The pixel already fires correctly with full parameters → move to `implement-conversions-api`
  for the server twin.
- The gap is server-side signal loss (ATT/ITP), not the pixel → `implement-conversions-api`.
- Base events are solid and the open problem is specifically match quality →
  `improve-event-match-quality`.
- The task is wiring a product feed to dynamic ads → `launch-advantage-plus-catalog-ads`
  (catalog-commerce).

## Prerequisites
- Admin access to the site's code or tag manager, and to Events Manager for the Business asset.
- A pixel created in Events Manager (or the existing one, located via `mads_list_pixels`).
- The funnel mapped to standard events: what page/action equals ViewContent vs AddToCart vs
  InitiateCheckout vs Purchase (or the lead-gen equivalents).
- Product/price data available at each event, usually from the page's data layer or CMS.

## Procedure
1. **Find or create the pixel.** `mads_list_pixels` for the `pixel_id` tied to the ad account's
   Business asset. HUMAN STEP: if none exists, create one in Events Manager.
2. **Install the base pixel on every page.** HUMAN STEP: place the base pixel script (or the Meta
   tag via a tag manager) in the global header so PageView fires on every load, not only
   checkout/conversion pages; partial installs undercount reach and break retargeting audiences.
3. **Map funnel steps to standard events.** ViewContent (product/detail page), AddToCart,
   InitiateCheckout, AddPaymentInfo, Purchase (order confirmation), or Lead/CompleteRegistration/
   Subscribe for lead and subscription funnels. Prefer a standard event over a custom one whenever
   one fits, only standard events get full optimization and AEM treatment.
4. **Attach required parameters to every commerce event.** `value` (a number, never a formatted
   string), `currency` (ISO 4217, e.g. USD), `content_ids` (matching catalog SKUs exactly),
   `content_type` (`product` or `product_group`). A Purchase with no value "fires" but is unusable
   for VALUE optimization and ROAS reporting.
5. **Name custom events deliberately, only when nothing standard fits.** Use a clear, stable name
   (e.g., `StartedTrial`); custom events can still be optimization events but don't get the same
   AEM priority-mapping treatment as standard events.
6. **Turn on advanced matching.** HUMAN STEP: enable automatic advanced matching in the pixel's
   Events Manager settings, or pass hashed `em`/`ph` in the pixel init call, a low-effort EMQ
   gain using data the browser already collects.
7. **Verify every event in Events Manager Test Events.** HUMAN STEP: walk the funnel end to end
   (view product, add to cart, checkout, purchase, or the lead-gen path) with Test Events open;
   confirm each event fires once, named correctly, with every required parameter populated.
8. **Spot-check production volume for a week.** Compare event counts against expected traffic or
   order volume; an event firing far below expectation usually means it's only wired on one
   template or page variant.

## Decision rules
- IF a funnel step has no matching standard event THEN create a clearly-named custom event rather
  than repurpose an unrelated standard event, misuse corrupts that event's meaning account-wide.
- IF Purchase fires without value/currency THEN treat it as broken, not done, value optimization
  and ROAS both depend on it.
- IF advanced matching is off THEN turn it on before any other EMQ work, it's the cheapest gain
  available.
- IF the pixel is only on some page templates THEN treat installation as incomplete.
- IF a custom event maps cleanly to a standard event (a custom "Order" that is really Purchase)
  THEN migrate it, custom events don't get the same AEM priority-1 treatment.
- **Done means:** the base pixel fires on every page, every relevant standard event fires with
  value/currency/content_ids/content_type where applicable, advanced matching is on, and Test
  Events confirms the full funnel with zero missing parameters.

## Common failure modes
- Pixel installed only on the checkout/thank-you page, retargeting and reach are both wrong.
- Purchase value passed as a formatted string ("$49.99") instead of a number, silently breaks
  value-based bidding.
- `content_ids` not matching the catalog's SKU format exactly, breaks dynamic ads and
  catalog-based retargeting even though the event technically fires.
- Duplicate PageView fires from an SPA route change re-triggering pixel init.
- Advanced matching left off "because CAPI will cover it", they're additive, not substitutes.
- Custom events multiplying because no one checked whether a standard event already covered it.

## Related skills
- Run before: `implement-conversions-api` (mirrors these exact events server-side),
  `improve-event-match-quality`, `configure-attribution-settings`,
  `configure-aggregated-event-measurement`.
- Feeds: `select-campaign-objective` (Sales/Leads objectives require this signal to exist first).
- Catalog-specific event parameters: `launch-advantage-plus-catalog-ads` (catalog-commerce).