Postback comes back 200 every time and the conversion still isn't in my tracker

Have strange one. Network fire postback, i see it in my access log, my endpoint answer 200. Conversion not appear in tracker.

Not all of them. Maybe one in six. Same offer, same source, no pattern i can find by hour or by geo.

I check the click id is in the request, is there. I check the log again, is 200. Anyway the tracker just does not have the row. Is like the request arrive and then nothing happen with it.

Who has seen this before.

200 means your web server accepted the request. It says nothing about whether your tracker ever processed it. Those are two different pieces of software and people conflate them constantly.

First thing to separate them:

grep 'postback' access.log | awk '{print $7}' \
  | grep -o 'cid=[^&]*' | sort > from_log.txt

Then export the click ids your tracker actually recorded for the same window and diff the two files. If the log has 600 and the tracker has 500, you have your hundred and you know they arrived.

IME the usual cause at that ratio is a duplicate-suppression window. Most trackers drop a second conversion on the same click id inside some interval, default is often 60 seconds or five minutes, and if the network retries on a timeout you get exactly this: request logged, 200 returned, row silently discarded as a dupe.

Second most common is your queue. If conversions go through a worker and the worker dies quietly, you'll get 200s all day and no rows.

What's the tracker?

Self hosted, the usual one everybody run. Is on 2GB box with the redirect on same machine, maybe this is stupid but it work until now.

Will do the diff tonight.

redirect and tracker on 2gb together. there's your queue dying

One in six is a suspiciously specific number and it's worth checking whether it's actually one in six or whether it's one in six of a subset.

Split the missing ones by whatever dimensions you have - hour, device, source, and specifically whether the click and the conversion happened on different days. Cross-midnight conversions are where a lot of trackers lose rows, because the click lookup is partitioned by date and a naive query only checks today's partition.

If the missing ones cluster on cross-day conversions you've found it in twenty minutes and it has nothing to do with the network.

Have you asked the network for their postback send log? If they retry, it will show, and half this thread becomes unnecessary.

following, i think i have this on one offer and assumed it was normal

had literally this last year and it was the network shaving, they just fire the postback so it looks clean and don't count it their side!! check their dashboard number against yours

Is solved and is exactly what PipelineRat say, second option.

Worker was dying every few hours, restart by supervisor, and everything in the queue at that moment is gone. Nothing in the tracker log because the tracker never see it. 200 come from nginx, not from the app. This is the part i did not understand.

Memory. 2GB with redirect on same box, like grindstone say. I move tracker to own box, four days now, zero missing.

Not shaving. Network number and my number match to one conversion now, so cashflowkid is wrong this time but is not a stupid thing to check first, anyway.