Patent Application
20180322535
The online advertising industry is growing increasingly sophisticated. As the number of display ads grows, driven mainly by more intelligent programmatic ad buying capabilities, the amount of control that publishers (entities who have an inventory of advertising space to sell) want with respect to selling this ad space inventory grew. And with it the value of the publisher's inventory rose as well. There is an increasing desire among publishers to carve out specific inventory buckets for their ad space inventory. On the advertiser side, advertisers are now increasingly particular about how much they will pay to place their ads on Web pages. Presently, prices for paying for ad space is based on fairly generic level controls, such as Web site traffic, location on Web page, visibility on page, and the like. The specific audience, that is, who would see the ad, does not play a role in determining the value of an ad space or segment.
Referring to
One aspect of the online advertising industry is that ads may be served to users across large geographic areas. For example, an individual publisher may have a website that is viewed by people within large geographic areas, including different countries around the world. As a result, the online ads will typically be served from geographically distributed servers. Thus, in the example of
Providing a geographically distributed online advertising service generates a problem in controlling the number of impressions served. In many applications it is desirable to have a cap on the number of impressions for a particular campaign, creative, real time bidding, or ad network. This is also known as an impression cap. However, coordinating impression caps in a distributed online advertising environment is difficult.
Therefore, it would be desirable to provide tools for improved control of serving impressions in an online advertising campaign.
In one aspect of the preset invention, a method of serving ads to ad segments on Web pages is described. Impression caps may be imposed on geographically distributed data centers. In an individual data center a server may dynamically request information to update a local impression cap at the server. The rules for determining an impression cap for a server may include selecting the impression cap to be a small fraction of a total impression cap for a data center to minimize under/over serving. Additionally, the impression cap may be selected to be sufficiently large to keep latency within acceptable limits. Additionally, other rules may be imposed on the impression cap at the local server. After a server exhausts an impression cap quota it dynamically requests information from a central store to update its impression cap quota. Additional monitoring of actual impressions served may be used to aid in determining the number of remaining impressions to be served by the servers of a data center.
The invention and the advantages thereof may best be understood by reference to the following description taken in conjunction with the accompanying drawings in which:
In the drawings, like reference numerals are sometimes used to designate like structural elements. It should also be appreciated that the depictions in the figures are diagrammatic and not to scale.
Methods, systems, and computer readable media for impression capping in an online advertising distributed environment are described.
In one embodiment a get impression served details 355 command is used for the cron analysis modules 360 to fetch information on impressions served. The central icap store 340 may use a get details and set icap command 365 to get the chronological information, which may include information on the number of impressions to be served and the impressions actually served.
Each individual server 305 of the data center 300 fetches an icap quota from the central icap store 340 keeps the fetched quota locally at the server. Once that icap quota has been exhausted at the individual server, the server will then fetch an updated icap quota from the central icap store and continue to serve impressions. The process of each server fetching an updated icap quota each time a previous icap quota is exhausted continues until the remaining icap quota in the central icap store 340 is exhausted.
As an illustrative example, assume that there is an impression cap (icap) of 100,000 for a given data center. Suppose there are servers A, B, and C of different clusters. Suppose server A fetches an icap quota of 100 and keeps it at the server locally. Once the 100 impressions are served by that server, it will again fetch an updated quota (e.g., 100) from the central store. Several different aspects are illustrated by this example. In this example the impression cap quota is small compared with the total icap for the data center. Thus, there is a low chance of over-serving or under-serving. However, the icap quota is also large enough so that the icap quota is not always updated from the central store. That is, the icap quota is selected to be large enough to keep latency within acceptable limits. Additionally, the use of the central store eliminates the need to maintain cluster information to control the impression cap. Moreover, because the data center is monitoring the actual impressions served, the remaining inventory can be determined and used to refine the icap quota updates based on the remaining inventory.
As previously discussed an individual server 305 may include a rules module 307 to update the icap quota. An exemplary server algorithm to update the icap quota will now be described in accordance with an embodiment of the present invention. In one embodiment, on each server call request, the following steps are implemented by the server:
1. Get related winnable inventory having impression cap enabled.
2. If icap data is not available locally for an inventory take a default icap, where an exemplary default icap may be set to be a small number such as 1. Setting the default icap to be a small value avoids a first time huge update request to the central data store. Moreover, setting the default icap to be a small number, such as 1, can be accommodated while an estimation is performed at the centralized data store of the remaining icap for the data center.
3. Determine if the icap data is available locally but <=0, and if the icap is available at the central store. For this case, fetch icap quota as per icap available at central store, decrement same at central store and store it locally for further use.
4. If the inventory having icap wins, then decrement the icap count for the same inventory by 1 locally, then again go through step 3 to update icap if required.
In one embodiment a rule is provided for the local Icap data to expire based on a condition, such after a pre-selected time or other condition.
As an illustrative example suppose for an ad request that c1, c2, c3, c4 are different types of active inventory each having icap enabled. Then in one embodiment the following steps will be followed by the server:
1. The server checks the icap value locally for the different types of inventory c1, c2, c3,c4. In this example, for a first time call the icap data will not be available locally so the server will take the default icap (e.g., a small value, such as 1) and will do further processing.
2. Now suppose that the inventory c2 is finally owned and served. The icap count is then decremented locally by 1. In this example, the default icap is assumed to also be 1. As the icap count is now <=0, an updated icap quota (e.g., say 100) will be fetched from central store and set locally for further use.
3. Thus, after step 2 we have icap for c1=1,c2=100,c3=1,c4=1.
4. The Server again get a call and one of the inventories cl, c2, c3, and c4 is selected.
5. Whichever campaign wins will decrement the icap locally by 1.
In one embodiment the icap quota fetched by server will be dynamic and will be decided as per the remaining icap at central store. Initially the server will be unaware of the icap at the central store so it will fetch a minimal quota at first. Once it knows the icap at the central store it will decide its quota accordingly as below:
An icap_quota_factor is one of the deciding factors to calculate a dynamic quota. In one implementation a default value for the icap_quota_factor is 5.
An icap_minimum_quota is a minimum icap quota.
An icap_max_quota is a maximum icap quota.
A factor value is based on the data center server count and the icap quota server as follows:
Then using these expressing the updated (next) icap quota is given by the following expression to adjust the next icap quota based on the remaining icap at the central store, the icap minimum quota, and the factor value:
In one embodiment, and estimate is formed for the icap at some initial time period for the central store, such as at the beginning of the day (the 0th hour with respect to the beginning of a new time period). This estimate may be weighted based on how many impressions were served in the previous time period by the data server. However, if no impressions were served in the previous time period by the data center, then the estimate can be based on the percentage of servers in the data center, or by other techniques. A default number can also be set to each server.
For example, in one embodiment each day the chron analysis module 360 will run in each data center. This provides the number of impressions served by the data center in the previous time period. This is performed to decide the maximum number of impressions to be served for the day, which is updated in the central store. This update is performed for all active inventories.
In one implementation, the update will depend on the total number of impressions to be served today multiplied by the percentage of impressions served yesterday by the data center then the following algorithm may be used:
However, suppose that in the previous time period that no impressions were served by that data center. In this situation a different algorithm may be used:
By default, an icap of 1 is given to all server this is accommodated in estimation by below step:
As previously discussed, in one embodiment the cron analysis module 360 monitors the impressions that are actually served on a user browser. An impression is counted served only if it is served on a user's browser. This improves accuracy. For example suppose that an auction happens at the publisher end. Suppose some of the impressions are lost. This may arise from problems in the network through which the impression is served to the end user or for other technical reasons. In this situation, the lost impressions need to be re-delivered.
A redelivery algorithm may be implemented on a period basis. In one implementation an algorithm to redeliver lost impressions is followed every 15 minutes, although it will be understood that the algorithm could be repeated with other periodicities. An exemplary redelivery algorithm is as follows:
a. Find out all active inventories whose icap is finished at central store in a DC.
b. If the icap is finished 15 min before current time at central store for given DC then:
c. Set Remaining_Impression_to_serve_by_DC in central store.
In addition, embodiments of the present invention further relate to computer storage products with a computer-readable medium that have computer code thereon for performing various computer-implemented operations. The media and computer code may be those specially designed and constructed for the purposes of the present invention, or they may be of the kind well known and available to those having skill in the computer software arts. Examples of computer-readable media include, but are not limited to: magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs and holographic devices; magneto-optical media such as floptical disks; and hardware devices that are specially configured to store and execute program code, such as application-specific integrated circuits (ASICs), programmable logic devices (PLDs) and ROM and RAM devices. Examples of computer code include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter.
Although illustrative embodiments and applications of this invention are shown and described herein, many variations and modifications are possible which remain within the concept, scope, and spirit of the invention, and these variations would become clear to those of ordinary skill in the art after perusal of this application. Accordingly, the embodiments described are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.
This application is a Continuation of U.S. application Ser. No. 14/276,654, filed on May 13, 2014, the contents of which are incorporated herein by reference in its entirety
| Number | Date | Country | |
|---|---|---|---|
| Parent | 14276654 | May 2014 | US |
| Child | 16039554 | US |
