An affiliate deep link error is any failure that stops a link from delivering the visitor to the intended merchant page with the affiliate identifier and subID intact. The failure is frequently silent: the page loads, the HTTP status reads 200 OK, and the visitor lands on a default landing page or a product page that carries no usable tracking information. This article sets out the common causes, a repeatable test sequence for web and app deep links, and a classification method (Broken, Needs Attention, Healthy) for deciding what to fix first.
TL;DR
- A deep link can fail in three ways: it returns an error, it loads the wrong page, or it loads the right page without carrying tracking. Only the first is caught by a standard status-code check.
- Network documentation lists permitted deep-link domains, redirect rules, invalid IDs, rejected parameters, and missing click identifiers as typical causes of failed tracking links.
- SubID testing requires a clean browser session, one click, and a check of the click report for the landing page and SubID values.
- App deep links add a second layer of failure: association files, user-initiated actions, WebView behavior, and local persistence of the referral ID.
- Classify each link as Broken, Needs Attention, or Healthy, then repair in that order. The publisher decides what to change; the audit supplies the evidence.
Table of Contents
- What a deep link does, and where it fails
- Common causes of affiliate deep link errors
- Classifying what you find
- How to trace redirects and confirm the affiliate ID survives
- Auditing SubID tracking
- App deep links that fail to open or track
- Finding and prioritizing old links
- Our perspective
- Get the evidence for your own library
- FAQ
- Sources
What a deep link does, and where it fails
A standard affiliate link sends a visitor to a merchant's home page or a campaign page. A deep link sends the visitor to a specific product, category, or article, while the tracking path records the click against the publisher's account. Networks generate these links in different ways. Rakuten Advertising's publisher documentation describes an Automate feature that converts ordinary advertiser URLs into commission-generating deep links, and states that if an advertiser disables deep linking, visitors are sent to the advertiser's default landing page instead.
That behavior illustrates the central audit problem. The visitor still arrives, the link still "works," and the reader who clicked a specific product recommendation sees something else. The same documentation notes that when Automate cannot affiliate a link, the link can still redirect normally while carrying no affiliate information, and recommends checking browser developer-console messages.
impact.com documents a comparable condition: a tracking link can still send a user to the site without the click identifier, but journey tracking and attribution may be negatively affected. In both cases, a status-code monitor reports a healthy link. The link is commercially unhealthy. For a longer treatment of that distinction, see the guide on why a 200 OK does not mean an affiliate link is healthy.
Common causes of affiliate deep link errors
The causes divide into those controlled by the merchant or network, and those controlled by the publisher. impact.com's troubleshooting page lists the following as possible tracking-link issues, and the list is a useful checklist for any network:
- Permitted deep-link domains. The destination domain is not on the program's allowed list, so the deep link is rejected or redirected.
- Blocking or redirect rules. The merchant site strips or reroutes the incoming request before the tracking parameters are stored.
- Invalid Ad or Program IDs. The link was built from an identifier that was retired or never valid.
- Rejected URL parameters. A parameter appended by the publisher (including a SubID in the wrong format) is not accepted.
- Partner blocklisting. The publisher account is blocked from the program.
- Missing click identifier. The path completes, but the click ID is not passed along.
- External redirects. A third-party redirect between the click and the merchant drops information.
These are described in the network's own guidance on troubleshooting broken tracking links. Other causes appear most often in older content: merchants change URL structures, discontinue products, or consolidate sites, and a deep link built years earlier now resolves to a generic page or an out-of-stock listing.
Two publisher-side causes deserve separate mention. The first is encoding. TUNE's documentation warns that a click action embedded in a creative may fail unless the click URL is URL-encoded. A destination URL with its own query string, pasted unencoded into a tracking wrapper, is a frequent source of truncated parameters. The second is link shortening, which adds a redirect hop that the publisher does not control; the related analysis in shortened link not tracking: causes, tests and fixes covers that case.
Classifying what you find
A test result is only useful when it maps to a decision. The classification below uses three terms consistently, so that a list of several hundred links reduces to an ordered work queue.
| Classification | Observed condition | Typical examples | Publisher action |
|---|---|---|---|
| Broken | The link returns an error or the destination is confirmed unavailable | 404 or 500 response; discontinued product page; invalid program ID | Replace or remove |
| Needs Attention | The link loads, but the page or tracking path is questionable | Redirect to a generic homepage; deep link landing on a default page; click identifier absent; unverifiable tracking path | Manual review, then decide |
| Healthy | The link loads the intended page and the tracking path shows no observed fault | Product page matches the anchor; expected parameters present through the redirect chain | Retain; recheck on a schedule |
The middle category is the one that standard checkers do not produce. A link that redirects to a merchant's home page is not an error in HTTP terms, and whether it still earns anything is not something a page load can establish. For that reason, Needs Attention is deliberately a review category rather than a verdict: the evidence indicates a commercial concern, and the publisher judges whether to keep, replace, or retire the link. The 500-series failures are covered separately in affiliate link 500 errors: causes, fixes and checks.
How to trace redirects and confirm the affiliate ID survives
A deep link typically passes through several hops: a publisher domain or shortener, a network tracking domain, a merchant redirect, and the final page. At each hop, the affiliate ID and SubID may be preserved, rewritten, or dropped. The procedure below isolates the hop where the loss occurs.
- Record the starting URL exactly as it appears in the monetized anchor. Copy it from the rendered page, not from the editor, since plugins and templates sometimes rewrite links at output.
- Request the URL without following redirects and record each status code and
Locationheader in order. A command-line client or a redirect-tracing tool both work. - Compare parameters at every hop. Note which of the affiliate ID, SubID, and click identifier are present at hop one, and where each disappears.
- Compare the final page to the anchor. If the anchor names a specific product and the final URL is a home page, category page, or search page, the deep link did not resolve.
- Open the link in a clean browser session and check the developer console for messages from the network's script, as Rakuten's documentation recommends for links that cannot be affiliated.
- Repeat on mobile, since some merchants serve a different redirect path to mobile user agents.
The full method, including how to read each hop, is in the guide to tracing and auditing affiliate redirect chains. Publishers running accelerated mobile pages should also review the six AMP checks, because AMP templates can alter outbound links.
Auditing SubID tracking
SubID problems are a distinct category. The link loads and the click may register, but the SubID either does not appear in reports or arrives altered, which makes per-page attribution unreliable. Two points from network documentation frame the test.
First, TUNE states that there is no reporting tool that directly shows whether deep links were used; partners can append sub-ID values to identify deep-link usage. The SubID is therefore both an attribution field and the only practical marker for separating deep-link clicks from other traffic on that platform.
Second, Affilae's testing guide provides a concrete procedure. It recommends disabling ad blockers and privacy extensions, accepting the cookie banner, using one browser session, clicking the link, and then checking the Clicks report for the date and time, partnership, landing page, and SubID. The same guide states that a test conversion must reach the order or lead confirmation page, after which it can be found by order number.
Applied as a general audit routine, the sequence is:
- Assign a unique test SubID to the link under review, so that the click can be isolated in the report.
- Click once, in one session, with extensions disabled, to remove blockers as a variable.
- Open the click report and confirm the SubID, the landing page, and the timestamp match the test.
- Compare the recorded landing page to the intended page. A SubID that appears with the wrong landing page is a Needs Attention finding, since the click registered but the deep link did not resolve.
- Where a test purchase is practical and permitted by the program, follow it to the confirmation page and locate the conversion in the network report.
A caution on interpretation: a click that appears in a report confirms that the click was recorded. It does not confirm that a later conversion will be credited, because crediting depends on merchant and network rules that a link test cannot observe. An audit can show that the tracking path is intact or compromised; it cannot show whether commission was paid.
Publishers that are building a new page, or reviewing one before relaunch, can adapt a website launch checklist to add these click and landing-page checks before the page goes live. The broader testing rationale is set out in evidence-first affiliate link testing.
App deep links that fail to open or track
App deep links (Universal Links on iOS, App Links on Android) introduce failure points that do not exist on the web. The visitor may be sent to the browser instead of the app, or the app may open on the wrong screen, and the referral can be lost between the link and the signup or purchase.
Link behavior and association files
impact.com's documentation on Universal Links recommends checking that the link action is user-initiated, the advertiser-domain association file allows the destination path, and the WebView supports redirects. The same page explains that Universal Links require a user-initiated action: a JavaScript-triggered navigation, a URL pasted into a search bar, or a newly instantiated WebView may not open the app, whereas HTTP 3xx redirects preserve the original user event in impact.com's implementation.
FirstPromoter's mobile documentation adds the configuration requirements. Direct app deep linking requires an iOS apple-app-site-association file with Associated Domains, and an Android assetlinks.json file with matching AndroidManifest.xml configuration; misconfigured association files commonly cause browser fallback. A publisher cannot edit those files on a merchant's domain, but can recognize the symptom: the link opens in the browser when the app is installed.
Opening the wrong screen
Adjust's iOS developer documentation lists several causes of an intended screen failing to open: an incorrect deep-link path or query syntax, an incorrect application lifecycle handler, redirect misconfiguration, URL-resolution configuration, an onboarding or login flow, or app code that ignores the incoming URL. Most of these are developer-side. For a publisher, the practical consequence is that a link that opens the app on a login screen, rather than the product, belongs in Needs Attention until retested.
Referral persistence
Native apps cannot rely on browser cookies. FirstPromoter's documentation states that the app must extract the referral ID from the incoming link, persist it locally, and have the backend submit it to the Tracking API on signup or purchase. If any step is missing, the click is recorded but the referral is not carried through. Adjust provides a verification point for install attribution: in the Testing Console device data, TrackerName should show the test link rather than Organic.
TUNE's U.S. support documentation states that partners must configure deep links in the platform for them to be trackable, and recommends testing them before campaigns launch. The same discipline applies to any app-bound link in a content library: test on a physical device with the app installed and again without it.
Finding and prioritizing old links
Older content is where deep link errors accumulate, because merchants change structures after a post is published. A workable approach sorts by two variables: the traffic a page still receives and the classification of the links on it.
- Inventory every monetized anchor by page, merchant, and network, including links inside images, buttons, and comparison tables.
- Rank pages by current traffic. A Broken link on a page with steady visits outranks a Broken link on a page with none.
- Test each link using the redirect and SubID procedures above, and assign Broken, Needs Attention, or Healthy.
- Work the queue in this order: Broken links on high-traffic pages, Needs Attention links on high-traffic pages, then the remainder.
- Record the evidence (status codes, final URL, parameters observed) next to each finding, so that a later recheck has a baseline.
The classification logic is expanded in affiliate links that stop earning: test, classify, prioritize. Pages that draw traffic but convert weakly often have a post-click cause rather than a content cause, as examined in why poorly converting affiliate links fail after the click. Publishers with audiences outside the United States should also consider where cross-border clicks fail, since geo-redirects can drop tracking parameters.
Our perspective
Most link-checking practice stops at the status code, and that is the limit we designed our audits to move past. A deep link that returns 200 OK while landing on a generic homepage, an unavailable product, or a tracking path that may no longer earn is, by the standard of the publisher's revenue, not healthy. The status code cannot show it.
For that reason we separate findings into three classifications: Broken, Needs Attention, and Healthy. The separation matters operationally. Confirmed Broken links require a decision. Needs Attention links require a human look at evidence. Treating the two as one list produces either wasted review time or unexamined risk.
We also set a boundary on what an audit asserts. We detect links that are commercially unhealthy and supply the evidence; we do not verify that commission was credited, we do not estimate recovered or lost income, and we do not repair links. The publisher decides what to change, and the report is designed to make that decision faster and better documented.
Every engagement begins with a free sample report, so the evidence format can be assessed before any purchase.
Michael N.
Get the evidence for your own library
The Full Audit costs $97 as a one-off purchase. It applies manual and semi-automated checks to the affiliate links on a site, classifies each finding as Broken, Needs Attention, or Healthy, and returns a prioritized action plan with suggested replacements, with clear fixes separated from items that need manual review. The audit identifies issues; it does not change links on the site.
The Free Sample ($0) shows the evidence format on your own content before any commitment. Review the sample audit report, or see the Full Audit details and the audit for publishers.
FAQ
Why does my deep link load but not track?
A page load only shows that the destination responded. Tracking can fail separately, for example when the click identifier is dropped at a redirect, a parameter is rejected, or the advertiser disables deep linking and the visitor is sent to a default landing page. Trace each redirect hop and compare the parameters at every step.
How do I test whether a SubID is being recorded?
Assign a unique SubID to the link, click it once in a clean browser session with ad blockers and privacy extensions disabled, and open the network's click report. Confirm that the SubID, landing page, and timestamp match your test. A recorded click does not confirm that a later conversion will be credited.
Why do app deep links open the browser instead of the app?
Common causes include a missing or misconfigured association file (apple-app-site-association on iOS, assetlinks.json on Android), a link action that is not user-initiated, or a WebView that does not support the redirect. These settings sit on the merchant's side, so the publisher's role is to document the symptom and retest.
Which findings should be fixed first?
Start with Broken links on pages that still receive traffic, then Needs Attention links on the same pages, then the remaining pages by traffic. Healthy links need only a scheduled recheck, since merchants change URL structures and discontinue products over time.
Sources
- Troubleshoot Broken Tracking Links, impact.com
- Troubleshooting Universal Links in App-to-App Tracking, impact.com
- Automate Overview, Rakuten Advertising Publisher Help Center
- Deep Links, TUNE
- Testing click and conversion tracking, Affilae
- Test deep linking, Adjust Developer Hub
- Deep Linking for Mobile Apps, FirstPromoter
Recommended
- Publishers: 5 Tests to Find, Classify, and Fix Missing Affiliate IDs
- Affiliate Redirect Chains: How to Trace and Audit Them
- Affiliate Link 500 Errors: Causes, Fixes and Checks
- Stop Revenue Leaks for Publishers: Prioritize Broken Affiliate Links
This article was produced with AI assistance and reviewed for accuracy. Findings language ("Broken," "Needs Attention," "Healthy") reflects Affiliate Link Audit's evidence-based classification system.