Towards a Bill of Rights for Online Advertisers

Edelman, Benjamin. “Towards a Bill of Rights for Online Advertisers.” Advertising Week (September 21, 2009).

Online advertising presents remarkable efficiencies–better targeting, improved measurement and greater return on investment. Yet there are challenges, particularly when networks of intermediaries place ads through convoluted relationships, and all the more so when small advertisers cannot effectively negotiate terms dictated by advertising powerhouses. The result is a troubling mess of ads gone wrong–advertisers charged in ways they didn’t fairly agree to, and on terms they didn’t meaningfully accept. But online advertising doesn’t have to be a wild west. I propose five specific rights advertisers should demand as they buy online placements.

Advertising Week abridgement extracted from full original article:

Towards a Bill of Rights for Online Advertisers

PPC Platform Competition and Google’s "May Not Copy" Restriction

By all indications, Google AdWords features far more advertisers than competing PPC platforms such as Yahoo Search Marketing and Microsoft adCenter. (Consider: Search for “thinkpad x60 power supply” at Google, and there are six relevant ads from vendors who actually sell that product. Search at Yahoo Search or Microsoft Live Search, and there are various ads from indexers and aggregators, but only one or two from vendors directly selling the product. Other searches for offbeat, unusual or region-specific keywords show similar patterns.)

Why do more advertisers choose Google? Because more users search at Google, Google can offer wider ad distribution than any single competitor. So if an advertiser had to choose just one ad platform, Google would be the natural choice.

But in principle advertisers can easily use multiple ad platforms. Ads are trivially small plaintext data, and In principle ads can be copied from platform to platform without restriction. So why don’t more Google advertisers use Yahoo, adCenter, and others too?

One possible answer comes from a little-noticed Google AdWords API Terms & Conditions restriction which substantially hinders advertisers’ efforts to use multiple providers — exactly prohibiting software vendors from helping advertisers copy AdWords campaigns to competing platforms. In this article, I identify the restriction at issue, analyze its effects on advertisers and competing ad platforms, critique response from Google, and compare this restriction with Google’s commitment to “data portability” in other contexts.

The Restriction at Issue

To use the Google AdWords API, a software developer must accept Google’s AdWords API Terms & Conditions. The T&C’s include the following requirement:

“Any information collected from an input field used to collect AdWords API Campaign Management Data may be used only to manage and report on AdWords accounts. Similarly, any information or data used as AdWords API Campaign Management Data must have been collected from an input field used only to collect AdWords API Campaign Management Data. For example, the AdWords API Client may not offer a functionality that copies data from a non-AdWords account into an AdWords account or from an AdWords account to a non-AdWords account.” (emphasis added)

Sure enough, searching the web for commercial tools to synchronize PPC campaigns or to export data from Google to competing platforms, I found none.

The “May Not … Cop[y] Data” Prohibition: Effect on Advertisers

The quoted restriction prevents advertisers from easily exporting ads from Google to a competing paid search provider. Consider: The essence of an export procedure is to copy data from an AdWords account to a non-AdWords account — exactly what the restriction prohibits.

Indeed, available export procedures are strikingly complex. For example, to import a Google AdWords campaign into Microsoft adCenter, Microsoft offers a 17-step procedure (with some steps made more complicated by the presence of multiple sub-steps).

Microsoft’s procedure is necessarily convoluted because Google’s “may not … cop[y]” restriction prevents Microsoft, or any other vendor, from writing a tool that connects to the Google API, downloads an advertiser’s ads, and uploads those ads directly to, e.g., Microsoft adCenter. Instead, advertisers must download data manually, reformat it to match adCenter’s requirements, and upload it to Microsoft — just as Microsoft’s lengthy procedure specifies.

For many advertisers, Google’s restrictions on data export impose an ongoing burden even beyond the advertiser’s initial signup with a competing PPC provider. Consider an advertiser that changes its ads or keywords often — perhaps selling seasonal merchandise, or experimenting with alternative advertising strategies. Such an advertiser would typically prefer to make changes in one place, and have the changes automatically propagate to all the advertiser’s PPC platforms. If Google remains the advertiser’s primary PPC provider, the advertiser would probably want to make changes in Google’s interface, then have other PPC platforms optionally automatically copy those changes. But Google’s “may not … cop[y]” restriction applies equally to ongoing resynchronizations. If an advertiser made daily changes to its Google campaigns, it would have to daily repeat the manual export/import process — a task that would be both time-consuming and prone to error.

In short, the net effect of the quoted restriction is to reinforce the tendency of small to medium-sized advertisers to “single-home” — to use only Google AdWords, to the exclusion of competing platforms.

At their peril do advertisers rely solely on Google: If advertisers get stuck using only Google, for lack of any easy and efficient way to buy some traffic elsewhere, Google can charge prices higher than competing platforms. Of course Google can’t raise prices infinitely; at some point, advertisers would overcome the lock-in, accept manual export, and copy ads to competitors. But Google’s “may not copy” restriction increases the costs of multi-homing — letting Google charge that much more than competitors, without advertisers facing compelling incentives to look elsewhere.

The “May Not … Cop[y] Data” Prohibition: Effect on Competing Ad Platforms, on Publishers, and on Users

By encouraging small to medium-sized advertisers to advertise only with Google AdWords, Google’s API restriction reduces the number of advertisers using competing ad platforms. This harms competing platforms in two distinct ways. First, it reduces competitors’ coverage — preventing competitors from featuring relevant ads that pertain to obscure user searches. (Consider the power supply example from the first paragraph of this piece — better and more useful ads at Google.) With fewer relevant ads, the competing platform offers users an inferior service — inviting users to look elsewhere, and reducing the likelihood of a paid click that would earn the platform an advertising fee.

Second, by reducing the number of advertisers bidding for advertising positions at other platforms, the quoted provision dramatically reduces revenue at those platforms. My December 2006 Optimal Auction Design in a Multi-unit Environment estimates the revenue benefits of additional advertisers based on publicly-available data and estimates of market fundamentals. The intuition is straightforward: When many advertisers seek positions for a given search term, they must bid higher to avoid being outbid and receiving inferior listing position. Conversely, when only a few advertisers seek positions, prices can be strikingly low since even a low bid earns a prominent position.

Google’s API restriction also reduces the value of advertising inventory held by third-party publishers. Consider a publisher seeking to sell its sponsored search or other text ad inventory to a provider of sponsored search services. In general, Google can afford to pay more because Google’s revenue per search is higher than competitors’. But how much will Google offer? Google maximizes profits by narrowly outbidding competitors; anything higher is waste. So the weaker competitors become, the lower Google can bid — and the less revenue publishers receive for the traffic they sell. Google’s “may not copy” API restriction serves a role in weakening competing platforms — keeping advertisers using Google alone, and hence reducing competing ad platforms’ ability to pay for publishers’ inventory.

End users also suffer from Google’s restriction on copying ads. Were it not for Google’s restriction, more advertisers would sign up to use competing ad platforms — increasing the usefulness of Yahoo Search and Microsoft Live Search for the users who choose those services.

Google’s Response

I forwarded these concerns to Google in March, and I managed to get in touch with Doug Raymond, product manager for AdWords API. Doug offered three rationales for the restriction. The list below summarizes his arguments (black) and my responses (blue).

  • Google: The quoted provision only applies to third-party developers. Individual advertisers remain free to write software that exports their Google campaigns.
    • Small to medium-sized advertisers don’t want to be developers. Rather, they want to use code that others write. That’s exactly why the AdWords API offers a concept of developers, rather than requiring that every advertiser write its own code.
    • As a leading provider of centralized computing services, as distinguished from small programs individual users build themselves, Google well knows the benefits of rigorous design by competent professionals.
  • Google: Advertisers can extract their data in other ways, e.g. a comma-separated-value (CSV) file.
    • Manual export is convoluted, slow, and error-prone. API-based access would be faster, easier, and more reliable.
    • The existence of an inferior alternative does not justify imposing restrictions that prohibit superior implementations.
    • In other contexts (detailed below), Google has made strong requests for, and commitments to, data portability.
    • In other contexts, Google emphasizes the benefits of streamlined, automated data transfer — never viewing convoluted manual procedures as an acceptable alternative.
  • Google: Third-party developers ought not have free access to advertiser data.
    • Google’s AdWords API already offers an appropriate security model to limit developers to serving those AdWords advertisers that have specifically granted such permission. In short, a developer needs a password to access an advertiser’s account.

Google’s Position on Data Portability in Other Contexts

Google’s prohibition on AdWords API data export stands in sharp contrast to Google’s position on data portability in other contexts. Indeed, Google has previously taken a firm position in favor of data portability. Some specific examples: In a November 2006 interview at the Web 2.0 Summit, Schmidt specifically promised that “We [Google] would never trap user data.” Schmidt added that “If users can switch it keeps us honest.” Just last month, Google CEO Eric Schmidt called for open access to (and indexing of) social network data — telling IBM’s Business Partner Leadership Conference “People should be able to move from place to place, and their data is available everywhere” and “open is best for the consumer.” Well-known Google blogger Matt Cutts summarized Google’s commitment to data openness with the catchy title “Not trapping users’ data = GOOD” and a long list of Google products that support data export.

I credit that Schmidt’s statements refer to other kinds of data — search engines’ records of users’ search history, and a wide assortment of data held by social networks. But the same principles plainly apply to access to search ads: Just as consumers benefit from being able to move their data as they see fit, so too do advertisers benefit from flexibility.

Moreover, it strains credibility for Google to ask social networks to share their data with Google, while Google simultaneously imposes contractual roadblocks preventing others from accessing Google data.

Next Steps and Google’s Other Restrictions

Google already faces antitrust scrutiny for its striking growth and market share. In that context, it’s particularly hard to defend the restriction at issue — a barrier to competition, without any apparent pro-competitive purpose. Regulators might reasonably require that Google remove the quoted provision — letting third-party developers export and synchronize AdWords data if advertisers so desire. This would be a trivially straightforward requirement — just a sentence to be stricken from Google’s AdWords API T&C’s. Because Google’s existing APIs already provide the required data, Google would not need to add any new code or any new API functions.

Other AdWords API restrictions also deserve scrutiny. For example, Google insists that advertising tools collect AdWords instructions through separate fields not used for other ad platforms — blocking simplification via a single interface to streamline advertisers’ decisions. Google prohibits advertising tools from storing Google data in a single relational database along with data for other ad platforms — increasing the complexity of designing a system to manage campaigns on multiple platforms. And Google prohibits reports that compare Google ad performance data (e.g. costs and profits from advertising at Google) with data from other ad platforms — hindering advertisers’ efforts to evaluate competitors’ offerings. I gather Google defends these restrictions on the grounds that they purportedly prevent advertiser confusion. Perhaps — but their more obvious effect is to increase the costs and complexity of using competing ad platforms. Perhaps I’ll consider these restrictions in greater detail in a future article.

Meanwhile, I’m struck by Google’s calls for data portability in other contexts. With Google’s ongoing request that other companies provide data to Google, perhaps Google will return the favor by abandoning its “may not copy” restriction — ideally promptly and unilaterally, without requiring that regulators force Google’s hand.

Microsoft adCenter (teaching materials) with Peter Coles

Coles, Peter, and Benjamin Edelman. “Microsoft adCenter.” Harvard Business School Case 908-049, January 2008. (Revised February 2010.) (educator access at HBP. request a courtesy copy.)

Microsoft considers alternatives to expand its presence in online advertising, especially text-based pay-per-click advertising. Google dominates, and it is unclear how Microsoft can grow, despite considerable technical and financial resources. Microsoft considers a set of alternatives, each with clear benefits but also serious challenges.

Teaching Materials:

Microsoft adCenter (Teaching Note) – HBP 908062

Direct Revenue Deletes Competitors from Users’ Disks updated February 8, 2005

For companies making programs that show users extra pop-up ads, one persistent problem is that users are bound to take action once their computers get too clogged with unwanted software. Find a removal tool, hire a technician, reinstall Windows, buy a new computer, or just stop using the Internet — whatever users do, the pop-up companies won’t make any more money if users don’t keep surfing, and don’t keep clicking the ads. The problem is all the worse because so many unwanted programs install others (usually in exchange for a per-install commission). So if a user has one program showing extra pop-ups, the user might soon have five more.

What’s an “adware” company to do? Direct Revenue has one idea: Delete its competitors’ programs from users’ hard disks. With the other programs gone, users’ computers will run more or less as usual — showing some extra ads from Direct Revenue, but perhaps not attracting so much attention that users take steps to remove all unwanted software.

Direct Revenue’s End User License Agreement provides, in relevant part:

“[Y]ou further understand and agree, by installing the Software, that BetterInternet and/or the Software may, without any further prior notice to you, remove, disable or render inoperative other adware programs resident on your computer …”

In my recent testing, I’ve observed the removals Direct Revenue’s EULA seems to anticipate. And I’m not the only one: I’ve just received a copy of a lawsuit filed by Avenue Media, complaining that Direct Revenue is “systematically deleting Avenue Media’s Internet Optimizer without users’ knowledge or consent.” Indeed, in my November 17 testing, I found that software installed on my PC by ABetterInternet (a product name used by Direct Revenue) received the following instructions from its targeting server, calling for the removal of Avenue Media’s Internet Optimizer:

request for instructions from server

POST /bi/servlet/ThinstallPre HTTP/1.1

Host: thinstall.abetterinternet.com

begin response from server

excerpted to show only removal
code targeting Internet Optimizer

HTTP/1.1 200 OK
Date: Wed, 17 Nov 2004 15:31:00 GMT
Server: Apache/2.0.46 (Red Hat)
Content-Length: 3881
Connection: close
Content-Type: text/xml

list of running processes to stop (“kill”)

<install><action type=”KillProc”>
<proc exe=”optimize.exe” />
</action>

start of an “.INF” file
(in usual Windows .INF format)


<action type=”installINF”>
<inf section=”DefaultInstall”>

[DefaultInstall] …
DelReg=RegistryEntries
DelFiles=ProgFiles,systemFiles

registry entries to be removed


[RegistryEntries] …
HKLM,SOFTWARE\Microsoft\Windows\CurrentVersion\Run,”Internet Optimizer”

files on disk to be removed

[ProgFiles]
Internet Optimizeractalert.exe,,,1
Internet Optimizeroptimize.exe,,,1
Internet Optimizerupdateactalert.exe,,,1

In my testing, Direct Revenue’s software acts on these instructions — stopping the optimize.exe task (Internet Optimizer’s main program), then deleting the associated registry entries and program files. So I think Avenue Media is correct as to the basic facts of what’s happening. Conveniently, in tests beginning on November 17, I even made videos showing Internet Optimizer’s software being deleted — files eerily disappearing as Direct Revenue’s software deleted Internet Optimizer along with other targeted programs.

How do I happen to have records, logs, and even videos of events occurring several weeks ago? As it turns out, both Internet Optimizer and Direct Revenue were unwanted additions to my test PC: Both were installed through security holes, much like the installations I documented in my Who Profits from Security Holes? write-up and video last month. I’ve been making more such videos — roughly one a day for the past few weeks. So I’ve repeatedly seen Direct Revenue removing Internet Optimizer.

In my security-hole videos, I never saw nor accepted any Direct Revenue license. So, at least as to me, Direct Revenue cannot convincingly cite its EULA to defend its removal of Internet Optimizer. (See also my recent analysis of Gator’s EULA.) However, my test PC became noticeably faster after Direct Revenue removed other unwanted programs that had been installed through security holes. So, for some consumers, Direct Revenue’s removal of competitors’ programs may offer a useful if surprising benefit. (Compare: Radlight removing Ad-Aware, without any apparent benefit to consumers.)

Case documents: Avenue Media v. Direct Revenue

As promised: Internet Optimizer’s case documents, alleging claims under the Computer Fraud and Abuse Act as well as for tortious interference with economic relations:

Complaint: Avenue Media, N.V. v. Direct Revenue LLC, BetterInternet LLC (PDF)
Memorandum in Support of Temporary Restraining Order (PDF)
Declaration of Moses Leslie (PDF)
Response by Direct Revenue (PDF) and supporting declaration of Joshua Abram (PDF)

Avenue may be suffering from wrongful behavior by Direct Revenue, but note that Avenue has problems of its own. In my tests, Avenue’s software (like Direct Revenue’s) was installed without any notice or consent whatsoever. (Again, I have video proof.) However installed, Internet Optimizer’s primary function is to show extra advertising, primarily by replacing web browser error messages with its own ads — not a feature most users request. In addition, Internet Optimizer’s EULA admits to tracking web sites visited and keywords searched. Finally, Doxdesk reports that Internet Optimizer has (or recently had) security holes that risk unauthorized installation of other software.

Update (February 8, 2005): Avenue Media and Direct Revenue have reportedly reached a settlement. No money will change hands, but the companies have agreed to no longer disable each other’s software.

More on Direct Revenue

Removing competitors’ programs is not Direct Revenue’s only controversial activity. Direct Revenue’s core business is showing extra pop-up ads. Which ads? Covering which sites? Early next year, I expect to release a report detailing some of the advertisers supporting Direct Revenue, and showing some ads Direct Revenue targets at certain web sites. Advance access available by request.

I also plan to present the sensitive information sent by Direct Revenue to its servers. In recent testing, I’ve seen Direct Revenue collect each user’s ethernet address or “MAC address” — a unique identifier permanently associated with each network card (i.e. with each computer). Direct Revenue also transmits users’ Windows product IDs — of particular interest due to their use in Microsoft’s product activation system.

I have recently observed that Direct Revenue tracks the .EXE names of all running tasks, specifically checking for installations of certain competing programs (including Gator and 180solutions) and for certain spyware-removal programs (including Ad-Aware and PestPatrol). Direct Revenue checks for these programs in the same way it checks for Internet Optimizer — suggesting that Direct Revenue might also target some or all of these programs for automatic deletion, just as it automatically deleted Internet Optimizer in the log shown above. That hypothesis is more than speculative: My November videos and packet logs show Direct Revenue deleting not just Internet Optimizer but also ActAlert/DyFuCa, EliteToolbar, and others.

Finally, note that Direct Revenue recently received $20 million of funding from Insight Venture Capital Partners, as well as $6.7 million from Technology Investment Capital Corp (TICC).