The pixel log: reading exactly what happened to every conversion attempt

When a conversion you expected does not appear, guessing is the slow way to find out why. The pixel log is the fast way. It records every conversion-pixel and postback attempt your tracking endpoints received — whether it stored a conversion, was ignored, or failed — and tells you exactly what the tracker did with each one. It is the inbound record: pixels arriving at the platform, as opposed to the outbound pixels the platform fires at your affiliates.

What each row shows

Every attempt logs the time, whether it was a browser pixel or a server postback, the offer, advertiser, affiliate, and campaign it resolved to, the click ID and transaction ID that were sent, the request URL with sensitive values redacted, the event and revenue, and a disposition — a short code for what the tracker did — alongside a plain-language reason. Expand any row for the full request parameters and a what-to-check hint. A summary strip across the top shows attempted, converted, and ignored counts for the range, with a clickable chip per disposition so you can filter to just the rows you care about.

There is a small quality-of-life detail for admins: because the logged parameters are redacted, a failing pixel can be hard to place. When the platform can match a contact from the pixel's email or phone, the expanded row shows that person's name and contact details — looked up live, never stored in the log — so you can tell whose conversion an attempt was while you investigate.

The dispositions and what to do

• converted — a new conversion was stored and credited. This is the one you want; nothing to fix.
• unattributed — no click matched, by parameter or cookie, and no affiliate ID was sent. The conversion is recorded but counts as ignored, with revenue and payout zeroed, and appears in no performance report. The reason text pinpoints the cause, including a cookie ignored for being outside the offer's attribution window. Fix the click-ID passthrough, extend the window if conversions arrive late, or send an affiliate ID on server pixels.
• click_not_found — the click ID did not match any recorded click, but an affiliate fallback still attributed it. Usually a placeholder value, a typo, or a truncated click ID; fix the plumbing that carries the click ID to the pixel.
• duplicate — a re-fire with an existing transaction ID, a matched dedup rule, or a second conversion on a one-per-click offer. This is normal and safe for retries and refreshes. Only investigate if you expected a genuinely new conversion, in which case your transaction ID is probably being reused.
• cap_rejected — a conversion cap set to Redirect dropped it, so nothing was stored. Raise the limit or switch the cap to Continue if you would rather keep recording.
• test_mode — the attempt carried a test flag from a dry run and was kept out of live reports. Expected during testing.

The same codes come back to your server

A server fire — a POST, or a GET with format=json — returns a status field using the very same vocabulary as these dispositions, plus a couple more for account-resolution and internal errors. So a server integration can read the outcome in its own logs without opening this page at all; the pixel log is still where you get the full request parameters and the human-readable reason.

How long entries last

The pixel log is a short-term diagnostic record: individual entries are kept for 90 days and then removed. This never touches your conversions or their attribution — those live in your reports for the life of the subscription. If you need a permanent copy for an audit or a partner dispute, widen the date range and export a CSV before the rows age out.

Want us to sit down with your pixel log and turn the red rows green? Book a demo and we will troubleshoot it with you.