What broke · Meta Conversions API · 4 September 2026
One dataset for every client, and why that is wrong.
Send every client's bookings to one Meta dataset and one company's ads learn from another company's customers. Each client needs their own, read from their own row.
What broke By Lovro Lucic · 4 September 2026 · 2 min read
What Meta does with external_id
external_id carries your own identifier for a person, hashed. Meta uses it to cluster a person's events into one identity inside a dataset. That is what lets a "sat" event attach to the "booked" event before it. It is also what turns an audience of "held a slot, never confirmed" into a list of people rather than a list
of hits. It does that per dataset. Send two businesses' people into one dataset and it does what you asked: it clusters them together.
What breaks
An agency-style system runs several clients. The Conversions API token and pixel id get read from the
environment, one pair for the whole deployment, because that is the shape the first account set up leaves
behind. Add a second client and every one of their bookings goes into the first client's dataset. The first
client's ad account then learns from people who booked a bathroom in a different state with a different
company. Nothing fails. Events Manager shows healthy volume. The one symptom is an account that learned the wrong thing, over weeks.
The rule
- The dataset is a property of the client, read from the client's row on every send, the way Google's customer id already is. The deployment's own dataset is a fallback for one client: the deployment itself.
- Refuse rather than fall back. A client that runs its own ad account and has no dataset recorded must send nothing. A conversion in the wrong dataset is worse than one that never went. The missing one shows up as an unsent event in your own record. The wrong one is invisible everywhere, and it teaches the wrong account.
- The retry has to route the same way. A repair sweep that resends failed events must carry the client's dataset on each row. Otherwise every retry undoes the routing the live path got right.
- Warn at setup, refuse at send. A readiness check that says "pixel id is not set" is only useful if the sender enforces it. The warning is the half people build; the refusal is the half that makes it matter.
How to check it yourself
Pick a client. In their Events Manager, look at the server events' page address, the field event_source_url, and the
count. If the count covers every client's bookings, or the URL points at another client's booking page, this is your
setup.
What this does not cover
- Meta's agency and business-manager structures for sharing a pixel across accounts on purpose. This note is about sharing one by accident.
- Whether a shared dataset is ever the right design. For a franchise system with one brand and one funnel it can be; for independent businesses it never is.