Rogue affiliates want to claim payment from merchants’ affiliate programs, but the worst offenders are long-since ejected from direct relationships and even from subaffiliate networks. Facing these headwinds, many rogue affiliates increasingly resort to a technique I call “cashback hijacking”. In this method, a rogue affiliate joins a cashback service and extracts its link to a given merchant. The rogue affiliate engages in some form of misconduct—often brand bidding, but potentially adware or something else—which it monetizes via the cashback link. The merchant, network and cashback service by default track the resulting purchases as if they were genuine cashback users making genuine purchases—never realizing that these are actually an attacker monetizing tainted traffic from unwitting users. Meanwhile, the unwitting users complete what, to them, seem like normal purchases. In due course the rogue affiliate is able to cash out what the cashback service sees as normal cashback earnings.
Database analytics to the rescue
The most promising path to stop this problem is for the affiliate network to compare device signals upon first click on an affiliate link, versus upon conversion. Device signals are most obviously the IP address plus user-agent header (revealing browser type and version plus operating system). IP address can change during a session for any device behind a rotating proxy (used by some large companies and a handful of ISPs) or on 4G/5G wireless. But normal residential broadband doesn’t often change IP during a session. Meanwhile, user-agent should not ordinarily change for a given device. An ordinary cashback user who clicks and buys on a single device shouldn’t have a mismatch. Some devices block or rewrite UA headers completely, of course, but that wouldn’t change from the click to the conversion. The key insight is that a double mismatch, as to both IP and user-agent, is substantially more suspicious than either mismatch alone.
The comparison should be between the IP and UA at conversion, versus the “first” time this link was used. An ordinary attacker would extract the affiliate network’s link from a redirect chain, such that the first invocation of the link—the first time traffic hit the network—would actually reveal the attacker’s IP and UA. A savvier attacker would follow the cashback link only as far the exit from the cashback service, never loading the network’s link, so that the first time the network sees the link would be traffic from the first unwitting user receiving this cashback hijacking link. In that case, the first unwitting user would not have a mismatch, but there would be a mismatch for every subsequent unwitting user. A cashback hijacker that frequently updated its cashback hijacking links could reduce its double mismatch frequency (though still way above normal users). To avoid this problem completely, the cashback service could tell the network the IP and UA associated with the click ID upon link creation (for example via a hash of IP and hash of UA, both salted with a secret pre-shared with the network; or a daily server-to-server transfer). The network would use those values as the true first IP and UA of a given link (with a given click ID).
All analysis of mismatch rates should be at the level of the cashback user (user ID). For example, analysis might find that a given cashback user sent ten conversions, of which all ten had a double IP and UA mismatch—calling for high skepticism. The most natural explanation for high double mismatch is that this “cashback user” is actually a cashback hijacker. If there is any other explanation, I don’t know it.
A cashback service can facilitate such analysis by providing cashback user IDs in a secondary parameter included with each click. It’s no problem to hash the user IDs (including with salt not shared with the network). The goal is for a networks to be able to see which clicks and conversions came from which (supposed) cashback user. That’s easy with a hashed user ID, but impossible if the cashback service instead sends only a click ID (user ID + timestamp, salted and hashed) that prevents a network from recognizing patterns across clicks for a single user.
A network might object that my proposal is extra work. But cashback services already require networks to provide a system investigating missing cashback. So extra work to support cashback affiliates is not unexpected. Meanwhile, cashback is a high proportion of affiliate network revenue, so extra work is proportional to business benefit. Ultimately the work is appropriate and important to deter abuse, preventing cashback hijackers from running rampant and monetizing all manner of tainted traffic. Meanwhile the approach I propose is highly scalable: Automated database queries to detect violations and report them to cashback services. Compared to other forms of affiliate misconduct, more often caught by hand or with device automation, database queries are delightfully scalable.
Alternative architectures are possible. If a network could share hashed IP addresses and user-agent headers with a cashback service, the cashback service could run this analysis on its own. But even with hashing, sharing user details is bound to raise privacy questions. Plus, this architecture risks the ill-gotten funds remaining with the cashback service, rather than being returned to the merchant (or never taken from the merchant in the first place).
See also explainer discussion with Dustin Howes.
Delaying payment
A separate strategy would deter cashback hijackers through delayed payment—a strategy I first proposed in 2008. (Seriously!) Delays provide three interrelated benefits. First, a longer delay requires a rogue affiliate to advance more money for traffic acquisition (from a search engine or adware traffic broker). Some rogue affiliates lack the working capital.
Second, a longer delay means that if the rogue affiliate doesn’t get paid, it has a bigger loss—more money expended to buy the traffic.
Third, a longer delay gives a network and cashback service more time to find the problem. My database analytics approach, above, could in principle run daily or continuously. But in practice most teams will want manual review, and many won’t immediately build a full automated pipeline. Delay provides time to see a trend and take appropriate action.
Payment delay raises the potential concern of delaying rebates to real users. But low-risk users can still be paid promptly. (Consider users with years of account history, and those with diverse purchases unlikely to be cashback hijacking.) Cashback necessarily entails returning funds at some point in the future, so users shouldn’t be surprised by delay. Ultimately a bit of delay for new cashback users is a reasonable tradeoff for blocking cashback hijacking.