Event Match Quality Repair for Meta and TikTok Pixels

An Event Match Quality score below 6.0 on Purchase means Meta is discarding a share of your conversions before the bidder ever scores them. Most accounts we open sit between 4.2 and 5.5. Ten working days of work usually moves Purchase to 8.0 or above, and the account that follows behaves differently on identical creative and identical budget, because the optimiser is finally being graded on events it can attribute to a person. What we believe about this: The bidding model is the product you are buying. Agencies that skip this step spend the next six months managing around a fault they cannot see, then bill the plateau as creative fatigue. We will not take a media retainer on an account we have not measured first, and this engagement exists so that refusal has somewhere to go. What the work touches: We diff browser and server payloads event by event. Every Purchase, InitiateCheckout, AddToCart and Lead that leaves the browser is matched against what arrives at the Conversions API, and we count which ones arrive once, twice, or never. Deduplication is verified on event_id and event_name pairs rather than assumed from documentation. Parameter coverage is rebuilt in order of match weight: external_id, em, ph, fbc, fbp, client_ip_address and client_user_agent before the address block, because that is the order the graph actually resolves in. The single most frequent fault in Polish stacks is fbclid landing before the consent banner resolves, so _fbc is never written and every subsequent event loses its strongest identifier. That is a banner sequencing problem, not a pixel problem, and we will tell you so rather than sell you a container. On TikTok the same diff runs against Events API 2.0: ttclid and _ttp capture, event_id parity between Pixel and server, and the Advanced Matching fields TikTok weights differently from Meta. Delivery paths we work in: server-side Google Tag Manager on a first-party subdomain, Stape, Shopify's Web Pixels sandbox and Checkout Extensibility where parameter truncation happens silently, and Meta's Conversions API Gateway when there is no engineering time to book this quarter. Consent: We work inside TCF v2.2 and Consent Mode v2. We do not transmit personal data without a legal basis, we do not hash an email server-side and describe the result as consented, and we do not build anything that routes around a refusal. Where the real constraint is a 38 percent consent rate, the fix is the banner and the words on it. What you receive: A payload diff as a spreadsheet, one row per event, with the failing parameter named. The GTM container export or CAPI implementation as a change your team can read and reject. Dated before and after EMQ readings per event. A one-page note for your engineering lead, written to be actioned without us in the room. Not included: Attribution modelling, MMP configuration, media buying, creative. Consent platform licensing. Any claim that recovered events equal recovered revenue; they do not, and a shop quoting you the uplift in advance is guessing. Who this is not for: Accounts spending under roughly 40,000 EUR a month, where the measurement gain will not clear the fee. App-only advertisers, whose iOS work is a separate engagement with different mechanics. Teams who want the number raised for a board slide. EMQ is a diagnostic, not a target, and we will not tune it in isolation from delivery.