Category: specific companies

Specific companies

Posted on

Discrimination at Airbnb with Michael Luca

Online marketplaces often contain information not only about products, but also about the people selling the products. In an effort to facilitate trust, many platforms encourage sellers to provide personal profiles and even to post pictures of themselves. However, these features may also facilitate discrimination based on sellers’ race, gender, age, or other characteristics.

Last week Michael Luca and I posted Digital Discrimination: The Case of Airbnb.com, in which we test for racial discrimination against landlords in the online rental marketplace Airbnb.com. We collected information about all Airbnb hosts in New York City, including their rental prices and the quality of their properties. We find that non-black hosts charge approximately 12% more than black hosts for the equivalent rental. These effects are robust when controlling for all information visible in the Airbnb marketplace, including even property photos.

Our findings highlight the risk of discrimination in online marketplaces, suggesting an important unintended consequence of a seemingly-routine mechanism for building trust. There is no fundamental reason why a guest needs see a host’s picture in advance of making a booking — nor does a guest necessarily even need to know a host’s name (from which race may sometimes be inferred). In other respects, Airbnb has been quite sophisticated in limiting the information available to hosts and guests on its platform — for example, AIrbnb prohibits (and runs software to prevent) hosts and guests from sharing email addresses or phone numbers before a booking is made, lest this information exchange let parties contract directly and avoid Airbnb fees. Given Airbnb’s careful consideration of what information is available to guests and hosts, Airbnb might consider eliminating or reducing the prominence of host photos: It is not immediately obvious what beneficial information these photos provide, while they risk facilitating discrimination by guests.

Posted on

Digital Discrimination: The Case of Airbnb.com

Edelman, Benjamin, and Michael Luca. “Digital Discrimination: The Case of Airbnb.com.” Harvard Business School Working Paper, No. 14-054, January 2014.

Online marketplaces often contain information not only about products, but also about the people selling the products. In an effort to facilitate trust, many platforms encourage sellers to provide personal profiles and even to post pictures of themselves. However, these features may also facilitate discrimination based on sellers’ race, gender, age, or other aspects of appearance. In this paper, we test for racial discrimination against landlords in the online rental marketplace Airbnb.com. Using a new data set combining pictures of all New York City landlords on Airbnb with their rental prices and information about quality of the rentals, we show that non-black hosts charge approximately 12% more than black hosts for the equivalent rental. These effects are robust when controlling for all information visible in the Airbnb marketplace. These findings highlight the prevalence of discrimination in online marketplaces, suggesting an important unintended consequence of a seemingly-routine mechanism for building trust.

Posted on

Comments to European Commission on Proposed Google Commitments with Zhenyu Lai

The European Commission last month posted a restatement of its concerns at certain Google practices as well as Google’s proposed commitments. This week I filed two comments, including one with Zhenyu Lai, critiquing Google’s proposal. They are available here:

Comments on AT.39740 (Edelman and Lai) as to Google’s exclusive use of screen space to promote its own specialized services, and as to an alternative remedy to preserve competition and user choice in the area of specialized search services.

Comments on AT.39740 (Edelman) as to the failure of Google’s proposed commitments to undo the harm of Google’s past violations, and alternative remedies preserve competition in the area of specialized search services, taking data from publishers, providing advertising services to publishers, and allowing advertisers to use multiple ad platforms.

Our suggested remedy for Google favoring its own vertical search services: Let users choose from competing offeringsAs to Google’s decision to favor its own specialized search services, Zhenyu and I question whether Google’s proposed commitments would effectively preserve competition. In our recent measurement of the effects of Google Flight Search, we found that Google’s large Flight Search “onebox” displays sharply reduced traffic to other online travel agencies as well as driving up the proportion of clicks to AdWords advertising. Google proposes to display a few small “Rival Links” to competitors, but these links would be placed and formatted in ways that make them unlikely to attract users’ attention or facilitate competitive markets.

Instead, we suggest a “ballot box” in which users can choose their preferred specialized search services in any area where Google offers and favors its own specialized search services. For example, the first time a user runs a hotel search or flight search, the user would be presented with a menu of options — reminiscent of the “browser ballot box” a user sees when first booting Windows in Europe. This approach is entirely feasible: Facebook has long merged content from myriad independent developers; numerous developers quickly built browser add-ons to disable Google Search Plus Your World when they found its initial results unhelpful; and the G++ for Google Plus browser add-on integrates other social networks with G+ even though Google declines to provide such integration. Indeed, search engine guru Danny Sullivan in September 2011 suggested that Google “let[] people choose their shopping, local, etc one box provider?”, echoing my February 2011 call for interchangeable components for competing specialized search services. In our comment, Zhenyu and I explore a proposed implementation of this concept.

As to the Commission’s concerns more generally, my comment addresses Google’s failure to undo the harm resulting from Google’s past violations. For each of the Commission’s concerns, I present alternative remedies focused on protecting competition and affirmatively undoing the harm from Google’s past violations. I also flag the need for tough penalties to deter further violations by Google and others.

Reuters yesterday reported that the Commission is likely to require further concessions from Google, including improved remedies. Comments to the Commission are due by June 27.

Posted on

Google’s Exclusive Flight Search OneBox with Zhenyu Lai

Google often shows “OneBox” search results promoting its own services. These results have prompted antitrust scrutiny: Google awards these preferred placements exclusively to Google’s own services, such as Google Flight Search and Google Maps, but never to competing services such as Kayak or Mapquest. Moreover, Google presents OneBox with special format, including distinctive layouts, extra images, and even in-page interactivity — benefits not available to ordinary listings for other sites. Regulators and competitors sense that these exclusive practices can undermine competition and innovation by denying traffic to would-be competitors. But how large is the effect? How much does Google’s exclusive OneBox placement impact search engine traffic to adjacent online markets?

In a working paper, Zhenyu Lai and I measure the impact of OneBox by using a quasi-experiment before and after the introduction of Google Flight Search. Using a third-party data service, we compare user behavior on searches across thousands of search queries like “cheap flights from sfo to san ” (which displayed a OneBox for Google Flight Search), and similar search queries like “cheaper flights from sfo to san” (emphasis added) (which did not display OneBox). We find that Google’s display of Flight Search in an exclusive OneBox decreased user click-through rates on unpaid search results by 65 percent, and increased user click-through rates on paid advertising links by 85 percent. This effect was disproportionately evident among online travel agencies that were popular destinations for affected search queries.

Our draft provides detailed empirical results as well as a model of how a search engine’s incentives to divert search depend on consumers’ perceptions of the difference between non-paid and paid placements.

Exclusive Preferential Placement as Search Diversion: Evidence from Flight Search

(update: published as Edelman, Benjamin, and Zhenyu Lai. “Design of Search Engine Services: Channel Interdependence in Search Engine Results.” Journal of Marketing Research (JMR) 53, no. 6 (December 2016): 881-900.)

Posted on

Privacy Puzzles at Google Play

Last week app developer Dan Nolan noticed that Google transaction records were giving him the name, geographic region, and email address of every user who bought an Android app he sold via Google Play. Dan’s bottom line was simple: “Under no circumstances should [a developer] be able to get the information of the people who are buying [his] apps unless [the customers] opt into it and it’s made crystal clear to them that [app developers are] getting this information.” Dan called on Google to cease these data leaks immediately, but Google instead tried to downplay the problem.

In this post, I examine Google’s relevant privacy commitments and argue that Google has promised not to reveal users’ data to developers. I then critique Google’s response and suggest appropriate next steps.

Google’s Android Privacy Promise

In its overarching Google Privacy Policy, Google promises to keep users’ data confidential. Specifically, at the heading “Information we share”, Google promises that “We do not share personal information with companies, organizations and individuals outside of Google unless one of the following circumstances apply”. Google then lists four specific exceptions: “With your consent”, “With domain administrators”, “For external processing”, and “For legal reasons.” None of these exceptions applies: users were never told that their information would be shared (not to mention “consent[ing]” to such sharing; Google shared data with app developers, not domain administrators; app developers do not process data for Google, and the data was never processed nor provided for processing; and no legal reason required the sharing of this information. Under Google’s standard privacy policy, users’ data simply should not have been shared.

Users purchase Android apps via the Google Play service, so Google Play policies also limit how Google may share users’ information. But the Google Play Terms of Service say nothing about Google sharing users’ details with app developers. Quite the contrary, the Play TOS indicate that Google will not share users’ information with app developers. At heading 10, Magazines on Google Play, Google specifically notes the additional “Information Google Shares with Magazine Publishers”: customer “name, email address, [and] mailing address.” But Google makes no special mention of information shared with any other type of Google Play content provider. Notice: Google notes that it shares certain extra information with magazine publishers, but it makes no corresponding mention of sharing with other content providers. The only plausible interpretation is that Google does not share the listed information with any other kind of content provider.

Users’ Google Play purchases are processed via Google Wallet, so Google Wallet policies also limit how Google may share users’ information. But the Google Wallet privacy policy says nothing about Google sharing users’ details with app developers. Indeed, the Google Wallet privacy policy is particularly narrow in its statement of when Google may share users’ personal information:

Information we share
We will only share your personal information with other companies or individuals outside of Google in the following circumstances:
* As permitted under the Google Privacy Policy.
* As necessary to process your transaction and maintain your account.
* To complete your registration for a service provided by a third party.

None of these exceptions applies to Google sharing users’ details with app developers. The preceding analysis confirms that the Google Privacy Policy says nothing of sharing users’ information with app developers, so the first exception is inapplicable. Nolan’s post confirms that app developers do not need users’ details in order to provide the apps users request; Google’s app delivery system already provides apps to authorized users. And app developers need not communicate with users by email, making it unnecessary for Google to provide an app developer with a user’s email address. Google might argue that it could be useful, in certain circumstances, for app developers to be able to email the users who had bought their apps. But this certainly is not “necessary.” Indeed, Nolan had successfully sold apps for months without doing so. The third exception does not apply to any app that does not require “registration” (most do not). Even if we interpret “registration” as installation and perhaps ongoing use, Nolan’s experience confirms why the third exception is also inapplicable: Nolan was easily able to do everything needed to sell and service the apps he sold without ever using users’ email addresses.

Even if it were necessary for Google to let developers contact the users who bought their apps, such communications do not require that Google provide developers with users’ email addresses. Quite the contrary, Google could provide remailer email addresses: a developer would write to an email address that Google specifies, and Google would forward the message as needed. Alternatively, Google could develop an API to let developers contact users. These suggestions are more than speculative: Google Checkout uses exactly the former technique to shield users’ email address from sellers. (From Google’s 2006 announcement: “To provide more control over email spam, Google Checkout lets shoppers choose whether or not to keep email addresses confidential or turnoff unwanted email from the stores where they shop”) Similarly, Google Wallet creates single-use credit card numbers (“Virtual OneTime Card”) to let users make purchases without revealing their payment details developers. Having developed such sophisticated methods to protect user privacy in other contexts, including more complicated contexts, Google cannot credibly argue that it was “necessary” to reveal users’ email addresses to app developers.

Evaluating Google’s Defenses

Siliconvalley.com quotes an unnamed Google representative defending Google’s approach:

“Google Wallet shares the information necessary to process a transaction, which is clearly spelled out in the Google Wallet Privacy Notice.”

I emphatically disagree. First, it simply is not “necessary” to provide developers with access to customer names or email addresses in order to process customer transactions. Apple has long run a similar but larger app marketplace without doing so. Scores of developers, Nolan among many others, successfully provide apps without using (and often without even knowing they are receiving) customer names and email addresses. To claim that it is “necessary” to provide this information to developers, Google would need to establish that there is truly no alternative — a high bar, which Google has not even attempted to reach.

Second, this data sharing is not “spelled out in the Google Wallet Privacy Notice” and certainly is not “clear[]” there. The preceding section analyzes the relevant section of the Google Wallet privacy policy. Nothing in that document “clearly” states that Google shares users’ email addresses with third-party developers. The only conceivable argument for such sharing is that such sharing is “necessary” — but that immediately returns us to the arguments discussed above.

Resolution

Google widely promises to protect users’ private information. Google makes these promises equally in mobile. Having promised protection and delivered the opposite, Google should not be surprised to find users angry.

Some app developers defend Google’s decision to provide developers with customer details. For example, the Application Developers Alliance commented that “in the Google Play environment the app purchaser customer data (e.g., name and email address) belongs to the developer who is the seller” — arguing that it is therefore appropriate that Google provide this information to app developers. Barry Schwartz of Marketing Land added “I want to be able to service my customers” and indicated that sharing customer names and emails helps with support and refunds. Perhaps there are good reasons to provide customer data to developers. But these arguments offer no reason why Google did not tell users that their details would be sent to app developers. The Application Developers Alliance suggests that anyone uncertain about data sharing should “carefully review the Google Play and Google Wallet terms of service.” But these documents nowhere state that users’ information is provided to app developers (recall the analysis above), and in fact the documents indicate exactly the opposite.

Meanwhile, sharing users’ details with app developers risks significant harms. Nolan noted two clear problems: First, a developer could use customer contact details to track and harass users who left negative reviews or sought refunds. Second, an attacker could write malware that, running on app developers’ computers, logs into Google’s systems to collect user data. While one might hope app developers would keep their computers secure from such malware, there are tens of thousands of Android developers. Some are bound to have poor security on some local machines. Users’ data shouldn’t be vulnerable to the weakest link among these thousands of developers. An attacker could devise a highly deceptive attack with information about which users bought which apps when — yielding customized, accurate emails inviting users to provide passwords (actually phishing) or install updates (actually malware).

Moreover, Google is under a heightened obligation to abide by its privacy commitments. For one, privacy policies have the force of contract, so any company breaching its privacy policy risks litigation by harmed consumers. Meanwhile, Google’s prior privacy blunders have put Google under higher scrutiny: Google’s Buzz consent order includes twenty years of FTC oversight of Google’s privacy practices. After Google violated the FTC consent order by installing special code to monitor Apple Safari users whose browser settings specifically indicated they did not want to be tracked, the FTC imposed a $22.5 million fine, its largest ever. Now Google has again violated its privacy policies. A further investigation is surely in order.

A full investigation of Google’s activities in this area will confirm who knew what when. Though Nolan’s complaint was the first to gain widespread notice, at least three other developers had previously raised the same concern (1, 2, 3), dating back to June 2012 or earlier. An FTC investigation will confirm whether Google staff noted these concerns and, if they noticed, why they failed to take action. Perhaps some Google staff proposed updating or clarifying applicable privacy policies; an investigation would determine why such improvements were not made. An investigation would also confirm the allegation (presented in an update to News.com.au reporting on this subject) that prior to October 2012, Google intentionally protected users’ email addresses by providing aliases — letting app developers contact users without receiving users’ email addresses. Given the clear reduction in privacy resulting from eliminating aliases, an investigation would check whether and why Google made this change.

Even before that investigation, Google can take steps to begin to make this right. First, Google should immediately remove users’ details from developers’ screens. Google should simultaneously contact developers who had impermissible access and ask them to destroy any copies that they made. If Google has a contractual basis to require developers to destroy these copies, it should invoke those rights. In parallel, Google should contact victim users to let them know that Google shared their information in a way that was not permitted under Google’s own policies. Google should offer affected users Google’s unqualified apologies as well as appropriate monetary compensation. Since Google revealed users’ information only after users purchased paid apps, users’ payments offer a natural remedy: Google should provide affected users with a full refund for any apps where Google’s privacy practices did not live up to Google’s commitments.

Posted on

The Right Remedies for Google’s AdWords API Restrictions

Last week the FTC closed its 21-month investigation of Google after Google made several small concessions, among them dropping certain restrictions on use of Google’s AdWords API — rules that previously limited how advertisers and tool-makers may copy advertisers’ own data from Google’s servers. Removing the restrictions is a step forward for advertisers and for competition. But the FTC could and should have demanded more from Google in order to address the harm resulting from seven years of these restrictions.

I first flagged Google’s AdWords API restrictions in my June 2008 senate testimony and in greater detail in PPC Platform Competition and Google’s “May Not Copy” Restriction. In short, the restrictions prohibited making and sharing tools to quickly copy and synchronize ad campaigns across multiple ad platforms — effectively compelling small to midsized advertisers to use Google only, for lack of tools to manage their campaigns on multiple platforms. Google enforces this prohibition with a system of tool passwords and audits — letting Google swiftly and completely disable any tool that Google deems impermissible. Indeed, any tool-maker found offering a noncompliant tool would immediately lose all access to Google’s AdWords API, as to all of its tool-using subscribers, a devastating blow that kept tool-makers under Google’s thumb.

As I pointed out, these AdWords API restrictions let Google charge prices higher than competing platforms: Thanks to these restrictions, a small to midsized advertiser would struggle to buy some placements from Yahoo or Microsoft, even if those vendors offered lower prices. Higher advertising costs directly harm advertisers, and higher prices get passed to consumers (according to the relative elasticity of supply and demand). I also pointed out harms to others in the advertising ecosystem: Competing ad platforms struggle to attract advertisers, hence showing less relevant advertising (discouraging users from clicking ads) and enjoying less auction pressure to push prices upward. Meanwhile, I noted, the AdWords API restrictions give Google that much more leverage in its negotiations with publishers: by weakening other ad platforms’ monetization, Google can more easily win deals for publishers’ inventory, granting publishers lesser compensation for the content they post.

Strikingly, Google has never seriously defended the AdWords API restrictions. In June 2008, Doug Raymond, Product Manager for AdWords API, argued that advertisers are free to export their data in other ways, e.g. as a CSV text file. But that far-inferior manual export is ad-hoc, time-consuming, and error-prone — a poor fit for high-priced online advertising. Indeed, this manual approach is a sharp contrast from a modern automation API, and a far cry from what Google offers in other contexts.

By all indications, competition regulators share my concerns. In a November 2010 press release, the European Commission flagged “restrictions on the portability of online advertising campaign data” as its fourth concern in reviewing Google’s conduct, a concern most recently reiterated in December 2012 remarks by EC Competition Commissioner Joaquín Almunia. Last week’s statement by FTC Chairman Leibowitz is in accord: “Some Commissioners were concerned by the tendency of Google’s restrictions to raise the costs of small businesses to use the power of internet search advertising to grow their businesses.”

So everyone but Google agrees that the AdWords API restrictions are improper, and even Google has little to say in its defense. Indeed, despite abandoning most other aspects of its investigation, the FTC did pursue this matter. But the FTC reports only that Google is to remove AdWords API restrictions and that, the FTC indicates, ends the FTC’s concern on this subject. I am surprised by such a narrow remedy. The AdWords API restrictions have been in place for more than five years. Were it not for these restrictions, advertisers for five years would have enjoyed lower prices. For five years, third-party publishers would have received higher payment for their ad space. For five years, consumers would have seen more relevant ads at competing ad platforms, perhaps helping to increase competitors’ market shares and put a check on Google’s dominance. Moreover, for five years competing ad platforms would have enjoyed higher advertising revenues and higher ad click-through rates. It’s all well and good for Google to remove the API restriction going forward. But that does nothing at all to address past harm to advertisers and others.

Three Appropriate Remedies

What remedies would be appropriate for Google’s seven years of improper AdWords API restrictions? Let me offer three suggestions:

First, after years of improper conduct in this area, Google should expect to pay monetary damages. Google’s AdWords API restrictions inflated the prices charged to advertisers. Google should disgorge these ill-gotten gains via pro-rata refunds to advertisers.

Second, Google’s changes should be formal binding commitments formalized in a consent agreement. The 1969 Report of the American Bar Association Commission to Study the Federal Trade Commission recognized that voluntary commitments were ineffective, and the FTC largely discontinued voluntary commitments after that report. Indeed, FTC Commissioner Rosch last week noted that the FTC’s voluntary commitment approach lets Google offer a statement of its current intent, which Google could reverse or alter at any time. Moreover, an order would have required the FTC to take a clearer position on whether Google’s conduct violated the law: An order would have required the FTC to file a complaint, which in turn requires a finding by the FTC that there is reason to believe a violation has occurred. This formality would offer a useful confirmation of the FTC’s view — either the FTC believes a violation occurred, or it does not, but the voluntary commitment process lets the FTC avoid a public statement on this subject. Finally, orders are also vetted with third parties to make sure they will be effective. Microsoft’s Dave Heiner immediately offered several gaps in the FTC’s approach on AdWords API restrictions. I would have offered additional feedback had I been asked.

Finally, the FTC’s investigation surely found documents or records confirming the intent and effect of Google’s AdWords API restrictions. The FTC should at least describe those documents — if not release them in full. Describing or releasing these documents would let concerned parties determine what private claims they may have against Google. If the documents confirm meritorious claims, victims can pursue these claims through private litigation (here too, as Commissioner Rosch suggested).

Google’s AdWords API restrictions were a direct assault on competition — indefensible rules serving only to hinder advertisers’ efforts to efficiently use competing search engines, without any plausible pro-competitive justification. On this clear-cut issue, the FTC should have pursued every remedy permissible under its authority. Fortunately it’s not too late for state attorneys general and the European Commission to insist on more.

Posted on

Flash-Based Cookie-Stuffer Using Google AdSense to Claim Unearned Affiliate Commissions from Amazon with Wesley Brandi

Merchants face special challenges when operating large affiliate marketing programs: rogue affiliates can claim to refer users who would have purchased from those merchants anyway. In particular, rogue “cookie-stuffer” affiliates deposit cookies invisibly and unrequested — knowing that a portion of users will make purchases from large merchants in the subsequent days and weeks. This tactic is particularly effective in defrauding large merchants: the more popular a merchant becomes, the more users will happen to buy from that merchant within a given referral period.

To cookie-stuff at scale, an attacker needs a reliable and significant source of user traffic. In February we showed a rogue affiliate hacking forum sites to drop cookies when users merely browse forums. But that’s just one of many strategies. I previously found various cookie-stuffing on sites hoping to receive search traffic. In a 2009 complaint, eBay alleges that rogue affiliates used a banner ad network to deposit eBay affiliate cookies when users merely browsed web pages showing certain banner ads. See also my 2008 report of an affiliate using Yahoo’s Right Media ad network to deposit multiple affiliate cookies invisibly — defrauding security vendors McAfee and Symantec.

As the eBay litigation indicates, display advertising networks can be a mechanism for cookie-stuffing. Of course diligent ad networks inspect ads and refuse cookie-stuffers (among other forms of malvertising). So we were particularly surprised to see Google AdSense running ads that cookie-stuff Amazon.

The 'Review Different Headphones' ad actually drops Amazon Associates affiliate cookies.
This innocuous-looking banner ad sets Amazon Associates cookies invisibly.
The Imgwithsmiles attack

We have uncovered scores of web sites running the banner ad shown at right. On 40 sites, on various days from February 6 to May 2, our crawlers found this banner ad dropping Amazon Associates affiliate cookies automatically and invisibly. All 40 sites include display advertising from Google AdSense. Google returns a Flash ad from Imgwithsmiles. To an ordinary user, the ad looks completely innocuous — the unremarkable “review different headphones” image shown at right. However, the ad actually creates an invisible IMG (image) tag loading an Amazon Associates link and setting cookies accordingly. Here’s how:

First, the ad’s Flash code creates an invisible IMG tag (10×10 pixels) (yellow highlighting below) loading the URL http://imgwithsmiles.com/img/f/e.jpg (green).

function Stuff() {
  if (z < links.length) {
    txt.htmltext = links[z];
    z++;
    return(undefined);
  }
  clearinterval(timer);
}
links = new array();
links[0] = "<img src="http://imgwithsmiles.com/img/f/e.jpg" width="10" height="10"/>";z = 0;timer = setinterval(Stuff, 2000);

While /img/f/e.jpg features a .jpg extension consistent with a genuine image file, it is actually a redirect to an Amazon Associates link. See the three redirects preserved below (blue), including a tricky HTTPS redirect (orange) that would block many detection systems. Nonetheless, traffic ultimately ends up at Amazon with an Associates tag (red) specifying that affiliate charslibr-20 is to be paid for these referrals.

GET /img/f/e.jpg HTTP/1.0
Accept: */*
Accept-Language: en-US
Referer: http://pagead2.googlesyndication.com/pagead/imgad?id=CICAgICQvuXgahDQAhiYAjII3bQHU19r_Isx-flash-version: 10,3,183,7User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; ...)Host: imgwithsmiles.comConnection: Keep-AliveHTTP/1.1 302 Moved TemporarilyDate: Wed, 02 May 2012 19:56:59 GMTServer: Apache/2.2.21 (Unix) mod_ssl/2.2.21 OpenSSL/0.9.8e-fips-rhel5 mod_bwlimited/1.4
X-Powered-By: PHP/5.2.17
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: PHPSESSID=174272468a212dd0862eabf8d956e4e0; path=/
Location: https://imgwithsmiles.com/img/kick/f/e.jpg
Content-Length: 0
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html-


HTTPS redirect decoded via separate manual request


GET /img/kick/f/e.jpg HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Accept-Language: en-US
User-Agent: ...
Accept-Encoding: gzip, deflate
Host: imgwithsmiles.com
Connection: Keep-AliveHTTP/1.1 302 Moved Temporarily
Date: ...
Server: Apache/2.2.21 (Unix) mod_ssl/2.2.21 OpenSSL/0.9.8e-fips-rhel5 mod_bwlimited/1.4
X-Powered-By: PHP/5.2.17
Location: http://imgwithsmiles.com/img/t/f/e.jpg
Content-Length: 0
Connection: close
Content-Type: text/html-GET /img/t/f/e.jpg HTTP/1.0
Accept: */*
Accept-Language: en-US
x-flash-version: 10,3,183,7
User-Agent: Mozilla/4.0 (compatible; ...)
Connection: Keep-Alive
Host: imgwithsmiles.com
Cookie: PHPSESSID=174272468a212dd0862eabf8d956e4e0HTTP/1.1 302 Moved TemporarilyDate: Wed, 02 May 2012 19:56:59 GMT
Server: Apache/2.2.21 (Unix) mod_ssl/2.2.21 OpenSSL/0.9.8e-fips-rhel5 mod_bwlimited/1.4
X-Powered-By: PHP/5.2.17
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Location: http://www.amazon.com/gp/product/B002L3RREQ?ie=UTF8&tag=charslibr-20
Content-Length: 0
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
Content-Type: text/html

If a user happens to make a purchase from Amazon within the subsequent 24 hours, Amazon will pay a commission to this affiliate — even though the affiliate did nothing at all to cause or encourage the user to make that purchase.

Does Amazon know?

The available information does not reveal whether or not Amazon knew about this affiliate’s practices. Nor can we easily determine whether, as of the May 2, 2012 observations presented above, this affiliate was still in good standing and receiving payment for the traffic it sent to Amazon.

On one hand, Amazon is diligent and technically sophisticated. Because Amazon runs one of the web’s largest affiliate programs, Amazon is necessarily familiar with affiliate fraud. And Amazon has ample incentive to catch affiliate fraud: Every dollar paid to fraudulent affiliates is money completely wasted, coming straight from the bottom line.

On the other hand, we have observed this same affiliate cheating Amazon for three months nonstop. All told, we’ve seen this affiliate rotating through 49 different Associates IDs. If Amazon had caught the affiliate, we would have expected the affiliate to shift away from any disabled affiliate accounts, most likely by shifting traffic to new accounts. Of the 28 Associates IDs we observed during February 2012, we still saw 6 in use during May 2012 (month-to-date) — suggesting that while Amazon may be catching some of the affiliate’s traffic, Amazon probably is not catching it all.

A further indication of the affiliate’s earnings comes from the affiliate’s willingness to incur out-of-pocket costs to buy media (AdSense placements from Google) with which to deliver Amazon cookies. As best we can tell, Amazon is the affiliate’s sole source of revenue. Meanwhile, the affiliate must pay Google for the display ad inventory the affiliate receives. These direct incremental costs give the affiliate a clear incentive to cease operation if it concludes that payment from Amazon will not be forthcoming. From the affiliate’s ongoing actions we can infer that the affiliate finds this scheme profitable — that its earnings to date have exceeded its expenses to date.

How profitable is this affiliate’s attack? Conservatively, suppose 40% of users are Amazon shoppers and make an average of four purchases from Amazon per year. Then 0.4*4/365=0.44% of users are likely to make purchases from Amazon in any given 24-hour period. Suppose the affiliate buys 1,000,000 CPM impressions from Google. Then the affiliate will enjoy commission on 0.44%*1,000,000=4,384 purchases. At an average purchase size of $30 and a 6.5% commission, this would be $8,547 of revenue per million cookie-stuffing incidents. How much would the affiliate have to pay Google for 1,000,000 CPM impressions? We’ve seen this affiliate on a variety of sites, but largely sites in moderate to low-priced verticals. At $2 CPM, the affiliate’s costs would be $2,000 — meaning the affiliate would still be slightly profitable even if Amazon caught 3/4 of its affiliate IDs before the first payment!

We alerted our contact at Amazon Associates to our observations. We will update this post with any information Amazon provides.

Posted on

Earnings and Ratings at Google Answers

Edelman, Benjamin. “Earnings and Ratings at Google Answers.” Economic Inquiry 50, no. 2 (April 2012): 309-320. (draft as first circulated in 2004.)

I analyze all questions and answers from the inception of the Google Answers service through November 2003, and I find notable trends in answerer behavior: more experienced answerers provide answers with the characteristics askers most value, receiving higher ratings as a result. Answerer earnings increase in experience, consistent with learning on the job. Answerers who focus on particular question categories provide answers of higher quality but earn lower pay per hour (perhaps reflecting a lack of versatility). Answers provided during the business day receive higher payments per hour (a compensating differential for working when outside options are most attractive), but more experienced answerers tend to forego these opportunities.