how this one is built
Every other plugin sends events. PixelCapi proves they arrived.
That sentence is the entire product, and it is a claim about evidence rather than features. A sent event and a delivered event are not the same thing, and only one of them can be checked.
This page is what follows from taking that seriously: what gets included, where the sending runs, and what we refuse to tell you we know.
proof over promises
A setting is not evidence.
Every plugin in this category has a deduplication switch, and every one will report that it is on. That is a description of intent. What you need is the event ID that actually went out.
One ID on both halves of the same event, with the platform's own trace ID recorded beside the server send. That is the strongest evidence obtainable from outside the platform's systems, and it is the thing the whole product is arranged around.
everything included
One price per number of sites. Nothing else changes.
Everything included at every tier. No add-ons. No product limits. Tiers differ only by number of sites.
- Every platform integration, at every tier.
- Every proof tool, at every tier.
- No add-ons to buy, ever.
- No product, catalogue or event-volume limits.
- Tiers differ by one thing only: how many sites you may activate.
your server is the server
No containers. No rented cloud.
PixelCapi runs server-side from your own WordPress server. The server-side half needs no tag-manager container to configure and no cloud host to pay for, because the machine already serving your store is doing the sending.
Cache-proof by design
No per-visitor event ID is ever baked into cacheable HTML. Byte-identical cached pages were verified to still produce unique matched pairs.
Server-first Purchase
Purchase fires from the payment hook, so a sale survives an offsite gateway, a closed tab and a thank-you page that never loads.
Never in the checkout's way
An asynchronous queue with retries means a slow platform API delays nobody's payment — and does not quietly lose the event either.
honest verification
We say what we cannot confirm.
The temptation in this category is a green checkmark that means nothing. It is also the fastest way to lose the only thing a measurement tool sells.
-
What a Verify button should say
Each platform gets its own verification, and each one reports what it can and cannot confirm. Where a platform’s endpoint cannot authenticate credentials without OAuth, we say exactly that instead of showing a green check that means nothing.
-
What the log shows
Both copies of every event, the event IDs they actually carried, and the trace ID the platform returned for the server send. That trace ID is the platform’s own receipt.
-
What we will not claim
The free checker cannot confirm that a server-side event arrived, because nothing outside your own server can. Every report says so, in the report.
The same rule governs this website. Capabilities still in development carry a badge wherever they are mentioned, including on the pricing page, rather than being listed as if they shipped.
Coming to PixelCapi ProEU-facing, consent-first
Consent gates both halves, together.
A server-side event that ignores a visitor's refusal is not a technical detail — it is the refusal being overridden by the half they cannot see.
One decision, both sides
Consent gates the browser pixel and the server send together. Google Consent Mode v2 is supported in both basic and advanced modes.
Consent that survives the redirect
A payment webhook arrives with no cookies and no session, so the visitor's decision is recorded on the order at checkout and read back when the event is finally sent.
This site holds itself to it too: nothing loads until you choose, and the privacy page lists every event by name.
questions
What people ask before buying
What does “proving delivery” actually mean?
Every conversion is sent twice — once from the browser, once from your server — carrying one shared event ID so the platform merges them into a single conversion. Dedup Doctor shows you both copies and compares the IDs they actually carried, with the platform’s own trace ID beside the server send. A deduplication setting describes an intention; the event IDs on the wire describe what happened.
Do I need Google Tag Manager?
No. PixelCapi sends from your own WordPress server straight to each platform’s API. There is no container to configure and no cloud service to rent for the server-side half.
Which platforms does it send to?
Meta via the Conversions API, GA4 via the Measurement Protocol, Google Ads via its tag, and TikTok via the Events API — each with that platform’s own hashing rules, including the multibyte and diacritic case folding and the phone and geo differences between them. Pinterest, Bing and Snapchat are not supported.
Does it slow down my checkout?
No. Sends go through an asynchronous queue with retries, so a platform API having a bad minute never holds up a customer’s payment — and never silently drops the event either.
Is everything on this page available today?
Not all of it. Order-to-Event Reconciliation, the Match Quality Center, the Identity Store and the Health Watchdog are in development, and every page that mentions them says so with a roadmap badge. Dedup Doctor, server-first Purchase, the platform integrations and the consent handling ship today.
What happens to my data?
Personal data is SHA-256 hashed to each platform’s own normalisation rules before it is sent. IP address, user agent and click IDs go raw because the platforms require them in that form. Access tokens are stored server-side only and are never logged.
Stop guessing. Start proving.
The free checker reads your public pages and reports what is really on them. Read-only, no signup, about ten seconds.
Free, no signup
Check your tracking