Pixel and Conversions API Repair for Meta and TikTok

Most Meta pixels we inherit in Mexico score between 4.2 and 5.8 on Event Match Quality for Purchase. We rebuild the event layer until Purchase holds at 8.0 or better across a full 14-day window, and in this market the single change that does most of that work is phone normalization, not email. Mexico dropped the 1 that used to follow +52 on mobile numbers in August 2019. Most CRM and checkout exports still carry it. Every one of those rows fails to match. Where we start: We read the flow before we touch it: the browser pixel, whatever tag manager sits in front of it, the checkout or booking backend, and the system that actually holds customer identity. We diff the payload leaving the browser against the payload leaving your server for the same order, then count the events that arrive twice, arrive once, or never arrive. On a typical travel account we find 8 to 20 percent of purchases missing from the server stream entirely, and almost always they are the ones that settled late. What we build: Server-side events on Meta's Conversions API and TikTok's Events API, sent from your backend at the moment of business truth — a confirmed booking, a settled OXXO payment, a captured SPEI transfer — rather than at a browser redirect. Deduplication on a shared event_id that both server and browser emit, so the pair collapses instead of double-counting. Click identifier capture and persistence: fbclid and ttclid read on landing and written to a first-party cookie by your server, because Safari caps JavaScript-written cookies at seven days and your booking lag is longer than that. Identifier hashing to spec: E.164 phone numbers without the legacy 1, lowercased and trimmed email, city, state, postal code, country, and an external_id keyed to your own customer record so audiences and events share one spine. The parts specific to this region: Click-to-WhatsApp traffic carries a ctwa_clid that most implementations drop on the floor. We capture it at the message webhook and post the conversion back when the conversation qualifies, not when it opens. Delivery aggregator orders through Rappi, DiDi Food and Uber Eats never touch your pixel; we tell you which of those can be recovered through promo-code or deep-link mapping and which are permanently dark, in writing, before you pay us. What we will not do: We will not install a tag manager container and describe it as server-side tracking. We will not send an identifier we have not watched match in a test event. We will not configure your consent platform or advise on what it should collect — that is your counsel's decision and we implement against whatever it emits. We do not attach a monthly monitoring fee to this work; you get the runbook and your engineers own it afterwards. Who this is not for: Advertisers with no backend access and no engineering time. This work lands in your codebase and somebody on your side has to merge it. If your only route to the site is a marketing tag manager, the ceiling here is low enough that we would rather decline than take the fee. What you receive: The pull request or code specification, a payload map for every event, before-and-after match quality broken out by parameter, and a one-page statement of what remains unmeasurable and why.