Meta Pixel & Conversions API specialist — diagnose and fix over-counting Purchase events

Summary We run an online social sweepstakes gaming platform. Our Meta advertising is being undermined by a tracking problem: Meta is reporting far more Purchase events (and far higher purchase value) than actually occur in our backend database. We need an experienced Meta Pixel / Conversions API (CAPI) specialist to audit our current setup, identify exactly why the Purchase event is over-counting, fix it, and validate the fix against our real transaction data. The problem Meta's reported purchases and purchase value are dramatically higher than the actual purchases recorded in our database. The gap is large and systematic — Meta-reported return on ad spend runs roughly 5× our true figure, and on individual days we've seen Meta report 60×+ against an actual return of around 2×. This isn't just a reporting nuisance. It corrupts campaign optimisation: when we run value- or purchase-optimised campaigns, Meta optimises toward inflated conversions and wastes budget chasing events that didn't really happen. We've had to pause our value-optimised ad set as a result. What we know / don't know We are not certain how our tracking is currently configured — specifically whether the Purchase event fires browser-side only, via the Conversions API only, or both. Confirming this is part of the job. We do not yet know the exact over-fire mechanism. We can clearly see the discrepancy versus our database; we have not isolated the cause. Suspected causes (for you to confirm or rule out) Browser Pixel and Conversions API both sending Purchase without correct event_id deduplication (the classic cause of 2–5× inflation). The Purchase event firing more than once per transaction (e.g. on confirmation-page reloads, back-navigation, or single-page-app re-renders). Purchase firing on non-purchase actions (page loads, add-to-cart, etc.). An incorrect or multiplied value parameter. Scope of work / deliverables Audit our current Pixel and CAPI/server-side setup (tag manager, site code, server events — wherever Purchase is sent from) and document how it is actually wired today. Diagnose the precise cause of the over-counting, with evidence (e.g. event logs showing duplicate or spurious fires). Implement the fix — correct deduplication (event_id shared across browser + server), correct firing trigger (once per genuine purchase), and correct value/currency parameters. Reconcile and validate Meta-reported Purchase counts and value against a sample of our backend transaction records, demonstrating the numbers now align within an acceptable margin. Document the final setup and hand over a short runbook so we can maintain it and spot regressions. Access we will provide Meta Business Manager — Events Manager and the relevant Pixel/Dataset (partner/limited access). Access to our website code and/or tag manager container. Access to our server-side event environment, if CAPI is server-side. A sample of aggregated backend purchase records for reconciliation. No customer personal data will be shared — reconciliation will use counts, values and timestamps only. Required skills / experience Demonstrable, recent experience with Meta Conversions API and server-side tracking (not just the browser pixel). Deep understanding of event_id deduplication and how Meta matches browser and server events. Comfortable working in [tag manager / server-side GTM / CAPI Gateway / direct API — we'll confirm which once you audit]. Experience reconciling ad-platform-reported conversions against a source-of-truth database. Engagement Phase 1 — Audit & diagnosis (fixed scope, fast turnaround): tell us exactly what's wrong and how you'll fix it. Phase 2 — Fix & validation: implement, then prove it against our data. This is time-sensitive — we want to begin this week. Please state your earliest start date and rough turnaround for Phase 1. To apply, please include A 2–3 sentence summary of how you'd approach diagnosing browser-vs-server duplicate Purchase events. One example of a past project where you fixed conversion over-counting or built/repaired a CAPI setup, including the before/after discrepancy. Your availability this week and your rate (hourly or fixed for Phase 1). Answers to the screening questions below.