Adding city or state to a Meta Conversions API event can move its Event Match Quality (EMQ) score. That does not, by itself, show that Meta matched more people. If your server derived those fields from the very IP address already in client_ip_address, you supplied a second description of the same network observation. A real address entered at checkout is different: it comes from the customer and may carry information the IP cannot provide. Meta accepts both types of fields, but does not publish the weighting needed to claim that any particular score increase is a matching gain.
This distinction matters when an audit turns into a race for a 9 or 10. EMQ is a diagnostic for the customer information on web events, not a measurement of revenue or match rate. Our EMQ score guide explains how scores differ across PageView, Login and Purchase. Here the narrower question is whether extra location fields add useful evidence or just make a dashboard look healthier.
What does Meta actually ask you to send?
Meta’s Conversions API customer information reference lists client_ip_address and client_user_agent separately from ct (city), st (state), zp (postal code) and country. Its GTM server tag maps the client IP from the event model and hashes city, region, postal code and country from address data when available. That implementation confirms the fields exist and can be sent together. It does not say their contributions are independent or reveal the EMQ formula.
Send the visitor’s real client IP, rather than the address of your server or proxy, when policy and consent permit. Meta says not to hash the IP address. Customer address fields require the normalization and SHA-256 hashing specified in the reference. Do not copy a hashed value into the wrong field or label a shipping address as a browser location. The CAPI with GTM guide covers the route from the browser request to the server event.
| Field | Where it can come from | What it tells you |
|---|---|---|
client_ip_address |
The visitor’s request, forwarded correctly through your server | A network address; useful for matching, but shared and changeable |
ct, st, zp, country from IP lookup |
A database’s estimate from that same address | Approximate location, with no independent customer observation |
ct, st, zp, country from checkout |
An address supplied for an order or account | Potentially independent customer data, subject to accuracy and permission |
em, external_id, fbp, genuine fbc |
Account, browser or ad-click context | Other identifiers with their own collection and validation rules |
Why isn’t IP-derived location a new signal?
An IP lookup takes an address and returns an estimated place. If the input IP is already in the CAPI payload, the returned city and state are functions of information Meta already received. They can make the payload more complete according to a field checklist, but they do not create a new observation of who bought. IP geolocation can also be wrong at city level, especially for mobile networks, corporate egress, VPNs and shared connections. An inaccurate city adds noise to the event.
There is a limit to what anyone outside Meta can claim. Meta does not publish its matching weights or a controlled result isolating IP-derived ct and st. It would be too strong to promise that those fields never affect matching, just as it would be too strong to promise that a higher EMQ proves they do. A published CAPI experiment found that IP-based matching can occur even with very little other information, and also documented accuracy limits. That experiment sent IP-derived location along with the IP; it did not isolate city or state. It supports caution about proxy signals, not a universal zero-effect claim.
When can city and state be useful?
A verified checkout or account address can describe a person more specifically than the network they happened to use. A buyer may place an order on a work connection, travel, or use mobile data routed through another city. In those cases a real customer address could help distinguish records. It still needs to be accurate, permitted for this use, normalized and hashed as Meta requires. An old billing address or a merchant’s own location is not a substitute for the customer’s information.
The value also depends on the event. An anonymous PageView normally has no customer address. A Purchase may have one, along with email, account ID and browser context. Review the fields that legitimately exist at each step instead of copying checkout fields backward into earlier events. If your Purchase lacks the actual client IP, email that the customer supplied, or a stable external_id, fixing that collection path is a clearer first task than enriching every PageView with an IP lookup. The Facebook Conversions API guide explains the matching fields and their formats.
How do you test whether location fields helped?
Start with a payload audit. In your server logs or a safe test environment, verify where each value originated. Record whether ct and st were entered by a customer or inferred from client_ip_address. Check forwarding headers so the IP is the visitor’s, and compare the city lookup with any verified address before trusting it. Never put raw personal fields in diagnostic logs.
Then compare like with like. Hold the event type, time window, eligible traffic, consent state and other identifiers as steady as possible. Change only the location fields for a controlled cohort if your implementation and policy allow it. Watch EMQ, parameter coverage and Meta’s additional conversions reported, where available. Compare the purchase count against the payment or order system as a separate check. A score change with no movement in a useful outcome is a dashboard result, not evidence of better attribution. A movement in outcomes still needs enough volume and a stable comparison before you call it causal.
Do not send fabricated city or state values to make the test easier. Use real permitted data or omit the fields. Meta’s best practices frame EMQ as an estimate of how effective customer information may be at matching. The word estimate matters: it is not a public counter of matched accounts. The event recovery guide likewise separates events delivered to a platform from real orders recovered.
What should a tracking audit prioritize instead?
Work from the event’s purpose backward. For Purchase, verify that the payment webhook represents a confirmed transaction, the event carries its stable order reference, and browser and server copies use the same event name and event_id for deduplication. Then inspect the customer fields that actually exist: email, account ID, client IP, user agent, fbp, and fbc only where a real Meta click created one. Check consent and hashing at the point each field enters the pipeline. Finally, inspect EMQ and any coverage warnings.
This order keeps the score in proportion. A perfectly formatted location field will not repair a duplicate Purchase or a success page that fires before payment clears. If you implement for clients, the Advanced Tracking Academy library includes GTM containers built around webhook-validated conversions. Stape hosting can support the server container when that architecture fits, but hosting does not turn guessed location into verified customer data.
Practical rule: keep genuine customer location when you have a lawful reason to send it. Do not add city and state guessed from an already-sent IP solely to polish EMQ. Judge any change against verified event quality and a comparable outcome, not the score alone.