Meta Pixel Integration

Many people treat a Meta Pixel setup as finished once the base code sits in the head tag and the indicator turns green. The base code sends only PageView, which tells Meta nothing about who ended up buying. Optimise on that and the campaign will diligently find people who open pages, not people who pay.

A full install has four layers: base code with one Pixel ID not duplicated by an older copy in the theme or Google Tag Manager, conversion events mapped to real actions with value and currency in IDR, the Conversions API on the server, then domain verification in Business Manager, unlocking the eight Aggregated Event Measurement slots.

Slot order matters: Meta counts one event per visitor per visit, the highest priority one for that domain, so a Purchase sitting below PageView can vanish from iPhone users' reports.

Ad blockers, private browsing, and third party cookie limits cut off events before they reach Meta, and losing two to four conversions in ten is ordinary on mobile traffic. The Conversions API closes that gap by sending the same event from your server, a path no browser extension can intercept.

Two events describing one action must be recognised as one, which takes an identical event_id and event name so the copy is dropped. Matching improves through advanced matching: one way hashed customer details, an external_id from your CRM, and the fbp and fbc cookies from the original visit. More signals mean a higher Event Match Quality score.

Most sales in Indonesia do not close on the website. A visitor reads the page, taps the WhatsApp button, and the deal plays out in a chat no pixel can see. With nothing built for that, all Meta learns is that somebody opened a page and left.

We put a Lead event on every WhatsApp button, the floating one and those inside product cards, each carrying its page's context. For clients who log leads in a CRM, a second server side event fires when that lead becomes an order, carrying the deal value, so Meta learns to recognise buyers.

Almost every account we inspect has a live pixel. What it sends is rarely correct, and a broken pixel still produces numbers, so nobody complains until someone compares the report against real WhatsApp conversations.

The top two faults can be confirmed without extra tools: a duplicate pixel shows as two identical rows with different Event IDs, and runaway Purchase shows as more purchases in the report than orders in your system.

This check needs no developer access, even on a site another vendor built. Open Events Manager, select your pixel, go to Test Events, then paste in your site address. Your site opens in a new window and each event shows within seconds, so do whatever matters most to your business, such as pressing the WhatsApp button.

Only PageView means no conversion is recorded; two identical rows with different Event IDs mean a duplicate install. From there, read Diagnostics for missing parameters, check the Event Match Quality score, since under five usually means advanced matching is absent, then filter your Network panel to /tr requests.