Question from Reddit user:
One of my clients has been struggling to implement CAPI for over a year now, and their IT just can’t do it. Currently they’re struggling with deduplication, and whatever spaceship ecomm custom build they have is fucking it up so that they can’t work it out.
(Don’t tell me they need to change IT, that’s obvious to me, but I am not the decision maker here, I’m just the agency.)
So my client has asked whether it’s smart to keep the pixel at all, and if we went with only CAPI then maybe we wouldn’t even need to deduplicate. I couldn’t really answer this question, because while it seemed deduplication is meant to ensure pixel and API events aren’t tracked twice, I’m not sure it’s not necessary to have unique events IDs for other reasons as well.
Has anyone had a CAPI-only setup? Is that viable? Also, do we need to deduplicate in that case?
Thank you!
Answer from Nabil:
The short answer is:
Yes, a Conversions API (CAPI) only setup is absolutely viable and is becoming the preferred, most reliable method of sending conversion data to Meta, but you will still need a robust method for managing unique event identifiers for accurate reporting and optimization.
Deduplication is specifically required only when you send the same event via both the Meta Pixel (browser-side) and CAPI (server-side).
If you remove the Pixel entirely and only send events via CAPI, you will eliminate the need for deduplication, significantly simplifying your tracking.
A server-side solution using the Facebook Conversions API with Google Tag Manager and a server-side host like Stape or Google Cloud Platform is the ideal solution to bypass your client’s current IT and custom e-commerce platform struggles.
The long answer is:
Your client’s instinct to switch to a CAPI-only setup is a sound strategic move, especially given the continuous challenges with client-side tracking, such as browser restrictions, ad blockers, and your client’s unique e-commerce platform complexities.
The primary purpose of deduplication is indeed to prevent double-counting when Meta receives identical events from the browser (Pixel) and your server (CAPI).
By moving to a CAPI-only model, you entirely eliminate this specific deduplication requirement.
This simplification addresses the exact issue your client is currently struggling with.
However, you still need to ensure your CAPI events are correctly structured.
Even in a CAPI-only setup, unique event IDs are essential.
Meta uses these IDs to process events accurately, particularly for things like delayed events, multi-device matching, and ensuring the quality of the data for their machine learning algorithms.
If you send the same purchase event twice with two different timestamps but the same unique event ID, Meta’s system will recognize it as a redundant submission and will ignore the second one, preventing duplicate counting in your reports.
The most effective way to implement a stable, CAPI-only solution that bypasses your client’s unreliable e-commerce platform is to use Google Tag Manager and a server-side tagging host like Stape or Google Cloud Platform.
You would implement a single, reliable data layer on the website to capture your standard events like PageView, ViewContent, and Purchase.
GTM then passes this data from the client-side to your server container.
The server container, which is hosted on Stape or GCP, processes the data, attaches a unique event ID to each event, and then sends the event directly to Meta’s server using the Facebook Conversions API.
This approach insulates your tracking from browser issues and your client’s complex e-commerce build, giving you a much more reliable, first-party data stream that will immediately improve reporting accuracy and campaign optimization, without the headache of cross-platform deduplication.
About The Author
