Three weeks ago, MegaLag and I revealed Honey not just breaking affiliate network rules (by failing to stand down when network rules require), but affirmatively hiding from testers. This is an explosive finding. It’s one thing to break stand-down rules – most plugins have been caught with violations from time to time, and usually their developers shrug, claim it was inadvertent, and promise to improve. I’ve long suspected many of these violations were intentional. But with Honey, finally I could prove intentionality.
So far, reaction has been muted. Last week Honey silently changed its configuration files to turn off the “selective stand-down” trickery. That’s a kind of admission, but without engaging with the substance of what the company did. Honey’s subsequent statement to Hello Partner was equally incomplete – blaming prior management, despite Honey making recent updates to the ssd configuration file, meaning someone at Honey certainly knew this feature was in place. Honey co-founder Ryan Hudson was quick to defend Honey from prior allegations, but has been strikingly silent on this subject.
Affiliate networks are starting to take action. Impact suspended Honey from its marketplace – though for how long, they didn’t say. Rakuten kicked Honey out of its network completely – meaning that Rakuten merchants can’t work with Honey even if they want to. No doubt Rakuten was frustrated that Honey repeatedly tricked Rakuten’s testers. In fact, the publisher class action lawsuit against Honey reported 17 citations to Rakuten documents about Honey stand-down violations – confirming both that Honey has been trying these tricks for years, and that Rakuten was on their trail. (Alas, the substance was redacted, at least for now.) Meanwhile, LinkShare – the affiliate network Rakuten acquired in 2005 to form Rakuten Advertising – was historically tough on shopping plugin misconduct. (In 2004, I showed Ebates installing through security exploits. LinkShare ejected Ebates for a time, then quietly readmitted them.) LinkShare’s historic tough stance on shopping plugin misconduct should flow through to Rakuten. Based on both its recent frustration and its historic track record, I fully credit Rakuten’s stated reason for penalizing Honey. But cynics alleged “hypocrisy” from a “direct competitor”, pointing out that Rakuten runs a competing shopping plugin that benefits from Honey’s expulsion.
Ultimately I doubt expelling Honey is a viable long-term solution. More likely, Honey will somehow apologize and be readmitted. (After all, that’s what LinkShare did with Ebates 21 years ago, though to be sure the situations are somewhat different, and arguably there’s stronger proof of intentionality in Honey’s recent violations, compared to what I could prove about Ebates in 2004.) Fundamentally, networks’ core function is to connect merchants and publishers. Their culture, staff, and fees are centered on this capability, and anything else is anathema to them. Some merchants are bound to want Honey back – affiliate managers are remarkably forgiving. Expulsion from the Rakuten network is, weirdly, too severe a penalty – reducing Rakuten’s own revenue, hence not credible and unlikely to last.
Yet Rakuten is absolutely right to say Honey’s approach was unacceptable. More is needed both to prevent similar problems from recurring, and to emphasize the seriousness of Honey’s violations. Let me offer three suggestions.
First, networks should revise their rules about shopping plugins. The rules date back to 2002. (Not a typo!) Some new practices are arguably not covered by many networks’ rules, and gaps and ambiguities are increasingly apparent. With James Little, Group Commercial Director at TopCashback, I’m working on proposed new rules. We address situations that we believe to be unclear under current rules. And we add new requirements designed to ease testing. We’re mindful of our own fallibility, so we suggest an orderly process for any member of the public to raise apparent ambiguities. In addition, rules should be revisited periodically – no more waiting for disaster or scandal.
Second, shopping plugins — not just Honey — need to come clean about prior violations. MegaLag, I, and others have been tracking other plugins with stand-down violations. VPT has been testing shopping plugins at scale for years, and has hundreds of violations on file. If a shopping plugin that knows it had “bugs” within (say) the last year, it should affirmatively contact all networks to report what went wrong and how and when the problem was fixed. Only “bugs” timely reported in that way should be treated as good faith mistakes. And any other shopping plugin that intentionally hid from testers – yes, we have more examples – should turn itself in too. The penalty for being caught by networks, or by independent testers like us, should be a lot worse than the penalty for admitting what happened. Whatever penalty Honey faced, as the first shopping plugin caught intentionally hiding from testers – competitors should expect the penalty for the second to be a lot worse.
Third, Honey should pay a fine to networks. This fine should be substantial, calibrated to Honey’s ill-gotten gains – the incremental revenue Honey collected when it intentionally did not stand down. In due course the publisher class action may also obtain benefits for publishers, but that’s a separate matter, highly uncertain, and no grounds to reduce a payment to networks right now. Two key reasons for a fine: One, a fine is credible in a way that suspension and expulsion are not. Two, networks can use the fine revenue to redouble their compliance efforts. Hire a few extra FTE’s for hands-on testing. Build a lab with undercover devices to defeat geofencing. Pay bounties to outsiders who find violations. All of this feels expensive in the abstract, but with a seven-digit fine from Honey, suddenly these costs are small potatoes.
I’m reminded of the old adage “never let a good crisis go to waste.” Honey’s misconduct should bring real improvements to affiliate network compliance — arguably, well overdue.