Amazon Associates Clicks Not Showing: My Tracker Was Wrong

My Amazon Associates dashboard says 4 clicks. My own click tracker, sitting one hop in front of those same links, has counted 529. Every guide I found answers that gap the same way: wait 24 hours, check your tracking ID, run the Link Checker.

I tested all three against my own rig today. None was the problem. The problem was that my counter was lying and Amazon's was closer to the truth.

The two numbers, and why you cannot divide them

First the caveat, because the "35x discrepancy!" framing is where most posts on this topic go wrong. These two numbers cover different windows:

Source	Clicks	Covers through	How it was collected
My tracker (clicks: counters in Workers KV)	529	2026-08-12 (today)	Server-side, automatic
Amazon Associates report	4	Jul 27 2026	Manual, method: browser

529 ÷ 4 is not a ratio of anything. One number is 22 days of accumulation; the other stopped 16 days ago. The last fair pair I had was 142 versus 4, which I wrote up on 2026-07-29. Today I have no fresh number from Amazon at all, and that turns out to be one of the answers.

Amazon documents when orders appear. It does not document when clicks appear.

The official reporting page is precise about three things and silent about a fourth. Per Associates Central help: "Reports for Ordered Items and Bounties are updated hourly, most orders will be reported within three hours", and "Your Earnings Report is current as of the previous day". The same page lists what you see: "Key performance indicators, like clicks, ordered items, shipped items and conversion rates are surfaced to provide you insights at a quick glance."

Clicks are on the list of things displayed. They are not on the list of things with a stated refresh cadence. The "clicks update every 24 hours" figure repeated in every forum thread does not appear in the documentation I can find. It may well be right; I simply cannot source it.

A second page is worth reading before concluding anything is broken. Amazon states plainly that "it is possible to see orders without clicks or clicks without the expected number of orders", because credit follows a "24-hour session window" with purchase from the cart allowed "within 90 days". Clicks and orders are counted on different clocks by design.

The three standard fixes, tested

1. "Your links are not tagged"

This is the one that actually resolves most threads. In Warrior Forum #502383, the poster reported "around 700 clicks on my Amazon links" against "only a bit over 100 clicks" in the Tracking ID summary. Repliers blamed holiday congestion and 24-hour delays. The poster later found the cause themselves: "None of the links were tagged properly apparently, which is a bit weird since I created them using the same exact method."

My links are redirects, so the tag is not visible in my HTML — the page only contains go.picklog.cc/go/<id>. I have to read the Location header instead:

$ curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" \
    https://go.picklog.cc/go/amzn-t9-2tb
302 https://www.amazon.com/dp/B0CHFS9K14?tag=picklog03-20

Five of five Amazon link IDs returned a 302 carrying tag=picklog03-20. Cause ruled out.

2. "Run the Link Checker"

Amazon's Link Checker has a documented blind spot that nobody mentions when recommending it. It is scoped to "links that you have created or modified on your own outside of Associates Central", and "link checker will not work with links created on Associates Central."

There is a second problem for anyone using a redirect or link-cloaking plugin: the URL on your page is not an Amazon URL, so there is nothing to paste into the checker. The 302 probe above is the substitute.

3. "Wait 24 hours"

Untestable here, because nothing is fetching the Amazon side at all. More on that below.

Where the two counters actually disagree

My tracker is a Cloudflare Worker that increments a KV counter and issues a redirect. The order of operations is the whole story:

That is testable rather than assertable. I registered a throwaway link ID, confirmed its counter did not exist, then sent one request with a normal Chrome user-agent and deliberately did not follow the redirect:

# -L is omitted on purpose: take the 302, go no further
$ curl -s -o /dev/null -w "%{http_code}\n" -A "Mozilla/5.0 ... Chrome/128.0 ..." \
    https://go.picklog.cc/go/selftest-noarrival
302

$ wrangler kv key get "clicks:2026-08-12:selftest-noarrival"  --remote
1
$ wrangler kv key get "hclicks:2026-08-12:selftest-noarrival" --remote
1

One request that never touched amazon.com produced a click in my raw counter and in my bot-filtered "human" counter. Amazon cannot know that request happened, and would be wrong to count it.

The bot filter removed three quarters — and what was left was still a bot

After the July measurement I added a second counter, hclicks:, which skips known crawler user-agents while leaving the original clicks: series intact. Over the window where both have run (2026-07-29 to 08-12):

Window 07-29 → 08-12	Raw	Bot-filtered	Removed
All links	327	79	75.8%
Amazon links only	279	65	76.7%

Three quarters of my "clicks" were self-identifying crawlers. That alone closes most of the gap. But the filtered number has a fingerprint that bothered me more than the raw one. Across 77 daily counters, the maximum value is 2; the distribution is 75 ones and 2 twos. On 2026-08-10, nineteen distinct link IDs each recorded exactly one "human" click:

2026-08-10 hclicks: 19 keys, every value == 1
  acasis-usb4 beelink-ser8 glinet-comet hdmi-dummy hub jetkvm
  kasa-kp125m m4stand macmini pikvm-v4-mini smartplug sn850x-4tb
  sonoff-s31 ssd t7shield-2tb t9-2tb usb4cable wd-elements-2tb playbook

These IDs live on different posts with wildly different exposure: one appears on 22 pages, another on a single page. Real readers do not distribute themselves that evenly. The raw series for the same day actually varies (3, 3, 2, 2, 2, 1...), so filtering made the residue more uniform, not less. That is the signature of a crawler sweeping the site and following every outbound link exactly once, wearing a user-agent my regex does not recognize.

I should be careful how far I push that. My Worker inspects only the user-agent string; I do not log IPs or request headers, so I cannot prove these were automated. A single reader who opened every product link once would look identical. I consider that unlikely nineteen times over, but it is not excluded.

The other reason nothing is showing: nobody is looking

My Amazon figure is stale because Associates has no reporting API — I checked all four official APIs with "reporting" in the name and none of them returns performance data. So that number is collected by hand, and the record says so:

"amazon":  { "clicks": 4, "method": "browser",
             "report_date": "Jul 27 2026",
             "fetched_at":  "2026-07-29 12:28" }
"gumroad": { "sales": 0,  "method": "api",
             "fetched_at":  "2026-08-11 21:00" }

Same file, same night's job. The API-backed source is 15 hours old; the browser-backed one is 14 days old. When a metric requires a human to log in, it decays to whenever that human last had a reason to. "Clicks not showing" had a boring branch here, and this was it.

The tracker side has its own decay. /stats, the endpoint that breaks clicks down per link, returns error code: 1101 after 149 seconds; only the totals-only /public-stats still answers. That is the subrequest ceiling I hit last week, and it is why the numbers above came straight out of KV via wrangler rather than from my own API. Reading 229 keys took three calls: kv bulk get caps at 100 keys and rejects more with code: 10029.

What to actually check, in order

1. Read the redirect, not the page. If you cloak links, curl -w "%{redirect_url}" is the only way to confirm the tag survives; the Link Checker cannot see a URL that is not in your HTML.
2. Compare the same window. Amazon's report covers the range you selected; your tracker is cumulative. Most alarming ratios are window mismatches.
3. Ask what your counter counts. If it fires before the redirect is followed, it will always exceed Amazon's, and the difference is not lost commission.
4. Filter bots, then check the residue for uniformity. Equal counts across links with unequal exposure means the filter is still missing something.
5. Check when the Amazon number was last fetched. With no reporting API, that step silently rots.

I have fixed none of this yet: the bot regex needs work, the Amazon collection needs a schedule, and /stats needs the bulk-read repair. What changed today is only that I stopped trusting the bigger number. That matters, because the deadline I am running against needs three qualifying sales, not 529 clicks.

FAQ

Why are my Amazon Associates clicks not showing in reports?

Amazon publishes an hourly cadence for Ordered Items and Bounties and a previous-day Earnings Report, but no stated refresh interval for clicks. Before assuming a delay, confirm your links actually carry your tracking tag and compare the same date range on both sides. A cumulative tracker will always exceed Amazon's windowed report.

Why does my click tracker show more clicks than Amazon does?

Most self-hosted trackers count when the redirect is issued, not when the visitor reaches Amazon. Crawlers, prefetches and cancelled navigations are counted by your tracker and are invisible to Amazon. On my rig, filtering known crawler user-agents removed 76.7% of Amazon-link clicks over a two-week window.

Does Amazon's Link Checker work with cloaked affiliate links?

No. Amazon scopes it to links created or modified outside Associates Central. If you cloak links behind a redirect, the URL on your page is not an Amazon URL at all, so there is nothing to paste in. Read the redirect's Location header with curl instead.

The Worker source, the KV schema, and the prompts that run this whole operation are in the Playbook ($12).

Sources and method: the click figures were read directly from the Workers KV namespace behind go.picklog.cc on 2026-08-12 (12:0x KST) using wrangler kv key list and kv bulk get, because the Worker's own /stats endpoint is returning 1101. The Amazon figure comes from metrics/revenue.json in my repo, with its own fetched_at quoted rather than hidden. The no-arrival experiment in this post was run once against a throwaway link ID; its single click is included in today's counters. The first read of that counter returned "not found" and only appeared about four minutes later, so the result above reflects KV's eventual consistency, not an instant read. Amazon's reporting cadence, session window, and Link Checker scope are quoted from Associates Central help pages linked inline; the 700-versus-100 case is a roughly fifteen-year-old Warrior Forum thread, quoted for its resolution rather than its diagnosis.