Actually, I am a Fan of Affiliate Marketing! I’ve had a busy year uncovering affiliate misconduct—Honey hiding stand-down violations from testers; Phia forcing clicks; ShopMy telling merchants to cancel others’ commissions; Wildfire Kudos forcing clicks. And actually I’ve been catching these kinds of problems since 2004. (Not a typo!) You might think I’d be sour on affiliate marketing. But no: I very much value affiliate marketing. Let me explain. First, affiliate market aligns incentives to a greater extent than any other form of advertising. Affiliate marketers only get paid when a user buys. Yes, this can be gamed—use adware, shopping extensions, brand-bidding, or cookie-stuffing to find customers who were going to buy anyway. But it’s a lot harder than gaming paid search (click fraud, requiring only bots to fake clicks) or display ads (IFRAMEs to load ads). The smaller attack surface discourages attackers from even trying. Conversely, with incentives better aligned, advertisers can work with small publishers. More than that, affiliate marketing is unusual, among online marketing channels, in making its rules explicit and contractual. What an affiliate has to do to get paid—that’s written in the governing contract, at least the network’s standard form contract and sometimes a customization from each merchant. How much pay for how much work—for sure, in the fee schedule. What tactics are prohibited—again, yes, it’s written down. All that might sound like table stakes. How could a contract for advertising be otherwise? But consider Google. From its standard T&C’s: “Positioning of advertisements on the Google website or on any page therein is at Google’s sole discretion.” Under that nonnegotiable form contract, advertisers have little ability to insist on particular placements—and little remedy if Google substitutes inferior alternatives. A decade ago, I showed Google and its nastiest partners—adware vendors, typosquatters, and worse—inflating conversions and taking credit for sales that were going to happen anyway. Even an advertiser who read my work and was convinced of the problem would face a contract written by Google, and written to limit Google’s exposure to claims like these. Compare affiliate, where an advertiser can easily reject or eject an unwanted affiliate. And Google’s “positioning … at Google’s sole discretion” is just the tip of the iceberg. A walk down memory lane: Google promoted AdX as a second-price auction, but multi-state litigation alleged that Google “us[ed] advertisers’ bids against them to manipulate publishers’ price floors.” Meta faces similar allegations of pricing shenanigans, charging a “blended price” intentionally between first price and second price, though Meta had promised to use a second-price auction. And the FTC and states allege that Amazon deployed “secret reserve pricing” to charge prices more than a second-price auction, adding a “slow rollout schedule” so advertisers wouldn’t notice and complain. An advertiser dissatisfied with unwanted placements or inflated prices has little practical recourse against behemoth ad platforms like Google, Meta, or Amazon. First, the ad platforms wrote the contracts—and, as the Google “sole discretion” quote above illustrates, wrote them with their own interests in mind. Second, the behemoths are worthy of the name. Woe is the marketing executive who recommends foregoing Google, Meta, and Amazon. Creating their own gravity, these behemoths are too big to ignore, no matter how they mistreat their advertiser customers. Affiliate is the opposite. A deeply dissatisfied merchant could close its entire affiliate program, as a few have over the years. But that nuclear option is rarely needed because affiliate dashboards offer extraordinary control: A merchant can eject specific affiliates any time, at most on 30 days notice but often effective immediately, for any reason or no reason. Furthermore a merchant can change the rules. Add more terms to your excluded keyword list? Pay lower commissions to shopping extensions that can’t demonstrate incrementality? Require every affiliate to upload screenshots showing promotional methods? The main limit is a merchant’s creativity. My pipeline of affiliate misconduct write-ups is healthy, and I’ll have more in the coming months. I criticize affiliate marketing not because I dislike it, but because I want it to be better and know it can be better. Every time I compare affiliate marketing problems with larger alternatives, I’m reminded how fortunate advertisers are to have a channel that is both competitive and accountable. https://www.benedelman.org/fan-of-affiliate-marketing/ #rss #feeds #linksharing #qwibbit

Catching and Deterring Cashback Hijacking 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. https://www.benedelman.org/cashback-hijacking/ https://www.benedelman.org/images/cashbackhijacking-full.svg #cashbackhijacking #rss #feeds #linksharing #qwibbit

Forced Clicks from Wildfire’s Kudos Extension Kudos, a shopping extension powered by Wildfire, in its current version invites users to “auto-activate Boost”—at which point any click, even Dismiss, invokes an affiliate link. This is a bad deal for merchants, who pay commissions for things users would have bought anyway. Plus it violates rules from applicable affiliate networks, which only allow shopping extensions to invoke affiliate links when users actually click. In a particularly brazen twist, this feature shipped turned on by default for approximately seven months, and Kudos only disabled it when I and others caught competing shopping extension Phia with a similar violation. Kudos’ current practice When a user installs Kudos, a post-install screen invites a user to “Auto-activate boost.” The user can also turn on “Auto-activate Boost” from the Kudos settings screen. A mouseover bubble repeats text from the post-install screen. In a representative test, with Auto-activate Boost turned on, I requested temu.com. A Kudos window appeared, proposing that I “Activate extra earnings” or “Activate & close”. I instead clicked “Dismiss”. Kudos opened a new tab invoking Kudos’ affiliate link to Temu, and when that tab finished loading, Kudos closed it. Video. I saw the same behavior when clicking elsewhere, for example on the “Exclusions Apply” link. While my screenshots and video show Kudos practices on Chrome on a desktop PC, Kudos’ Safari Mobile extension has the same Auto-activate Boost setting. On Safari Mobile, Kudos’ new tab opens invisibly to the user (versus flashing briefly in the tab bar on Chrome for desktop). As I demonstrated for Phia in July, a user can reveal the invisible window by opening Safari’s tab-switcher with excellent timing—though normal users would have no reason to attempt that, not to mention get the timing just right. Previously turned on by default Through version 4.520.0, Kudos pre-activated the Auto-activate Boost setting. Through and including that version, the Boost settings screen (popup.js) got the value for the Auto-activate Boost setting from code that treated the setting as on by default (Code below shown pretty-printed for readability.) [u,d] = useState(e?.preferences?.disableAutoBoostActivation ?? null) y = u ?? false v = !y ... createElement(Pfe, null, "Auto-activate Boost", ...), ... isOn: v, onChange: k If the user never touched the setting, u would be null, which would make y false, so v (set to not y) would be true, and the Auto-activate Boost setting in the settings screen would be set to isOn=true. Kudos’ auto-activate code followed much the same logic. From container.js: y && !0 !== t?.preferences?.disableAutoBoostActivation Here, y denotes whether the merchant supports Kudos’ Boost benefits (unrelated to the variable y from the prior code snippet). !0 is always true. With true on the left, the !== operator evaluates to true when the right side is anything other than true. If the right side is null, undefined, or false (such as for a user who left the Auto-activate setting at its default), the right side will not equal true, so the overall expression will evaluate to true and Kudos will proceed with the automatic click. Timing Historic versions of the Kudos extension reveal that the Auto-activate Boost feature was added in 4.308.0 (shipped December 18, 2025). That’s the peak of the holiday shopping season—an advantageous time for Kudos to claim extra commission, with merchants and networks badly positioned to notice changes in time. When Auto-activate Boost shipped in December 2025, it was turned on by default, as described in the preceding section. Kudos reversed this default in version 4.527.2, released July 17, 2026. That’s eight days after I revealed shopping extension Phia forcing clicks. The best interpretation is that Kudos realized it was likely to get caught as I or others continued testing more shopping extensions. Rakuten policies require that an extension maker “notify us [Rakuten] in writing” about any “revision” of an extension. I’d like to see evidence that Kudos and Wildfire actually did what this rule requires—a particularly important step for a material revision such as even offering an automatic click feature, not to mention turning it on by default. Contracts on point The prohibition on automatic clicks is a network rule, designed to increase the incrementality of affiliate traffic and protect merchants from undue expense. Relevant contract provisions: CJ Publisher Service Agreement: “Software may not be used to force clicks [or] perform redirects without an affirmative click by a user”. Rakuten Affiliate Network Policies: “The DSA [downloadable software application] must not force clicks or ‘cookie stuff’. The DSA must not insert a cookie onto the user’s computer without the user knowingly taking an action. … The only way the Supplier cookie can be set is by a voluntary click from the user.” Leaving no doubt, Rakuten continues: “The offer may not automatically redirect to the advertiser website, even if the user has indicated that they ‘always’ want to receive rewards… It must be clicked on by the consumer before the offer can be redirected.” Awin Code of Conduct: “Publishers only initiate tracking via a tracking link used for click tracking if the user voluntarily and intentionally interacted with the Ad Media or Tracking link.” (emphasis added in each quote) Kudos might say users should be allowed to turn on automatic clicks if they want. But users cannot alter network rules because users are not the beneficiaries of those rules, and are not even privy to the contracts that establish those rules. Towards resolution Wildfire and Kudos should disable automatic clicks, and explain how this feature shipped. Who designed it? Who approved the feature generally? Who approved the decision to turn on Auto-activate Boost by default, and to turn that off in July 2026? Did anyone tell the networks about any of this? Networks should audit Kudos and Wildfire traffic since December 18, 2025, when the feature appeared. Merchants should demand refunds for commissions paid on auto-activated clicks, along with the fees passed through to their networks. If it’s not possible to determine which commissions came from automatic clicks, networks should make a reasonable estimate, erring on the side of returning more to merchants. Wildfire and Kudos should also pay the costs merchants and networks incur to investigate and remediate. My bottom line: Merchants paid commissions on sales Kudos claimed credit for, through clicks plainly outside governing contracts. Merchants and networks are entitled to learn how much money Kudos took from them, and to get it back. https://www.benedelman.org/wildfire-kudos-forced-clicks/ #rss #feeds #linksharing #qwibbit