Patent Application
20160239873
This invention relates general to electronic mediation systems, and more particularly to electronic mediation systems for online advertising networks.
An online advertising (“ad”) network includes a server system that connects advertisers (“demand sources”) to publishers that want to display advertisements on connected screen devices such as personal computers (PCs), smartphones, Connected (Smart) Television (CTV or Smart TV), computer tablets, etc., that are connected to the Internet. A key function of an ad network is to aggregate ad space supply (“inventory”) from publishers and to match it with advertiser demand.
An ad network includes an ad server which facilitates the placement of advertisements on connected screen devices. An ad server is a web server associated with a database that directs advertisements to connected screen devices that are displaying contents provided by a publisher. In some cases, a publisher is a website provider and in other cases the publisher can be an application or “app” running on the connected screen device, or even the operating system of the connected screen device itself. The advertiser pays for the placement of the ad, where payment is typically split between the ad network and the publisher.
In many cases, an ad network is connected to multiple demand sources. The various types of demand sources can be generally categorized as: 1) direct sold campaigns (e.g. advertising campaigns run on behalf of a particular company); 2) network demand sources (e.g. advertisements from an advertising exchange or other network source); and 3) house ads (also known as remnant or last minute advertising). While publishers typically desire to maximize their revenues, they may not know which demand source is the most profitable. For that reason, publishers or publisher networks may assign a priority to various demand sources.
The demand sources chosen and the priorities allocated among the demand sources tends to be based upon educated guesses and are often less than optimal. Publishers may manually vary their allocations from time-to-time in an attempt to achieve a given goal, e.g. optimizing revenue, increasing interactivity, increasing usability, etc. but this is an expensive and inaccurate methodology and one which is prone to error in that there are a great many variables that can affect the results.
Various examples are set forth herein for the purpose of illustrating various combinations of elements and acts within the scope of the disclosures of the specification and drawings. As will be apparent to those of skill in the art, other combinations of elements and acts, and variations thereof, are also supported herein.
In an embodiment, set forth by way of example and not limitation, a mediation recommendation system/method for multiple demand sources is provided by embedding a mediation enabled SDK into a client device. In this example, when the SDK makes an Ad Request, a mediation process is initiated on an Ad Server using an Ad Source Policy bucket and priority that is provided by the publisher associated with that Ad Request. Throughout the process of providing and playing the ad on the client device, data concerning the selection, receipt and play of the ad is gathered by the Ad Server and an associated Beacon server and stored on a database for analysis.
In an embodiment, set forth by way of example and not limitation, a recommendation engine can use the database described above, along with other information it may have at its disposal, to recommend a change in ad sources and/or percentage user allocation among ad sources using, for example, content based approaches, collaborative filtering approaches, or hybrids thereof. These recommendations can be of various types, including economic recommendations, ad source accuracy, ad source performance, diversity, etc., and can be in the form of an ordered list.
In an embodiment, set forth by way of example and not limitation, a mediation recommendation system includes: a user device having a first digital processor, a first non-transient computer readable media, and a first network interface, where the first computer readable media includes mediation-enabled client Software Design Kit (SDK) program instructions executable on the first digital processor to provide a mediation waterfall and to communicate via the first network interface; and a recommendation server including a second digital processor, a second non-transient computer readable media, and a second network interface, the second computer readable media including program instructions executable on the second digital processor to provide recommendations and to communicate via the second network interface.
In an embodiment, set forth by way of example and not limitation, a method for mediation and recommendation for multiple electronic demand sources includes: receiving at an advertisement (ad) server an ad request from a user device; initiating a mediation process on the ad server using an ad source policy and a priority that is provided with a publisher associated with the ad request; and providing 3rd party ad source recommendations to the user device.
An advantage of example systems and methods as disclosed herein is that certain publisher goals, e.g. revenue optimization, synergy with published content, etc., can be automatically addressed by providing recommendations to the publishers rather than requiring publishers to manually modify allocations and priorities of demand sources in an attempt to reach those goals.
These and other examples of combinations of elements and acts supported herein as well as advantages thereof will become apparent to those of skill in the art upon a reading of the following descriptions and a study of the several figures of the drawing.
Several examples will now be described with reference to the drawings, wherein like elements and/or acts are provided with like reference numerals. The examples are intended to illustrate, not limit, concepts disclosed herein. The drawings include the following figures:
The recommendation servers 12 can be implemented as a single server or as a number of servers, such as a server farm and/or virtual servers, as will be appreciated by those of skill in the art. Alternatively, the functionality of the recommendation servers 12 may be implemented elsewhere in the network system 10 such as on an advertiser server 14, as indicated at 12A, on the publisher server 16, as indicated at 12B, or as part as cloud computing as indicated at 12C, all being non-limiting examples. As will be appreciated by those of skill in the art, the processes of recommendation servers 12 may be distributed within network system 10.
In the example of
It should further be noted that, in some instances, an ad network is, essentially, transparent to advertisers, publishers or both. That is, an ad network may be considered to be a publisher or collection of publishers to an advertiser and/or an ad network may be considered to be an advertiser or collection of advertisers to a publisher.
The publisher servers 16 can each represent one or more servers, such as a server farm. In the example of
It should be noted that the selection of publishers can be enhanced by categorizing the publishers by, for example, content. That is, a “publisher” can be a single legal entity, or a subset of that entity, or a part of a group of entities, by way of several non-limiting examples. For example, a publisher entity may have 1000 publications of which 100 are directed to dramatic content, 100 are directed to comedy, etc. The subset of publications of the publisher entity having a common thematic content may be considered a “publisher.” Furthermore, “publishers” may include a group of publications provided by different agencies which conform to a theme such as, by way of non-limiting examples, drama, sports or entertainment. Also, as will be appreciated by those of skill in the art, publishers can also include application, app, operating system (OS) publishers operating on, for example, mobile user devices such as smartphones, tablet computers, etc.
User devices 18 can be any type of terminal, screen or device including, by way of non-limiting examples, a computer 18A, a connected TV (a/k/a Smart TV or CTV) 18D, a tablet 18B and a smartphone 18C. The distinguishing characteristics of user devices 18 include connectivity to the Internet 20 and display screens which can display, for example, advertisements delivered to the user devices over the Internet.
I/O devices such as mass storage 38, network interface 40, and other I/O 42. As will be appreciated by those of skill in the art, there are a number of computer readable media available to the microprocessor 24 such as the RAM 32, SRAM 34, VRAM 36 and mass storage 38. The network interface 40 and other I/O 42 also may include computer readable media such as registers, caches, buffers, etc. Mass storage 38 can be of various types including hard disk drives, optical drives and flash drives, to name a few.
Exchanges 50, in turn, can be coupled to one or more Advertisers 52, one or more Ad Networks 54, etc. It will be appreciated that the network of the Ad Fulfillment System 44 can include other computers, databases and servers, e.g. Advertisers 56 and 58 connected to the Ad Network 54. However, at some point latency becomes an issue in that the person using the user device will typically only wait for a short period of time for an advertisement before “clicking out” and moving on to another screen.
It will be appreciated that, in this non-limiting example, the Recommendation Server 12′ is the gateway for the fulfillment of the ad request by the user device 18. The request to the Recommendation Server 12′ can be accomplished, by way of example, with a customized ad network SDK (Software Development Kit) 19 which allows the user device 18 to send a request to the URL (Universal Resource Locator) of, in this example, Recommendation Server 12′. The SDK can, for example, be embedded in a player provided to the user device 18 by Publisher 16, A Request will include, as a minimum, the IP address of the user device 18 so that the Recommendation Server 12′ may send its Reply (e.g. the Priority List) back to the user device 18. However, the SDK may provide additional data concerning, by way of non-limiting example, the user, the user device, its environment and/or how it is being used to the Recommendation Server 12′.
When the user device 18 is a computer 18A, or another user device that can support a web browser, part of the Request can include what is known as a “cookie.” A cookie is a relatively small file of information about a user device which may include demographics, personal information, browser history, context and other information or Attributes that can help with the ad selection process. However, cookies are being increasingly disabled and/or blocked for privacy purposes and they are not generally used on user devices (such as many mobile devices) by application programs (“apps”) that don't implement a web browser.
As well known to those of skill in the art, a Web beacon is an object that is embedded in the advertisement that is usually invisible to a user but allows the detection of whether the user has viewed the advertisement. Typically, a Web beacon is small (e.g. 1×1 pixels) transparent gif image (or an image of the same color as the background) that is embedded into the HTML of the advertisement so that the viewing of the advertisement sends a Beacon Request to the Beacon server. The Ad Request data is stored by the Ad server 64 in a database 74 and the Beacon Request data is stored by the Beacon server 72 in the database 74.
The database 74 can be used by a Reporting module and a Recommendation module (“engine”) 78. A database 80 can be used to store the outputs of the Reporting model and the Recommendation module 78 for access by a Mediation Console 82. The database 80 is also used by a Mediated Target Placement cache 84 for targeted placements. The Mediation Module 66 is coupled to the Mediated Target Placement cache 84 and to a Mediation Enablement Front/back cache 86.
If a publisher provides an Ad Source Policy bucket 88 and priority to the Ad Server 64, then Mediation module 66 provides for the allocation of ads among the various demand sources. This will be referred to herein as a “Priority List.” In this example, a demand source Ad_Source_1 is allocated 50% of the ads, demand source Ad_Source_2 is allocated 25% of the ads, and demand source YuMe is allocated 25% of the ads as the Priority List. In this example, an Ad Request from SDK 19 at 62 will result in a Mediation Response Reply to the SDK 19 which can be handled, by way of non-limiting example, by a Mediation Waterfall process 90 which first tries Ad_Source_1, then Ad_Source_2, and then YuMe demand sources in order to fulfill the Ad Request. In an alternate example embodiment, a publisher can override the recommendation process and can manually set priorities with respect to demand sources.
The ordering of the Mediation Waterfall process 90 can be automatically changed by changing the Priority List, as will be appreciated by those of skill in the art, in response to the number of successful fulfillments from each of the demand sources. If the Mediation Waterfall process 90 is successful in fulfilling an Ad Request, the Ad is played at 70 and a Beacon Request is sent to the Beacon server 72 as described previously. Also, Waterfall activity data is sent to the Beacon server 72. This data at Beacon server 72 is processed as described above. If the Mediation Waterfall process is unsuccessful in fulfilling the Ad Request, an Ad Request Mediation Disabled is sent to the Standard Placement Decision 68 to be handled as described previously.
Recommendation systems have a number of properties including: {circle around (1)} user preference; {circle around (2)} prediction accuracy; {circle around (3)} coverage (e.g. publisher/demand source); {circle around (4)} confidence; {circle around (5)} trust (e.g. show recommendation for few demand sources that a publisher already knows and likes to build trust in the recommendation system); {circle around (6)} novelty; {circle around (7)} serendipity (e.g. a measure of how surprising the successful recommendation is); {circle around (8)} diversity; {circle around (9)} utility (e.g. many e-commerce sites employ in order to improve revenue, but also can be diversity or serendipity); {circle around (10)} risk (e.g. expected revenue but also minimize risk); {circle around (11)} robustness (e.g., can the system be gamed?); {circle around (12)} privacy (e,g. do the publisher's preferences remain private?); {circle around (13)} adaptability; and {circle around (14)} scalability (e.g. can it scale to thousands of publishers and tens of demand sources per publisher). Locations which address these properties in mediation recommendation system/method 60 are labeled accordingly.
It will therefore be appreciated that, in an embodiment set forth by way of example and not limitation, a mediation recommendation system/method 60 for multiple demand sources is provided by embedding a mediation-enabled SDK 19 into a client device 18. In this example, when the SDK 19 makes an Ad Request, a mediation process is initiated on an Ad Server 64 using an Ad Source Policy bucket and priority 88 that is provided by the publisher associated with that Ad Request. Throughout the process of providing and playing the ad on the client device, data concerning the selection, receipt and play of the ad is gathered by the Ad Server 64 and an associated Beacon server 72 and stored on a database 74 for analysis.
In an embodiment, set forth by way of example and not limitation, a Recommendation engine 78 can use the database 74, along with other information it may have at its disposal, to recommend a change in ad sources and/or allocation among ad sources using, for example, content based approaches, collaborative filtering approaches, or hybrids thereof. These recommendations can be of various types, including economic recommendations, recommendations to increase user interactivity and/or usability, etc.
Although various examples have been described using specific terms and devices, such description is for illustrative purposes only. The words used are words of description rather than of limitation. It is to be understood that changes and variations may be made by those of ordinary skill in the art without departing from the spirit or the scope of any examples described herein. In addition, it should be understood that aspects of various other examples may be interchanged either in whole or in part. It is therefore intended that the claims be interpreted in accordance with the true spirit and scope of the invention without limitation or estoppel.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/US14/64452 | 11/6/2014 | WO | 00 |
| Number | Date | Country | |
|---|---|---|---|
| 61900954 | Nov 2013 | US |
