Author(s): Hernan M

Originally published on Towards AI.

Key Takeaways

Affiliate link health isn’t binary, even if most dashboards force it into green/red.
A link can be “up” and still be quietly losing a third of your traffic.

The strongest signal I’ve found is landing page arrival rate: across repeated tests, what fraction of attempts actually land on the intended page.
Logged over time, that’s a time series with recognizable pre-failure shapes — gradual drift, volatility spikes, and geo-specific rot.

Those shapes imply different features: slope for gradual decay, rolling variance for pre-collapse, and segmentation for geo rot.
This starts to look like condition monitoring, not classic URL classification.

The industry impact is non-trivial: Trackonomics estimates link rot costs affiliate marketing at least $160M annually, and reports it affects “almost half” of pages with affiliate links (impact.com).
What’s missing is the predictive layer — and the hard parts are labels, domain shift, and false-positive cost.

Same metric, different failure shapes — why one-size-fits-all “broken link” checks keep losing the plot.

The failure nobody catches in time: when the offer URL is “up” but the funnel is quietly dying

Last quarter I noticed a pattern that still bugs me.
A publisher I know spent two weeks optimising creative, placements, and audience targeting on a high-volume affiliate campaign.

Everything looked fine in monitoring.
The offer URL returned a valid status, the redirect chain “worked,” and the uptime checks were green.

But the money didn’t match the effort.
When we pulled the test logs and computed landing page arrival rate, it had slid from 94% to 61% over 11 days.

That drop wasn’t a single outage.
It was a slow leak — one that a binary “alive” check will never flag.

What I didn’t expect was how long this can run before anyone calls it.
Teams will blame creative fatigue, auction pressure, or “bad traffic” long before they suspect the link itself is degrading.

And the economics are already ugly without this nuance.
Trackonomics’ scan across 7,000+ pages and 25 major publishers found link rot affects almost half of pages with affiliate links, with 3–10% of live affiliate links affected, and an estimated $160M in annual commissions lost (impact.com).

So yes, broken links matter.
But the failure mode I’m seeing now is worse: links that are “working” while the funnel quietly dies.

Turning redirects into a measurable signal: attempts in, landings out — everything else is just excuses.

Why reactive link monitoring has a ceiling (and why “HTTP 200” is the wrong success metric)

Reactive monitoring is mature.
It’s good at telling you what’s broken right now.

Most link checkers will catch obvious failures: bad status codes, SSL errors, redirect loops, and hard geo-blocks.
They’ll also validate permanent redirects — useful, because permanent redirects can lock in mistakes and create long-lived chains that are painful to unwind (findredirect.com).

That tooling is necessary.
I’m not arguing otherwise.

The ceiling shows up when “success” is defined as “the request didn’t error.”
Affiliate links fail partially: throttling, intermittent bot defenses, inconsistent redirect behavior, or a destination that sometimes resolves and sometimes doesn’t.

Picture a link sitting at 73% landing page arrival rate and falling.
Every binary check still passes, so the dashboard stays green, and the publisher keeps sending traffic.

Tools like LinksTest log the full history of tests per URL over time — the raw infrastructure that makes a predictive layer theoretically possible, even if that layer doesn’t exist yet.

The rub is that reactive checks treat each test as independent.
But decay is a trajectory.

If you’ve built any time series monitoring, you know where this is going.
The question isn’t “did it work once?” but “is the system’s behavior changing?”

To get there, you need to stop treating a link test as a one-off probe and start treating it as repeated trials you can aggregate into a time series — then look for the kinds of anomalies that only show up in sequences.

HTTP 200 is a weak success metric; time-series features are how you catch the slow leaks.

The signal: landing page arrival rate as a time series (three decay patterns that look “healthy” until they don’t)

Here’s the core technical move.
Each test run against an offer URL is a Bernoulli outcome: did the full redirect chain resolve to the intended landing page, yes or no?

Run that test N times per day — across agents, geos, and times — and you can compute a daily arrival rate.
Now you’ve got a time series.

And this is where the anomaly detection framing fits better than “broken link detection.”
A lot of link decay is a collective anomaly or interval anomaly: sequences that are wrong in aggregate even if individual points don’t look crazy (Anomalo).

In practice, what I found is that three decay patterns show up repeatedly.
They look similar to anyone staring at a line chart, but they demand different features and different operational responses.

Pattern A: gradual linear decay (the slope is the early warning)

This is the slow bleed.
Arrival rate drops 2–3% per day for a week, and nobody panics because “it’s still mostly fine.”

Operationally, it often correlates with staged throttling, progressive geo restrictions, or a redirect dependency getting slower and flakier.
Not always — but often enough that I treat it as a first-class pattern.

The feature that matters is simple: the slope of a rolling 7-day linear regression on arrival rate.
You don’t need deep learning to get value here; a slope threshold plus a persistence rule catches a lot.

If you want a more formal baseline, change-point detection is a good mental model.
CUSUM-style detectors are explicitly designed to accumulate small deviations until they become statistically meaningful, which maps nicely to “death by a thousand cuts” degradation (MDPI).

A concrete (hypothetical) example: imagine 200 tests/day.
Day 1: 94% (188 successes). Day 7: 78% (156). Day 11: 61% (122). That’s not noise; it’s a trend.

The publisher implication is straightforward.
If you can detect the slope on day 4 instead of day 11, you can rotate offers or reroute traffic before the campaign’s learning and momentum collapse.

But slope is a blunt instrument; when the series starts wobbling instead of drifting, you need to switch from “is it trending down?” to “is it becoming unstable?”

Pattern B: volatile pre-collapse (variance rises before the floor drops out)

This one is a headscratcher the first time you see it.
The link oscillates: 85% → 94% → 71% → 89% → 43% → 12% → 0%.

Binary monitoring will call most of those days “up.”
But any human looking at the series feels the instability.

The feature that matters here isn’t slope; it’s volatility.
Rolling standard deviation (or a robust alternative like MAD) on arrival rate tends to spike before the final failure.

Why would variance rise first?
My sense is it’s often an intermediary system flipping between states: bot mitigation rules, load shedding, inconsistent redirect targets, or regional edge issues that your test fleet samples inconsistently.

This is where drift-aware monitoring literature is suggestive, even if it’s not a drop-in solution.
In phishing URL detection, for example, researchers combine KS-test drift detection with online learning to adapt to changing distributions (Wiley).

I’m not claiming affiliate links are phishing URLs.
But the monitoring problem rhymes: the distribution changes before the system “fails.”

If you’re a publisher, the implication is different than Pattern A.
Volatility means you can’t trust today’s test to predict today’s revenue; you need to treat the link as unstable and plan for rapid failover.

One more wrinkle: sometimes the “instability” isn’t temporal at all — it’s geographic, and your global average is quietly papering over it.

Pattern C: geo-specific decay (global averages lie)

This is the one that causes the most misdiagnosis.
Global arrival rate looks stable at 91%, so everyone relaxes.

Then you segment by geo and see MX and CO at 54% and falling.
If you’re buying LATAM traffic, you’ll feel this as “audience quality” or “creative stopped working.”

What I didn’t expect is how often teams never check segmentation until after spend is gone.
And by then, the postmortem is political: media buyers blame the offer, affiliate managers blame traffic, and nobody owns the link.

The feature here is disaggregation.
Compute arrival rate per test geo, then compute slope per geo, with a minimum sample rule so you don’t chase noise.

This isn’t fancy.
It’s just refusing to let averages hide the problem.

The publisher implication is tactical.
You might not need to pause the campaign globally; you might need to exclude a region, swap a localized destination, or route that geo to a different offer.

Once you can tell which pattern you’re in, the next step is collecting redirect-chain telemetry so you can warn earlier — and with fewer false alarms.

Geo-specific rot: the average line lies unless you segment.

The feature engineering problem: from arrival rate to redirect-chain telemetry (and why this looks like predictive maintenance)

Arrival rate is the headline metric.
But if you want early warning with fewer false alarms, you need more telemetry.

Three feature families I’d build first:

Redirect chain length over time.
Extra hops appearing is often a leading indicator — new tracking domains, new “consent” interstitials, or a misconfigured permanent redirect that adds a step. Permanent redirects are especially risky because they can embed long-term mistakes (findredirect.com).

Response latency per hop.
Even when arrival rate stays high, rising latency in an intermediary can be the canary. When that intermediary tips over, arrival rate follows.

Response header stability.
Subtle changes in cache headers, server signatures, or bot-defense headers can precede behavior changes. This is noisy, but in practice it’s useful as a “something changed” signal.

Conceptually, this looks more like condition monitoring than binary classification.
You’re watching a system degrade, not labeling static URLs as good/bad.

IBM’s framing of predictive monitoring matches this: monitor behavior over time, alert on behavioral change, and let humans decide the action (IBM).
That’s basically what we want for affiliate links.

But here’s the part I can’t hand-wave away.
Labeling.

Even if the features are sound, supervised learning needs ground truth, and “when did decay start?” is not a crisp timestamp.
The threshold is ambiguous, and that ambiguity will dominate model quality.

Take this with a grain of salt — it’s just my perspective.
But I think the feature engineering is the easy part.

The hard part isn’t detecting anomalies — it’s choosing which mistakes you can afford.

The three unsolved problems (the parts I can’t hand-wave away)

This is already happening.
The data exists, the pain exists, and the reactive tooling is good enough that the remaining failures are the subtle ones.

So why don’t we have reliable link decay prediction in affiliate marketing?
Three problems keep showing up when I sketch this out with real teams.

Problem 1: ground truth is ambiguous (when does “decay” begin?)

You can label “failed” retrospectively.
The first day arrival rate hits 0% is easy.

But “decay started” is a judgment call.
Is it the first day below 95%? The first sustained negative slope? The first volatility spike?

Different publishers will answer differently based on traffic volume and tolerance.
A site sending 50 clicks/day can’t react the same way as one sending 500,000.

A plausible research direction is weak labeling.
For example: define decay onset as the first day a rolling slope breaches a threshold for K consecutive windows, then have humans adjudicate a sample.

It’s messy.
And I’m not sure there’s a universal definition that won’t backfire.

Problem 2: patterns don’t generalize across networks (domain adaptation in disguise)

Affiliate networks don’t share an architecture.
Redirect chains differ, tracking domains differ, bot defenses differ, and throttling behavior differs.

So a model trained on Network A’s history may fail on Network B.
This is domain shift, whether we call it that or not.

The drift-aware security literature is a useful analogy: detect distribution drift (KS tests are common), then adapt models online (Wiley).
But again, analogy isn’t solution.

My pragmatic take: build network-specific baselines first.
Then monitor feature distributions for drift as a guardrail, not as a magic fix.

I’m seeing this now with teams who want “one model to rule them all.”
It’s usually the wrong bet.

Problem 3: false positives are expensive (cost-sensitive learning, not a threshold tweak)

A false positive alert isn’t just an annoying Slack ping.
It can cause a publisher to pause a campaign unnecessarily — wasting spend, losing momentum, and eroding trust in the monitoring system.

And the cost asymmetry varies by campaign.
Pausing a $200/day test is different from pausing a $200k/day evergreen funnel.

IBM uses downtime cost to motivate predictive monitoring in industrial contexts (they cite downtime costing well over $100k/hour) (IBM).
Affiliate links aren’t factory pumps, but the asymmetry logic holds: response time and wrong calls have real cost.

So evaluation can’t just be AUC.
You need to score alerts as decision policies with explicit costs: false positive cost tied to spend and platform learning, false negative cost tied to lost commissions and user experience.

This is the part that matters.
If you don’t model cost, you’ll ship a system everyone learns to ignore.

What would need to be true to build predictive link decay monitoring (without fooling ourselves)

I don’t think this is science fiction.
But I do think it needs to be framed as a research problem, not a feature request.

Three things would need to be true.

First, we’d need labeled historical datasets with retrospective decay onset timestamps — even approximate ones.
Not perfect labels; consistent ones.

Second, we’d need network-specific baseline models rather than a single universal classifier.
Train per network, per offer type, maybe even per redirect topology class.

Third, we’d need explicit cost-sensitive learning where false positives are weighted differently based on campaign spend and traffic velocity.
That means the “best” model might differ per publisher, because the cost function differs.

The honest caveat is that the raw infrastructure already exists: repeated tests per URL, logged over time, are common in this space.
The unsolved part is the labeling methodology and the cost-sensitivity framework.

That’s a tractable research problem.
I’m not fully sure what the cleanest labeling standard looks like yet — and if you get that wrong, everything downstream (features, models, alerts) turns into expensive noise.

Sources

• Link Rot — A Marketing Challenge that Deserves Attention (impact.com / Trackonomics)
• Machine Learning Approaches to Time Series Anomaly Detection (Anomalo)
• What is predictive monitoring and how to make it happen (IBM)
• 308 Redirect Checker: Free Online Tool for Redirect Testing (findredirect.com)
• Adaptive Drift-Aware Feature Monitoring and Online Learning (Wiley)
• Adjusted CUSUM Change-Point Detection in Degradation Processes (MDPI)

Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor.

Published via Towards AI