Patent Grant
10237628
This patent application relates to systems and techniques for bidding advertisements in one or more communication networks such as the Internet.
Many companies seek to attract customers by promoting their products or services as widely as possible. Online video advertising is a form of promotion that uses the Internet and World Wide Web for delivering video advertisements to attract customers. Online advertising is often facilitated through companies called online advertising networks that connect advertisers to web sites that want to sell advertising space for displaying advertisements. Such an advertising network aggregates advertisement space supply from various websites (including on-line content publishers) and matches the aggregated advertisement space supply with advertiser demand. Advertisement exchanges are technology platforms used by online advertising networks for buying and selling online advertisements or advertisement impressions. Advertisement exchanges can be useful to both buyers (e.g., advertisers and ads agencies) and sellers (e.g., online publishers) because of the efficiencies and other advantages they provide. Various advertisement exchanges are, however, often limited by the types of advertisements they can buy and sell, their inventory sizes, and abilities in targeting specific viewers (e.g., potential customers).
The growing number of users accessing the Internet using video-playback capable wireless devices such as smartphones, tablet devices and laptop computers creates opportunities for large volumes of online video advertising and a demand for improvements to online video advertising.
The disclosed technology can be used in various implementations that facilitate communications with tracking and measurement third-party services and service providers in a real-time bidding (RTB) system for video advertisements. The disclosed implementations can be configured to provide a reliable and efficient client side component that interfaces with the third party service providers to enable generation and transmission of various video advertisement tracking and measurement operations. The disclosed implementations relate to various operations, devices and computer program products that enable acquisition of tracking and measurement results for an arbitrary period of time rapidly and efficiently, at any time and from any place.
For the purposes of illustration, the present application sometimes refers to existing industry standards or specifications as examples of how the disclosed techniques may be used in an RTB system. The disclosed technologies, however, can be used in various RTB systems beyond the specific RTB systems and/or standards mentioned in the examples of the present application.
BrightRoll Exchange (BRX) is an implementation of digital video advertisement exchange technologies by BrightRoll, Inc. (San Francisco, Calif.) and offers billions of monthly video advertising impressions, reaching millions of users on thousands of web sites and mobile applications on different user devices, such as mobile phones, tablets, laptop computers, desktop computers, Web-connected game machines and Web-connected TVs. Real-Time Bidding (RTB) allows buyers to bid on advertisement inventory using their own decision making technology for video ads on an impression-by-impression basis, moving buy-side advertisement decision making up in the delivery chain to the buyers own platform from the publisher's advertisement server or exchange. RTB enables buyers to decide whether to bid on a particular impression, how much they want to pay or which creative they want to deliver (unlike non-RTB models that require the buyer to serve an advertisement when the downstream advertisement server determines the impression meets the buyer's need, and the buyer only has an opportunity for creative optimization). The RTB auction platform evaluates all the bids, determines the winner and serves the winning creative.
In an exemplary RTB workflow, the publisher player makes a request for the ad service, and the ad servers respond with a Video Ad-Serving Template (VAST) document, where VAST is a specification by the Interactive Advertising Bureau (IAB) that provides a common ad response format for video players that enables video ads to be served across all compliant video players. In accordance with the disclosed embodiments, a VAST document provided by the RTB includes a media file that points to a Scout software module, which is a client-side component of the RTB system and is implemented to collect video ads activities on the client side. Further details of the Scout are provided below. The publisher player can load the Scout into itself using, e.g., the Video Player Ad-Serving Interface Definition (VPAID) specification. VPAID establishes a common interface between video players and ad units to allow interactive in-stream ad experiences and provides a communication protocol between video players and ad units to allow a single executable ad (one that requires software logic to be executed as part of ad playback) to be displayed in-stream with the publisher's video content, in a compliant video player. The Scout operates to provide various additional features and functionalities, depending the particular RTB procedure in use. As described below, a Scout can also be deployed in third party services or devices for RTB tracking and measurement functions.
Once playback of the advertisement on the client device starts, various parameters, actions and events may be tracked and measured. Such measurement and tracking is often carried out with the help of pixels that are fired upon occurrence of certain events associated with the video advertisements. The term “firing pixels” refers to triggering a communication request in form of an http request to a server that is going to log that request to indicate that some event has happened. For example, if it is desired to track that an ad impression has occurred, an http request with some parameters related to the ad can be generated to indicate actual occurrence of the video ad impression. The pixels are fired when a component at the user device recognizes that a qualified event has occurred, which triggers the notification of the appropriate server or entity. For example, firing pixels can be sending a signaling or notification to a destination provided by the third-party service provider to indicate occurrence of a predefined event as defined by the third-party service provider. These are critical to the BRX system and can be used to expedite billing, as well as monitoring the effectiveness of various ad campaigns as tracked by third-party service providers.
The following table provides a sample listing of events that can trigger firing of the pixels. In table below, the client-side component (i.e., the Scout) fires the pixels. As provided in the table below, the event behavior can be adjustable based on the type of file (e.g., a VPAID unit or a Video such as FLV). When parsing a VAST document, the Scout collects any tracking pixels provided and fires each of them upon receiving the corresponding event. The Scout may find and collect pixels at any number of levels while following VAST wrapper tags. The pixels are often fired in the order they were found. In any given VAST document, the Scout may find any number of pixels for each event type. All pixels are often fired in the order they were found. In the table below, Click-Tracking refers to tracking a user's actions of clicking on an advertisement that directs the user to another content, ad or website.
Other events and behaviors can be defined and implemented as needed through the use of the Scout and/or can be prescribed through third-party tools and services that are engaged with the client device and the RTB system. The information obtained from the tracking pixels (both from BRX and third-party VAST tags) is collected and analyzed at the BRX system and/or at third party services.
The third-party tracking and measurement services (e.g., Nielsen, comScore, Telemetry, etc.) provide various additional information such as demographic information about the users, popularity of video and audio content, effectiveness of an advertisement campaign, and other tracking and measurement services. The BRX system may use such third-party services to, for example, obtain age and demographic information for a site to facilitate the bidding process and placement of a video advertisement. To provide these services and functionalities, such third-party services often rely on information that is provided to them when a particular advertisement is selected to run on a particular website, and upon the occurrence of certain events, such as the extent the advertisement was viewed, user interactions with the advertisement and the like.
The disclosed technologies can be used to enable seamless integration of various third-party services with the BRX system by taking advantage of the Scout, and further receiving and processing the third-party data at the BRX system.
Referring again to
In the context of third-party services, after it is known which advertisement is going to play, the third-party tracking and measurements services are initialized. These third-party measurement tools and services are extendable; that is, new services and tools can be added or existing services can be removed. For example, a new Scout code, or a new configuration file associated with the Scout, can be provided to the client device to implement such changes to third-party services. Third-party tracking services may include their own libraries (e.g. JavaScript based libraries, SWFs, etc.) that can be loaded onto the Scout on the client-side to track the needed information. For instance, the Scout can embed or execute the third-party JavaScript. Once executed, the third-party library performs the prescribed actions for collecting information that is needed by the third-party service.
Once the data is provided to the third-party service (e.g., after the JavaScript transmits cookie information to Nielsen), the third-party service may conduct additional operations to accumulate, process and analyze the received information in conjunction with external data, if necessary. For example, a third-party service may conduct inquiries to other databases, social networks, etc. to obtain complementary information needed for achieving a particular tracking and measurement objective. The processed third-party tracking and measurement results are then provided to the BRX system (e.g., based on a campaign ID and site information). In such third-party service applications, the Scout provides information (e.g., fires tags) that populates campaign and advertising information in a variety of different third-party services.
In interactions with most third-party measurement services, the message exchange can be asymmetric in the context that the information is provided to the third-party service at a higher granularity but the results of third-party measurements are often only available at a lower level of granularity. However, such cumulative information may not accurately reflect the information needed by for a particular application and may further include singularities, outliers, or additional unwanted information that must be removed.
For example, a typical third-party service provider (e.g., Neilson) campaign can be provided to the BRX system for a particular monitoring interval that requires a start date and an end date. At the end of the monitoring interval, the third-party monitoring service provides the cumulative information for that period. For example, a particular set of information (e.g., the demographic of users of a certain webpage or certain video content) is provided for a 100-day period as cumulative numbers. Further, the third-party tracking and measurement results can only be provided for a maximum number of days (e.g., 100 days), after which the results are automatically reset and starts over again. One problem with such cumulative reporting is that demographics associated with certain websites may rapidly change and, therefore, a 100-day or a 50-day cumulative data may not accurately represent the fast-changing users' demographics for advertisement placement in an RTB system.
In some exemplary embodiments, such shortcomings can be alleviated by specifying multiple requests for third-party services (e.g., one request on a daily basis). Using the tracking and measurement results corresponding to those requests, tracking and measurement results for an arbitrary time interval can be obtained. For instance, by subtracting the cumulative results for day n−1 from day n, non-cumulative data for a single day is obtained. In another example, subtracting the cumulative results for day n−14 from day n, non-cumulative data for a 14-day period ending with day n is obtained. The above described processing can be used to, for example, obtain the total number of views for a particular period.
In some embodiments, additional data processing is provided to account for the switch-over or re-setting of data at the end of a monitoring interval. As noted earlier, some third party services provide such cumulative data for a maximum number of days (e.g., 100 days), after which the accumulation of the data is reset. Therefore, subtracting the tracking and measurement numbers for day n−1 from day n may result in a negative number (which is not correct). In some embodiments, the processing of the tracking measurement results can be adjusted to account for such switch-over or reset periods.
In other exemplary embodiments, additional operations needed to obtain the information appropriate for the BRX system include determining the number of unique viewers. To this end, the total number of views is divided by a “frequency” parameter which is the average number of times that individual viewers have actually seen a particular ad. This information is sometimes referred to as “uniques.”
Other data provided by the third-party services includes what is called the “Universe,” which represents the overall information about particular demographic segments. For example, if the BRX system is interested in male viewers between the ages of 12 and 17 on a particular day, the universe could indicate that, on this particular day, there were 1 million male viewers between the ages of 12 to 17. Such information, when processed in conjunction with the uniques, allows other numbers and parameters to be obtained. For example, if there are 1 million males in the 12-17 year age group, 100 impressions (views) of a particular ad with a frequency of 4, on average, the reach of the ad within this age group is (100/4)/1,000,000 or 0.0025%.
Moreover, the results generated by the third-party services, although in cumulative format, do not always increase from one day to the next. For example, subtracting the numbers for day n−1 from numbers for day n may sometimes result in a negative number. This inconsistency can be partly due to various normalization procedures that are undertaken by the third-party services. For example, if any one impression becomes too high, certain normalization operations are conducted by some third party service providers, which can result in the next cumulative number to be less than the previous number. In some embodiments, when processing the third-party data, such anomalies due to normalization procedures are identified and corrected to provide consistent and accurate numbers.
The disclosed technologies can generate tracking and measurement numbers either on a daily basis or over other desired period of time, even though the third-party services only provide data on a cumulative basis, with switch over periods, and retroactive normalizations that can greatly reduce the utility and ease-of-use of such data. To this end, the cumulative measurement and tracking results obtained from the third-party services are processed at the BRX system to remove various inconsistencies and provide the processed tracking and measurement information with flexibility based on needs of the BRX system and its customers.
In some scenarios, the third-party services provide their data in the form of a file (e.g., comma separate values (CSV)) at an uncertain time during a particular time interval (e.g., a particular day). Typically, such files are pulled from the third-party services. In some embodiments, the third-party services interface is configured to place such data files at a location in the cloud. This way, the third-party data can be accessed by the RTB system at any time and at any location. To provide further context for this feature, it should be appreciated that, at any given time, the RTB system is processing a large volume of bids, e.g., millions of bids, for advertisements and the associated signaling. At the same time, user devices fire a large number of pixels, e.g., millions of pixels, at the third-party services or the BRX system, while the associated tracking and measurement results are provided by the third-party services for BRX system ingestion. Further, such user devices are located throughout disparate geographic locations (e.g., worldwide). By configuring the system to locate the measurement and tracking data in the cloud, the BRX system is capable of accessing such large volumes of data rapidly and efficiently from any place and at any time.
The ad server 304 may perform functions such as handling incoming ad requests from multiple ad viewer devices 302, and may respond with an ad or a “no ad” placement. The ad server 304 may operate on a time budget, e.g., 50 to 800 msec., within which it responds to an ad request. The ad server 304 may provide ad data to the viewer device 302 using VAST format. The decision about which advertisement to be sent may be based on various factors and real time data such as publisher placement, uniform resource locator (URL), a geographic location of the viewer device, time of day, demographic segment to which the viewer belongs, and so on.
When the ad server 304 receives a video placement request from the viewer's device 302, the ad server 304 may pass on the request to two or more bid servers 310. The request may include information about the viewer, the viewer's demographic profile and other rules associated with the ad placement opportunity that may influence the selection of a winning bid. In some embodiments, the front end ad servers 304, bid servers 310 and the administrator's console 308 may be part of a video ad insertion platform 312 offered by a single vendor, e.g., the BRX platform offered by Brightroll, Inc.
The bid servers 310 in turn request bids from multiple third party bidders 306. When bids are received from third party bidders 306, or at the end of a time period (e.g., 90 milliseconds), a decision is made about the winning bid. In some embodiments, the winning bid not only will have the highest dollar value but also should match the demographic profile of the viewer. For example, if the viewer is on the West coast, an advertisement for users on East coast may not be allowed to win bid even when the third party bidder bids the highest dollar value. The winning bidder is then notified for winning the bid. The winning bidder is provided with information to allow the winning bidder to transmit a video advertisement to the viewer.
As noted previously, the Scout (not shown in
Certain aspects of the disclosed technologies can be implemented as a device that includes a processor and a memory comprising processor executable code. The processor executable code, when executed by the processor, configures the device, including the components therein, to perform any one of and/or all operations that are described in the present application. For example,
Various embodiments described herein are described in the general context of methods or processes, which may be implemented in one embodiment by a computer program product, embodied in a computer-readable medium, including computer-executable instructions, such as program code, executed by computers in networked environments. A computer-readable medium may include removable and non-removable storage devices including, but not limited to, Read Only Memory (ROM), Random Access Memory (RAM), compact discs (CDs), digital versatile discs (DVD), Blu-ray Discs, etc. Therefore, the computer-readable media described in the present application include non-transitory storage media. Generally, program modules may include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of program code for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps or processes.
For example, one aspect of the disclosed embodiments relates to a computer program product that is embodied on a non-transitory computer readable medium. The computer program product includes program code for carrying out any one or and/or all of the operations of the disclosed embodiments.
The foregoing description of embodiments has been presented for purposes of illustration and description. The foregoing description is not intended to be exhaustive or to limit embodiments of the present invention to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments. The embodiments discussed herein were chosen and described in order to explain the principles and the nature of various embodiments and their practical application to enable one skilled in the art to utilize the present invention in various embodiments and with various modifications as are suited to the particular use contemplated. The features of the embodiments described herein may be combined in all possible combinations of methods, apparatus, modules, systems, and computer program products.
This application claims the benefit of U.S. Provisional Patent Application No. 61/935,320, filed on Feb. 3, 2014, and which is incorporated by reference herein in its entirety.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5929849 | Kikinis | Jul 1999 | A |
| 8473997 | Qiu | Jun 2013 | B2 |
| 8478250 | Rao | Jul 2013 | B2 |
| 8578412 | Van Vleck | Nov 2013 | B2 |
| 8713603 | Kilar | Apr 2014 | B2 |
| 8782696 | Moonka | Jul 2014 | B2 |
| 8799951 | Hamilton | Aug 2014 | B1 |
| 8832745 | Stallings | Sep 2014 | B2 |
| 8850471 | Kilar | Sep 2014 | B2 |
| 8997150 | Kilar | Mar 2015 | B2 |
| 9712585 | Lohmar | Jul 2017 | B2 |
| 10037546 | Benisch | Jul 2018 | B1 |
| 20010001160 | Shoff | May 2001 | A1 |
| 20020104090 | Stettner | Aug 2002 | A1 |
| 20030149975 | Eldering | Aug 2003 | A1 |
| 20050060232 | Maggio | Mar 2005 | A1 |
| 20060168619 | Reams | Jul 2006 | A1 |
| 20060212355 | Teague | Sep 2006 | A1 |
| 20060294538 | Li | Dec 2006 | A1 |
| 20070214049 | Postrel | Sep 2007 | A1 |
| 20080066107 | Moonka et al. | Mar 2008 | A1 |
| 20080189215 | Travez | Aug 2008 | A1 |
| 20090307732 | Cohen | Dec 2009 | A1 |
| 20090316688 | Meenavalli | Dec 2009 | A1 |
| 20100031162 | Wiser | Feb 2010 | A1 |
| 20110055864 | Shah | Mar 2011 | A1 |
| 20110078305 | Varela | Mar 2011 | A1 |
| 20110078718 | Jakobi | Mar 2011 | A1 |
| 20120060188 | Stallings | Mar 2012 | A1 |
| 20120072949 | Rakshit | Mar 2012 | A1 |
| 20120110616 | Kilar | May 2012 | A1 |
| 20120144416 | Wetzer | Jun 2012 | A1 |
| 20120240177 | Rose | Sep 2012 | A1 |
| 20130074131 | Cerveau | Mar 2013 | A1 |
| 20130081073 | Kang | Mar 2013 | A1 |
| 20130205326 | Sinha | Aug 2013 | A1 |
| 20140173038 | Newton | Jun 2014 | A1 |
| 20140201126 | Zadeh | Jul 2014 | A1 |
| 20140250457 | Ramaswamy | Sep 2014 | A1 |
| 20140351835 | Orlowski | Nov 2014 | A1 |
| 20140380346 | Jagtiani | Dec 2014 | A1 |
| 20150046935 | Wei | Feb 2015 | A1 |
| 20150181306 | Innes | Jun 2015 | A1 |
| 20160029061 | Pizzurro | Jan 2016 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 20150222961 A1 | Aug 2015 | US |
| Number | Date | Country | |
|---|---|---|---|
| 61935320 | Feb 2014 | US |
