The subject matter of this application is generally related to online advertising.
Interactive media (e.g., the Internet) has great potential for improving the targeting of advertisements (“ads”) to receptive audiences. For example, some websites provide information search functionality that is based on keywords entered by the user seeking information. This user query can be an indicator of the type of information of interest to the user. By comparing the user query to a list of keywords specified by an advertiser, it is possible to provide targeted ads to the user. An example of such a system is AdWords™ offered by Google, Inc. (Mountain View, Calif.).
In some online advertising systems, advertisers pay for their ads on a cost-per-click (CPC) basis. In such systems, advertisers bid for ads by entering a maximum CPC bid. Those advertisers that prefer to work with averages may find it difficult to budget for advertising when they do not know how much each click will cost.
While the actual cost paid for each click is less than this maximum CPC bid, it can vary quite a bit, depending on factors like the specific keyword being bid on, the competitive landscape of other competing bidders, the time of day or day of week, etc. Those advertisers who prefer to work with the average cost they pay per click may find it difficult to budget for advertising when they do not know how much each click will actually cost. Similar cost management issues arise in other advertising systems where advertisers bid on, for example, a maximum cost per thousand impressions (CPM) basis, and are unable to predict how much they actually spend for these impressions.
To work around this missing functionality, some advertisers check and update keyword bids manually. If the average paid CPC is too low, an advertiser can raise one or more maximum CPC bids so as to ensure higher levels of success. If the advertiser is spending too much per click, one or more of the maximum CPCs are lowered. Accordingly, account managers who manage ad accounts for large advertisers can spend much of their time micro-managing ad campaigns to meet their client's CPC targets. Smaller advertisers often turn to third party bid managers to manage their accounts.
In an online advertising system, preferred cost bidding allows advertisers to specify a preferred “average” cost target (e.g., CPC, CPM), rather than a “maximum” cost target (e.g., maximum CPC, CPM). The system attempts to bring the advertiser's overall advertising cost as close as possible to the advertiser's specified average cost, using an iterative process (e.g., a feedback loop) that updates current bids for keywords using historical performance data for the key words.
In some implementations, a current bid is automatically adjusted in an adaptive way to compensate for natural changes in fluctuations of the market using historical performance data to compute a bid that is likely to result in an average cost (per click) that is close to the advertiser's preferred average target cost (per click).
In some implementations, a current bid for a keyword is automatically adjusted (e.g., multiple times a day) by setting the current bid equal to a linear combination of the current bid and a one or more previous bids (e.g., bids from a previous time period) determined by a linear projection of historical performance data for the keyword through a (0, 0) point on a plot of cost as a function of bid.
In some implementations, a method includes: identifying input specifying a target average cost for a keyword; and automatically updating a current bid for the keyword using historical performance data for the keyword to achieve the target average cost.
In some implementations, a method includes: receiving input specifying a target average cost for a key word; and automatically adjusting a current bid for the keyword during a time window to achieve the target average cost, using a linear combination of the current bid and a previous bid for a previous time window, determined by a linear projection through an origin point on a plot of cost as a function of bid.
In some implementations, a method includes: identifying input specifying a target average cost for a keyword; and automatically adjusting a current bid for the keyword by setting the current bid equal to a convex combination of weighted past linear projections on a plot of cost as a function of the target average bid.
With preferred cost bidding, advertisers can better control their costs and thereby maximize their returns by targeting a preferred average cost, rather than a maximum CPC or CPM.
Other entities, such as users 108 and the advertisers 102, can provide usage information to the system 104, such as, for example, whether or not a conversion or click-through related to an ad has occurred. This usage information can include measured or observed user behavior related to ads that have been served. The system 104 performs financial transactions, such as crediting the publishers 106 and charging the advertisers 102 based on the usage information.
In this example, a computing network is shown that includes a network based delivery paradigm. This is only an example, other delivery or architecture paradigms are possible.
A computer network 110, such as a local area network (LAN), wide area network (WAN), the Internet, or a combination thereof, connects the advertisers 102, the system 104, the publishers 106, and the users 108.
One example of a publisher 106 is a general content server that receives requests for content (e.g., articles, discussion threads, music, video, graphics, search results, web page listings, information feeds, etc.), and retrieves the requested content in response to the request. The content server may submit a request for ads to an ad server in the system 104. The ad request may include a number of ads desired. The ad request may also include content request information. This information can include the content itself (e.g., page or other content document), a category corresponding to the content or the content request (e.g., arts, business, computers, arts-movies, arts-music, etc.), part or all of the content request, content age, content type (e.g., text, graphics, video, audio, mixed media, etc.), geo-location information, etc.
In some implementations, the content server can combine the requested content with one or more of the ads provided by the system 104. This combined content and ads can be sent to the user 108 that requested the content for presentation in a viewer (e.g., a browser or other content display system). The content server can transmit information about the ads back to the ad server, including information describing how, when, and/or where the ads are to be delivered or rendered (e.g., in HTML or JavaScript™).
As can be appreciated from the foregoing, the advertising management system 104 can serve publishers 106, such as content servers and search services. The system 104 permits serving of ads targeted to content (e.g., documents) served by content servers. For example, a network or inter-network may include an ad server serving targeted ads in response to requests from a search service with ad spots for sale. Suppose that the inter-network is the World Wide Web. The search service can be capable of crawling much or all of the content. Some of this content can include ad spots (also referred to as “inventory”) available. In one specific example, one or more content servers may include one or more documents. Documents may include web pages, email, content, embedded information (e.g., embedded media), meta-information and machine executable instructions, and ad spots available. The ads inserted into ad spots in a document can vary each time the document is served or, alternatively, can have a static association with a given document.
The disclosed implementations are not limited to targeting an average CPC or CPM for keywords. For example, in some implementations an advertiser can bid for the right to display an ad on a specific site. Also, advertisers can specify average target metrics other than CPC or CPM, such as specifying a target average return on investment (ROI), average cost per conversion/action (CPA) or any other desired metric.
In some implementations, to compute bids the historical performance data about the performance of each keyword is needed. This data can include but is not limited to: impressions, clicks, cost, bids, user-specified preferred CPC, etc. The historical performance data can be collected and stored in various places, such as a database (e.g., MySQL database), table or any other suitable data structure. For example, the historical performance data can be retrieved from logs generated by bidding processes. These log files can contain current statistical data starting when a bid is first made on a campaign. The logs can be processed on a scheduled basis (e.g., every hour) and/or in response to one or more trigger events, to extract the data and write it to a file having a structured format, for example. The file can then be accessed by the preferred cost bidding system and processes, as needed. In some implementations, data is stored for only those keywords which received at least one click.
Given the advertiser's specified preferred average cost target, an initial bid can be set. For example, if the advertiser specifies the historical average as the preferred average cost target, then the most recent maximum CPC or other metric can be used as the advertiser's initial bid. If the advertiser specifies a target that is not equal to the historical average, then the bid can be a multiple of the advertiser's preferred average cost target (e.g., 1.25 times the target value). Other schemes for specifying a preferred average cost target can be used, including combining the approaches described above.
After an initial bid is set, the bid is periodically updated to achieve the advertiser's target CPC (or other metric) for a next time period (e.g., once a day). In other implementations, an average bid can be managed over multiple time periods. In some implementations, the bid can be updated multiple times over a single accounting period (e.g., a day). This strategy helps even out fluctuations (e.g., underbidding early in the day can be corrected by overbidding later in the day). It also helps mitigate problems in markets where there is no bid that exactly achieves the target. For example, if a given bid B results in an average cost below the desired target but the bid B plus one cent results in an average cost well above the target, there is no single bid that would achieve the target exactly. However, by bidding B part of the day and B plus one cent for part of the day, the target can be hit more precisely.
In some implementations, a bid can be computed using only the initial bid and CPC for the previous x (e.g., two) time periods, where a time period can be any suitable period of time (e.g., an hour, a day, a week, etc.). Using fewer time periods allows greater adaptability to changing keyword markets. In some implementations, we define the following parameters:
Additionally, there are several cases to consider in updating a bid based on the number of clicks, Kc, Kp, for the current and previous time periods, respectively:
Regarding (Bc, Cc/Kc) and (Bp, Cp/Kp) as two data points on a plot of CPC as a function of bid, one strategy is to calculate the line intersecting those two points, and set the bid to the point on that line that achieves the desired target. It could be the case, however, that the calculated bid is either less than T, or more than Tmax, in which case the bid can be reset to T or Tmax, accordingly. It is expected that the line calculated has a non-negative slope, i.e., that CPC is a non-decreasing function of the bid. However, fluctuations in the market and differences in particular queries on which the keyword is matched may result in a negative slope. A negative slope can be handled as described above for case (ii).
A drawback to the simple linear projection strategy is that it assumes low noise in the data. It may be that using these two points to project could lead to erratic behavior. To stabilize the calculation, in one implementation the point (0,0), i.e., an origin point, can be included in the linear projection calculation. For example, both points can be projected with origin (0,0) and the average of the two resulting bids can be taken. More specifically, we let B1=T Bc Kc/Cc, and let B2=T Bp Kp/Cp, then set the bid equal to the average of B1 and B2. In another implementation, we take the average of the two points, then project with (0,0) to calculate the bid. More specifically, we set B=(Bc+Bp)/2, and set P=(Cc/Kc+Cp/Kp)/2. Then the bid can be set equal to T B/P.
Although perhaps more stable then simple linear projection, using a linear projection to (0,0) could also suffer from noise. To address the noise, in some implementations the bid can be set equal to a linear combination of the current bid and the bid calculated from the projection with (0,0). Note that with this strategy, we do not use case (ii) described above.
More specifically, we calculate B′=(T Bc Kc/Cc), and we set the bid equal to (1−p) Bc+p B′, where p is a number between 0 and 1. The variable, p, controls how much we weight the current data relative to the data from the past. Note that if Kc=0 (i.e., there are no clicks), then we still use case (i) above, and so effectively B′=Bc.
In general, the current bid will be a convex combination of the projections from the past, where the weight on a projection decreases geometrically as you go into the past. More specifically, if Bi is the ith bid we make, and Ci and Ki are the cost and clicks that result from that bid, then let Ji=(T Bi Ki/Ci) be the bid calculated from the projection. For the first bid, we have no history, so we can have J1=(3/2)T, which can be an arbitrary value. This value can be set using the initial bid options described above. Also, if at any point we have Ki=0 (i.e., we have no clicks) then Ji=Bi-1 and, Bi will have the property:
B
i
=p J
i-1
+p(1−p)Ji-2+p(1−p)2Ji-3+ . . . +p(1−p)i-3J2+(1−p)i-2 J1,
where p can be around ⅓ or any other suitable value.
Using this third strategy, updates to the bid can be made once every 24 hours, for example.
In some implementations, a multi-period technique maintains two bids, B_lo and B_hi, such that B_lo<B_hi. In the past, bidding B_lo yielded an average cost of Cpc_lo<Cpc_target, and bidding B_hi yielded an average cost of Cpc_hi>=Cpc_target. If B_hi−B_lo> minimum billable unit (mbu) (e.g., 1 cent), the process is in a search phase. In the search phase, the process tries to reduce the interval of uncertainty by setting the bid B somewhere between B_lo and B_hi. If B_hi−B_lo=mbu, the process enters a stable phase when it bids either B_lo or B_hi, depending on whether the average over the past x hours (e.g., 24 hours) was above or below the target. In an ideal static market, the process would stay in the stable phase forever. However, since the market conditions do change, the process has a way to invalidate the bracket bids and restart the search.
Depending on the available data, the process can do one of the following:
In the processes described above, each data point corresponds to a “bidding period,” and includes data such as the time of the beginning and end of the bidding period, the bid that was active during the bidding period, as well as the number of clicks, impressions and cost accrued over the bidding period. The average cost (e.g., CPC) over a bidding period is equal to the cost divided by the number of clicks.
In general, each bidding period corresponds to a time interval between two bid updates. However, some intervals may not contain enough data to reliably compute CPC (in particular, if the number of clicks in a bidding period is zero, the CPC is undefined). In this case, we can aggregate multiple consecutive update intervals into a single bidding period. We only aggregate intervals over which the bid remained unchanged.
In some implementations, we let p_lo be the most recent bidding period in which the average CPC was below Cpc_target. Let B_lo be our bid in that period, and Cpc_lo be the average CPC in that period. The bid B_lo is deemed valid, if there is no later period p′ in which we bid B′<=B_lo and Cpc′, the average Cpc cost per click in that period is greater than Cpc_target.
Similarly, we can define B_hi and Cpc_hi. Let p_hi be the most recent bidding period in which the average CPC was greater or equal to Cpc_target. Let B_hi be our bid in that period, and Cpc_hi be the average Cpc in that period. The bid B_hi is deemed valid, if there is no later period p′ in which we bid B′>=B_hi and Cpc′, the average Cpc cost per click in that period is less than Cpc_target.
Note that either B_lo or B_hi can be invalid, but as long as we have at least one data point, one of them can be defined and valid. In case that only one of these two points is valid, we can use it as the sole data point.
The processes described above for preferred cost bidding can be used to manage the average cost in metrics other than CPC. For example, instead of targeting a certain CPC, we can target CPM, cost per action (CPA), average conversion value, etc.
In some implementations, the various processes described above can be selected based on fitness formula that minimizes the click-weighted average distance to target, which can be calculated for each keyword as follows:
where Tgt. is the target cost (e.g., the advertiser's preferred CPC for a keyword), Actual (i) is the average cost on day i, and Clicks(i) is the number of clicks on day i. This formula can be generalized to a group of keywords.
In some implementations, advertisers 516 interact with the automated bid manager 502 through one or more user interfaces in Web pages provided by the Web server 504.
In some implementations, the historical performance data can be provided by the ad server 506, which serves ads to, for example, a Web site or other Web property operated by a publisher 514. The ad server 506 can perform various ad targeting processes (e.g., based on keywords, ad context, user profiles, location, etc.) for selecting ads from the ad repository 510 for presentation to users 518. In some implementations, the ad server 506 combines ads with content (e.g., video, audio, digital photos), then serves the content and ads to users 518.
The one or more processors 610 may execute machine-executable instructions (e.g., C or C++, Java, etc., running on the Solaris operating system available from Sun Microsystems Inc. of Palo Alto, Calif. or the Linux operating system widely available from a number of vendors such as Red Hat, Inc. of Durham, N.C.) to perform one or more aspects of the present invention. At least a portion of the machine executable instructions may be stored (temporarily or more permanently) on the one or more storage devices 620 and/or may be received from an external source via one or more input interface units 630.
In one embodiment, the system 600 may be one or more conventional personal computers. In this case, the processing units 610 may be one or more microprocessors. The bus 640 may include a system bus. The storage devices 620 may include system memory, such as read only memory (ROM) and/or random access memory (RAM). The storage devices 620 may also include a hard disk drive for reading from and writing to a hard disk, a magnetic disk drive for reading from or writing to a (e.g., removable) magnetic disk, and an optical disk drive for reading from or writing to a removable (magneto-) optical disk such as a compact disk or other (magneto-) optical media.
A user may enter commands and information into the personal computer through input devices 632, such as a keyboard and pointing device (e.g., a mouse) for example. Other input devices such as a microphone, a joystick, a game pad, a satellite dish, a scanner, or the like, may also (or alternatively) be included. These and other input devices are often connected to the processing unit(s) 610 through an appropriate interface 630 coupled to the system bus 640. The output devices 634 may include a monitor or other type of display device, which may also be connected to the system bus 640 via an appropriate interface. In addition to (or instead of) the monitor, the personal computer may include other output devices (not shown), such as speakers and printers for example.
The various operations described above may be performed by one or more systems 600, and the various information described above may be stored on one or more systems 600.
The disclosed embodiments can be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a web browser through which a user can interact with an implementation of what is disclosed here, or any combination of one or more such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), e.g., the Internet.
The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
While this specification contains many specifics, these should not be construed as limitations on the scope of what being claims or of what may be claimed, but rather as descriptions of features specific to particular embodiments. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub-combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or variation of a sub-combination.
Similarly, while operations are depicted in the drawings in a particular order, this should not be understand as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.
A number of embodiments of the invention have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention.
The subject matter of this patent application is generally related to U.S. patent application Ser. No. 11/172,614, for “Determining And/Or Managing Offers Such As Bids For Advertising,” filed Jun. 30, 2005, Attorney Docket No. GP-372-00-US, which patent application is incorporated by reference herein in its entirety.