Permissions make it possible for AppLovin to do what the allegation claims

This post is part of AppLovin Nonconsensual Installs. See important disclosures.

Ordinarily, if app A wants to install app B, it must send the user to Google Play—where installation only proceeds if the user taps the prominent green Install button. At Google Play, accidental installs are rare, and nonconsensual installs are effectively unheard of.

If installations occur outside Google Play, the first question is technical feasibility. It is not enough that source code appears to support this behavior (as shown in my execution path analysis); the Android security model must also allow it. A close review of security settings in the relevant manifests shows that such installs are indeed possible—and in fact, the unusual settings documented on this page are difficult to explain any other way.

Save The Girl manifest indicates authorization to invoke AppHub

The Android game “Save The Girl” includes the following entry in its manifest:

<intent>
<action android:name="com.applovin.am.intent.action.APPHUB_SERVICE"/>
</intent>

Ordinarily, apps do not need this line to receive ads from AppLovin.  So why does this game—and dozens of others—request permission to invoke AppHub?  What legitimate purpose does this serve?

AppHub manifest indicates authorization to invoke T-Mobile packages with elevated permissions

The AppHub manifest includes permission to interact with a T-mobile installer helper:

<uses-permission android:name="com.tmobile.dm.cm.permission.UPDATES_INSTALL"/>
<uses-permission android:name="com.tmobile.dm.cm.permission.UPDATES_LOCAL_INSTALL"/>
<uses-permission android:name="com.sprint.permission.INSTALL_UPDATES"/>
<uses-permission android:name="com.sprint.permission.INSTALL_LOCAL_UPDATES"/>
<queries>
<package android:name="com.tmobile.pr.adapt"/>
<package android:name="com.sprint.ce.updater"/>
<package android:name="com.tmobile.dm.cm"/>
</queries>

One plausible explanation is that AppHub uses a T-Mobile install helper to complete out-of-box (OOBE) installations.  But that only raises a further question: Why would third-party games need to connect to the same privileged middleware?

Com.tmobile.dm.cm has elevated permissions including installing other apps

The com.tmobile.dm.cm package has the critical permission necessary to install other apps.

<uses-permission android:name="android.permission.INSTALL_PACKAGES"/>
<uses-permission android:name="com.android.permission.INSTALL_EXISTING_PACKAGES"/> ...

Reviewing code, I found that this is the package that ultimately installs promoted apps.  The combination of that code (which passes execution to the installer) and this permission (which grants the package the ability to do so) reinforce my conclusion.

Some AppLovin APKs seek permission to install apps themselves, without a manufacturer/carrier install helper

In some cases, AppHub does not rely on a manufacturer or carrier install helper.  Certain AppLovin APKs instead request install permissions directly. For example, the Adapt v3.40.2 manifest includes:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="3400299"
android:versionName="3.40.2"
android:compileSdkVersion="34"
android:compileSdkVersionCodename="14"
package="com.tmobile.pr.adapt"
platformBuildVersionCode="34"
platformBuildVersionName="14">
<uses-sdk
android:minSdkVersion="23"
android:targetSdkVersion="34"/>
<uses-permission android:name="android.permission.INSTALL_PACKAGES"/>...

AppLovin’s public statements are consistent with AppLovin sometimes receiving this permission. From AppLovin’s Array Terms:

To provide the Array Services to you, we may need access to the “INSTALL_PACKAGES” and “QUERY_ALL_PACKAGES” Android device permissions. We receive these permissions through your carrier or mobile phone original equipment manufacturer, and we use them to provide you with the Array Services, including presenting Direct Download screen to you and facilitating the on-device installation of mobile applications at your election (where Array acts as the technical installer, not your carrier).

This paragraph — including phone manufacturer or carrier preinstalling AppLovin code and presetting these permissions — matches what I observed. Of course the “at your election” claim is contrary to my analysis of the execution path, and my tabulation of user complaints, indicating nonconsensual installations.

Labels and strings in AppLovin code

This post is part of AppLovin Nonconsensual Installs. See important disclosures.

Flipping through AppLovin APKs, it is easy to find labels and strings that appear to indicate nonconsensual installations. Examples are below.

These labels must be interpreted with care. Ultimately these are labels, not directly indicating actual application functionality. Anyone could name a function FlyToMoon(), but that doesn’t mean he has a rocket or a launchpad.

Furthermore, there could be proper reasons for certain silent installs. Consider the out-of-box experience, when it is routine for manufacturers and carriers to place apps on a user’s device. Consider installations in which user consent is obtained in some earlier part of the process.

Overall, I consider the execution path a more reliable method of determining what AppLovin’s code does. On the other hand, the execution path is complicated—requiring parsing thousands of lines of code to follow the flow, and requiring substantial technical skills to understand the code. In contrast, reviewing strings can be as easy as Edit-Find and dictionary meaning.

Labels and strings in Java code

AppLovin’s code includes various labels that indicate or reference nonconsensual installations. A representative example: com.applovin.array.apphub.tmobile includes a class called TmobileSilentInstallManager. The literal meaning of a “silent install” is one without user consent.

Elsewhere in AppLovin code, there are hundreds of references to “Install”, “Installer”, “installing”, “startInstall”, and the like, including more precise labels such as “andr_app_installing_start”, “an.ui.ntfn.installing_progress.enabled”, and “package_installing_successfully_finished_notification_id”. AppLovin logging also includes status messages like “Failed to start install”, “Failed to start installing”. These labels and strings leave no doubt that AppLovin can install apps—but they do not prove that installations are silent, automatic, or nonconsensual. Other labels, like “DirectInstallOrDownload”, indicate a nonstandard installation (not via Google Play) and suggest the install has few steps (calling into question what disclosure is provided and what consent obtained), but again are less than complete proof.

Labels in JavaScript code

The AppHub APK embeds a resource file, index-BFfWBgBF.js, which contains labels indicating non-consensual “auto” installations. The file merits close examination (see my execution path analysis), but even its labels reveal its purpose. For example:

e.IsAutoInstallEnabled="ui.dd.mp.installation_countdown"
e.AutoInstallDelayMs="ui.dd.mp.install_countdown_ms"
const wt = {
...
autoInstallDelayMs: 5e3,
isAutoInstallEnabled: !0,
...

shouldStartAutoInstall
SetInstallationOnDismissEnabled
isAutoInstall
AppAutoInstallTimerEnd

Other labels indicate that installation may occur simply when a user closes an ad:

e.IsOneClickInstallOnCloseEnabled
...
const wt = {
...
isOneClickInstallOnCloseEnabled: !0
...
SetInstallationOnDismissEnabled

A JavaScript “Breadcrumb” message logger even records a possible event, “Installation on ‘X’ button click”. Yet clicking an X is ordinarily understood as rejection, not consent. Similarly, an error handler describes “Failed to set installation on dismiss enabled”—implying that, when working correctly, the code can indeed install on dismiss. But what user thinks “dismiss[ing]” an ad is basis for an installation? Code snippets below.

catch(a => {
    pe.reportError(new Error("Failed to set installation on dismiss enabled", {
pe.leaveBreadcrumb({
    message: 'Installation on "X" button click', ...

Taken together, these labels describe scenarios where installations proceed without a user being asked to install or without the user agreeing to install.

Possible settings screen entries consistent with automatic installations

The resource file index-BFfWBgBF.js also includes a potential settings screen with the following labels:

zu = "Enable Direct Download",
Gu = "Download apps with a single click", ...
Ra = { EnableDirectDownload: zu,
EnableDirectDownload_Description: Gu, ...

From the resource file alone, it is unclear whether this screen is ever presented to users, and if so, under what conditions or with what default setting. Yet users consistently report unexpected app installations, suggesting that the option may be enabled by default—or hidden in a screen users do not ordinarily open.

My personal experience reinforces doubt about such a screen being shown to users. In spring 2025, I purchased a new T-Mobile phone directly from the carrier. On first boot, the out-of-box setup prominently displayed AppLovin screens urging me to download apps. At no point did I see any option to “Enable Direct Download” or to “Download apps with a single click.”

User complaints confirm that no such screen is shown. In reviewing complaints, I found no screenshots of such a screen being proactively shown. One user noted:

I found an app called Content Manager on my Samsung S24 that I bought through T-Mobile. There was an option there that says “Allow Install of New Apps” and I turned it off, and the ad installs stopped. (Skybreak, April 6, 2024)

This complaint reinforces the problem: a user would have no reason to hunt through a Content Manager settings screen to disable unwanted installs. Nor does failing to disable a buried option constitute consent for arbitrary app installations.

AppLovin Execution Path

This post is part of AppLovin Nonconsensual Installs. See important disclosures.

A reliable way to understand what software does is to examine its source code and trace the execution path.  This is rarely possible for compiled code, but AppLovin is largely Java, which can be decompiled using tools such as JADX.  I reviewed decompiled source code alongside the full app manifests and relevant resource files embedded within APKs.  Together, these materials reveal both what the apps are permitted to do (via permissions), how execution proceeds from function to function, and, ultimately, what occurs.

Let me remark on three key challenges in interpreting the decompiled code.  First, length.  After decompilation using JADX, the AppHub APK totals a remarkable 626,053 lines of code.  Then there’s more in the AppLovin SDK, in install helpers, in manifests, and in JavaScript.  Of course most of the code is irrelevant to app installs.  In the excerpts linked below, I focus on what I found to be relevant.  But the execution path remains lengthy even after excerpting.

Second, both decompilation and deliberate obfuscation by AppLovin make parts of the code difficult to read.  Decompilation recovers some labels (function names and variable names), but others are lost and must be generated by JADX – yielding labels that are difficult to interpret (such as AbstractC1838d0) and not the labels actually used in AppLovin’s source code.  Meanwhile, AppLovin intentionally obfuscated (minified) its JavaScript—not unexpected, because they have no reason to help anyone read it, but still an impediment to understanding.

Third, Android’s architecture—including coroutine continuation functions for multithreading—adds further complexity.  This code is not the simple a() calls b() calls c() taught in introductory programming classes.

Nonetheless, with knowledge of Java syntax and Android architecture, and with determination and grit, the execution flow is apparent.  I worked on understanding this code on-and-off from February to September 2025, and I now feel I have a good understanding.  My remarks below are my best effort under important constraints, including both the size of the task and AppLovin’s intentional obfuscation.  I cannot guarantee perfection.  See my disclosures.

In the index below, I present code in the sequence in which it operates.  Where a function name is less than self-explanatory, I remark on its purpose.  In the linked pages, I introduce each block of code with a short narrative about key steps, and I use red text to mark the flow from one step to the next.  Occasional comments, marked with the prefix // , are added by me to explain selected areas.

In the AppLovin SDK

trackAndLaunchClick()

startDirectInstallOrDownloadProcess()

showDirectDownloadAppDetailsWithExtra()

AppHub mRemote.transact()

In AppHub wrapper

onTransact()

showDirectDownloadAppDetailsWithExtra() with service method AbstractC1838d0.m3826C(),delegate C2823r(), and Kotlin coroutine continuation with entry point mo410()

BinderC2829u.m4811d() creates intent DirectDownloadActivity

c3429t1.m5750a()

C3394o1 with continuation entry point mo410r()

In DirectDownloadActivity

onCreate()

onAppDetailsCreate()

setupAppDetailsFragment() and coroutine continuation class C3359j1 with continuation entry point mo410r()

DirectDownloadMainFragment C3374l2 and onViewCreated mo1147B() with coroutines C3339g2, C3332f2, and C3325e2, plus coroutine continuation orchestrator M5734P and URL builder m5748L

AbstractC3404p4.mo1147B() with C3334f4 and C3320d4 (WebView loader)

DirectDownloadMainFragment continuation entry point mo410r()

WebView loads JavaScript resources that implement auto-install

C4785e (WebView loader)

Variable wt (default configuration)

Wt() checks IsAutoInstall and installs if set

C() checks isOneClickInstallOnCloseEnabled and installs if set

Wt() checks if AutoInstallDelayMs is set, and if so uses av() to hook a timer’s onExpire event to the install function

c() install function

Ge.installApp() hooks /install-app endpoint

makeNativeXhrRequest()

makeHttpRequest() wraps browser-native XMLHttpRequest

Java URL interceptor prepares to run T-mobile InstallerHelper

DirectDownloadMainFragment C3374l2 creates C3298a3 which creates C5252f (WebView interception manager)

C5252f registers endpoint handler C5461u for /install-app

C5461u activates DirectDownloadPackageManager C2495r1 with coroutine resume function m4446F()

C0033f0 creates C0023a0 (installation executor) and coroutine resume function m431o() and continuation entry point mo410r()

mo410r() runs T-Mobile InstallerHelper startInstall()

In T-Mobile InstallerHelper

m14262a message dispatcher

sendEmptyMesage()

startInstall()

prepareInstall()

performInstallBundle()

m14247a (InstallParams method)

PackageInstaller (Android Package Manager from core Android)

Prior Critiques of AppLovin

This post is part of AppLovin Nonconsensual Installs. See important disclosures.

My work follows six prior critiques in which others questioned AppLovin practices, both as to app installations and beyond.  I organize those critiques here, in chronological order, to assist those who wish to reread them. I emphasize those reports and sections that, like my post today, consider nonconsensual installations.

Culper 1 – pages 7-25 about installs

Fuzzy Panda – Part II discusses Direct Downloads and other methods of gaming installs (citing my work), among other subjects

Culper 2 – broader topics: misrepresentation of Chinese ties, national security concerns

Muddy Waters – focused on tracking and persistent identifiers

Mike Shields – on installs (citing me)

Olivia Solon (Bloomberg) – reporting an SEC probe of AppLovin’s data-collection practices

Compared with prior reports, I provide a more detailed technical analysis. For example Solon’s report of SEC inquiry does not provide any source code, screenshots, packet logs, or other direct evidence of data collection violations. I also provide greater proof relative to prior reports of nonconsensual installations. For example, the prior reports about nonconsensual installs present snippets of code, whereas I trace the full execution chain from ad delivery all the way to installation. Similarly, prior reports offer a few complaints about nonconsensual installations, but I offer hundreds, plus I explore patterns of complaints across devices and situations, and I cross-check complaints against details in decompiled AppLovin code.

Honey’s Contractual Breaches and Value (or Lack of It) to Merchants

On December 21, YouTuber MegaLag dropped a 23 minute video eviscerating Honey.  Calling Honey a “scam”, he made two core allegations.

  1. Honey announcing
    Honey claims affiliate commission if a user presses “Got it” to acknowledge no deal found

    Honey takes payments that would otherwise go to influencers who recommended products users buy. (video at 2:50) MegaLag shows Honey claiming payments in four scenarios: i) if a user activates a function to search for coupons (even if none are found), ii) if a user activates a function to claim Honey Gold (no matter how meager the rebate), iii) if the user gets the message “We searched for you but didn’t find any deals” and merely presses the button “Got it”, and iv) If Honey shows the message “Get Rewarded with PayPal” “Shop eligible items to earn cash off future purchases” and the user presses “checkout”.

  2. Honey doesn’t actually get the best deals for users. If a merchant joins Honey (and begins to pay Honey affiliate commissions), Honey allows the merchant to limit which coupons Honey shows to users. MegaLag points out that letting merchants remove discounts from Honey is squarely contrary to Honey’s promise to users that it will find “the Internet’s best discount codes” and “find every working promo code on the Internet.” (video at 16:20)

16 million views and growing, MegaLag’s video has prompted a class action lawsuit and millions of users uninstalling Honey.

I’m a big fan of MegaLag.  I watched most of his other videos, and they’re both informative and useful—for example, testing Apple AirTags by intentionally leaving items to be taken; exploring false claims by DHL about both package status and their supposed investigations.  Meanwhile, nothing in MegaLag’s online profile indicates prior experience in affiliate marketing.  But for a first investigation on this subject, he gets most things right, and he uses many appropriate methods including browser dev tools and screen-capture video.  Based on its size and its practice, Honey absolutely deserves the scrutiny it’s now getting.  Kudos to MegaLag.

Nonetheless there’s a lot MegaLag doesn’t say.  Most notably, he doesn’t mention contracts—the legal infrastructure that both authorizes Honey to get paid and sets constraints on when and how it may operate.  Furthermore, he doesn’t even consider whether merchants get good value for the fees they pay Honey.  In this piece, I explore where I see Honey most vulnerable—both under contract and for merchants looking to spend their marketing funds optimally.

The contracts that bind Honey

Affiliate marketing comprises a web of contracts.  Most affiliate merchants hire a network to track which affiliate sent which traffic, to provide reports to both merchant and publishers, and to handle payments.  For a single affiliate-merchant relationship, an affiliate ends up subject to at least two separate contracts: the network’s standard rules, and any merchant-specific rules.  Of course there are tens of thousands of affiliate merchants, and multiple big networks.  So it’s impossible to make a blanket statement about how all contracts treat Honey’s conduct.  Nonetheless, we can look at some big ones.  Numbering added for subsequent reference.

Commission Junction Publisher Service Agreement

C1 “You must promote Advertisers such that You do not mislead the Visitor”

C2 “the Links deliver bona fide Transactions by the Visitor to Advertiser from the Link”

C3 “You must accurately, clearly and completely describe all promotional methods by selecting the appropriate descriptions and providing additional information when necessary.”

C4 “You agree to: (i) use ethical and legal business practices”

C5 “Software-based activity must honor the CJ Affiliate Software Publishers Policy requirements (as such requirements may be modified from time to time), including but not limited to: (i) installation requirements, (ii) enduser agreement requirements, (iii) afsrc=1 requirements, (iv) requirements prohibiting usurpation of a Transaction that might otherwise result in a Payout to another Publisher (e.g. by purposefully detecting and forcing a subsequent click-through on a link of the same Advertiser) and (v) non-interference with competing advertiser/ publisher referrals.”

Rakuten Advertising Downloadable Software Applications (DSAs) Overview, Testing Process, Policies

R1 “Your DSA should become inactive on the sites of any advertisers who opt-out or stand down on those that do not want you to redirect their traffic.  Publishers who fail to comply with this rule will jeopardize their relationship with advertisers as well as with Rakuten Advertising.”

R2 “[W]e expect your DSA to: Stand down when it recognizes any publisher links”

R3 “[A]ll software must recognize Supplier domains and the linksynergy tracking links. When a Supplier domain or the linksynergy code is detected, the software may not operate or redirect the consumer to the advertiser site using the Software Publisher tracking ID (also known as Supplier Affiliate ID or Encrypted ID). We do not allow any DSA software that interferes with or deters from any Publisher or Advertiser website.”

R4 “The DSA must stand-down and not display any forms of sliders or pop-ups to prompt activation if another publisher has already referred an end user.”

R5 “The DSA 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 that results in the cookie being placed.”

R6 “The end user must click through the offer that is presented. Placing the mouse over an offer, only viewing it or viewing all offers is not a click through.”

R7 “The DSA must not automatically drop a cookie when the end user is only viewing offers. The cookie should only be dropped once the end user clicks on a specific offer.”

Awin including ShareASale – Code of Conduct, Awin US Publisher Terms, SAS US Publisher Agreement

A1 “’Click’ means the intentional and voluntary following of a Link by a Visitor as part of marketing services as reported by the Tracking Code only;”

A2 “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.”

A3 Publishers only initiate tracking for a specific advertiser if the consumer interacted directly with ad media for this advertiser.”

A4 ”do not mislead consumers”

A5 “transparency about traffic sources and the environment that ads are displayed in”

In addition, all networks indicate that publishers must disclose their practices to both networks and merchants.  Awin Code of Conduct is representative: “Publishers proactively disclose all promotional activities and obtain advertiser approval for their activities.”  Rakuten’s Testing Process is even more prescriptive, requiring an affiliate both to submit a first version and to notify Rakuten about any changes so it can retest; plus requiring publishers to answer 16 questions about their software including technical details such as DOM ID and Xpath of key functions.

Honey violates network policies

MegaLag’s video show violations of these network policies.  I see three clusters of violations.

(1) Honey invokes its affiliate links although users did not fairly request any such thing.  Consider “We searched for you but didn’t find any deals” with button labeled “Got it” (MegaLag scenario iii above). “Got it” doesn’t indicate that the user wants, expects, or agrees that Honey will invoke its affiliate link.  That’s certainly misleading (contrary to rule C1).  Nor can Honey claim that a user who clicks “Got it” is “knowingly taking an action that results in the cookie being placed” (R5) because clicking “Got it” isn’t the kind of action that rule contemplates.  Rakuten rules R6 and R7 are equally on point, disallowing invoking an affiliate link based on an activity that doesn’t indicate intent (such as a mouseover), and requiring that an affiliate link only be invoked “once the end user clicks on a specific offer.”  “Got it” isn’t an offer, so under R7, that’s not grounds for invoking a Rakuten link.  So too for Awin, where A1 defines “click” to include only links that are “part of marketing services” (but “Got it” is not marketing service).  See also A2 and A3 (allowing links only as part of “ad media”, but “Got it” is not ad media); and of course A4 (“do not mislead consumers”).

Honey’s invocation of affiliate links upon a “Get rewarded with PayPal” message (MegaLag scenario iv above) is on similarly shaky ground.  For example, responding to a PayPal offer is not “knowingly taking an action that results in the cookie being placed” (R5) – the user knows only that he’s closing the message, not that he’s requesting an affiliate referral back to the merchant.  Similarly, a PayPal offer is not “marketing services” or “ad media” for an Awin merchant (rules A1-A3).

The rule to invoke affiliate links only when a user so requests is no mere technicality.  In affiliate marketing, an affiliate may be paid if 1) the user sees a link, 2) the user clicks the link, and 3) the user buys from the specified merchant.  Skipping step 2 sharply increases the circumstances in which a merchant has to pay commission—not a term a merchant would agree to.  When an affiliate skips step 2, it’s cookie-stuffing.  Publishers have gone to jail for this (and had to pay back commissions received).  Honey didn’t quite stuff cookies as that term is usually used—the user did click something.  But when nothing on the button (not its label, not the surrounding message, not any principle of logic or engineering) indicates or even suggests the button will activate an affiliate link—that’s terrible value for the merchant.

(2) Honey presents its affiliate links although a user recently clicked through another publisher’s offer.  (MegaLag at 2:50)  But networks’ rules require Honey to stand down if another publisher has made a referral.  See rule C5.v (“non-interference with competing advertiser/ publisher referrals”) and R2 (“Stand down when it recognizes any publisher links”).  Rakuten even makes explicit that the stand-down obligation applies not just to automatic clicks (which, uh, aren’t permitted in any event) but also to sliders and popups: “The DSA must stand-down and not display any forms of sliders or pop-ups to prompt activation if another publisher has already referred an end user.” (R4)

Here too, this is no technical violation.  Other publishers need “stand down” rules so they have a fair chance to earn commission for their work promoting a given merchant.  Standing down from another affiliate’s click is the most fundamental affiliate network rule for downloadable software and browser plug-ins.

(3) Honey falls short of disclosure obligations.  “You must accurately, clearly and completely describe all promotional methods by selecting the appropriate descriptions and providing additional information when necessary” (C3).  Publishers must provide “transparency about traffic sources and the environment that ads are displayed in” (A5).  I’m open to being convinced that Honey told networks and merchants it would invoke affiliate links with buttons as weakly labeled as “Got it.”  I don’t buy it.  Merchants have a clear contractual basis to expect complete and forthright disclosures—it is literally their money being paid out.  And merchants authorized networks to collect and evaluate these disclosures for them.  No shortcuts.

One might object that networks can waive rules or create exceptions for key partners.  Not so fast!  Merchants and publishers rely on networks to enforce their published rules exactly as promised.  In fact, in 2007, both merchants and publishers sued ValueClick to allege that it had been less than diligent in enforcing its rules.  ValueClick’s Motion to Dismiss argued that it could do what it wanted, that it had disclaimed all warranties, and that it made no promises that merchants or publishers were entitled to rely on.  But the court denied ValueClick’s motion, eventually yielding a settlement requiring both improved efforts to detect affiliate fraud as well as certain refunds to merchants and payments to publishers.  There’s room to disagree about how much benefit the settlement delivered.  (Maybe the settlement promised changes that ValueClick was going to do anyway.  Maybe the monetary payments were a small fraction of the amount lost by merchants and publishers.)  But the fundamental principle was clear: Networks must follow their contractual representations including policies about prohibited behaviors.  And while networks may try to disavow quality responsibilities, for example via disclaimers in contracts, courts are skeptical of the unfettered discretion these provisions purport to create.  A network that promises to track affiliate transactions ultimately ought to do so accurately, and should neither grant arbitrary waivers nor look the other way about serious misconduct.

How did we get here?

Honey’s one-sentence response to MegaLag was “Honey follows industry rules and practices, including last-click attribution.”  It’s no surprise that Honey claims compliance.  But I was surprised to see affiliate thought-leaders agree.  For example, long-time affiliate expert Brook Schaaf remarked “Honey appears to be in compliance with network standards.”  Awin CEO Adam Ross says MegaLag’s video “portray[s] performance marketing attribution as a form of theft or scam”—suggesting that he too thinks Honey did nothing wrong.

I’ll update this piece with when others dig into the contracts and compare Honey’s practices with the governing requirements.  But after more than 20 years working on affiliate fraud—my first piece on this subject was, wow, 2004—let me offer four observations.

One, it’s easy to get complacent.  Much of what Honey does is distressingly normal among browser extensions.  Test the Rakuten Cashback app and you’ll find much the same thing.  Above, I linked to litigation against Honey, but there’s also now similar litigation against Capital One, alleging that its Capital One Shopping browser extension is out of line the same way as Honey.  Brook and Adam are right that Honey’s tactics aren’t a surprise to anyone who’s been in the industry for decades.  Many people have come to accept behaviors that don’t follow the literal meaning of stated policies.  Some would say the policy is out of date.  I’d say, instead, that key decision-makers have been asleep at the switch.

Two, networks’ incentives are mixed.  On one hand, networks want affiliate marketing to be seen as trusted and trustworthy, which requires eliminating practices widely seen as unfair.  At the same time, affiliate networks typically charge a commission on every dollar of commission paid.  As a result, networks directly benefit from anything that increases the number of dollars of commission paid—such as allowing browser plug-ins to change non-commissionable traffic into commissionable traffic.  Merchants should be skeptical of networks too quickly declaring traffic compliant when networks literally get paid for that finding.  With Rakuten operating both a cashback service (with browser plugin) and an affiliate network, their incentives are particularly muddy: If Rakuten Advertising declares a given browser plugin tactic to be permitted, Rakuten Cashback can then use that tactic, increasing both Cashback fees (the Cashback margin on each dollar of rebate) and Advertising fees (the network margin on each dollar of affiliate activity).  I like and respect Rakuten and its leaders, but their complicated incentives mean serious people should give their pronouncements a second look.

Three, most people read the governing contracts hastily if at all.  I’m proud to have pulled out the 17 rules above, and I encourage readers to follow my links to see these and other rules in the larger policy documents.  Fact is, there’s lots of material to digest.  I’ve found that networks’ compliance teams often build rules of thumb that diverge from what the rules actually say, and ignore rules that are in some way seen as inconvenient or overly restrictive.  That’s a mistake.  The rules may not be holy, but they have the force of contract, and there’s real money at issue.  Importantly, networks are spending other people’s money­­­—making sure normal publishers get every dollar they fairly earned; and making sure merchants pay the correct amount, but not a penny more.  This calls for a high level of care.  We’re two weeks into the response to MegaLag.  How many people posted video-responses, blogs, or other remarks without finding, reading, and applying the governing policies?

Four, personalities and work styles invite even merchant staff to accept what Honey is doing.  Representative short-hand: “Go along to get along.”  Most marketers chose this line of work to make connections, not to play policeman.  Attend an affiliate marketing conference and you’re a lot more likely to see DJs and beer (party!) than network sniffers and virtual machines (forensic tools).  Meanwhile, it’s awfully easy for an affiliate manager to tell a boss “we’re working with Honey, the billion-dollar product from PayPal”—then head to the Honey gala at an industry conference.  Conversely, consider the affiliate manager who has to explain “we wasted $50k on Honey last month.”  People have been fired for less.  Ultimately, online marketing plays a procurement function—trying to spend an employer or client’s money as skillfully as possible, to get as much benefit as possible for as little expense as possible.  That’s hard work, and I don’t fault those who want an easier path.  I also don’t fault those who prefer the networking and gala side of marketing over the software forensics.  Nonetheless, collective focus on the fun stuff goes a long way towards explaining how problems can linger (and grow).

Is Honey profitable for merchants?

For a merchant evaluating Honey, the fundamental question is pretty simple: Does Honey bring the merchant incremental sales and positive ROI?  Clearly Honey’s browser extension positions it to claim credit on purchases users were already going to make, but incremental sales are what matter to merchants—purchases made only thanks to Honey.

My hypothesis is that Honey is ROI negative for most merchants.  If a user goes to (say) dell.com, the user is already interested in Dell.  Why should Dell let Honey’s browser plug-in jump in and claim a commission on that user’s purchase?  Maybe Honey will increase the user’s conversion rate from 5% to 5.1% (by proclaiming what a good deal the user has found, or by touting a Honey Gold sweetener).  But with payment to Honey, Dell’s margin will drop from (say) 7% to 5%.  Would Dell prefer 7% profit on 500 sales, or 5% profit on 510?  That math is pretty easy.

Of course the numbers in the preceding paragraph are just hypotheticals.  If users sufficiently trust Honey (whether correctly or otherwise), their conversion rate might increase enough to justify Honey’s fees to merchants.  If Honey could somehow persuade users to spend more—“add one more item to your cart, and you can get this $10 coupon”—that could increase value to merchants too (though I’ve never seen Honey deliver such a message).  Some merchant advisors think this is plausible.  I have my doubts.

Alarmingly, many merchants decide to work with Honey (and other “loyalty” software) without rigorously measuring incrementality (or even trying).  Most merchants take some steps to measure the ROI of search and display ads.  For years, affiliate ROI has been more challenging.  But I recently devised a rigorous method that’s doable for most merchants.  I’d enjoy discussing with anyone interested.  When I have findings from a few merchants, with their permission I’ll share aggregate results.

Looking ahead

It’s easy to watch MegaLag’s piece and come out sour on affiliate marketing.  (“What a mess!”)  For that matter, the affiliate marketing section of my site has 28 articles over 20+ years, almost all about some violation or abuse.

Yet I am fundamentally a fan of affiliate marketing.  Incentives aren’t perfectly aligned between affiliate, network, and merchant, but they’re a whole lot closer than in other kinds of online advertising.  One twist in affiliate is that when a rogue affiliate finds a loophole, they can often exploit it at scale—by some indications, even more so than in other kinds of online advertising.  Hence the special importance of networks and merchants both providing fairness and being perceived as providing fairness.  MegaLag’s critique of Honey shows there’s no shortage of work to do.

Risk, Information, and Incentives in Online Affiliate Marketing

Edelman, Benjamin, and Wesley Brandi. “Risk, Information, and Incentives in Online Affiliate Marketing.” Journal of Marketing Research (JMR) 52, no. 1 (February 2015): 1-12. (Lead Article.)

We examine online affiliate marketing programs in which merchants oversee thousands of affiliates they have never met. Some merchants hire outside specialists to set and enforce policies for affiliates, while other merchants ask their ordinary marketing staff to perform these functions. For clear violations of applicable rules, we find that outside specialists are most effective at excluding the responsible affiliates, which we interpret as a benefit of specialization. However, in-house staff are more successful at identifying and excluding affiliates whose practices are viewed as “borderline” (albeit still contrary to merchants’ interests), foregoing the efficiencies of specialization in favor of the better incentives of a company’s staff. We consider the implications for marketing of online affiliate programs and for online marketing more generally.

Accountable? The Problems and Solutions of Online Ad Optimization

Edelman, Benjamin. “Accountable? The Problems and Solutions of Online Ad Optimization.” IEEE Security & Privacy 12, no. 6 (November-December 2014): 102-107.

Online advertising might seem to be the most measurable form of marketing ever invented. Comprehensive records can track who clicked what ad–and often who saw what ad–to compare those clicks with users’ subsequent purchases. Ever-cheaper IT makes this tracking cost-effective and routine. In addition, a web of interlocking ad networks trades inventory and offers to show the right ad to the right person at the right time. It could be a marketer’s dream. However, these benefits are at most partially realized. The same institutions and practices that facilitate efficient ad placement can also facilitate fraud. The networks that should be serving advertisers have decidedly mixed incentives, such as cost savings from cutting corners, constrained in part by long-run reputation concerns, but only if advertisers ultimately figure out when they’re getting a bad deal. Legal, administrative, and logistical factors make it difficult to sue even the worst offenders. And sometimes an advertiser’s own staff members prefer to look the other way. The result is an advertising system in which a certain amount of waste and fraud has become the norm, despite the system’s fundamental capability to offer unprecedented accountability.

Pitfalls and Fraud in Online Advertising Metrics: What Makes Advertisers Vulnerable to Cheaters, and How They Can Protect Themselves

Edelman, Benjamin. “Pitfalls and Fraud in Online Advertising Metrics: What Makes Advertisers Vulnerable to Cheaters, and How They Can Protect Themselves.” Journal of Advertising Research 54, no. 2 (June 2014): 127-132.

How does online advertising become less effective than advertisers expect and less effective than measurements indicate? The current research explores problems that result, in part, from malfeasance by outside perpetrators who overstate their efforts to increase their measured performance. In parallel, similar vulnerabilities result from mistaken analysis of cause and effect–errors that have become more fundamental as advertisers target their advertisements with greater precision. In the paper that follows, the author attempts to identify the circumstances that make advertisers most vulnerable, notes adjusted contract structures that offer some protections, and explores the origins of the problems in participants’ incentives and in legal rules.

The Darker Side of Blinkx

Video and advertising conglomerate Blinkx tells investors its “strong performance” results from “strategic initiatives” and “expanding demand, content, and audiences.” Indeed, Blinkx recently climbed past a $1.2 billion valuation. At first glance, it sounds like a great business. But looking more carefully, I see reason for grave doubts.

My concerns result in large part from the longstanding practices of two of Blinkx’s key acquisitions, Zango and AdOn. But concerns extend even to Blinkx’s namesake video site. In the following sections, I address each in turn. Specifically, I show ex-Zango adware still sneaking onto users’ computers and still defrauding advertisers. I show the ex-AdOn traffic broker still sending invisible, popup, and other tainted traffic. I show Blinkx’ namesake site, Blinkx.com, leading users through a maze of low-content pages, while charging advertisers for video ads systematically not visible to users.

The Legacy Zango (Adware) Business

In April 2009, Blinkx acquired a portion of Zango, a notorious adware vendor known for products that at various times included 180 Search Assistant, ePipo, Hotbar, Media Gateway, MossySky, n-Case, Pinball, Seekmo, SpamBlockerUtility, and more. Zango was best known for its deceptive and even nonconsensual installations — in write-ups from 2004 to 2008, I showed Zango installing through security exploits (even after design updates purportedly preventing such installations by supposed rogue partners), targeting kids and using misleading statements, euphemisms, and material omissions, installing via deceptive ActiveX popups, These and other practices attracted FTC attention, and in a November 2006 settlement, Zango promised to cease deceptive installations as well as provide corrective disclosures and pay a $3 million penalty.

Few users would affirmatively request adware that shows extra pop-ups, so Blinkx and its distributors use deceptive tactics to sneak adware onto users’ computers. In a representative example, I ran a Google search for “Chrome” (Google’s well-known web browser), clicked an ad, and ended up at Youdownloaders.com — a site that bundles Chrome with third-party advertising software. (The Youdownloaders footer states “The installers are compliant with the original software manufacturer’s policies and terms & conditions” though it seems this claim is untrue: Chrome Terms of Service section 5.3 disallows copying and redistributing Chrome; 8.6 disallows use of Google’s trademarks in a way that is likely to cause confusion; 9.3 disallows transfer of rights in Chrome.) In my testing, the Youdownloaders installer presented offers for five different adware programs and other third-party applications, among them Weather Alerts from desktopweatheralerts.com. Installation video.

I consider the Youdownloaders installation deceptive for at least four reasons: 1) A user’s request for free Chrome software is not a proper circumstance to tout adware. The user gets absolutely nothing in exchange for supposed “agreement” to receive the adware; Chrome is easily and widely available for free, without adware. It is particularly one-sided to install five separate adware apps — taking advantage of users who do not understand what they are asked to accept (including kids, non-native speakers, and those in a hurry). 2) On the Weather Alerts page of the installation, on-screen statements mention nothing of pop-up ads or, indeed, any advertising at all. In contrast, the FTC’s settlement with Zango requires that disclosure of advertising practices be “clear and prominent,” “unavoidable,” and separate from any license agreement — requirements not satisfied here. 3) The Youdownloaders user interface leads users to think that the bundled installations are compulsory. For example, the “decline” button (which lets a user reject each adware app) appears without the distinctive shape, outline, color, or font of an ordinary Windows button. 4) Users are asked to accept an objectively unreasonable volume of agreements and contracts, which in my testing include at least 14 different documents totaling 37,564 words (8.5 times the length of the US Constitution).

Tellingly, Blinkx takes considerable steps to distance itself from these deceptive practices. For example, nothing on Blinkx’s site indicates that Weather Alerts is a Blinkx app or shows Blinkx ads. The Desktopweatheralerts.com site offers no name or address, even on its Contact Us form. Weather Alerts comes from a company called Local Weather LLC, an alter ego of Weather Notifications LLC, both of Minneapolis MN, with no stated affiliation with Blinkx. Weather Notifications’ listed address is a one-bedroom one-bathroom apartment — hardly a standard corporate office. Nonetheless, multiple factors indicate to me that Desktop Weather Alerts is delivers a version of Zango adware. For one, Desktop Weather Alerts popups use the distinctive format long associated with Zango, including the distinctive browser buttons at top-left, as well as distinctive format of the advertisement label at bottom-left. Similarly, many sections of the license agreement and privacy policy are copied verbatim from longstanding Zango terms. Within the Weather Alerts EXE, strings reference 180search Assistant (a prior Zango product name) as well as 180client and various control systems long associated with Zango’s ad-targeting system. Similarly, when Weather Alerts delivers ads, its ad-delivery communications use a distinctive proprietary HTTP syntax both for request (to showme.aspx, with a HTTP POST parameter of epostdata= providing encoded ad context) and response (a series of HTML FORM elements, most importantly an INPUT NAME=ad_url to indicate the popup to open). I have seen this syntax (and its predecessors) in Zango apps for roughly a decade, but I have never seen this syntax used by any advertising delivered by other adware vendors or other companies. Moreover, when a Blinkx contractor previously contacted a security vendor to request whitelist treatment of its adware, the Blinkx representative said “The client is Blinkx … Your engine … was flagging their installer package SWA as SevereWeatherAlerts…” (emphasis added). Notice the Blinkx representative indicating that SWA (another Local Weather program, virtually identical save for domain name and product name) is “their” app, necessarily referring to Blinkx. Finally, in a February 2014 presentation, Blinkx CEO Brian Mukherjee included the distinctive Local Weather icon (present throughout the LW app and in LW’s installation solicitations) as part of the “Blinkx Ecosystem” — further confirming the link between LW and Blinkx. Taken together, these factors give good reason to conclude that Local Weather is applications are powered by Blinkx and part of the Blinkx network. Furthermore, in my testing Blinkx is the sole source of advertising for Weather Alerts — meaning that Blinkx’s payments are Weather Alerts’ primary source of revenue and primary reason for existence. (Additions made February 13, 2014, shown in grey highlighting.)

Blinkx/Zango software continues to defraud affiliate merchants. Blinkx/Zango software continues to defraud affiliate merchants.

Meanwhile, Zango-delivered advertising remains a major cause of concern. Zango’s core advertising product remains the browser popup — a disruptive form of advertising unpopular with most users and also unpopular with most mainstream advertisers. Notably, Zango’s popups perpetrate various advertising fraud, most notably ‘lead stealing” affiliate windows that cover merchant sites with their own affiliate links. If the user purchases through either window, the Zango advertiser gets paid a commission — despite doing nothing to genuinely cause or encourage the user’s purchase. (Indeed, the popup interrupts the user and thereby somewhat discourages a purchase.) At right, I show a current example: In testing of January 19, 2014, Blinkx/Zango sees a user browsing Walmart, then opens a popup to Blinkx/LeadImpact (server lipixeltrack) which redirects to LinkShare affiliate ORsWWZomRM8 and on to Walmart. Packet log proof. Thus, Walmart ends up having to pay an affiliate commission on traffic it already had — a breach of Walmart’s affiliate rules and broadly the same as the practice for which two eBay affiliates last year pled guilty. I’ve reported Zango software used for this same scheme since June 2004. As shown at right and in other recent examples, Zango remains distinctively useful to rogue affiliates perpetrating these schemes. These rogue affiliates pay Blinkx to show the popups that set the scheme in motion — and I see no sign that Blinkx has done anything to block this practice.

Rather than put a stop to these practices, Blinkx largely attempts to distance itself from Zango’s legacy business. For one, Blinkx is less than forthright as to what exactly it purchased. In Blinkx’s 2010 financial report, the first formal investor statement to discuss the acquisition, Blinkx never uses the word “Zango” or otherwise indicates the specific company or assets that Blinkx acquired. Rather, Blinkx describes the purchase as “certain net assets from a consortium of financial institutions to facilitate the growth of the video search and advertising businesses.” If a reader didn’t already know what Blinkx had bought, this vague statement would do nothing to assist.

Even when Blinkx discusses the Zango acquisition, it is less than forthcoming. UK news publication The Register quotes an unnamed Blinkx spokeswoman saying that Blinkx “purchased some technical assets from the bank [that foreclosed on Zango] including some IP and hardware, which constituted about 10 per cent of Zango’s total assets.” Here too, readers are left to wonder what assets are actually at issue. A natural interpretation of the quote is that Blinkx purchased trademarks, domain names, or patents plus general-purpose servers — all consistent with shutting the controversial Zango business. But in fact my testing reveals the opposite: Blinkx continues to run key aspects of Zango’s business: legacy Zango installations continue to function as usual and continue to show ads, and Blinkx continues to solicit new installations via the same methods, programs, and partners that Zango previously used. Furthermore, key Zango staff joined Blinkx, facilitating the continuation of the Zango business. Consider Val Sanford, previously a Vice President at Zango; her LinkedIn profile confirms that she stayed with Blinkx for three years after the acquisition. I struggle to reconcile these observations with the claim that Blinkx only purchased 10% of Zango or that the purchase was limited to “IP and hardware.” Furthermore, ex-Zango CTO Ken Smith contemporaneously disputed the 10% claim, insisting that “Blinkx acquired fully 100% of Zango’s assets.”

Blinkx has been equally circumspect as to the size of the ex-Zango business. In Blinkx’ 2010 financial report, Blinkx nowhere tells investors the revenue or profit resulting from Zango’s business. Rather, Blinkx insists “It is not practical to determine the financial effect of the purchased net assets…. The Group’s core products and those purchased have been integrated and the operations merged such that it is not practical to determine the portion of the result that specifically relates to these assets.” I find this statement puzzling. The ex-Zango business is logically freestanding — for example, separate relationships with the partners who install the adware on users’ computers. I see no proper reason why the results of the ex-Zango business could not be reported separately. Investors might reasonably want to know how much of Blinkx’s business comes from the controversial ex-Zango activities.

Indeed, Blinkx’s investor statements make no mention whatsoever of Zango, adware, pop-ups, or browser plug-ins of any kind in any annual reports, presentations, or other public disclosures. (I downloaded all such documents from Blinkx’ Financial Results page and ran full-text search, finding no matches.) As best I can tell, Blinkx also failed to mention these endeavors in conference calls or other official public communications. In a December 2013 conference call, Jefferies analyst David Reynolds asked Blinkx about its top sources of traffic/supply, and management refused to answer — in sharp contrast to other firms that disclose their largest and most significant relationships.

In March-April 2012, many ex-Zango staff left Blinkx en masse. Many ended up at Verti Technology Group, a company specializing in adware distribution. Myriad factors indicate that Blinkx controls Verti: 1) According to LinkedIn, Verti has eight current employees of which five are former employees of Zango, Pinball, and/or Blinkx. Other recent Verti employees include Val Sanford, who moved from Zango to Blinkx to Verti. 2) Blinkx’s Twitter account: Blinkx follows just nineteen users including Blinkx’s founder, various of its acquisitions (including Prime Visibility / AdOn and Rhythm New Media), and several of their staff. Blinkx follows Verti’s primary account as well as the personal account of a Verti manager. 3) Washington Secretaty of State filings indicate that Verti’s president is Colm Doyle (then Directory of Technology at Blinkx, though he subsequently returned to HP Autonomy) and secretary, treasurer, and chairman is Erin Laye (Director of Project Management at Blinkx). Doyle and Laye’s links to Blinkx were suppressed somewhat in that both, at formation, specified their home addresses instead of their Blinkx office. 4) Whois links several Verti domains to Blinkx nameservers. (Details on file.) Taken together, these facts suggest that Blinkx attempted to move a controversial business line to a subsidiary which the public is less likely to recognize as part of Blinkx.

The Legacy AdOn Business

In November 2011, Blinkx acquired Prime Visibility Media Group, best known for the business previously known as AdOn Network and MyGeek. I have critiqued AdOn’s traffic repeatedly: AdOn first caught my eye when it boasted of relationships with 180solutions/Zango and Direct Revenue. New York Attorney General litigation documents later revealed that AdOn distributed more than 130,000 copies of notorious Direct Revenue spyware. I later repeatedly reported AdOn facilitating affiliate fraud, inflating sites’ traffic stats, showing unrequested sexually-explicit images, and intermediating traffic that led to Google click fraud.

Similar problems continue. For example, in a February 2013 report for a client, I found a botnet sending click fraud traffic through AdOn’s ad-feeds.com server en route to advertisers. In an August 2013 report for a different client, I found invisible IFRAMEs sending traffic to AdOn’s bing-usa.com and xmladfeed.com servers, again en route to advertisers. Note also the deceptive use of Microsoft’s Bing trademark — falsely suggesting that this tainted traffic is in some way authorized by or affiliated with Bing, when in fact the traffic comes from AdOn’s partners. Moreover, the traffic was entirely random and untargeted — keywords suggested literally at random, entirely unrelated to any aspect of user interests. In other instances, I found AdOn receiving traffic directly from Zango adware. All told, I reported 20+ distinct sequences of tainted AdOn traffic to clients during 2013. AdOn’s low-quality traffic is ongoing: Advertisers buying from AdOn receive invisible traffic, adware/malware-originating traffic, and other tainted traffic that sophisticated advertisers do not want.

An AdOn staff member touts multiple incriminating characteristics of AdOn traffic. An AdOn staff member touts multiple incriminating characteristics of AdOn traffic.

Industry sources confirm my concern. For example, a June 2013 Ad Week article quotes one publisher calling AdOn “just about the worst” at providing low-quality traffic, while another flags “crazy traffic patterns.” In subsequent finger-pointing as to tainted traffic to OneScreen sites, OneScreen blamed a partner, Touchstorm, for working with AdOn — wasting no words to explain why buying from AdOn is undesirable. Even intentional AdOn customers report disappointing quality: In comments on a posting by Gauher Chaudhry, AdOn advertisers call AdOn “the reason I stopped doing any PPV [pay-per-view] … this is bot traffic”, “junk”, and “really smell[s] like fake traffic.” Of 31 comments in this thread, not one praised AdOn traffic quality.

Recent statements from AdOn employees confirm undesirable characteristics of AdOn traffic. Matthew Papke’s LinkedIn page lists him as Director of Contextual Ads at AdOn. But his page previously described AdOn’s offering as “pop traffic” — admitting undesirable non-user-requested pop-up inventory. His page called the traffic “install based” — indicating that the traffic comes not from genuine web pages, but from adware installed on users’ computers. See screenshot at right. All of these statements have been removed from the current version of Matthew’s page.

Problems at Blinkx.com: Low-Quality Traffic, Low-Quality Content, and Invisible Ads

Alexa reports a sharp jump in Blinkx traffic in late 2013. Alexa reports a sharp jump in Blinkx traffic in late 2013.

Alexa reports a sharp jump in Blinkx traffic in late 2013. Zango adware caused my computer to display this page from the Blinkx site, full-screen and without standard window controls.

Blinkx’s namesake service is the video site Blinkx.com. Historically, this site has been a bit of an also-ran — it’s certainly no YouTube! But Alexa reports a striking jump in Blinkx popularity as of late 2013: Blinkx’s traffic jumped from rank of roughly 15,000 worldwide to, at peak, rank of approximately 3,000. What could explain such a sudden jump?

In my automated and manual testing of Zango adware, I’ve recently begun to see Zango forcing users to visit the Blinkx site. The screenshot at right gives an example. My test computer displayed Blinkx full-screen, without title bar, address bar, or standard window buttons to close or minimize. See also a partial packet log, wherein the Blinkx site attributes this traffic to Mossysky (“domain=mossysky”), one of the Zango brand names. It’s a strikingly intrusive display — no wonder users are complaining, about their computers being unusable due to Blinkx’s unwanted intrusion. See e.g. a December 2013 Mozilla forum post reporting “my computer has been taken over by malware, half the links are inaccessible because of hovering links to Blinkx,” and a critique and screenshot showing an example of these hovering links. On a Microsoft support forum, one user reports Internet Explorer automatically “opening … numerous BLINKX websites” — as many as “20 websites open at one time, all Blinkx related.”

Moreover, Alexa’s analysis of Blinkx visitor origins confirms the anomalies in this traffic. Of the top ten sites sending traffic to Blinkx, according to Alexa, six are Blinkx servers, largely used to forward and redirect traffic (networksad.com, advertisermarkets.com, networksads.com, advertiserdigital.com, blinkxcore.com, and networksmarkets.com). See Alexa’s Site Info for Blinkx.com at heading “Where do Blinkx.com’s visitors come from?”

Strikingly, Zango began sending traffic to Blinkx during the winter 2013 holiday season — a time of year when ad prices are unusually high. Zango’s popups of Blinkx seem to have ended as suddenly as they began — consistent with Blinkx wanting extra traffic and ad revenue when ad prices are high, but concluding that continuing this practice at length risks excessive scrutiny from both consumers and advertisers.

Meanwhile, examining Blinkx.com, I’m struck by the lack of useful content. I used the Google search site:blinkx.com to find the parts of the Blinkx site that, according to Google, are most popular. I was directed to tv.blinkx.com, where the page title says users can “Watch full episodes of TV shows online.” I clicked “60 Minutes” and received a page correctly profiling the excellence of that show (“the granddaddy of news magazines”). But when I clicked to watch one of the listed episodes, I found nothing of the kind: Requesting “The Death and Life of Asheboro, Stealing History, The Face of the Franchise,” I was told to “click here to watch on cbs.com” — but the link actually took me to a 1:33 minute home video of a dog lying on the floor, “Husky Says No to Kennel”, syndicated from YouTube, entirely unrelated to the top-quality 60 Minutes content I had requested. (Screen-capture video.) It was a poor experience — not the kind of content likely to cause users to favor Blinkx’s service. I tried several other shows supposedly available — The Colbert Report, The Daily Show with Jon Stewart, Family Guy, and more — and never received any of the listed content.

In parallel, the Blinkx site simultaneously perpetrated a remarkable scheme against advertisers: On the video index page for each TV show, video advertising was triggered to play as I exited each page by clicking to view the supposed video content. Because the supposed content opened in a new tab, the prior tab remained active and could still host a video player with advertising. Of course the prior tab was necessarily out of visibility: Blinkx’s code had just commanded the opening of a new tab showing the new destination. But the video still played, and video advertisers were still billed. Screen-capture video.

Industry sources confirm concerns about Blinkx ad visibility. For example, a December 15, 2013 Ad Week piece reported Vindico analysis finding just 23% of Blinkx videos viewable (defined as just 50% of pixels visible for just one second). By Vindico’s analysis, an advertiser buying video ads from Blinkx suffers three ads entirely invisible for every ad visible even by that low standard — a remarkably poor rate of visibility. In contrast, mainstream video sites like CBS and MSN enjoyed viewability rates two to four times higher.

Putting the Pieces Together

  Q3 ’13 Headcount ’13 Revenue ($mm) revenue / headcount ($k)
Tremor 287 $148 $517
YuMe 357* $157 $440
RocketFuel 552 $240 $434
Criteo 452 $240 $532
Blinkx 265** $246*** $927

* Q3 ’13 headcount not available. 357 is 2012 year-end. S&M spend up ~50% in 2013. Adjusted revenue/headcount is $293k
** Q3 ’13 headcount not available. 265 is 2012 year-end. S&M spend up ~15% in 2013. Adjusted revenue/headcount is $803k.
*** 2013 revenue estimate based on Bloomberg consensus estimates

Comparing Blinkx’s revenues to competitors, I am struck by Blinkx’s apparent outsized success. See the table at right, finding Blinkx producing roughly twice as much revenue per employee as online video/display ad networks and advertising technology companies which have recently made public offerings. Looking at Blinkx’s sites and services, one doesn’t get the sense that Blinkx’s service is twice as good, or its employees twice as productive, as the other companies listed. So why does Blinkx earn twice as much revenue per employee? One natural hypothesis is that Blinkx is in a significantly different business. While other services make significant payments to publishers for use of their video content, my browsing of Blinkx.com revealed no distinctive content obviously licensed from high-quality high-cost publishers. I would not be surprised to see outsized short-term profits in adware, forced-visit traffic, and other black-hat practices of the sort used by some of the companies Blinkx has acquired. But neither are these practices likely to be sustainable in the long run.

Reviewing Blinkx’s statements to investors, I was struck by the opacity. How exactly does Blinkx make money? How much comes from the legacy Zango and AdOn businesses that consumers and advertisers pointedly disfavor? Why are so many of Blinkx’s metrics out of line with competitors? The investor statements raise many questions but offer few answers. I submit that Blinkx is carefully withholding this information because the company has much to hide. If I traded in the companies I write about (I don’t!), I’d be short Blinkx.

This article draws in part on research I prepared for a client that sought to know more about Blinkx’s historic and current practices. At my request, the client agreed to let me include portions of that research in this publicly-available posting. My work for that client yielded a portion of the research presented in this article, though I also conducted significant additional research and drew on prior work dating back to 2004. My agreement with the client did not oblige me to circulate my findings as an article or in any other way; to my knowledge, the client’s primary interest was in learning more about Blinkx ‘s business, not in assuring that I tell others. By agreement with the client, I am not permitted to reveal its name, but I can indicate that the client is two US investment firms and that I performed the research during December 2013 to January 2014. The client tells me that it did not change its position on Blinkx after reading my article. (Disclosure updated and expanded on February 4-5, 2014.)

I thank Eric Howes, Principal Lab Researcher at ThreatTrack Security, and Matthew Mesa, Threat Researcher at ThreatTrack Security, for insight on current Blinkx installations.

Measuring and Managing Online Affiliate Fraud with Wesley Brandi

Affiliate programs vary dramatically in their incidence of fraud. In some merchants’ affiliate programs, rogue affiliates fill the ranks of high-earners. Yet other similarly-sized merchants have little or no fraud. Why the difference?

In Information and Incentives in Online Affiliate Marketing, Wesley Brandi and I examine the impact of varying merchant management decisions. Some merchants hire specialist outside advisors (“outsourced program managers” or OPM’s) to set and enforce program rules. Others ask affiliate network staff to make these decisions. Still others handle these tasks internally.

A merchant’s choice of management structure has significant implications for both the information available to decision-makers and the incentives that motivate those decision-makers. Outside advisors tend to have better information: An OPM sees problems and trends across its many clients. A network is even better positioned — enjoying direct access to log files, custom reports, and problems reported by all merchants in the network. That said, outside advisors usually suffer clear incentive problems. Most notably, networks are usually paid in proportion to a merchant’s affiliate channel spending, so networks have a significant incentive to encourage merchants to accept even undesirable affiliates. In contrast, incentives for merchants’ staff are typically more closely aligned with the merchant’s objectives. For example, many in-house affiliate managers have stock, options, or bonus that depend on company profitability. And working in a company builds intrinsic motivation and loyalty. In short, there are some reasons to think outsourced specialists will yield superior results, but other reasons to favor in-house staff.

To separate these effects, we used crawlers to examine affiliate fraud at what we believe to be unprecedented scope. Our crawlers ran more than 2 million page-loads on a variety of computers and virtual computers, examining the relative susceptibility of all CJ, LinkShare, and Google Affiliate Network merchants (as of spring 2012) to adware, cookie-stuffing, typosquatting, and loyalty apps.

We found outside advisors best able to find “clear fraud” plainly prohibited by network rules, specifically adware and cookie-stuffing. But in-house staff did better at avoiding “grey area” practices such as typosquatting — schemes less plainly prohibited by network rules, yet still contrary to merchants’ interests. On balance, there are good reasons to favor each management approach. Our advice: A merchant choosing outsourced management should be sure to insist on borderline decisions always taken with the merchant’s interests at heart. A merchant managing its programs in-house should be careful to avoid known cheaters that a savvy specialist would more often exclude.

Our results clearly reveal that networks take actions that are less than optimal for merchants. It’s tempting to attribute this shortfall to malicious intent by networks, but the same outcome could result from networks simply putting their own interests first. Consider a network that receives undisputed proof that a given affiliate is cheating a given merchant. Should the network eject that affiliate from the entire network (and all affiliated merchants), or only from that single merchant’s program? The former helps dozens or hundreds of merchants, but with corresponding reduction to network revenues. No wonder many networks chose the latter. Similarly, when networks decide how much to invest in network quality — engineers, analysts, crawlers, and the like — their incentive to improve quality is tempered by both direct cost and foregone revenue.

Incidental to our analysis of management structure, we gathered significant data about the scope of affiliate fraud more generally. Some differences are stark: For example, Table 4 reports Google Affiliate Network merchants suffering, on average, less than half as much adware and cookie-stuffing as LinkShare merchants. I’ve been critical of Google on numerous issues. But when it comes to affiliate quality, GAN was impressive, and GAN’s high standards show clearly in our large-sample data. Note that our analysis precedes Google’s April 2013 announcement of GAN’s shutdown.

Our full analysis is under review by an academic journal.

(update: published as Edelman, Benjamin, and Wesley Brandi. “Risk, Information, and Incentives in Online Affiliate Marketing.” Journal of Marketing Research (JMR) 52, no. 1 (February 2015): 1-12. (Lead Article.)