Patent Application
20110035259
1. Technical Field
The disclosed embodiments relate to the field of advertising systems, and more particularly, to a modeling system and methods that evaluate and ensure cost-based viability of a real-time, auction-based advertising system with third-party integration.
2. Related Art
Electronic exchanges, including online auctions, have proliferated along with the Internet. These electronic exchanges aim to provide a high degree of trading efficiency by bringing together a large number of buyers and sellers. Such exchanges are typically focused on directly matching the bids and offers of buyers and sellers. Conventional transactions on these exchanges are typically between (i) buyers and sellers, (ii) intermediaries (e.g., brokers, which may be buyers or sellers), or (iii) buyers or sellers and their intermediaries.
The proliferation of Internet activity has also generated tremendous growth for advertising on the Internet. Typically, advertisers (e.g., buyers of advertisement (“ad”) space) and online publishers (sellers of ad space) have agreements with one or more advertising networks (ad networks), which serve a banner or ad of an advertiser across multiple publishers, and concomitantly provide each publisher access to a large number of advertisers. Ad networks, which may also manage payment and reporting, might also attempt to target certain Internet users with particular advertisements to increase the likelihood that the user will take an action with respect to the ad. From the perspective of the advertiser, effective targeting leads to a higher return on investment (ROI).
Online advertising markets exhibit undesirable inefficiencies when buyers and sellers are unable to transact. For instance, although a publisher may subscribe to many ad networks, and one or more of those ad networks may transact inventory with other ad networks, only one of the ad networks to which the publisher is subscribed may be involved in selling (e.g., auctioning) a given ad space for the publisher. The publisher, or a gatekeeper used by the publisher, selects or prioritizes which ad network or advertiser having a direct agreement with the publisher serves the impression for a given ad request.
Fluctuation in amounts paid for bids on ad queries (or “ad calls”) is also inherent in the online advertising markets as supply of advertising inventory space on publisher Web sites changes along with advertiser demand for that inventory. Accordingly, if the amount paid by all advertisers can be averaged and trends can be tracked to predict future revenue, it would also be helpful to track the cost-based viability of a real-time, auction-based advertising system that includes such fluctuations when considering projected revenue in light of projected costs.
The system and method may be better understood with reference to the following drawings and description. Non-limiting and non-exhaustive embodiments are described with reference to the following drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the present disclosure. In the drawings, like-referenced numerals designate corresponding parts throughout the different views.
By way of introduction, disclosed below is a modeling system and methods that evaluate and ensure cost-based viability of a real-time, auction-based advertising system with third-party integration. Using an exchange user interface of the system, a third-party network sets up an advertiser entity and an associated advertisement and desired targeting constraints. Accordingly, the system will also be referred to as an exchange system. A traffic cache file is created and read by an ad server (or exchange server) to represent the exchange data model. An exchange entity or company owns the exchange server.
Third-party integration of the system allows independent, non-exchange networks or advertisers to bid statically on inventory of publishers while third-party, exchange participants engage in bidding dynamically, in real time. When an ad query (or “ad call”) is generated in response to a user impression on a publisher Web page, the ad server computes all valid paths from the publisher to the third-party entities participating in the exchange data model. The ad server then generates requests for bids that are sent out to qualifying third-party entities, which can include one or more third-party networks. The system subsequently receives bids for filling that impression with an ad from the third-party entities—dynamically from exchange participants and statically from non-exchange participants—and determines a winner based on various business rules and targeting constraints, such as demographic and geographic restrictions. Ultimately, the system delivers the ad from the winning bidder to the Web page to fulfill the ad query, thus giving the user a chance to view and take action with respect to the delivered advertisement.
Because the auction-based advertising system joins together large numbers of publishers and advertisers, a significant amount of computer hardware is needed to run the exchange system in real time. This includes the servers and network components, such as routers, switches, etc., as discussed in detail below. Of course, operational costs, including maintenance expenses, are associated with this computer hardware. Furthermore, bandwidth costs are associated with receiving ad queries, passing on bid requests, receiving bids, and ultimately delivering advertisements. These bandwidth costs vary depending on whether packets of ad queries and bids, etc., are passed within a co-location facility (or data center or server farm), or are passed outside that facility across integrator networks and to third-party entities. Accordingly, aggregating all valid paths throughout the networked exchange system creates a non-linear problem that is more easily solved by analyzing portions of the valid paths separately, and then averaging latencies together.
In order to be viable as a real-time, auction-based advertising system, the backbone of the system hardware needs to support demands placed there. As discussed above, these demands fluctuate with advertising inventory supply and advertiser demand within the advertising marketplace. Accordingly, the present disclosure proposes a modeling system and methods to track a plurality of costs such as those mentioned above, and after amortization of those costs over a predetermined period of time, to compare them with trending revenue obtained from periodic advertiser fees. The modeling system may then recommend as-needed updates to the periodic advertiser fees, to ensure that the auction-based advertising exchange remains viable. The modeling system may also recommend when to add to computer hardware, such as adding servers, routers, switches, etc., to keep pace with growing demands placed on the exchange system and integrate the amortized costs of the additional hardware into the viability analysis.
The embodiments of the advertising system are described using a number of terms. In order to aid in clarity, some definitions of the terms used to describe these embodiments follow. However, these terms define general concepts, and are not to be construed narrowly. A publisher is a Web site that has inventory for the delivery of advertisements. As such, advertisements are displayed on the Web pages of the publisher's Web site. Users are generally those individuals who access Web pages through use of a browser. However, the term “user” may also be applied to describe entities that use the advertising exchange system, such as users that access an application on the advertising exchange system to set parameters. Various participants of the advertising exchange system are referred to as “entities.” Thus, the term “entity” is generally used to describe any number of participants of the advertising exchange system. Those participants include advertisers, publishers, advertising networks, and integrator networks.
An advertising network typically integrates entities, such as advertisers and publishers. An advertising network typically operates in conjunction with advertisers and publishers in order to deliver ads from one or more advertisers to Web pages of one or more publishers. For example, Yahoo! Inc, the assignee of the present application, operates such an advertising network.
An integrator network entity is a participant of the advertising exchange system that represents or integrates one or more entities on the advertising exchange system (e.g., advertisers, publishers, advertising networks, etc.). For example, an integrator network may represent advertisers on the advertising exchange system in order to deliver advertisements to publishers, advertising networks, and other integrator networks. In some embodiments, the integrator networks are referred to as the “users” of the advertising exchange system. The integrated networks may include third-party agents who operate on behalf of or are part of the integrator network. The term “third-party agent” is used to generally describe an agent or customer who participates in transactions on the advertising exchange system. Similarly, the term “third-party recipient” is used to describe a user or participant of the advertising exchange system who receives information from the system, such as bid requests. However, the terms “integrator networks,” “third-party agents,” and “third-party recipients” are intended to represent a broad class of entities, e.g., “third-party entities,” including publishers, advertisers, and networks, as well as the agents who represent them, all of which operate on the advertising exchange system.
One of ordinary skill will also recognize certain abbreviations such as cost per impression, Cost Per Mille or cost per 1,000 impressions (CPM), cost per click (CPC), cost per acquisition (CPA), and effective CPM (eCPM).
The user 103 accesses information and/or content provided by the publisher 104. One form of access may include a browser 105 that has inventory locations 107 for the presentation of advertising. In one embodiment, an ad query is generated that requests an advertisement, from advertisements 112, 121 and 125, for placement with the inventory location 107. The corresponding advertisement may be delivered to publisher 104 by one or more networks. In one example, the network 106 is coupled with the publisher 104, and the network 108 is coupled with the advertiser 110. For this example, the networks 106 and 108 are coupled with each other. Herein, the phrase “coupled with” is defined to mean directly connected to or indirectly connected through one or more intermediate components. Such intermediate components may include both hardware and software-based components. The advertiser 110 generally has one or more ad campaigns, each including one or more advertisements 112 that the advertiser 110 wishes to place with the inventory of publishers such as the inventory location 107 of the publisher 104, which is presented to the user 103 via the browser application 105.
For the example illustrated in
Alternatively, or in conjunction with the embodiments described above, some embodiments direct an ad query for the inventory 107 to an integrator network 118. In one example, the ad query is passed from the network 106 to the integrator network 118 with additional information, such as a geographic location for the destination of the advertisement. In the illustration of
Any number of third-party agents or entities may participate in the advertising exchange system 300. As described above, a third-party agent may include an integrator network, an advertiser, or other network. To conduct an auction, the advertising exchange 316 submits requests for bids to third-party agents who qualify to deliver the ad to the inventory location 307. In one embodiment, the eligibility is determined based on one or more business rules, specified by the publisher, a network, or the advertiser. In response, the third-party agents (318, 326, and 330) respond by generating a bid for the advertising opportunity, or alternatively, generate no bid for the opportunity. The advertising exchange collects the bids and selects a bid to “win” the auction, based on one or more predetermined criteria. An advertisement creative, corresponding to the auction winner, is then delivered to the user browser 305 for display in the inventory space 307.
The system 300 may also include a modeling server 310, which can be any computer with sufficient processing power and coupled with the advertising exchange 316, to compute valid paths through the system 300 and to estimate a plurality of server and network costs, amortized over a predetermined period of time. That a path is valid means that the end points are coupled together through one or more properly functioning network or server components. The amortization period, as an example, is commonly chosen to be three years. The costs are determined according to a number of average queries per second (QPS) transmitted at different portions of the valid paths, which will be discussed in more detail below, as the potential complexities of those valid paths are explained with reference to various embodiments. The modeling server 310 may also compare current periodic fees paid by third-party entities, which influences advertising revenue, with the amortized costs to determine cost-based system viability. The modeling server 310 may also update, as needed, the periodic fees based on the amortized costs, to maintain cost-based system viability. One of ordinary skill will appreciate that the modeling server (or computer) 310 may be integrated within the advertising exchange 316 in terms of hardware and/or software such that their respective functionalities are shared.
For this embodiment, the networking hardware 412 is coupled with both the advertising exchange 432 and the bid gateway 444, and may include routers, switches, hubs, or other types of networking hardware to pass network packets between the advertising exchange 432 and the bid gateway 444. The advertising exchange 432 includes several modules that provide a variety of functionalities such as an eligibility module 434, an integrator module 436, an auction module 438, and a bid gateway (BG) client module 440.
The eligibility module 434 determines which entities, including integrator networks and/or integrated entities, are eligible to respond to a particular ad query or to receive a request for an ad bid. The determination may be based on targeting information regarding, for instance, the user, the inventory, the browser, and/or the publisher, which are the destination of the requested advertisement. The eligibility module 434 preferably receives targeting, bidding, and eligibility information from the ad query 430, and passes information regarding the entities eligible to bid for the placement of advertising in response to the ad query 430. Some additional criteria for eligibility that may be used by the eligibility module 434 include knowledge regarding which entities (e.g., integrator networks) are enabled to receive a certain volume of bid requests for a certain period of time, and that have not reached their maximum quota of bid requests for the time period, or that have advertisements directed toward certain user segments, for example, of which the particular targeted user is a member of such user segments.
Once eligible entities are determined for bidding, the integrator module 436 communicates the information to the bid gateway 444. As explained more fully below, the bid gateway generates one or more ad bid requests for each eligible entity, such as the third-party agents 418, 446, 448. In one embodiment, the integrator module 436 uses a client-server approach, such as via the bid gateway client module 440 and a bid gateway server module 442, to communicate with the bid gateway 444. Of course, these communication paths may be further facilitated by the networking hardware 412 coupled between the advertising exchange 432 and the bid gateway 444.
The bid gateway 444 further transmits the generated ad bid requests to the appropriate entity or entities such as one or more of the third-party agents 418, 446, 448, and waits for responses to the bid requests. Preferably, the bid gateway 444 waits for only a predetermined period of time (e.g., less than 100 milliseconds), such that the bid request-response process does not add significantly to the overall round trip time for ad query/bid request and/or delivery. A third-party agent 418, 446, 448, such an integrator network, may respond to an ad bid request with a message containing a particular advertisement, and a monetary bid amount for the placement of the particular advertisement with the inventory, in response to the particular ad query for the particular user and/or the particular publisher, at the time of the ad query.
Preferably, the selected integrator networks (e.g., third-party agents) respond to the bid request within a predetermined amount of time. In some embodiments, the round trip time for the bid request and the bid response, from the bid gateway 444 to and from each responding eligible entity (e.g., integrator networks) is less than about 100 milliseconds, and in some cases the total round trip time for the ad query and ad delivery and/or presentation is less than about 500 milliseconds, with about a 200 millisecond average.
Alternatively, the integrator network (e.g., third-party agents 418, 446, 448) may respond with a message indicating “no bid,” or not respond at all within the allowable time period for response. The bid gateway 444 transmits any ad bids that are within the allowable response period to the integrator module 436. The auction module 438 then uses the ad bids to determine a winner among the received bid responses. In one embodiment, the auction module 438 executes a plurality of business rules to select the winning bid. The business rules may use any type of criteria to select a bid, including price of the bid. Accordingly, an advertisement is selected from the received bid responses, and is then delivered or served to the inventory location 407, and/or the user of the browser 405.
The advertising exchange 432 may perform a variety of additional or optional functions and/or services. For instance, the appropriate entities may be compensated according to their respective agreements, and the various activities of the system 400 may be logged for the exchange. Furthermore, the modeling server 410 (and/or the advertising exchange 432) may be coupled with the advertising exchange 432 and/or the bid gateway 444, to track movement of network packets through a plurality of valid paths within the system 400. Based on a number of average queries per second (QPS) transmitted at different portions of the valid paths, the modeling server 410 can estimate a plurality of server and network costs, including fixed hardware costs and variable operational costs, amortized over a predetermined period of time, as discussed above. Furthermore, the modeling server 410 may calculate latencies through the portions of valid paths to determine bandwidth costs. In the following description dealing with
Continuing with the process flow of
Once eligible entities are determined, bid request(s) are generated for the eligible entity(s) at block 506. In some embodiments, bid requests are customized for each eligible entity. The bid request may further include additional information to aid the eligible entities in determining how to respond to the bid request (e.g., whether to bid, how much to bid, which advertisement(s) to select for presentation). The information may include, for example, details regarding the publisher, the inventory, the browser, and/or the user, including segment data, and may further be retrieved from a user database or another source.
Once the bid request(s) are formed, the bid request(s) are transmitted to the eligible entities at block 508. Some embodiments use a bid gateway to generate and/or transmit the bid requests. In some embodiments, traffic management and/or rate limiting is further implemented. For example, bid requests are preferably dropped that are intended for destinations (e.g., integrator networks) having expired leases, and/or that exceed a user setting for queries within a time period (e.g., queries per second).
The third-party agent or integrator network forms a bid response at block 608. The bid response may include a selected advertisement and/or creative, and a selected bid for the placement of the ad with the publisher, inventory, user, and/or the browser. In some embodiments, the third-party agent or integrator network makes the selection based on the information sent from the advertising exchange. Further, some bid responses may include additional useful information, such as accounting data, targeting information (e.g., behavioral-type targeting information), and/or a mapping call and information to select a creative. Once the bid request is formed, the bid response is transmitted back to the advertising exchange at block 610. The bid response is transmitted by one or more eligible entities (e.g., integrator networks) to a bid gateway for selection of a winning bid and/or advertisement. For example, an integrator network may transmit a bid response on behalf of one or more third-parties or integrated entities.
After a winning bid and advertisement are determined, the selected advertisement is optionally delivered, served, or displayed to the user at block 708. Serving the advertisement typically involves placing the advertisement with an inventory location of a publisher for presentation to a user of a browser who is visiting the publisher's Web page having the inventory, for instance. Furthermore, additional operations or functions may be performed, such as compensation of the appropriate entities, logging activity, traffic management, and the like, at block 710.
By implementing an architecture of the online advertising system that includes a bid gateway, the network protocols of the auction engine (e.g., advertising exchange module) are independent of network protocols used to transmit bid requests and bids between the third-party recipients and the bid gateway. In addition, the bid gateway architecture insulates the location information of third-party recipients from the advertising exchange module.
In some embodiments, the input to the bid gateway includes a message that identifies an opportunity and the third-party entities eligible to bid on the opportunity. This message is expressed in the language of the exchange protocol. In response to the message, the bid gateway 844 stores the opportunity ID and information regarding the eligible entities. In some embodiments, the bid gateway 844 stores this data in shared memory for access by multi-processors, as described below. The bid gateway 844 configures a bid request message, and transmits the bid request message to the third-party entity using the protocol of the third-party entity.
The bid gateway architecture further allows for customization of communications, including information and the protocols between the online advertising system and third-party entities. For example, a third-party recipient (e.g., integrator network) may desire to receive certain marketing or targeting information with the bid request, while another third-party recipient may desire to receive different marketing or targeting information, or receive no targeting information with the bid request. The bid gateway architecture permits the online advertising system to scale in size. Specifically, the server architecture for the advertising exchange module 833 may be expanded independent of the cluster of servers used to implement the bid gateway 844.
Some embodiments of the advertising delivery system include additional advantageous components.
The advertising exchange 1132 and additional components and modules preferably are accessible by using one or more customer and/or application interfaces.
Separately, or in conjunction with these applications, a traffic manager (TM) user application 1294 provides users (e.g., integrator networks and third-party agents) a user interface application to permit them to set functionality and acquire information from the traffic manager 1254. For example, in some embodiments, the traffic manager user application 1294 permits users to set a desired rate to receive bid requests, to generate reports regarding the number of bid requests sent, received, and timed out, to set a lease period for which the user desires to receive bid requests from the advertising exchange, and to set an endpoint location (e.g., URL) that specifies a location to send bid requests.
In some embodiment, customers or users of the applications and the exchange system, such as network-type entities, integrator networks, and third-party agents, may log into and access selected applications and interfaces to perform various administrative tasks such as choosing options, configurations, and/or settings. The customers may also retrieve information regarding activities on the exchange, such as accounting, statistics, targeting, query aggregation, and other information. For example, the traffic manager user application 1294 provides one or more of rate limiting, querying of accounting or statistics, and/or outbound targeting functions. The modeling server 1210 may also be coupled with the traffic manager user application 1294, either through the bid gateway 1244, or directly, to obtain and use traffic-related information that informs of queries per second (QPS) rates throughout the system 1200. This information aids the modeling server 1210 to track use and costs associated with that use by entities and users of the system 1200.
Preferably, the integrator networks 1218, 1246, 1248 include a variety of different types and sizes of entities. For instance, these entities may include large, sophisticated network operators, and further include smaller, niche-type players such as a mom-and-pop- type operation or a researcher in a research institution. Preferably, the system 1200 scales to the needs of each entity, accordingly. In one example, the customer entities are provided client-managed throughput and/or traffic manager features.
As shown in
The rate limiter operates in a system that transmits bid requests to third-party recipients on a per opportunity basis. It is not essential that the third-party recipients receive a bid request for each opportunity. Thus, opportunities may be dropped. The rate limiter operates in accordance with these assumptions and principles.
In one embodiment, the rate limiter 1245 is time-based, as opposed to quantity- based. For example, if a selection system is purely quantity-based, then the output may select the maximum quantity desired in a very short period of time (e.g., 1000 bid requests may be dispensed in just a few minutes when the third-party recipient requests 1000 bid requests per hour). Instead, in a time-based system, the bid request selection module 1315 spreads out the transmission of bid requests to third-party recipients over time.
The rate tracking 1305 measures the rate or speed at which bid requests are received at the bid gateway for each third-party recipient. In some embodiments, rate tracking 1305 uses a histogram to track the number of bid requests for a third-party recipient. For example, in some embodiments, rate tracking 1305 sets-up a “bin,” and tracks the number of bid requests by counting the bid requests in the bin over a specified period of time. In other embodiments, rate tracking 1305 measures the time required to receive a predetermined number of bid request messages for a third-party recipient. Under this approach, rate-tracking 1305 varies the size of a time window, but maintains an equal number of bid requests within the time window. Any rate-tracking scheme that provides historical data, such as a histogram, may be used without deviating from the spirit or scope of the disclosure.
Bid request selection 1315 selects bid request messages for transfer to the third-party recipients. For example, if the third-party recipient has set the desired rate to 10 queries per second (QPS), and the rate tracking indicates a historical pattern of 100 bid requests per second (QPS), then bid request selection 1315 selects one out of every 10 bid request messages to transmit to the third-party recipient. In some embodiments, the bid request selection 1315 uses a probabilistic filter. For these embodiments, the bid request selection 1315 in essence flips a coin to determine whether to send the bid requests based on the historical rate and the desired rate set by the third-party recipient. In some embodiments, the probabilistic filter is averaged over a time window. If the time window is set relatively large, then the third-party recipient may potentially get bid requests that are not evenly spread over the time window. Alternatively, if the time window for the probabilistic filter is set too small, then too many computational resources may be required. In some embodiments, the probabilistic filter may set a time window between 5 and 15 minutes. One advantage in using a probabilistic filter is that it allows distributed control, but still provides a predictable system operation. As such, the bid gateway may be implemented over several servers, but the aggregate behavior of the entire system is predictable, which prediction can be used to forecast costs and the need to replace servers and hardware as discussed above.
In some embodiments, the traffic manager implements reporting functions. In general, the reporting functions provide a record or log of network transactions between the online advertising system (e.g., bid gateway) and the third-party recipients (e.g., integrator networks). In some embodiments, the reporting data or log records 1) errors in transmissions, 2) timeouts of bid requests to third-party recipients, 3) successful queries (bid requests sent to third-party recipients who responded with a bid in the requisite time), 4) the time of the transmissions, and 5) the location of the facility that conducted the transactions. The traffic manager may record other network transactions between the online advertising system and third-party recipients without deviating from the spirit or scope of the invention.
During operation of the system 1200, the data collection 1250 provides information regarding the type and volume of activities on the exchange, such as by the advertising exchange 1232 and/or of the system 1200 as a whole. This data may be further collected or aggregated in a data warehouse 1252, which is coupled with, and provides data to, the traffic manager 1254 and the traffic manager user application 1294. Rate data may also be supplied to the modeling server 1210 by way of the traffic manager user application 1294 or directly through the advertising exchange 1232. For example, a user of the system may generate reports regarding activity, such as bid requests and bid responses, through data collected in data collection 1250 into the data warehouse 1252 and accessed through traffic manager user application 1294. In the traffic manager 1254, the data is further available for access and/or use by applications and/or modules coupled thereto (e.g., by the traffic manager user application 1294, the bid gateway 1244, the traffic manager database 1258, and the like).
As shown in
Another type of information that is used, in addition to the outbound targeting information, is query aggregation type information. As shown in
In some embodiments, the traffic manager 1254 may be implemented on an application server, separate from server(s) that implement the bid gateway. The traffic manager may use data storage, such as a traffic manager database 1258. In a particular implementation, the traffic manager database 1258 provides for the storage and retrieval of query aggregation information, rate limit preferences of users (e.g., integrator networks), outbound targeting information, and the like.
As discussed above, a customer may access a traffic manager user application 1294 to configure a variety of preferences for the exchange, and/or obtain a variety of information regarding activities on the exchange. More specifically, an integrator network (e.g., integrator network 1218) advantageously selects rate-limiting preferences for the transmission of bid requests transmitted from the bid gateway 1244 to the integrator network or third-party agent 1218. A large entity that is capable of high data rates and/or fast response times may prefer higher volumes of bid requests than a smaller entity. For example, a large entity may request a data rate of bid requests of 100K queries per second (QPS) versus a small entity that may request a data rate of bid requests of only 10 QPS. This improves performance both for the customer, who sets its own query/request rate and therefore is not inundated by undesirable requests, and further improves performance across the exchange. First, the exchange expends fewer resources in sending high volumes of queries to smaller entities that are likely to be quickly saturated and unavailable to respond to a majority of the volume of requests. Second, the exchange wastes less time waiting for responses to a volume of requests that has a small chance of meeting the short response time constraint, or to which the entity has no intention of responding. Using this configuration, undesired processing and/or transmission are truncated at an early stage.
At various times, entities and/or connections may become unavailable on the exchange system. For example, an integrator network 1218 may be unable to receive or respond to queries (e.g., bid requests) and further may be unable to inform the exchange system or bid gateway 1244 of its status, or to even interact in other ways such as set its rate preferences. Some embodiments have a leasing time setting for each eligible entity, and some entities are further able to set their own leasing times. For example, the integrator network 1218 may set a leasing time of five minutes, and further sets a maximum bid request throughput of 100K queries per second (QPS). As an example, the advertising exchange 1232 may receive a massive number of ad queries, and may determine that the integrator network 1218 is eligible for those ad queries. The bid gateway 1244 and traffic manager 1254 (e.g., by using a rate limiter 1245) may further determine whether the number of queries sent to the integrator network 1218 is less than the threshold preference set by the integrator network 1218 (e.g., 100K QPS). The bid gateway 1244 may further determine whether the integrator network 1218 has a current valid lease (e.g., that has not expired, or that has been renewed). If each condition is met, then bid request(s) are transmitted to the integrator network 1218. If, for example, the Internet, local area, and/or collocation network connection from the bid gateway 1244 to the integrator network 1218 fails, or becomes temporarily unavailable due to congestion or another cause, or if the internal systems or servers of the integrator network 1218 are inoperable for a period longer than the leasing time, then the system 1200 advantageously foregoes transmissions (e.g., queries or bid requests), and does not wait or expect responses from the integrator network 1218.
Regardless of the cause of unavailability, the integrator network 1218 advantageously resets its leasing time, rate preferences, and other configuration settings, when it so desires or is able to resume activities on the exchange system. Moreover, the integrator network 1218 may custom tailor ramping for its activities on the exchange. For example, the integrator network 1218 may set a high volume of queries per second over a long continuous leasing time for sharp ramp up to near capacity for receiving bid requests. Alternatively, the integrator network 1218 may set incrementally increasing volumes of queries per second over several shorter leasing times for a gradual or sloped ramping of bid requests and activities on the exchange. Some ramping profiles are illustrated in
In some embodiments, during operation of the system 1200, historical and/or pattern data are accumulated at various locations including, for example, the traffic manager database 1258. For example, the data may include the settings of participating entities, rate preferences, leasing times, and also other information derived from the various components of the exchange system, such as the advertising exchange 1232, data collection 1250, data warehouse 1252, traffic manager 1254, and/or bid gateway 1244. The data may further include outbound targeting data, query aggregation data, and other accounting and statistical information. Customers, such as integrator networks, preferably access the stored information for verification with their own records of bid requests, responses, and/or placed advertisements. Such verification is particularly useful in pay-to-play type models where the entity pays for each of a type of transaction on the exchange (e.g., pays based on number of bid requests transmitted, and/or based on number of bid responses, and not only based on winning bids or placed advertisements).
U.S. patent application Ser. Nos. 12/398,841 and 12/398,877, both filed Mar. 5, 2009, which were referred to above, discuss transferring, targeting, and marketing information in bid requests to third parties. These applications, owned by the assignee of the present application, are incorporated herein by reference. Accordingly, the details of these applications will not be repeated here, which discuss, in part, how marketing and targeting information may be passed through the bid request or be obtained through a proprietary system of an advertiser that uses the bid request to obtain such information. The processing involved with extracting and integrating marketing and targeting information into the bid response process by an advertiser is part of the latency that may occur in the exchange server or bid gateway server receiving bids and corresponding advertisements in response to requests for bids. These latencies may be tracked over time and also predicted based on historical data by methods the same or similar to those discussed above; the latencies may then become part of the bandwidth cost analysis that is discussed in more detail below.
The foregoing embodiments advantageously use (bid request) rate control, time outs, and the like, to advantageously provide high-speed integrated and/or federated exchange services without the need for other optimizations, additional facilities, or components. The additional features described next are advantageously used alternatively, or in conjunction with, the foregoing embodiments.
In some embodiments, the bid gateway 1544 is preferably coupled with each integrator network (e.g., 1518), such that caches 1517 and 1546 may be updated with the most recent and/or relevant data for the cache entries (e.g., bid information).
In some embodiments, the caching includes a rapid data retrieval format, including a lookup and/or hash table format. Such an exemplary format is illustrated in a cache 1517 of
The hash and/or lookup value provides a fast pattern matching system for one or more repeat occurrences of some or all of an ad query, bid request, and bid response cycle. For example, each hash and/or lookup entry in the table preferably allows for rapid matching of the content and/or inventory of a publisher to selected users, segments, integrator networks, bids, ads, and/or creatives. In some embodiments, each cache line entry expires within an optimal time period thereby minimizing unnecessary storage of stale cache entries. The time-to-live sets the time period before the cache line entry is deleted from the cache.
At various times, advertising is requested for inventory locations 1607 within the browser 1605. In some embodiments, the advertising and/or bid requests to entities of the exchange are delivered to a bid module 1617 with a local cache 1619. The bid module 1617 and local cache 1619 are associated with the browser 1605 and/or inventory 1607 that is the destination for the requested advertising. For example, bid module 1617, associated with browser 1605 and/or inventory 1607, may receive one or more bids from various sources of advertising on the exchange. In response, bid module 1617 may conduct an auction offline, online, and/or in real time to determine the winner of the auction for placement of advertising with the inventory 1607. Furthermore, the bid module 1617 may place the winning advertisement within the inventory 1607 for presentation to user 1603. In some embodiments, the bid module 1617 may further provide accounting and/or logging information. The accounting or logging information may be later used for compensation of entities as well as for overall record keeping for the entities on the exchange. Some embodiments may further provide for user segmenting and/or mapping of user information for entities on the exchange including third-party entities.
In some embodiments, the local cache 1619 may include the contents and may be implemented similar to the cache 1607, described above in relation to
The interface devices 1717, 1745, 1747 may advantageously be dedicated to the integrator networks 1718, 1746, and 1748, respectively. The devices 1717, 1745, 1747 permit high data rate transmission between the bid gateway and the integrator network devices, and/or third-party devices, (e.g., third-party bid agent equipment). High data rate transmissions include, for example, fiber optic and similar channels, gigabit Ethernet, various forms of SCSI, micro channel, and the like. The devices 1717, 1745, 1747 may include all or part of the bid receipt and/or response architecture for one or more of the integrator networks 1718, 1746, 1748, and/or their integrated entities 1720 and 1722. Further, the devices 1717, 1745, 1747, may include caching structures such as described above within the devices, the bid gateway, and/or the advertising exchange within the collocation facility 1760 to further enhance the speed of operation.
The collocation facility 1760 may include, within a single site, various components for the rapid operation of a bid request/response system including, for example, one or more advertising exchanges 1732, one or more bid gateways 1744, and various integrator network and/or third-party interface devices 1717, 1745, 1747. Several collocation facilities 1760 are preferably located and operated from within multiple predetermined geographic regions. For instance, multiple and/or redundant collocation facilities 1760 are located within multiple locations across the Internet, such as San Francisco, Los Angeles, and New York, to serve North America and/or the United States, while additional facilities may be placed in local geographic regions to serve particular continents such as Europe, Asia, Africa, South America, and/or cities therein, as examples.
The online advertising exchange may participate in fulfilling both guaranteed and non-guaranteed contracts to the integrator networks 1718, 1746, 1748 and/or to the integrated entities 1720, 1722 and/or to other publishers, depending on what contracts are developed therebetween. For these embodiments, when conducting an auction, the online advertising exchange does not differentiate between inventory that may be sold to fulfill a guaranteed contract, and inventory that does not result in fulfillment of a guaranteed contract (i.e., referred to as “nonguaranteed inventory”). For these embodiments, when the advertising exchange module (e.g.,
A server system, as defined herein, may include a single server computer or a plurality of server computers. The servers may be located at a single (collocation) facility or the servers may be located at multiple facilities. In some embodiments, the advertising exchange module includes a plurality of servers, such as server systems 18401 to 1840N. The bid gateway includes one or more additional servers, coupled to and accessible by the server systems for the advertising exchange module, such as server systems 18401 to 1840N. In addition, the third-parties to the online advertising exchange system, such as integrator networks, third-party agents and third-party recipients, include one or more servers, such as servers 18401 to 1840N. As such, servers 18401 to 1840N are intended to represent a broad class of server farm architectures and may be configured in any manner without deviating from the spirit or scope of the present disclosure.
The client system 1820 may include a desktop personal computer, workstation, laptop, PDA, cell phone, any wireless application protocol (WAP) enabled device, or any other device capable of communicating directly or indirectly to a network. The client system 1820 typically runs a Web browsing program that allows a user of the client system 1820 to request and receive content from the server systems 18401 to 1840N over the network 1830. The client system 1820 typically includes one or more user interface devices 1822 (such as a keyboard, a mouse, a roller ball, a touch screen, a pen, or the like) for interacting with a graphical user interface (GUI) of the Web browser on a display (e.g., monitor screen, LCD display, etc.). A modeling server 1810 may be coupled with any or all of the server systems 18401 to 1840N locally or over the network 1830.
In some embodiments, the client system 1820 and/or system servers 18401 to 1840N are configured to perform the methods described herein. The methods of some embodiments may be implemented in software or hardware configured to optimize the selection of additional content to be displayed to a user.
The third-party integrated (3PI) architecture disclosed and described above includes a plurality of server and network costs that involve both fixed costs and operational costs, which include maintenance costs, in addition to bandwidth costs. As described above, the modeling server, or other computer, or the advertising exchange itself, may track query per second (QPS) rates at various portions and throughout the auction-based, real-time advertising system in order to predict both revenue and costs to ensure continued cost-based viability of the system. Table 1 includes a basic overview of the types of costs involved, which will be expanded on below. The advertising exchange server will also be referred to herein as an ad server for simplicity.
After predicting or estimating hardware and operability (bandwidth) costs, the modeling server may generate scenarios concerning how these costs can be recovered by bid payout and tech fees. The modeling server may also track how the cost components change when the following parameters change: (1) number of third-party networks (3PN); (2) the average message size of the 3PN bid requests and responses; (3) 3PN participation rate; and (4) a 3PN participation overlap.
The following assumptions may be made to simplify the modeling performed by the modeling server: (1) one 3PN creates one entity in the exchange data model; (2) the bid request and response message sizes are assumed to be constant; and (3) there is a fixed latency budget for 3PNs to respond. With regards to number two, depending on the network model being used, an advertiser can be reachable via multiple paths from the source publisher. There could be competing integrated networks that have concurrent deals with the same third-party advertiser which create the possibility of multiple paths, for instance. Accordingly, there could be some variation in bid request and response sizes, but the model assumes that they are constant for simplicity, or as seen later, may simply average them together. The following Table 2 summarizes cost model parameters and exemplary values for those parameters, which the cost model may employ in automating its estimations and predictions, as explained below.
Note that if all the 3PNs are competing for the same opportunities, then the 3PN_participation is 100%. In contrast, if every 3PN targets totally different publishers, then on average each ad query will only have one 3PN associated therewith, and the 3PN_participation_overlap would be one divided by the number of 3PNs.
There are at least two kinds of costs for a server or for networking hardware, including an upfront cost corresponding to the price, and the operating costs in terms of power and cooling. According to costs of serving models, these two costs are amortized to a fixed life time of a predetermined period. The predetermined period of time is usually about 3 years (or 36 months). The total cost of ownership for a server in 3 years is 2.5 times the upfront box price of the server. The model also assumes that the switch or router depreciation is also 3 years and the total cost of ownership is again 2.5 times the original hardware cost. Below, in Table 3, is a list of costs associated with the server and network hardware described above.
Note that the BAS is the main switch or router currently employed within the networking hardware of the collocation data center. One of skill in the art will recognize that different switches or routers may be used besides the BAS switch or router. Also, one of ordinary skill will recognize that values may be input into the cost model based on changing conditions or assumptions, including amortization period and total cost of ownership, etc.
The total bid gateway box costs are now described, in which the bid gateway is limited in three aspects: (1) computation that is required to serialize/deserialize data packets and the security signing of bid requests/responses; (2) bandwidth required to communicate with advertising exchanges and bid servers, e.g., with a 1 Gbit Ethernet card; and (3) a number of in-flight messages that equals the number of opened file descriptors. These limitations are reflected in the average QPS that a bid gateway can support. The term “in-flight” refers to the bid gateway real-time operation of passing and receiving bid requests and responses, respectively.
When the bid request/response message size is around 3 KB, neither the bandwidth nor the computation is the bottleneck. The in-flight number of messages affects the bid gateway performance the most. Assuming 3PNs are responding within a fixed latency, the model sums the incoming and outgoing QPS to characterize the peak performance of bid gateways. It has been observed through execution of the cost data model that when 3PN participation overlap is high, the bid gateways can support higher peak QPS.
The overlapping participation refers to the degree that 3PNs compete for the same set of opportunities, e.g., for ad queries or impressions, which arrive in the form of a bid request. The extreme cases include (A) no overlap of qualification on ad queries and (B) complete overlap, or in other words, all of the 3PNs qualify for the same ad queries. The following is a basic illustration of the impact on the bid gateway for each of these two extreme cases (no overlap and complete overlap).
As between the advertising exchange (or ad server) and the bid gateway, the bid gateway connects with ad servers using an optimized connection method possible within the data collocation facility. The communication within the collocation facility has a lower latency than communication outside of the collocation facility. Only one message is passed between the advertising exchange and the bid gateway for one ad query (impression call), no matter how many 3PNs are qualified for the opportunity. However, the more 3PNs that are participating, the larger the message size becomes.
As between the bid gateway and the information service provider (ISP) out to the 3PN bid servers, separate http connections are usually used for each 3PN. The communication that is thus outside the collocation facility has a higher latency than that within, as discussed above. The two extreme cases of participation overlap introduced above have the same outgoing QPS. Suppose the bid gateways' maximum outgoing QPS is 500. That is, within a second, there are 500 call outs to 3PNs. For the no overlap scenario (A), the 500 call outs are evenly distributed; and for the 100% overlap scenario (B), the 500 call outs are grouped into packets of 500 divided by the number of 3PNs, and the packets are evenly distributed. Because the number of 3PNs is very small compared with 500, the two traffic patterns do not imply different bandwidth requirements outside of the collocation facility. The conclusion is that the sum of incoming and outgoing QPS in case (A) is larger than that in case (B), thus the bid gateways perform better in case (B), with 100% overlap.
After measuring the bid gateway QPS at message size 1K and 5K, a linear function was used for messages sized in between those two rates. Table 4, below, displays the functions to be calculated at least on a daily basis.
With the parameters and calculated values, monthly costs for a certain QPS rate given a certain number bid gateways may result in an approximate monthly cost for the bid gateways. This calculation may be subsumed within the advertising exchange (ad server) calculation if there are no bid gateways, and all bid request generation and bid response reception happens through the advertising exchange itself.
Based on a queue model designed according to Tables 1-4, the end-to-end latency is a nonlinear function of the incoming QPS. For example, the end-to-end latency may be the addition of the two following latencies: (1) 296 for a 20 QPS extra-collocation; and (2) 279 for a 19 QPS intra-collocation. With the 3PN call out, the advertising exchange will have additional latency. For users to observe the same end-to-end latency when there is a 3PN call out, the incoming QPS for those active 3PN advertising exchanges should be reduced, thus the waiting queue is shorter and the latency overhead of “calling out” to the 3PNs may be reduced. The 3PN participation overlap has a significant impact on this cost. With the same overall participation, the more the overlap—or competition for the same set of bid request—among the 3PNs, the smaller the number of advertising exchanges need to perform “calling out,” thus the less impact to overall latency. This means that the system and network hardware located within the collocation facility can support a larger bandwidth demand in terms of QPS of bid request and bid responses given the same amount of hardware; therefore, there are fewer associated costs. Table 5, shown below, displays parameters that may be used in the calculation of total costs of advertising exchange server boxes, and the cost of any additional exchange server boxes that become required.
The bid request/response size not only affects the QPS of the bid gateway, but it also determines the total bandwidth of supporting 3PN call outs. There are two bandwidth requirements for the system: (1) within the collocation facility communication with ad exchange servers; and (2) outside the collocation facility communication with 3PN bid servers. These two bandwidths are priced differently, so the model uses an average price of the two. Typically, the bid response contains the advertisement from the 3PN and is larger in size than the bid request. Message size is, therefore, the average of the two. Table 6, shown below, includes parameters that may be used to calculate total bandwidth costs.
The bandwidth price, of course, may vary and be set by the owner and operator of the exchange system, or by an ad network such as owned by Yahoo! Total networking bandwidth costs, such as for switches or routers used in the collocation facility that support communication between the ad exchange server(s) and the bid gateway server(s), may also be calculated as per the parameters in Table 7.
Advertising exchanges charge 3PNs monthly fees to cover their costs of operation as described above, including server box and networking hardware, in addition to bandwidth costs. The model may also average the exchange costs to the number of times 3PNs are called, or average to the number of ad queries in which the 3PNs participate. Overall costs are amortized over three years (or 36 months). Most businesses replace computer hardware about every three years, on average, as this is the effective life of the computer hardware, proving the business desires to remain efficient and as fault-free as possible. Table 8, shown below, displays parameters that may be used to determine total costs associated with the auction-based exchange system, including intra- and extra-collocation facilities, and total hardware and bandwidth costs.
For example, in calculating total costs, assume that there are five 3PNs, each participating in 8% in ad query (calls), and on average there are 2.5 third-party networks (3PNs) per ad query (or call out). Based on these assumptions, the tech fee for each 3PN would be: (1) $1,900 a month; or (2) $0.09 per one million times a 3PN is called; or (3) $0.22 per one million ad queries with 3PN participation.
The per 3PN cost may be scaled to account for different cost components that respond to changes in the above parameters differently. The parameters may generally be scaled as follows. For the number of 3PNs, the scaling for: (1) the bid gateway costs is sub-linear; (2) the ad exchange server costs is sub-linear; (3) the bandwidth costs is sub-linear; and (4) the networking costs is sub-linear. For the level of 3PN participation, the scaling for: (1) the bid gateway costs is linear; (2) the ad exchange server costs is sub-linear; (2) the bandwidth costs is linear; and (4) the networking costs is step. For the level of 3PN participation overlap, the scaling for: (1) the bid gateway costs is inverse; (2) the ad exchange server costs is inverse; (3) the bandwidth costs is inverse; and (4) the networking costs is inverse.
The third-party integration (3PI) cost model disclosed above gives an estimation of the breakdown of different cost components, including server and networking hardware and associated bandwidth costs. Typical scenarios show that 3PNs need not pay expensive tech fees for the fee collection efforts of the advertising exchange to support the viability of the 3PI exchange system. The cost model also suggests that, with the addition of more 3PNs, the fee to each 3PN will decrease. Also, the participation rate is quite influential to the cost per 3PN. In the exchange data model, the entities and targeting constraints for 3PNs should be carefully considered so that a 3PN is called only when it has a high—or at least above-average—chance of winning the auction. Furthermore, the overlapping participation among 3PNs has a large impact on the cost per 3PI ad query. The higher the overlapping, the higher the per ad query cost overall. However, the cost per 3PN call out and the cost per 3PN are inversely related with the overlap, so it is a cost savings overall for the 3PI exchange system to have a high amount of overlap of competition for the same ad queries (bid requests).
In the above analysis, the model assumes a message size is around 2 KB. This is reasonable when bid responses of 3PNs are redirects. In contrast, however, if the 3PNs are sending real creatives (including gifts, etc.) back, the message size of those communications can be much larger. This will greatly increase the bandwidth-related costs, and in the extreme case, could be the bottleneck of scaling the system. It would be beneficial to decreasing the bandwidth costs and keeping the same predictable to avoid having large bid responses over 8 KB.
The computer system 1900 further includes a mass storage device 1920, peripheral device(s) 1930, portable storage medium device(s) 1940, input control device(s) 1970, a graphics subsystem 1950, and an output display 1960. For purposes of simplicity, all components in the computer system 1900 are shown in
The portable storage medium drive 1940 operates in conjunction with a portable non-volatile storage medium, such as a compact disc read only memory (CD-ROM), to input and output data and code to and from the computer system 1900. In one embodiment, the online advertisement system software is stored on such a portable medium, and is input to the computer system 1900 via the portable storage medium device 1940. The peripheral device(s) 1930 may include any type of computer support device, such as an input/output (I/O) interface, to add additional functionality to the computer system 1900. For example, the peripheral device(s) 1930 may include a network interface card for interfacing the computer system 1900 to a network.
The input control device(s) 1970 provide a portion of the user interface for a user of the computer system 1900. The input control device(s) 1970 may include an alphanumeric keypad for inputting alphanumeric and other key information, a cursor control device, such as a mouse, a trackball, stylus, or cursor direction keys. In order to display textual and graphical information, the computer system 1900 contains the graphics subsystem 1950 and the output display 1960. The output display 1960 may include a cathode ray tube (CRT) display or liquid crystal display (LCD). The graphics subsystem 1950 receives textual and graphical information, and processes the information for output to the output display 1960. The components contained in the computer system 1900 are those typically found in general purpose computer systems, and in fact, these components are intended to represent a broad category of such computer components that are well known in the art.
The system and process described may be encoded in a signal bearing medium, a computer readable medium such as a memory, programmed within a device such as one or more integrated circuits, one or more processors or processed by a controller or a computer. If the methods are performed by software, the software may reside in a memory resident or interfaced to a storage device, synchronizer, a communication interface, or non-volatile or volatile memory in communication with a transmitter. A circuit or electronic device may be designed to send data to another location. The memory may include an ordered listing of executable instructions for implementing logical functions. A logical function or any system element described may be implemented through optic circuitry, digital circuitry, through source code, through analog circuitry, through an analog source such as an analog electrical, audio, or video signal, or a combination thereof. The software may be embodied in any computer-readable or signal-bearing medium, for use by, or in connection with an instruction executable system, apparatus, or device. Such a system may include a computer-based system, a processor-containing system, or another system that may selectively fetch instructions from an instruction executable system, apparatus, or device that may also execute instructions.
A “computer-readable medium,” “computer-readable storage medium,” “machine-readable medium,” “propagated-signal” medium, and/or “signal-bearing medium” may include any device that includes, stores, communicates, propagates, or transports software for use by or in connection with an instruction executable system, apparatus, or device. The machine-readable medium may selectively be, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. A non-exhaustive list of examples of a machine-readable medium would include: an electrical connection “electronic” having one or more wires, a portable magnetic or optical disk, a volatile memory such as a Random Access Memory “RAM”, a Read-Only Memory “ROM”, an Erasable Programmable Read-Only Memory (EPROM or Flash memory), or an optical fiber. A machine-readable medium may also include a tangible medium upon which software is printed, as the software may be electronically stored as an image or in another format (e.g., through an optical scan), then compiled, and/or interpreted or otherwise processed. The processed medium may then be stored in a computer and/or machine memory.
The above-disclosed subject matter is to be considered illustrative, and not restrictive, and the appended claims are intended to cover all such modifications, enhancements, and other embodiments, which fall within the true spirit and scope of the present invention. Thus, to the maximum extent allowed by law, the scope of the present invention is to be determined by the broadest permissible interpretation of the following claims and their equivalents, and shall not be restricted or limited by the foregoing detailed description. While various embodiments of the invention have been described, it will be apparent to those of ordinary skill in the art that many more embodiments and implementations are possible within the scope of the invention. Accordingly, the invention is not to be restricted except in light of the attached claims and their equivalents.
Applications related to the present application include U.S. application Ser. No. 12/398,841 titled Architecture for an Online Advertisement Bidding System, filed Mar. 5, 2009, and U.S. application Ser. No. 12/398,877, titled A Bid Gateway Architecture for an Online Advertisement Bidding System, filed Mar. 5, 2009, both of which are herein incorporated by reference.
