Affiliate Conversion Drop Troubleshooting: Funnel Diagnosis Checklist (Click to Commission)
Clicks still look fine, so traffic quality must be the problem. No. That assumption costs more commission than any broken postback. Here is my argument: stop adjusting creative until you know which two ledgers disagree. The first mismatch inside one known click ID tells you which branch to fix. Everything downstream of that branch is noise until then.
This piece is the cross-network diagnostic spine. It is not a CRO listicle, not an Amazon-only steady-click guide, not a tracker plugin scoreboard, and not paid-media bid optimization. If you want the Amazon-specific pattern, soft-link to the steady-clicks piece later. This article teaches you how to follow one ID from click capture to bank ledger and find the break.
Failed assumption: clicks still look fine so traffic quality must be the problem
Operators often open the network dashboard, see healthy click volume, and conclude the landing page or the audience is the problem. Then they tweak creative, swap headlines, or add a popup. That is buying behavior changes before naming the disagreement.
Clicks and conversions are separate events. A click can log cleanly while every downstream hop fails. The network clicks report is not a proxy for a conversion. If the network shows one thousand clicks and zero sales, the break could be at the redirect, at cookie set, at the confirmation page, or inside the payout logic. You cannot know which one by staring at the aggregate.
The first job in affiliate conversion drop troubleshooting is ledger triage. Which two systems disagree? Your outbound analytics versus network clicks. Network clicks versus network conversions. Network conversions versus vendor-confirmed sales. Network ledger versus your bank. Each pair points to a different failure layer.
I recommend writing down the two ledgers before opening any tool. That single naming decision resolves more tracking pain than a plugin install. My full argument on why none of the dashboards agree lives in the tracking spine piece, but the short version: a network platform, a behavioral analytics tool, and a tracker are three ledgers with three jobs. They will not reconcile by design.
Here is the structural scenario that matters. A publisher fires twelve thousand outbound clicks. The network logs ten thousand nine hundred. Merchant analytics sees ten thousand six hundred sessions. Finance approves one hundred forty eight orders instead of one hundred ninety. That gap could be a redirect hop stripping the affiliate ID, a mobile-only deep link failure, cookie loss between browser and checkout, or valid clicks later rejected under merchant rules. Same symptom. Different failure mode. The only way to separate them is to follow one known identifier through every hop.
That is the entire thesis. One known ID. Every hop. First mismatch names the branch.
The six-hop map (click to commission)
The chain is not one pipeline. It is six separate handoffs, and any one of them can break while upstream metrics look healthy.
click capture -> redirect hop -> LP/offer -> conversion event -> network ledger -> payout/bank
Step one is click capture. Your own page generates an outbound click, often with a SubID or click ID appended. Step two is the redirect hop, where advertisers, aggregators, and link shorteners often rewrite or strip query strings. Step three is the landing page or offer, where merchant plugins like a consent management platform or an age gate can reset the cookie jar. Step four is the conversion event, where a sale fires on the merchant thank-you page but the affiliate plugin may not see it. Step five is the network ledger, where the conversion is recorded or rejected. Step six is payout and bank, where holds, clawbacks, and payment terms decide whether money actually lands.
A common failure mode is treating the first four steps as “traffic” and the last two as “finance.” Then you debug the wrong layer. The six-hop map forces you to think in handoffs. If the redirect hop drops the SubID, the network never receives your identifier. If the cookie path does not cover the checkout subdomain, the conversion event cannot be matched. If the network ledger shows the sale but your tracker does not, the break is likely a postback mismatch, not a traffic problem.
Every hop has one job. Your diagnostic job is to verify each handoff independently. The next section gives you the symptom-first decision tree for choosing which hop to test first.
Symptom decision tree (start here)
Do not start with a tool. Start with the symptom you can already see in the dashboards you have. Four branches cover most conversion drop cases.
Branch A: clicks down. If your outbound clicks dropped or the network is under-logging, the break is in click capture or redirect visibility. Check your raw link, your redirect chain, and whether a URL shortener or aggregator is normalizing parameters away. The redirect chain leakage audit covers hop forensics when this is the branch.
Branch B: clicks OK, conversions down. This is the most common and most misdiagnosed branch. Clicks log, but the conversion event never fires or never gets attributed. The break can be at the landing page, the cookie, the merchant plugin, the checkup subdomain, or the postback. Run the controlled test-click protocol from the next section before changing anything else.
Branch C: network shows a conversion, commission missing. The sale exists in the network ledger but your bank or commission report does not. This is payout logic, holds, clawbacks, or invalid conversions under merchant rules. Soft-link to the silent commission drops piece for redirect-flow changes that silently kill commission.
Branch D: your tracker and the network disagree. One system shows a conversion, the other does not. The break is usually tag or parameter mapping, a missed postback, or a SubID that arrives blank. If your test click arrives without SubID, the SubID blank column fix is the next stop. If the disagreement is tag mapping, use the tracking spine piece, not this article.
Here is a compact text decision tree.
clicks down -> Branch A (redirect/tag strip)
clicks OK, conv down -> Branch B (cookie/LP/postback)
network conv, no payout -> Branch C (hold/clawback)
tracker vs network clash -> Branch D (SubID/postback mapping)
The branch names the next test. If you are not sure, default to Branch B and run one known SubID through the full chain. That protocol is below.
Controlled test-click protocol
This is the highest-value hour you can spend in affiliate conversion drop troubleshooting. Fire one known SubID from a clean browser session, then verify each hop in order. Stop at the first mismatch. Do not fix that hop by installing a plugin. Document it, then decide.
Here is the protocol in six prose steps.
Step one: fire a known SubID from a clean browser. Use an incognito or private window so old cookies do not make you feel smarter than you are. Put a unique value like test-aug22-01 in your SubID slot. If your network uses Impact, use subId1. If CJ, use SID. If Awin, use clickref. Use the exact parameter your network expects. The tracking spine piece covers parameter mapping if you are unsure.
Step two: trace the redirect chain. Run the click through curl or a redirect chain detection tool. You are looking for silent 200 HTML hops that strip query strings. A 302 rewrite can drop SubIDs even when the landing page still loads. For hop audit tooling, soft-link once to the redirect chain detection tooling article.
Step three: verify the landing page loads with your parameters. After the final redirect, the URL and the page should still carry the identifier or have written it into a first-party cookie. Check the network tab. If the query string is gone and no cookie exists, the break is between hop one and hop three. Do not keep going.
Step four: check the cookie jar in devtools. Open Application > Cookies and inspect path, domain, and expiry. The cookie Path subdirectory trap is real: a cookie set with Path=/store will not be sent on /thankyou. A checkout on secure.store.example.com may not see a cookie set for example.com if the domain attribute is strict. Merchant plugins like a consent management platform or an age gate can overwrite the affiliate cookie entirely. A GDPR or privacy setting can block the cookie while the click still logs on the network side. If the cookie is missing after hop, record exactly which script did not fire.
Step five: confirm the network click row. Log into the network and verify the click arrived with your known SubID. If the network does not show the click, the break is upstream. If it shows the click but no SubID, the break is tag mapping. If the SubID arrives blank, the SubID blank column fix covers that failure path.
Step six: wait for a conversion test if available. Some programs allow a controlled test conversion. If they do not, you can still place a small order where program rules allow it. The goal is not to prove the sale happened. It is to prove the network received the attribution. If the network conversion arrives but your postback does not fire, you have a postback mismatch, which is covered in the ledger section below.
A controlled test click is not a guarantee that all traffic is healthy. One office click proves almost nothing. Device and geo conditions are where hidden breakpoints like to live. But it gives you a clean, known ID to match against the network and the ledger. That is more than any aggregate dashboard will give you.
Ledger disagreements (which two systems lie first?)
Once you have a known ID, the next job is reconciliation. The two systems that disagree tell you which party owns the break.
Your tracker versus network. If your tracker shows a conversion and the network does not, the break is likely a SubID or click ID that did not survive to the network. If the network shows a conversion and your tracker does not, the break is likely a postback mismatch or a silent postback. The network conversion is visible, but the postback URL may be empty, the token may not pass the click ID through, or the endpoint may be paused. The fix is to verify the raw postback request: if the click_id field is blank, fix the mapping before touching anything else.
Network versus vendor-confirmed sales. This is the two-ledger compare that catches merchant integration breaks. A Shopify store records the sale, but the affiliate plugin misses it. The network report shows nothing. That is not a traffic quality problem. It is a merchant-side integration failure. The comparison matrix in the next section helps you isolate it. GDPR and privacy popups also live here: the network can log the click while the cookie is blocked, so the sale happens but never attributes.
Network versus bank. If the network ledger shows a conversion but your bank ledger does not, the break is post-payout. That can be a hold period, a payment threshold, a clawback, or a reversal. Date-level comparison is the only way to argue this. Export the network report by date. Compare each date to your bank statement. The gap will show whether the break is a payment delay or a policy exclusion. Soft-link to silent commission drops for redirect-flow changes that look like payment problems but are not.
A date-level compare is also the best escalation package for an affiliate manager. Do not send a screenshot of a dashboard. Send a table: vendor sales by date, network conversions by date, bank deposits by date, and the gap column. That is the difference between a smoke alarm and a diagnosis.
When it is merchant-side vs yours
You cannot see the merchant’s backend, but you can infer where the break sits by comparing behavior across partners. If the same tracking plugin works for merchant A but not merchant B, the problem is not your plugin. It is merchant B’s implementation.
Build a comparison matrix with four rows: link format, checkout subdomain, thank-you tracking, and cookie scope. For each merchant, record whether the affiliate parameter survives the redirect, whether checkout lives on a subdomain that resets cookies, whether the thank-you page carries the network script, and whether the cookie path covers the purchase. When one merchant differs from the others, that difference is the break.
Merchant-side failures have a few classic shapes. A registration wall gates the conversion post-click, so the sale happens after a login that drops the affiliate cookie. Soft-link to the registration wall piece for that taxonomy. A merchant upgrade changes the redirect flow, and the new path strips the click ID. That is the silent commission drops failure, shareable across networks. Shopify is a special case: the store records the order, but the affiliate plugin does not see the conversion because the plugin is not on the new checkout. That is not a network problem. It is a merchant integration problem.
Amazon-specific steady-click patterns are their own branch. If clicks hold steady and conversions drop only on Amazon, the cause is usually cookie window collapse, tag stripping on redirect, or a change in Amazon’s own tracking. Do not rebuild that Amazon slice here. Go to the Amazon steady clicks piece. This article stays network-agnostic.
The test for merchant-side versus yours is simple: can you prove the click arrived intact before the merchant had a chance to apply rules? If yes, argue policy or integration. If no, keep tracing your own chain.
One-sitting checklist + short FAQ
The full diagnostic fits on one page. Run it in one sitting before you change creative or install anything.
Symptom branch: pick A, B, C, or D from the tree above. Known SubID test: fire one clean click with a unique value. Hop trace: confirm the ID survives through the chain. Cookie check: inspect path, domain, and expiry, especially on checkout subdomains. Ledger compare: match vendor-confirmed sales against network report and bank deposits, by date. Escalate with dates: if you cannot fix the break, hand the affiliate manager a date-level table, not a screenshot.
Then four frequent questions.
Clicks tracked but no sales? Stop looking at traffic. Run the controlled test-click protocol. The break is almost certainly downstream of the click, not upstream.
Can GDPR block conversions but not clicks? Yes. A consent management platform can allow the network click script but block the cookie that would later attribute the sale. The click logs, the sale happens, the network never gets the conversion event. That is a merchant CMP issue, not a traffic quality issue.
Network conversion but no postback? The sale is attributed in the network UI, but your tracker stays silent. Check the postback URL and the click ID pass-through. The network must echo the original SubID in the postback payload. If the field is blank, the mapping is broken. This is a configuration error, not a software purchase.
Can outgoing clicks serve as a proxy metric? No. Outgoing clicks count success only at hop one. They tell you nothing about hop four, five, or six. Use them as a health signal for capture, never as a conversion proxy.
The broader failure taxonomy, including silent attribution breaks that produce healthy clicks and no money, sits in the silent attribution breaks article. If your attribution model needs a larger volume threshold before this comparison is statistically meaningful, the multi-touch attribution volume piece handles that edge case.
Stop trying to fix a broken chain by changing the headline. Follow the ID. Name the two ledgers that disagree. The first mismatch is the branch, and the branch is the diagnosis.
