In short
A marketing pixel is a snippet of code on a website or in an email that reports user actions to an ad or analytics platform. Pixels power conversion tracking and retargeting by firing when a page loads or an action completes, sending the event and available identifiers back to the platform. They are also the piece of the stack that browsers and ad blockers increasingly restrict, which is why the same events are now sent server-side as well. A pixel is not obsolete: it captures browser context and fires in real time, which a server cannot replicate. The problem is coverage, because relying on the pixel alone means losing every event a blocker, a tracking-prevention feature, or an expired cookie removes. The durable pattern is a pixel and a server-side stream running together, deduplicated with a shared event ID, so you keep the pixel’s real-time context and recover the events it drops.
Why pixels undercount
Safari and Firefox cap cookie lifetimes, ad blockers strip tracking scripts, and slow pages lose events before the pixel fires. The pixel still has a job, but on its own it reports a partial picture.
Pixel plus server
The current standard is both: the pixel for real-time browser signal, a Conversions API for completeness, deduplicated with a shared event ID so platforms count each conversion once.
Why does a pixel alone undercount?
A retailer’s pixel reports fewer purchases than its order system records, because some browsers block it. Sending the same purchases server-side, deduplicated against the pixel, closes the gap between reported and actual sales.
Reference: Meta for Developers, Meta Pixel