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:
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.
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.
showDirectDownloadAppDetailsWithExtra() with service method AbstractC1838d0.m3826C(),delegate C2823r(), and Kotlin coroutine continuation with entry point mo410()
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()
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.
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 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”.
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)
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.
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.”
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.”
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.
We conducted randomized controlled trials (RCTs) to measure the efficiency gains from using Security Copilot, including speed and quality improvements. External experimental subjects logged into a M365 Defender instance created for this experiment and performed four tasks: Incident Summarization, Script Analyzer, Incident Report, and Guided Response. We found that Security Copilot delivered large improvements on both speed and accuracy. Copilot brought improvements for both novices and security professionals.
On May 26, 2016, the U.S. District Court for the Northern District of California approved the settlement of a class action against Facebook involving in-app purchases of Facebook Credits by minor children. The case was maintained on behalf of a class of children who were Facebook users (“child users”) below the age of 18 from whose Facebook accounts Facebook Credits were purchased. The case was filed by two minor children through their parents on February 23, 2012. The two children and the class were represented by attorneys Brooks Cutter and John R. Parker of the Cutter Law Firm in Sacramento, California; Daniel B. Edelman of the firm of Katz, Marshall & Banks in Washington, D.C.; and Benjamin Edelman, an associate professor at the Harvard Business School. On March 10, 2015, the Court certified the case as a class action for purposes of declaratory and injunctive relief on behalf of all minor children who were users of Facebook from whose Facebook accounts Facebook Credits were purchased at any time between February 23, 2008 and the date of the certification order, March 10, 2015. At the same time, the Court declined to certify a class action for purposes of class-wide monetary relief.
During the period covered by the suit, hundreds of thousands of child users purchased Facebook Credits for use in playing Facebook-based games and applications. To make such purchases, child users generally used credit cards, debit cards or other payment instruments that belonged to their parents or other responsible adults. Facebook made a practice of retaining the payment information provided at the time of the child user’s initial purchase for easy use in later purchases. Facebook advised that purchases by children were to be made only with the permission of the parent or guardian. Facebook did not, however, require evidence that any of the purchases was actually authorized by the parent, guardian or owner of the payment instrument. In many instances, the child user did not have authorization to use the card or other payment instrument to purchase Facebook Credits. Facebook specified in its terms of use that all transactions are “final”. It later stated that all transactions are “final except as otherwise required by law”.
Facebook’s Terms of Use state that purchase transactions are governed by the law of California. The Family Code of California provides that contracts with minors are voidable by the minor at any time before attaining the age of 18 or within a reasonable time thereafter. The court applied that principle to this case: “The law shields minors from their lack of judgment and experience and under certain conditions vests in them the right to disaffirm their contracts. Although in many instances such disaffirmance may be a hardship upon those who deal with an infant, the right to avoid his contracts is conferred by law upon a minor for his protection against his own improvidence and the designs of others. It is the policy of the law to protect a minor against himself and his indiscretions and immaturity as well as against the machinations of other people and to discourage adults from contracting with an infant.” (MTD decision, October 25, 2012, at pp. 11-12.) The court continued: “[O]ne who provides a minor with goods and services does so at her own risk.” (Id. at p.12.)
Facebook defended the claims in part by arguing that kids had received and used the electronic goods they paid for. The court specifically rejected this reasoning, finding that kids are entitled to refunds even for items they used. “Under California law, a minor may disaffirm all obligations under a contract, even for services previously rendered, without restoring consideration or the value of services rendered to the other party.” (MTD Decision at p.14, internal quotation marks omitted)
Prior to the settlement, Facebook provided an online procedure for refund requests in various specific circumstances such as fraudulent use of a user’s account by a third-party. Facebook’s refund procedure did not include an option to request a refund on the ground that the purchase was made when the user was a minor.
The settlement requires Facebook to apply refund practices and policies with respect to U.S. minors that comply with the California Family Code.
The settlement further requires Facebook to “add to its refund request form for In-App Purchases for U.S. users a checkbox or substantially similar functionality with accompanying text such that users are able to indicate that the In-App Purchases for which they are seeking a refund was made when the user was minor.”
The settlement additionally requires Facebook to “implement a dedicated queue within Facebook to address refund requests in In-App Purchases, made by U.S. Minors subject to verification of minority. The employees staffing the dedicated queue will receive further training regarding how to analyze and process such refund requests in accordance with applicable law.”
If you or your minor child were charged for Facebook credits purchased from an account belonging to someone age 17 or younger, you may be entitled to obtain refunds for such purchases through the use of the dedicated queue established by Facebook as a result of the settlement. Both minor account holders and the parents and guardians of such minors are entitled to claim such refunds. Claim refunds via the Facebook refund tool.
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.
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.
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.
Affiliate marketing is supposed to be low-risk for merchants: in theory, merchants only pay affiliates when a user makes a purchase. Specifically, an affiliate should earn a commission only if 1) the user browses the affiliate’s site, 2) the user clicks the affiliate’s specially-coded link to the merchant, and 3) the user makes a purchase from the merchant. But rogue affiliates find ways to bypass these requirements — be it cookie-stuffing, adware popups, typosquatting, or network-based traffic interception. In this piece, I show Delaware-based Aspira Networks approach: configuring its partners’ networks so that if a user makes a purchase from a targeted merchant’s site, the merchant has to pay Aspira an affiliate commission — even though Aspira did nothing to cause or encourage the user’s purchase.
The method is straightforward. Aspira partners with network operators to monitor and reroute users’ browsing. If a user requests a targeted merchant, Aspira intercedes — redirecting the user to an Aspiralabs.com “finder” page, through an affiliate click link, then back to the merchant. The affiliate redirect causes merchants to conclude, mistakenly, that Aspira caused users’ subsequent purchases.
In testing, I found that Aspira targets roughly a quarter of large mainstream US affiliate merchants. I found Aspira systematically using CJ publisher account 3965551. In testing, I did not find Aspira currently targeting merchants using LinkShare, though an early Aspira investor pitch (dated August 2009 in metadata) indicates that Aspira has worked with LinkShare as well as Google Affiliate Network.
Merchants have no reason to pay for Aspira’s traffic. Though affiliate network reports may attribute sales to Aspira, Aspira does not actuallycause additional or incremental purchases. Rather, these are purchases that merchants would have received anyway. Aspira tells prospective merchants that they will “sell more products” by working with Aspira, but I see no evidence to support that claim. Quite the contrary, in fact; in my testing, Aspira did not genuinely promote any merchants. Aspira claimed commission only after a user had already reached a merchant’s site.
Notably, Aspira’s networks violate longstanding and broadly-applicable network policies. For example, the Commission Junction Publisher Service Agreement indicates that commission is only due for “clicks through links” (provision 3.a). Aspira’s automatic redirects entail no genuine user “click” on any link; there’s an automatic redirect but not an actual click. Other CJ rules disallow “transactions … not in good faith” including all manner of automatic and nonincremental leads (provision 1.d.ii). Here too, Aspira falls short.
Aspira’s site focuses on public installations (coffee-shops and the like) where, in principle, one might imagine that network access was made available by payments from Aspira. But I found Aspira redirecting traffic from an ordinary office served by Indiana ISP Smithville Communications. So far as I know, Smithville never notified its customers that it would be monitoring their communications, redirecting them through affiliate links, or sharing their browsing activity with Aspira. (Smithville’s privacy policy makes no mention of Aspira or sending users’ browsing to third parties.) Nor did Smithville offer customers a discount for allowing Smithville and Aspira to monitor and redirect their browsing. Other users report (and criticize) similar redirects when using standard residential and commercial ISPs Access Media 3, Arvig, and OnShore Networks.
Aspira’s site gives little detail about its revenue from redirecting users through affiliate links. Partner Cash4trafik says “typical operators have realized historically …. about $1.00 – $10.00 per subscriber per year.” Notice that revenue must be shared among affiliate networks, Aspira, Cash4traffik, and ISPs — so if an ISP gets $5, the others might take another $15 along the way. Indeed, early Aspira financial projections — posted to the web and readily found by web search — indicate that Aspira planned to retain a 40% to 67% share of affiliate commissions.
Meanwhile, Aspira’s financial projections show a particularly brazen attempt to claim payments despite minimal effort. As of 2010, Aspira projected 2013 revenue climbing to $63 million with expense reportedly to stay below $7 million. Business plans are often overly optimistic, but an 89% profit margin is difficult to reconcile with genuine efforts to find incremental customers. In contrast, it’s wholly consistent with the practice I observed in which Aspira claims commission without any expense to find or attract users.
Whatever the benefits to Aspira and its partners, the effect on merchants is clearly negative: Aspira causes extra advertising expense without providing incremental purchases. Affiliate merchants should reject Aspira’s approach, save their marketing budgets for publishers with genuine incremental value, and encourage Aspira to shift to other activities.
Thanks to Thomas Rice for bringing this practice to my attention and facilitating my collection of proof of Aspira’s practices.
