Meta Conversions API Setup

The Conversions API is not a switch in Events Manager, it is a payload your server composes. Each one carries the same event name the pixel uses, the event time in seconds, the action source, hashed customer details, and the deal value in IDR. Leave a field out and Meta still accepts it and still counts it, so a misconfiguration rarely surfaces as an error.

Three things must be right at once: a token issued to a Business Manager system user, not a staff account that dies when they leave; the place the server code runs; and a short event list, since eight Aggregated Event Measurement slots per domain make a long one cannibalise itself. On our builds, payloads leave the server already included in the package.

The first task is not code, it is picking the events that stand for money arriving: Purchase with its value for a shop, a Lead on the WhatsApp press plus a second event on CRM approval for a service business. We settle that before writing code, because remapping events mid campaign throws away the baseline you would compare against.

A purchase reported twice, once by the pixel and once by the server, is deduplicated only when both payloads share an event_name and exactly the same event_id. That id is generated once on the page and reused on the server. Minting a fresh one server side is the fault we find most in audits, and the report doubles with no extra sales behind it.

That window runs about 48 hours, so slower payloads count as new actions. For an order that settles days later, send a different event with its own event_id rather than a repeat. Broken deduplication costs more than reporting: a campaign tuned to inflated numbers chases the wrong visitors, cost per result looks cheap, and your WhatsApp group stays quiet.

A server side event carries no cookies, so Meta needs other material to recognise the person: customer detail hashed one way with SHA-256 before it leaves, namely phone, email, name and postcode. Hashing happens on the server, and raw values never travel.

Two things sink Event Match Quality here: phone formatting and stray whitespace. Numbers belong in international form without the plus sign, because one still starting with zero hashes to a value matching nothing. Text must be lowercased and trimmed too, since a trailing space yields a different hash. A low match score usually means only one or two matching signals are actually reaching Meta.

In most Indonesian businesses the order does not close on the site. The visitor taps WhatsApp, haggles in the chat, then transfers the money. The browser pixel stops at that press, and with no server path all Meta learns is that somebody clicked and vanished.

The server path accepts events up to seven days late, which is what makes WhatsApp orders reportable. The press is logged as a Lead with an event_id and external_id, then once an admin marks it paid, the server sends a Purchase with the real rupiah value under that same external_id. Once purchase events carrying a rupiah value start landing, campaign optimisation has material to work with, and it can look for people who resemble buyers rather than people who resemble clickers.

Nearly every install we audit shows as active in Events Manager. What is rarely right is the payload, and since a wrong payload still produces numbers, nobody suspects anything until the report is held against the bank statement.

Checking it yourself takes three places. Test Events, with test_event_code pasted into your server config briefly, shows the payload within seconds and the matching material it carried. Diagnostics names missing parameters and events timestamped outside the window. The event source column should read as one event from browser and server, not two rows with suspiciously similar totals.

One last test beats all three. Turn on an ad blocker on one device, complete a conversion, then see whether the event still registers. If it does not, what you have is not the Conversions API, it is a browser pixel under a new name.