HK1208298B - Methods and apparatus to determine ratings information for online media presentations - Google Patents

Description

Method and apparatus for determining audience rating information for online media presentations

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent claims priority to U.S. Non-Provisional Patent Application No. 14/025,575, filed September 12, 2013, and U.S. Provisional Patent Application No. 61/817,829, filed April 30, 2013. U.S. Non-Provisional Patent Application No. 14/025,575 and U.S. Provisional Patent Application No. 61/817,829 are incorporated by reference in their entirety.

Technical Field

The present disclosure relates generally to monitoring media and, more particularly, to methods and apparatus for determining ratings information for online media presentations.

Background Art

Traditionally, audience measurement entities determine audience engagement levels for media programs based on registered panel membership. Specifically, the audience measurement entity recruits individuals who agree to be monitored into a panel. The audience measurement entity then monitors those panel members to determine the media programs (e.g., television or radio programs, movies, DVDs, etc.) to which those panel members are exposed. This allows the audience measurement entity to determine exposure measures for various media content based on the collected media measurement data.

Over the years, the technology for monitoring users' access to Internet resources (e.g., web pages, advertisements, and/or other content) has evolved significantly. Some known systems primarily perform such monitoring through server logs. Specifically, entities that provide content services on the Internet may use known techniques to record (log) the number of requests received for their content at their servers.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts an example system that may be used to determine the audience for an advertisement using distributed demographic information.

2 depicts an example system that can be used to correlate media exposure measurements with user demographic information based on demographic information distributed across user account records at different network service providers.

3 is a communication flow diagram of an example manner in which a client application may report impressions to a server that has access to demographic information of a user of the client application.

FIG4 depicts an example of a ratings entity impression table showing the volume of impressions of monitored users.

FIG. 5 depicts an example campaign-level age/gender and impression composition table per media cycle generated by the database proprietor.

FIG6 depicts another example campaign-level age/gender and impression composition table per media cycle generated by the ratings entity.

FIG. 7 depicts an example per-media-cycle combination campaign-level age/gender and impression composition table based on the composition tables of FIG. 5 and FIG. 6 .

8 depicts an example age/gender impression distribution table showing impressions based on the per-media period composition table of FIGs. 5-7.

9 is a flow diagram representative of example machine readable instructions that may be executed to identify demographic data attributed to an impression.

10 is a flow diagram representative of example machine readable instructions that may be executed by a client device to route a beacon request to a network service provider to record an impression.

11 is a flow diagram representative of example machine readable instructions that may be executed by a panelist monitoring system to record impressions and/or redirect beacon requests to a network service provider to record impressions.

12 is a flow diagram representative of example machine readable instructions that may be executed to dynamically designate a preferred network service provider from which to request demographic data attributable to an impression.

FIG. 13 depicts an example system that may be used to determine advertising exposure based on demographic information collected by one or more database owners.

14 is a flow diagram representative of example machine readable instructions that may be executed to process a redirected request at an intermediary.

15 is a flow diagram representative of example machine readable instructions that may be executed by a client device to send a beacon request to an impression monitor and a database owner.

16 is a flow diagram representative of example machine readable instructions that may be executed by a panelist monitoring system to record beacon requests and/or calculate viewership information based on beacon requests and demographic information.

FIG17 depicts an example impression log for recording impressions for user IDs and media IDs.

18 is an example processor system that may be used to execute the example instructions of FIG. 9 , FIG. 10 , FIG. 11 , FIG. 12 , FIG. 14 , FIG. 15 , and/or FIG. 16 to implement the example devices and systems described herein.

DETAILED DESCRIPTION

Over the years, the technology for monitoring user access to Internet resources such as web pages, advertisements, and/or other media (e.g., audio, video, interactive content, etc.) has evolved significantly. In the past, this monitoring was primarily performed using server logs. Specifically, an entity providing content services on the Internet would record the number of requests received for its content at its server. Conducting Internet usage surveys based on server logs is problematic for a number of reasons. For example, server logs may be tampered with directly or via zombie programs, which repeatedly request content from the server, thereby increasing server log counts. Secondly, content is typically retrieved once, cached locally, and then repeatedly viewed from the local cache, without involving the server during the repeated viewings. Server logs cannot track the viewing of these cached contents. Therefore, server logs are prone to both overcounting and incomplete counting.

The invention disclosed in Blumenau's U.S. Patent 6,108,637 fundamentally changes the way Internet monitoring is performed and overcomes the limitations of the aforementioned server-side log monitoring techniques. For example, Blumenau discloses a technique in which beacon instructions are used to mark Internet content to be tracked. Specifically, the monitoring instructions are associated with the HTML of the content to be tracked. When a client requests the content, both the content and the beacon instructions are downloaded to the client. Therefore, each time the content is accessed (whether from the server or from a cache), the beacon instructions are executed.

The beacon instructions cause monitoring data reflecting information about access to content to be sent from the client that downloaded the content to a monitoring entity. Typically, the monitoring entity is an audience measurement entity that does not provide the content to the client and is a trusted third party that provides accurate usage statistics (e.g., Nielsen Company, LLC). Advantageously, because the beacon instructions are associated with the content and are executed by the client application each time the content is accessed, monitoring information is provided to the audience measurement company regardless of whether the client is a panel member of the audience measurement company.

However, it is important to link demographic data to monitoring information. To address this issue, audience measurement companies establish panels of users who agree to provide their demographic information and have their internet browsing activity monitored. When individuals join the panel, they provide the audience measurement company with detailed information about their identity and demographic data (e.g., gender, race, income, home address, occupation, etc.). The audience measurement entity sets web tracking information (cookies) on the panel member's client device, which enables the audience measurement entity to identify the panel member each time the panel member accesses tagged content, thereby sending monitoring information to the audience measurement entity.

Because most clients providing monitoring information from tagged pages are not panelists and are therefore unknown to audience measurement entities, it is necessary to use statistical methods to attribute demographic information based on data collected for panelists to the larger user population providing data for the tagged content. However, the panel size of audience measurement entities is still small compared to the general user population. Therefore, the question arises: how to increase the panel size while ensuring that the panel's demographic data is accurate?

There are many database owners operating on the Internet. These database owners provide services to a large number of subscribers. In exchange for providing services, subscribers register with the owner. As part of this registration, subscribers provide detailed demographic information. Examples of these database owners include social network providers (e.g., Facebook, Myspace, etc.). These database owners set cookies on their subscribers' devices to enable the database owners to identify users when they visit their website.

Internet protocols make cookies inaccessible outside the domain (e.g., Internet domain, domain name, etc.) in which they are set. Thus, a cookie set in the amazon.com domain is accessible to servers in the amazon.com domain, but inaccessible to servers outside that domain. Thus, while audience measurement entities might find it advantageous to access cookies set by database owners, they are unable to do so.

Given this, audience measurement companies are looking to leverage database owners' existing databases to gather broader internet usage and demographic data. However, achieving this goal presents audience measurement entities with several challenges. For example, the question arises of how to access the database owner's data without compromising the privacy of subscribers, panelists, or owners of the tracked content. Another challenge is accessing this data despite technical limitations imposed by internet protocols that prevent audience measurement entities from accessing cookies set by database owners. The example methods, devices, and products disclosed herein address these challenges by extending beacon processing to include partner database owners and leveraging these partners as temporary data collectors.

Example methods, devices, and/or products disclosed herein accomplish this by responding to a beacon request from a client accessing tagged content (which may not be a member of the audience member panel and, therefore, may be unknown to the audience member entity) by redirecting the client from the audience measurement entity to a database owner (e.g., a social networking site) partnered with the audience member entity. This redirection initiates a communication session between the client accessing the tagged content and the database owner. The database owner (e.g., Facebook) can access any cookies it has set on the client to identify the client based on the database owner's internal records. If the client is a subscriber of the database owner, the database owner logs the content impression in association with the client's demographic data and then forwards the log to the audience measurement company. If the client is not a subscriber of the database owner, the database owner redirects the client to the audience measurement company. The audience measurement company can then redirect the client to a second, different database owner partnered with the audience measurement entity. This second owner can then attempt to identify the client as described above. This process of redirecting the client from database owner to database owner can be repeated any number of times until the client is identified and the content impression is recorded, or until all partners have been contacted without successfully identifying the client. The redirection all happens automatically, so the user of the client is not involved in the various communication sessions and may not even be aware that they are occurring.

Partnering database owners provide their log and demographic information to the audience measurement entity, which then compiles the collected data into statistical reports that accurately identify the demographics of the people who accessed the tagged content. Because clients are identified against a vast database of users far exceeding the number of people in traditional audience measurement panels, the data derived from this process is extremely accurate, reliable, and detailed.

Significantly, because the audience measurement entity remains the first stop in the data collection process (e.g., receiving a request from the client via a beacon instruction), the audience measurement entity is able to obfuscate the source of recorded content accesses and the identity of the content itself from the database owner (thereby protecting the privacy of the content source) without compromising the database owner's ability to record impressions of its subscribers. Additionally, Internet secure cookie protocols are adhered to, as only servers associated with the Internet domain that set the cookie (e.g., Facebook.com) can access a given cookie.

The example methods, devices, and products described herein can be used to utilize demographic information distributed across different databases on the Internet (e.g., different website owners, service providers, etc.) to determine content impressions, ad impressions, content exposure, and/or ad exposure. The example methods, devices, and products disclosed herein not only enable Internet ad exposure to be more accurately correlated with demographic data, but also effectively expand the size and composition of panels beyond those of participating audience measurement entities and/or ratings entities to include people registered in other Internet databases (e.g., databases of social media sites such as Facebook, Twitter, Google, etc.). This expansion effectively leverages the content tagging capabilities of ratings entities and the use of databases of non-ratings entities (e.g., social media and other websites) to create large, demographically accurate panels, thereby obtaining accurate and reliable measurements of exposure to Internet content such as advertisements and/or programs.

In the illustrated examples disclosed herein, ad exposure is measured in terms of online gross rating points. Gross rating points (GRPs) are a unit of measurement for audience size traditionally used in the context of television ratings. They are used to measure exposure to one or more programs, advertisements, or commercials, without involving multiple exposures of an individual to the same advertisement. For television (TV) advertising, one GRP is equal to 1% of TV households. Although GRPs have traditionally been used as a metric for television audiences, the example methods, devices, and products disclosed herein develop online GRPs for online advertising to provide standardized metrics that can be used across the entire internet to accurately reflect online ad exposure. These standardized online GRP measurements can provide advertisers with greater confidence that their online advertising spend is worthwhile. They can also facilitate cross-media comparisons of audiences for TV and online ads, such as those for TV and online ads. Because the example methods, devices, and/or products disclosed herein associate audience measurements with corresponding demographic data of users, the information collected by the example methods, devices, and/or products disclosed herein can also be used by advertisers to identify the markets reached by their ads and/or target specific markets for future advertising.

Traditionally, audience measurement entities (also referred to herein as "ratings entities") determine the demographic reach of advertisements and media programs based on registered panelists. That is, the audience measurement entity recruits individuals who consent to being monitored into a panel. During recruitment, the audience measurement entity receives demographic information from the recruited individuals, allowing it to subsequently correlate the advertising/media exposure of those panelists with different demographic markets. Unlike traditional techniques in which audience measurement entities rely solely on their own panelist data to gather demographic-based audience measurements, the example methods, devices, and/or products disclosed herein enable audience measurement entities to share demographic information with other entities operating based on a user registration model. As used herein, a user registration model is a model in which users subscribe to the services of those entities by creating an account and providing demographic-related information about themselves. Sharing demographic information associated with a database owner's registered users enables audience measurement entities to expand or supplement their panel data with substantially reliable demographic information from external sources (e.g., the database owner), thereby expanding the coverage, accuracy, and/or completeness of their demographic-based audience measurements. This access also enables audience measurement entities to monitor individuals who were not originally enrolled in an audience measurement panel. Any entity that has a database that identifies demographic data for a group of individuals can collaborate with an audience measurement entity. These entities may be referred to as "database owners" and include entities such as Facebook, Google, Yahoo!, MSN, Twitter, Apple iTunes, Experian, etc.

The example methods, devices, and/or products disclosed herein may be implemented by an audience measurement entity (e.g., any entity concerned with measuring or tracking audience exposure to advertising, content, and/or any other media) that collaborates with any number of database owners (e.g., online network service providers) to develop an online GRP. These database owners/online network service providers may be social networking sites (e.g., Facebook, Twitter, MySpace, etc.), multi-service sites (e.g., Yahoo!, Google, Experian, etc.), online retailer sites (e.g., Amazon.com, Buy.com, etc.), and/or any other network service site that maintains user registration records.

To increase the likelihood that measured audiences are accurately attributed to the correct demographic data, the example methods, devices, and/or products disclosed herein use demographic information from records at an audience measurement entity and demographic information at one or more database owners (e.g., network service providers) that maintain records or profiles of users with their accounts. Thus, the example methods, devices, and/or products disclosed herein can be used to supplement demographic information maintained by a ratings entity (e.g., an audience measurement company such as The Nielsen Company (Schaumburg, IL, USA) that collects media exposure measurements and/or demographic data) with demographic information from one or more different database owners (e.g., network service providers).

Using demographic information from different data sources (e.g., high-quality demographic information from a panel of audience measurement companies and/or registered user data from network service providers) improves the effectiveness of metric reporting for both online and offline advertising campaigns. The example technology disclosed herein uses online registration data to identify user demographics and uses server impression counting, tags (also known as beacons), and/or other technologies to track the number of impressions attributable to those users. Online network service providers such as social networking sites (e.g., Facebook) and multi-service providers (e.g., Yahoo!, Google, Experian, etc.) (collectively and individually referred to herein as online database owners) maintain detailed demographic information (e.g., age, gender, geographic location, race, income level, education level, religious beliefs, etc.) collected via user registration processes. As used herein, an impression is defined as an event in which a household or individual is exposed to media (e.g., an advertisement, content, a group of advertisements, and/or a collection of content). In Internet advertising, the number of impressions or impression count is the total number of times a media (e.g., content, advertisement, and/or advertising campaign) is accessed by the network population (e.g., the number of times the media is accessed). As used herein, demographic impressions are defined as impressions that are associated with characteristics (eg, demographic characteristics) of people exposed to media.

The example methods, devices and/or products disclosed herein can also report TV GRP and online GRP in a parallel manner.For example, the counting disclosed herein enables advertisers to report the number of individuals and users reached individually and/or collectively by TV and/or online ads.

The example methods, devices, and/or products disclosed herein also collect impressions mapped to demographic data at various locations on the internet. For example, an audience measurement entity collects impression data for its panel and automatically recruits one or more online demographic data owners to collect impression data for their subscribers. By combining this collected impression data, the audience measurement entity can then generate demographic impression data and GRP metrics for different advertising campaigns. These GRP metrics can be correlated or associated with specific demographic segments and/or markets targeted.

The example methods and apparatus disclosed herein determine audience demographics for media (e.g., video or audio) presented over a period of time. Since not all users who begin viewing a video will view the entire video, for example, the audience demographics for the first minute of a 30-minute video presented over the Internet may be different from the audience demographics for the 25th minute of the video.

The example methods and apparatus disclosed herein measure demographic data of media over a period of time by providing instructions to a client application (e.g., a web browser, an application, etc.) executing on a client computing device when the web browser loads the media. In some examples, the instructions cause the web browser to send requests (e.g., pingback messages) to an impression monitoring server at regular and/or irregular intervals (e.g., every minute, every 30 seconds, every 2 minutes, etc.). The example impression monitoring server identifies the request from the web browser and, in combination with one or more database owners, matches the impression information of the media with the demographic data of the user of the web browser.

In the example, a user loads a web page from a website publisher, where the web page corresponds to a specific 60-minute video. As part of the example web page, or in addition to the example web page, the publisher provides beacon instructions and/or causes the web browser to send pingback messages to a beacon server. When the beacon instructions are loaded by the example web browser, the beacon instructions cause the web browser to send pingback messages (e.g., HTTP requests, pings) to the impression monitoring server at specified intervals (e.g., once per minute). The example beacon instructions (or redirect messages from, for example, the impression monitoring server or database owner) also cause the web browser to send pingback messages to one or more database owners that collect and/or maintain demographic information about the user. The database owner sends the demographic information about the user associated with the web browser for combination with the impression determined by the impression monitoring server. If the user closes the web page containing the video before the video ends, the beacon instructions cease, and the web browser stops sending pingback messages to the impression monitoring server. By determining the number and/or content of the pingback messages received, the example impression monitor can determine that the user watched a video of a specific length.

The example methods and apparatus disclosed herein match impressions and/or persistent impressions (e.g., impression information over a period of time derived from a set of recorded impressions) of media at a web browser (e.g., a period of time in which a user is exposed to media via a web browser) to demographic information collected by a database owner. By matching impressions and/or persistent impressions to demographic data, the example methods and apparatus disclosed herein determine demographic impression characteristics of the audience (e.g., the audience at the first minute, the audience at the second minute, etc.) for each minute (or each period, where the period can be of any length) of the video.

In some examples, a web page enables a user to jump to a specific portion of a video (e.g., to pick up where they left off earlier). Upon detecting a jump request, example beacon instructions cause the web browser to issue a request to an impression monitoring server that includes the time the jump request was made and the time relative to the video to which the user was jumped. Upon receiving the request, the example impression monitoring server determines the time the user viewed the media. Thus, for example, the impression monitoring server may determine that the user viewed the last 15 minutes of a video, rather than the first 15 minutes of the video, or that the user viewed an intermittent portion or subset of the video.

The example methods, devices, and products disclosed herein are described as using cookies to store information locally on a client device and/or provide such stored information to another party or device. However, the example methods, devices, and products disclosed herein may additionally or alternatively utilize alternatives to cookies to store and/or communicate information. Examples of these alternatives include network storage, document object model (DOM) storage, local shared objects (also known as "Flash cookies"), media identifiers (e.g., iOS advertising IDs), user identifiers (e.g., Apple user IDs, iCloud user IDs, Android user IDs), and/or device identifiers (Apple device IDs, Android device IDs, device serial numbers, media access control (MAC) addresses, etc.).

FIG1 depicts an example system 100 that can be used to determine media exposure (e.g., exposure to content and/or advertising) based on demographic information collected by one or more database owners. "Distributed demographic information" is used herein to refer to demographic information obtained from at least two sources, at least one of which is a database owner (e.g., an online network service provider). In the illustrated example, content providers and/or advertisers distribute advertisements 102 via the Internet 104 to users accessing websites and/or online television services (e.g., WebTV, Internet Protocol TV (IPTV), etc.). Advertisements 102 may also or alternatively be distributed to traditional non-Internet-based (e.g., RF, terrestrial, or satellite) television sets via broadcast television services and be targeted to viewers using the techniques described herein and/or other techniques. Websites, movies, television programs, and/or other programs are generally referred to herein as content. Advertisements are typically distributed with the content. Traditionally, providing content to audiences has been virtually cost-free because it is sponsored by advertisers who pay to have their advertisements distributed with the content.

In the example shown, advertisement 102 may form one or more advertising campaigns and is encoded with identification codes (e.g., metadata) that identify the associated advertising campaign (e.g., a campaign ID), a creation type ID (e.g., identifying a Flash-based ad, a banner ad, a luxury ad, etc.), a source ID (e.g., identifying the publisher of the ad), and a placement ID (e.g., identifying the physical placement of the ad on the screen). Advertisement 102 is also tagged or encoded to include computer-executable beacon instructions (e.g., Java, JavaScript, or any other computer language or script) that are executed by a web browser accessing advertisement 102, for example, on the Internet. The computer-executable beacon instructions may additionally or alternatively be associated with the content to be monitored. Therefore, while this disclosure frequently discusses tracking advertisements, it is not limited to tracking any particular type of media. Rather, it can be used to track any type or form of content or advertisement across a network. Regardless of the type of content being tracked, execution of the beacon instructions causes the web browser to send one or more impression requests (e.g., referred to herein as beacon requests) to a designated server (e.g., an audience measurement entity). The beacon requests may be implemented as HTTP requests. However, while the HTML request sent identifies a web page or other resource to be downloaded, the beacon request includes audience measurement information (e.g., an advertising campaign identifier, a content identifier, user identification information, a timestamp, and/or a jump location in the media) as its payload. The server to which the beacon request is directed is programmed to record the audience measurement data of the beacon request as impressions (e.g., advertising and/or content impressions, depending on the nature of the media tagged with the beacon instructions). For example, for static types of media (e.g., banner ads), an impression may include a single impression count. In contrast, for dynamic types of media (e.g., audio, video, and/or interactive media), a persistent impression may include impressions associated with one or more time periods corresponding to all or a portion (e.g., a subset) of the media.

In some example implementations, advertisements tagged with these beacon instructions can be distributed with Internet-based media content (including, for example, web pages, streaming video, streaming audio, IPTV content, etc.) and used to collect demographic-based impression data. As mentioned above, the methods, devices, and/or products disclosed herein are not limited to advertisement monitoring, but can be adapted for monitoring any type of content (e.g., web pages, movies, television programs, etc.). Example techniques that can be used to implement these beacon instructions are disclosed in U.S. Patent No. 6,108,637 to Blumenau, which is incorporated herein by reference in its entirety.

Although example methods, apparatuses, and/or products are described herein as using beacon instructions executed by a web browser to send beacon requests to a designated impression collection server, example methods, apparatuses, and/or products may alternatively utilize an on-device statistics system to collect data that locally collects web browsing information without relying on content or advertisements encoded or tagged with beacon instructions. In these examples, the locally collected web browsing behavior can then be correlated with user demographic data based on a user ID as disclosed herein.

The example system 100 of FIG. 1 includes a ratings entity subsystem 106, a partner database owner subsystem 108 (implemented in this example by a social network service provider), other partner database owner (e.g., network service provider) subsystems 110, and non-partner database owner (e.g., network service provider) subsystems 112. In the illustrated example, ratings entity subsystem 106 and partner database owner subsystems 108 and 110 correspond to partner business entities that have agreed to share demographic information and capture impressions (as described below) in response to redirected beacon requests. Partner business entities may participate to advantageously confirm and/or increase the accuracy and/or completeness of their respective demographic information. Partner business entities also participate in reporting impressions that occur on their websites. In the illustrated example, other partner database owner subsystem 110 includes similar or identical components, software, hardware, and/or processing as partner database owner subsystem 108 to collect and record impressions (e.g., ad and/or content impressions) and associate demographic information with these recorded impressions.

The non-cooperative database owner subsystems 112 correspond to business entities that do not participate in sharing demographic information. However, the techniques disclosed herein track impressions (e.g., ad impressions and/or content impressions) that can be attributed to the non-cooperative database owner subsystems 112, and in some cases, one or more of the non-cooperative database owner subsystems 112 also report unique user IDs (UUIDs) that can be attributed to different impressions. The unique user IDs can be used to identify demographic data with demographic information maintained by cooperating business entities (e.g., ratings entity subsystem 106 and/or database owner subsystems 108, 110).

In the example of FIG1 , database owner subsystem 108 is implemented by a social network owner (e.g., Facebook). However, database owner subsystem 108 may alternatively be operated by any other type of entity (e.g., a network service entity providing services to desktop/stationary computer users and/or mobile device users). In the illustrated example, database owner subsystem 108 is located in a first Internet domain, and collaborating database owner subsystems 110 and/or non-collaborating database owner subsystems 112 are located in second, third, fourth, and so on, Internet domains.

1 , tracked content and/or advertisements 102 are presented to TV and/or PC (computer) panelists 114 and online-only panelists 116. Panelists 114 and 116 are users registered in panels maintained by a ratings entity (e.g., an audience measurement company) that owns and/or operates ratings entity subsystem 106. In the example of FIG1 , TV and PC panelists 114 include users and/or households monitored for exposure to content and/or advertisements 102 on a TV and/or computer. Online-only panelists 116 include users monitored for exposure (e.g., content exposure and/or advertisement exposure) via online sources while at work or at home. In some example implementations, TV and/or PC panelists 114 may be home-centric users (e.g., homemakers, students, teenagers, children, etc.), while fully online panelists 116 may be work-centric users who typically connect to work-provided Internet services via office computers or mobile devices (e.g., mobile phones, smartphones, laptops, tablets, etc.).

To collect exposure measurements (e.g., content impressions and/or ad impressions) generated by meters at client devices (e.g., computers, mobile phones, smartphones, laptops, tablets, TVs, etc.), the ratings entity subsystem 106 includes a ratings entity collector 117 and a loader 118 that perform collection and loading processes. The ratings entity collector 117 and the loader 118 collect exposure measurements obtained via the panelists 114 and 116 and store the collected exposure measurements in a ratings entity database 120. The ratings entity subsystem 106 then processes and filters the exposure measurements based on business rules 122 and organizes the processed exposure measurements into a TV & PC summary table 124, an online home (H) summary table 126, and an online work (W) summary table 128. In the example shown, summary tables 124, 126, and 128 are sent to a GRP report generator 130, which generates one or more GRP reports 131 to be sold or otherwise provided to advertisers, publishers, manufacturers, content providers, and/or any other entities related to such market research.

In the example shown in FIG1 , the ratings entity subsystem 106 is provided with an impression monitor 132 that is configured to track impressions (e.g., content impressions and/or ad impressions) corresponding to content and/or advertisements presented by a client device (e.g., a web browser executed on a computing device such as a personal computer, tablet, laptop or notebook computer, mobile device, game console, smart television, internet appliance, and/or any other internet-connected computing device, an application or "app" such as an application downloaded from an "app store," or any other type of client device) (whether received from a remote web server or from a local cache on the client device). In some example implementations, the impression monitor 132 may be implemented using the SiteCensus system owned and operated by Nielsen. In the example shown, when a client device presents content and/or advertisements, the identity of the user associated with the impression is collected using a cookie (e.g., a universally unique identifier (UUID)) tracked by the impression monitor 132. Due to internet security protocols, the impression monitor 132 may only collect cookies set on its own domain. Thus, for example, if Impression Monitor 132 is running in the "Nielsen.com" domain, it can only collect cookies set by Nielsen.com servers. Thus, when Impression Monitor 132 receives a beacon request from a given client, Impression Monitor 132 can only access cookies set on that client by, for example, servers in the Nielsen.com domain. To overcome this limitation, the example Impression Monitor 132 is structured to forward beacon requests to one or more database owners that partner with the audience measurement entity. Those one or more partners can recognize cookies set in their domain (e.g., Facebook.com) and therefore record impressions in association with the subscriber associated with the identified cookie. This process is further described below.

In the example shown, the ratings entity subsystem 106 includes a ratings entity cookie collector 134 that collects cookie information (e.g., user ID information) and the content ID and/or ad ID associated with the cookie from the impression monitor 132 and sends the collected information to the GRP report generator 130. Similarly, the cookies collected by the impression monitor 132 are those set by a server running in the domain of the audience measurement entity. In some examples, the ratings entity cookie collector 134 is configured to collect recorded impressions from the impression monitor 132 (e.g., based on the cookie information and the ad or content ID) and provide the recorded impressions to the GRP report generator 130.

The operation of the impression monitor 132 in conjunction with the client device and the partner site is described below in conjunction with Figures 2 and 3. Specifically, Figures 2 and 3 depict how the impression monitor 132 can collect user identities and track the exposure of those users to content and/or advertisements. The collected data can be used to determine information about the effectiveness of, for example, an advertising campaign.

For illustrative purposes, the following example involves a social network provider (e.g., Facebook) as the database owner. In the illustrated example, the database owner subsystem 108 includes a server 138 that stores user registration information, performs web server processing to serve web pages (possibly, but not necessarily, including one or more advertisements) to subscribers of the social network, tracks user activity, and tracks account characteristics. During account creation, the database owner subsystem 108 requires the user to provide demographic information (e.g., age, gender, geographic location, graduation year, group affiliation, and/or any other personal or demographic information). To automatically identify users who revisit the social network entity's web pages, the server 138 sets cookies on client devices (e.g., computers and/or mobile devices of registered users, some of whom may or may not be panelists 114 and 116 of the audience measurement entity). Cookies can be used to identify users, track users' visits to the social network entity's web pages, display those web pages according to the user's preferences, and so on. Cookies set by the database owner subsystem 108 can also be used to collect "domain-specific" user activity. As used herein, "domain-specific" user activity is user internet activity that occurs within the domain of a single entity. Domain-specific user activity may also be referred to as "intra-domain activity." The social network entity may collect intra-domain activity, such as the number of web pages visited by each registered user (e.g., web pages of the social network domain, such as other social network member pages or other intra-domain pages) and/or the type of device used for such visits (e.g., mobile (e.g., smartphone) or fixed (e.g., desktop) device). Server 138 is also configured to track account characteristics, such as the number of social connections (e.g., friends) maintained by each registered user, the number of photos posted by each registered user, the number of messages sent or received by each registered user, and/or any other characteristics of the user account.

The database owner subsystem 108 includes a database owner (DP) collector 139 and a DP loader 140, which collect user registration data (e.g., demographic data), intra-domain user activity data, inter-domain user activity data (described later), and account attribute data. The collected information is stored in a database owner database 142. The database owner subsystem 108 processes the collected data using business rules 144 to create DP summary tables 146.

In the example shown, other collaborating database owner subsystems 110 may share similar types of information with the audience measurement entity as that shared by database owner subsystem 108. Thus, if a person who is not a registered user of a social network service provider is a registered user of one or more other collaborating database owner subsystems 110, their demographic information may be collected from those social network service providers (e.g., Yahoo!, Google, Experian, etc.). The example methods, devices, and/or products disclosed herein advantageously use this collaboration or sharing of demographic information across a website domain to increase the accuracy and/or completeness of the demographic information available to the audience measurement entity. By using shared demographic data in combination with information identifying the content and/or ads 102 to which the user was exposed, the example methods, devices, and/or products disclosed herein generate more accurate demographically based exposure results, thereby enabling the determination of meaningful and consistent GRPs for online advertising.

As the system 100 expands, more collaborative participants (eg, like the collaborative database owner subsystem 110) may join to share further distributed demographic information and ad audience information for use in generating GRPs.

To protect user privacy, the example methods, devices, and/or products described herein utilize dual encryption technology by each participating partner or entity (e.g., subsystems 106, 108, 110) so that user identities are not revealed when demographic and/or audience information is shared between participating partners or entities. In this way, user privacy is not compromised by the sharing of demographic information because the entity receiving the demographic information cannot identify individuals associated with the received demographic information unless those individuals have consented to access their information by, for example, pre-enrolling in a group or service of the receiving entity (e.g., an audience measurement entity). If the individual is already in the receiving party's database, the receiving party will be able to identify the individual regardless of the encryption. However, the individual has already consented to being in the receiving party's database and, therefore, consented to access their demographic data and behavioral information in advance.

FIG2 depicts an example system 200 that can be used to associate exposure measurements with user demographic information based on demographic information distributed across user account records of different database owners (e.g., network service providers). The example system 200 enables the ratings entity subsystem 106 of FIG1 to locate the most suitable collaborator (e.g., database owner subsystem 108 of FIG1 and/or one of the other collaborating database owner subsystems 110 of FIG1 ) for each beacon request (e.g., a request from a client that performs a tag associated with tagged media (e.g., an advertisement or content) containing data identifying the media to enable the entity to record exposure or impressions). In some examples, the example system 200 uses rules and machine learning classifiers (e.g., based on an evolving set of empirical data) to determine the most suitable collaborator that is likely to have the demographic information of the user that triggered the beacon request. Rules can be applied at the publisher level, the campaign/publisher level, or the user level. In some examples, machine learning is not employed, and instead, partners are contacted in some ordered fashion (e.g., Facebook, Myspace, then Yahoo!, etc.) until a user associated with the beacon request is identified or all partners are exhausted without identification.

The ratings entity subsystem 106 receives and compiles impression data from all available partners. The ratings entity subsystem 106 may weight the impression data based on the overall reach and demographic quality of the partner providing the data. For example, the ratings entity subsystem 106 may reference historical data on the accuracy of a partner's demographic data to assign weight to the recorded data provided by the partner.

For rules applied at the publisher level, a set of rules and classifiers are defined that allow the ratings entity subsystem 106 to select the most appropriate partner for a particular publisher (e.g., the publisher of one or more of the advertisements or content 102 in FIG1 ). For example, the ratings entity subsystem 106 can use a combination of demographic data of the publisher and the partner network service provider to select partners that are most likely to have an appropriate user base (e.g., registered users who are likely to access the corresponding publisher's content).

For rules applied at the campaign level, such as the ability for publishers to select ad campaigns based on user demographics, target partner sites can be defined at the publisher/campaign level. For example, if an ad campaign targets males between the ages of 18 and 25, the ratings entity subsystem 106 can use this information to direct requests to partners (e.g., database owners maintaining sports websites, etc.) that are most likely to have the greatest reach within that gender/age group.

For rules applied at the user level (or cookie level), the ratings entity subsystem 106 can dynamically select preferred partners to identify clients and record impressions based on, for example, (1) feedback received from partners (e.g., feedback indicating that the panelist user ID does not match a registered user of the partner site or that the partner site does not have a sufficient number of registered users) and/or (2) user behavior (e.g., user browsing behavior may indicate that a particular user is unlikely to have a registered account with a particular partner site). In the example shown in FIG2 , rules can be used to specify when to deprecate user-level preferred partners using publisher (or publisher campaign) level partner targeting.

2 in detail, user device 202 represents a client device used by one or more of the panelists 114 and 116 of FIG. 1. As shown in the example of FIG. 2, user device 202 may exchange communications with impression monitor 132 of FIG. 1. In the example shown, partner A 206 may be database owner subsystem 108 of FIG. 1 and partner B 208 may be one of the other partner database owner subsystems 110 of FIG. 1. Panel collection platform 210 includes ratings entity database 120 of FIG. 1 to collect advertising and/or content exposure data (e.g., impression data or content impression data). A temporary collection platform may be set up at partner A 206 and partner B 208 sites to store recorded impressions, at least until the data is transmitted to the audience measurement entity.

The example user device 202 is shown executing a client application 212 directed to a host website (e.g., www.acme.com) displaying media 102 (e.g., audio, video, interactive media, streaming media, etc.). The media 102 (e.g., advertisement and/or content) is tagged with identifier information (e.g., media ID, creation type ID, setting ID, publisher source URL, etc.) and beacon instructions 213. The example beacon instructions 213 cause the client application 212 to request repeated pingback instructions 214 (also referred to herein as pingback instructions) from a beacon server 215. The example client application 212 sends a request including an identification of the media 102 to the beacon server 215, which generates and returns repeated pingback instructions 214 to the example panelist client device 202. In some examples, the beacon instructions 213 received with the tagged media 102 include repeated pingback instructions 214.

When executed by the user client device 202, the repetitive pingback instructions 214 cause the user client device 202 to send beacon requests (e.g., at specified intervals) to a remote server specified in the repetitive pingback instructions 214. In the example shown, the specified server is the audience measurement entity's server (i.e., the server at the impression monitor 132). The repetitive pingback instructions 214 can be implemented using Javascript or any other type of instructions or scripts executable by a client application (e.g., a web browser), including, for example, Java, HTML, etc. It should be noted that tagged web pages and/or advertisements are processed in the same manner by both panelist client devices and non-panelist client devices. In both systems, the repetitive pingback instructions 214 are received in conjunction with the download of the tagged media 102 and cause the client downloading the tagged media 102 (e.g., the user client device 202) to send a beacon request to the audience measurement entity. A non-panelist client device is shown at 203. Although the client device 203 is not a panelist 114, 116, the impression monitor 132 can interact with the client device 203 in the same manner that the impression monitor 132 interacts with the user client device 202 (associated with one of the panelists 114, 116). As shown in FIG2 , the non-panelist client device 203 also sends a beacon request 215 based on tagged content downloaded and rendered on the non-panelist client device 203. As a result, in the following description, the user client device 202 and the non-panelist client device 203 are generally referred to as "client devices."

In some examples, the client application 212 determines whether an impression qualification period (e.g., a minimum viewing period) has been reached before sending the first pingback. The duration (e.g., length) of the impression qualification period (e.g., minimum viewing period) can be configured based on, for example, characteristics of the tagged media (e.g., the length of the tagged media, the demographics of the expected viewers of the tagged media, etc.) and/or preferences or requirements of the media publisher (e.g., the publisher does not consider the tagged media valid for serving impressions until a certain length of the media has been viewed).

In the example shown, the client application 212 stores one or more partner cookies 216 and a panelist monitor cookie 218. Each partner cookie 216 corresponds to a corresponding partner (e.g., partners A 206 and B 208) and can only be used by the corresponding partner to identify the user of the user client device 202. The panelist monitor cookie 218 is a cookie set by the impression monitor 132 and identifies the user of the user client device 202 to the impression monitor 132. Each partner cookie 216 is created, set, or otherwise initialized in the user client device 202 when the user of the client device first visits the website of the corresponding partner (e.g., one of partners A 206 and B 208) and/or when the user of the client device registers with the partner (e.g., establishes a Facebook account). If the user has a registered account with the corresponding partner, the user ID (e.g., an email address or other value) of the user is mapped to the corresponding partner cookie 216 in the corresponding partner's record. When a client (e.g., a panelist client device or a non-panelist client device) registers for a panel and/or when a client processes tagged media (e.g., content or advertisements), a panelist monitor cookie 218 is created. When a user registers as a panelist and is mapped to the user's user ID (e.g., an email address or other value) in the ratings entity's records, the panelist monitor cookie 218 of the user's client device 202 may be set. Even though a non-panelist client device 203 is not a panelist, a panelist monitor cookie similar to the panelist monitor cookie 218 is created in the non-panelist client device 203 when the non-panelist client device 203 processes tagged media. In this way, the impression monitor 132 can collect impressions (e.g., ad impressions) associated with the non-panelist client device 203 even if the user of the non-panelist client device 203 is not registered with the panel and the ratings entity operating the impression monitor 132 does not have demographic data for the user of the non-panelist client device 203.

In some examples, the client application 212 may also include a partner priority cookie 220 that is set, regulated, and/or controlled by the impression monitor 132 and includes a priority list of partners 206 and 208 (and/or other database owners) that indicates the order in which beacon requests and/or pingback messages should be sent to the partners 206, 208, and/or other database owners. For example, if partner A 206 indicates that the user of the client device 202, 203 is not a registered user of partner A 206, the impression monitor 132 may specify that the client device 202, 203 should first send a beacon request and/or pingback message to partner A 206 and then to partner B 208 based on the execution of the repeated pingback instructions 214. In this way, the client devices 202, 203 may use repeated pingback instructions 214 in conjunction with a prioritized list of partner priority cookies 220 to send initial beacon requests and/or pingback messages to the initial partner and/or other initial database owners, and send one or more redirected beacon requests and/or pingback messages to one or more secondary partners and/or other database owners until one of the partners 206 and 208 and/or other database owners confirms that the user of the user client device 202 is a registered user of the partner's or other database owner's services and is able to record impressions (e.g., media impressions, etc.) and provide demographic information of the user (e.g., demographic information stored in the database owner database 142 of FIG. 1 ), or until all partners have been attempted but unsuccessfully matched. In other examples, the partner priority cookie 220 may be omitted, and the beacon instructions 213 and/or repeated pingback instructions 214 may be configured to cause the client device 202, 203 to unconditionally send the beacon request and/or pingback message to all available partners and/or other database owners so that all partners and/or other database owners have an opportunity to record an impression. In other examples, the repeated pingback instructions 214 may be configured to cause the client device 202, 203 to receive instructions from the impression monitor 132 in the order in which the redirected beacon request was sent to one or more partners and/or other database owners.

In some examples that use alternatives to cookies (e.g., network storage, Document Object Model (DOM) storage, local shared objects (also known as “Flash cookies”), media identifiers (e.g., iOS advertising IDs), user identifiers (e.g., Apple user IDs, iCloud user IDs, Android user IDs), and/or device identifiers (Apple device IDs, Android device IDs, device serial numbers, media access control (MAC) addresses, etc.), the example client devices 202, 203, the example beacon instructions 214, the example collaborators 206, 208, and/or the example impression monitor 132 cause the client devices 202, 203 to store alternative data and/or store data using an alternative format. For example, if the example system 200 utilizes network storage or DOM storage, the example beacon instructions 214 include a script (e.g., Javascript) to cause the client devices 202, 203 to store data such as a unique device identifier. The example beacon instructions 214 may include instructions to cause the client device 202, 203 to send the unique media identifier, user ID, and/or device identifier of the client device 202, 203 to the example impression monitor 132. The example impression monitor 132 and/or the example partners 206 and/or 208 may use non-cookie identifiers to record impression information and/or determine demographic information associated with the client device.

To monitor browsing behavior or track the activity of the collaborator cookie 216, the user client device 202 is provided with a web client logger 222. Additionally, the user client device 202 is provided with an HTTP request log 224, in which the web client logger 222 can store or log HTTP requests in association with the logger ID of the client logger 222, the user ID originating from the user client device 202, a beacon request timestamp (e.g., a timestamp indicating when the user client device 202 sent a beacon request (e.g., beacon requests 304 and 308 of FIG. 3 )), the uniform resource locator (URL) of the website displaying the advertisement, an advertising campaign ID, and/or a pingback message. In the illustrated example, the web client logger 222 stores the user ID of the collaborator cookie 216 and the panelist monitor cookie 218 in association with each recorded HTTP request in the HTTP request log 224. In some examples, the HTTP request log 224 can additionally or alternatively store other types of requests, such as file transfer protocol (FTP) requests and/or any other Internet protocol requests. The illustrated example web client recorder 222 can transmit these web browsing behavior or activity data from the HTTP request log 224 to the panel collection platform 210 in association with the corresponding user ID. In some examples, the web client recorder 222 can also be advantageously used to record impressions of untagged content or advertisements. Unlike tagged advertisements and/or tagged content (which include beacon instructions 213 and/or repeated pingback instructions 214 so that beacon requests are sent to the impression monitor 132 (and/or one or more partners 206, 208 and/or other database owners), which identifies impressions of the tagged content to send to the audience measurement entity for recording), untagged content and/or advertisements do not have these beacon instructions 213 and/or repeated pingback instructions 214 to give the impression monitor 132 an opportunity to record impressions. In these cases, the HTTP requests recorded by the web client recorder 222 can be used to identify untagged content or advertisements presented by the client application 212 on the user's client device 202.

In the example shown, the impression monitor 132 is provided with a user ID comparator 228, a rules/machine learning (ML) engine 230, an HTTP server 232, and a publisher/campaign/user targeting database 234. The user ID comparator 228 of the example shown is configured to identify beacon requests from users who are panelists 114, 116. In the example shown, the HTTP server 232 is a communication interface via which the impression monitor 132 exchanges information (e.g., beacon requests, pingback messages, beacon responses, confirmations, failure status messages, etc.) with the client devices 202, 203. The rules/ML engine 230 and publisher/campaign/user targeting database 234 of the example shown enable the impression monitor 132 to select the "best fit" partner (e.g., one of the partners 206 or 208) for each impression request (or beacon request and/or pingback message) received from the client device 202, 203. The "best fit" collaborator is the collaborator most likely to have the demographics of the user of the client device 202, 203 sending the impression request. The rules/ML engine 230 is a set of rules and machine learning classifiers generated based on the evolved empirical data stored in the publisher/campaign/user targeting database 234. In the example shown, rules can be applied at the publisher level, the publisher/campaign level, or the user level. In addition, collaborators can be weighted based on their overall reach and demographic quality.

To select partners (e.g., partners 206 and 208) at the publisher level for an ad campaign, the rules/ML engine 230 includes rules and classifiers that allow the impression monitoring system 132 to select the "best fit" partner for a particular ad campaign publisher. For example, the impression monitoring system 132 can use an indication of the target demographic composition of the publisher and partner (e.g., stored in the publisher/campaign/user targeting database 234) to select a partner (e.g., one of partners 206, 208) that is most likely to have the demographic information of the user of the client device 202, 203 requesting the impression.

To select partners (e.g., partners 206 and 208) at the campaign level (e.g., where a publisher has the ability to select advertising campaigns based on user demographics), the rules/ML engine 230 of the illustrated example is used to specify target partners at the publisher/campaign level. For example, if the publisher/campaign/user targeting database 234 stores information indicating that a particular advertising campaign is targeted to males aged 18 to 25, the rules/ML engine 230 uses this information to direct beacon request redirects and/or pingback message redirects to partners most likely to have the greatest reach within this gender/age group.

To select partners (e.g., partners 206 and 208) at the cookie level, the impression monitor 132 updates the target partner sites based on feedback received from the partners. Such feedback may indicate user IDs that do not correspond to or correspond to registered users of the partners. In some examples, the impression monitor 132 may also update the target partner sites based on user behavior. For example, such user behavior may be derived from analysis of cookie clickstream data corresponding to browsing activity associated with a panelist monitor cookie (e.g., panelist monitor cookie 218). In the example shown, the impression monitor 132 uses such cookie clickstream data to determine the age/gender bias of a particular partner by determining the age and gender that the browsing behavior is more indicative of. In this way, the impression monitor 132 of the example shown may update the target or preferred partners for a particular user or client device 202, 203. In some examples, the rule/ML engine 230 specifies when to deprecate a user-level preferred target partner with a publisher or publisher/campaign-level preferred target partner. For example, such a rule may specify the revocation of a user-level preferred target partner when the user-level preferred target partner sends multiple indications that it has no registered users corresponding to the client devices 202, 203 (e.g., different users on the client devices 202, 203 begin using different applications with different user IDs in their partner cookies 216).

In the example shown, the impression monitor 132 records impressions (e.g., ad impressions, content impressions, etc.) in a per-user media impression table 235 based on beacon requests (e.g., beacon request 304 of FIG. 3 ) received from client devices (e.g., client devices 202 , 203 ). In the example shown, the per-user media impression table 235 stores a unique user ID obtained from a cookie (e.g., panelist monitor cookie 218 ) in association with daily impression totals, including the time of the media impression (e.g., the time the beacon request was received from the client device 202 , 203 ) and the campaign/media ID. For example, a campaign ID may be used for some types of media (e.g., static ads), while a media ID may be used for other types of media (e.g., dynamic media with a duration). In some examples, the per-user media impression table 235 includes both media ID and campaign ID information. Thus, for each campaign/media ID, the impression monitor 132 records the daily total impressions of all and/or a portion of the media attributed to a particular user or client device 202 , 203 . The example media impressions may be compressed for a particular user ID and campaign/media ID to obtain an entry in the media impression table 235 corresponding to the description of the impression for that user ID and campaign/media ID.

Each of the collaborators 206 and 208 of the illustrated example employs an HTTP server 236 and 240 and a user ID comparator 238 and 242. In the illustrated example, the HTTP servers 236 and 240 are communication interfaces through which their respective collaborators 206 and 208 exchange information (e.g., beacon requests, beacon responses, confirmations, failure status messages, etc.) with the client devices 202 and 203. The user ID comparators 238 and 242 are configured to compare user cookies received from the client devices 202 and 203 with cookies in their records to identify the client devices 202 and 203, if possible. Thus, the user ID comparators 238 and 242 can be used to determine whether the user of the user client device 202 has a registered account with the collaborators 206 and 208. If so, the collaborators 206 and 208 can record impressions attributed to those users and associate those impressions with demographic data of the identified users (e.g., demographic data stored in the database owner database 142 of FIG. 1 ). The example partners 206, 208 of Figure 2 receive multiple beacon requests during a media impression at the client devices 202, 203. The example partners 206, 208 can condense the multiple beacon requests into a single impression for the identified user and media (e.g., a media identifier provided with the beacon request) in a manner similar to the media impression table 235.

In the example shown, the panel collection platform 210 is used to identify the registered users of the collaborators 206 and 208 (who are also panelists 114 and 116). The panel collection platform 210 can then use this information to cross-reference the demographic information stored by the ratings entity subsystem 106 for the panelists 114 and 116 with the demographic information stored by the collaborators 206 and 208 for their registered users. The ratings entity subsystem 106 can use this cross-reference to determine the accuracy of the demographic information collected by the collaborators 206 and 208 based on the demographic information collected by the ratings entity subsystem 106 for the panelists 114 and 116.

In some examples, the example collector 117 of the panel collection platform 210 collects web browsing activity information from the user client device 202. In these examples, the example collector 117 requests logged data from the HTTP request log 224 of the user client device 202 and logged data collected by other panelist client devices (not shown). Additionally, the collector 117 collects from the impression monitor 132 panelist user IDs set in the panelist client devices tracked by the impression monitor 132. Additionally, the collector 117 collects from one or more collaborators (e.g., collaborators 206 and 208) collaborator user IDs set in the panelist and non-panelist client devices tracked by the collaborators. In some examples, to comply with the privacy agreements of the collaborators 206, 208, the collector 117 and/or the database owners 206, 208 may hash the database owner cookie ID using a hashing technique (e.g., a double hashing technique).

In some examples, the loader 118 of the panel collection platform 210 analyzes and arranges the received panelist user IDs and collaborator user IDs. In the illustrated example, the loader 118 analyzes recorded data received from the panelist client device (e.g., from the HTTP request log 224 of the user client device 202) to identify panelist user IDs (e.g., panelist monitor cookie 218) associated with collaborator user IDs (e.g., collaborator cookie 216). In this way, the loader 118 can identify which panelists (e.g., some of the panelists 114 and 116) are also registered users of one or more of the collaborators 206 and 208 (e.g., the database owner subsystem 108 of FIG. 1 that stores demographic information of registered users in the database owner database 142). In some examples, the panel collection platform 210 operates to verify the accuracy of the impressions collected by the impression monitor 132. In some such examples, the loader 118 filters HTTP beacon requests recorded from the HTTP request log 224 that are associated with impressions of panelists recorded by the impression monitor 132, and identifies HTTP beacon requests recorded at the HTTP request log 224 that do not have corresponding impressions recorded by the impression monitor 132. In this way, the panel collection platform 210 can provide an indication of inaccurate impression recording by the impression monitor 132 and/or provide impressions recorded by the web client recorder 222 to fill in the impression data of panelists 114, 116 that was missed by the impression monitor 132.

In the example shown, the loader 118 stores overlapping users in the impression-based group demographics table 250. In the example shown, overlapping users are users who are both group members 114, 116 and are also registered users of collaborator A 206 (denoted as user P(A)) and/or registered users of collaborator B 208 (denoted as user P(B)). (Although only two partners (A and B) are shown, this is for ease of illustration, and any number of partners may be represented in table 250. The example impression-based panel demographics table 250 is shown as storing meter IDs (e.g., the IDs of the web client meter 222 and the web client meter of other client devices), user IDs (e.g., alphanumeric identifiers such as user names, email addresses, etc. corresponding to the panelist monitor cookie 218 and the panelist monitor cookies of other panelist client devices), beacon request timestamps (e.g., timestamps indicating when the user client device 202 and/or other panelist client devices sent a beacon request (e.g., beacon requests 304 and 308 of FIG. 3 )), uniform resource locators (URLs) of websites visited (e.g., websites where advertisements were displayed), and advertising campaign IDs. Additionally, the example loader 118 stores partner user IDs that do not overlap with panelist user IDs in the partner A (P(A)) cookie table 252 and the partner B (P(B)) cookie table 254.)

In some examples, impression monitor 132 and/or ratings entity partitions (e.g., filters) impression information and/or demographic impression information based on the type of media presented in the impression. For example, impression monitor 132 may determine that an impression includes one or more advertisements as a first media type and program content as a second media type. By partitioning impressions based on the type of media presented in the impression, example impression monitor 132 and/or ratings entity may determine ratings information only for the first media type and/or only for the second media type (and/or only for other media types presented in the impression). For example, example impression monitor 132 and/or ratings entity may ignore the time spent viewing a first media type (e.g., advertisements) when calculating views of a second media type (e.g., content or program views), and/or may ignore the time spent viewing a second media type when calculating views of a first media type. In other examples, pingback instruction 214 provides an indication of a time range in the media, which impression monitor 132 cross-references with a media database that includes time ranges for different media types in the media.

In some examples, the pingback instructions 214 cause the pingback requests 304, 308 to include an indication of a media type (e.g., advertisement, content, etc.) to facilitate segmentation or filtering of the media. Example pingback instructions 214 may include an indication of a time range within the media belonging to the media type and/or other instructions to discern the type of media being presented (e.g., code reading instructions, signature matching instructions, or instructions to perform other types of media ID data collection and/or media classification).

Example processing performed by the example system 200 is described below in conjunction with the communication flow diagram of FIG. 3 and the flow diagrams of FIG. 10 , FIG. 11 , and FIG. 12 .

Although Figures 1 and 2 illustrate example ways of implementing the ratings entity subsystem 106, one or more of the elements, processes, and/or devices shown in Figure 1 may be combined, divided, rearranged, omitted, eliminated, and/or implemented in any other manner. Additionally, the example impression monitor 132, the example rules/ML engine 230, the example HTTP server communication interface 232, the example publisher/campaign/user targeting database 232, the example GRP report generator 130, the example group collection platform 210, the example collector 117, the example loader 118, the example ratings entity database 120, and/or more generally, the example ratings entity subsystem 106 of Figures 1 and 2 may be implemented in hardware, software, firmware, and/or any combination of hardware, software, and/or firmware. Thus, for example, any of the example impression monitor 132, the example rules/ML engine 230, the example HTTP server communication interface 232, the example publisher/campaign/user targeting database 232, the example GRP report generator 130, the example panel collection platform 210, the example collector 117, the example loader 118, the example ratings entity database 120, and/or more generally, the example ratings entity subsystem 106 may be implemented via one or more analog or digital circuits, logic circuits, programmable processors, application specific integrated circuits (ASICs), programmable logic devices (PLDs), and/or field programmable logic devices (FPLDs). When any apparatus or system claims of this patent are read to encompass pure software and/or firmware implementations, at least one of the example impression monitor 132, the example rules/ML engine 230, the example HTTP server communication interface 232, the example publisher/campaign/user targeting database 232, the example GRP report generator 130, the example panel collection platform 210, the example collector 117, the example loader 118, and/or the example ratings entity database 120 is hereby expressly defined as comprising a tangible computer-readable storage device or storage disk, such as a memory, a digital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc., storing software and/or firmware. Furthermore, the example ratings entity subsystem 106 of Figures 1 and 2 may include one or more elements, processes, and/or devices in addition to or in lieu of those shown in Figures 1 and 2, and/or may include more than one of any or all of the elements, processes, and devices shown.

Turning to FIG3 , an example communication flow diagram illustrates an example manner in which the example system 200 of FIG2 records impressions passed through a client (e.g., clients 202, 203). The example series of events illustrated in FIG3 occurs when a client 202, 203 accesses tagged media (e.g., tagged advertisements, tagged content, etc.). Thus, the events of FIG3 begin when a client sends an HTTP request to a server for media, in this example, media that has been tagged to forward impressions to a ratings entity. In the example illustrated in FIG3 , the client application 212 of clients 202, 203 receives the requested media (e.g., tagged media 102, which may be advertisements and/or content) from a publisher (e.g., publisher 302). It will be appreciated that clients 202, 203 often request a webpage containing media of interest (e.g., www.weather.com), and the requested webpage includes media that is downloaded and rendered within the webpage. The advertisement may originate from a different server than the content originally requested. 3 includes beacon instructions 213 that cause the clients 202, 203 to request repeated pingback instructions 214 (e.g., to a beacon server 215) as part of the process of rendering the web page originally requested by the clients 202, 203. The example client application 212 sends a request to the beacon server 215 based on the beacon instructions 213, and the beacon server 215 returns the repeated pingback instructions 214.

For the purposes of the following description, assume that advertisement 102 is tagged with beacon instructions 214. Example beacon instructions 214 cause client application 212 of client 202 or 203 to send a beacon request 304 to impression monitor 132 when the tagged advertisement is accessed. In some examples, beacon instructions 214 cause client application 212 to request and receive pingback instructions 214 from beacon server 215. In the illustrated example, client application 212 sends beacon request 304 and/or pingback message using an HTTP request addressed to, for example, a URL of impression monitor 132 at a first internet domain. Beacon request 304 and/or pingback message include a campaign ID, media ID, creation type ID, and/or setting ID associated with media 102. Additionally, example beacon request 304 and/or pingback message include a document referrer (e.g., www.acme.com), a timestamp of the impression, and a publisher site ID (e.g., the URL http://my.advertiser.com of advertisement publisher 302). Additionally, if the client application 212 of the client 202 or 203 includes the panelist monitor cookie 218, the beacon request 304 and/or pingback message will include the panelist monitor cookie 218. In other example implementations, the cookie 218 may not be passed until the client 202 or 203 receives a request sent by a server of the impression monitor 132 in response to, for example, the impression monitor 132 receiving the beacon request 304 and/or pingback message. The example client application 212 sends additional beacon requests 304 and/or pingback messages at intervals determined by the beacon instructions 213 and/or repetitive pingback instructions 214. For example, the beacon instructions 213 and/or repetitive pingback instructions 214 may cause the client application 212 to send a beacon request every minute (or other time period) while the media 102 is loading and/or playing in the client application 212.

In some examples, beacon instructions 213 and/or repeated pingback instructions 214 also cause client application 212 to send a beacon request 304 in response to a specific event (e.g., a user manipulation and/or interaction with media 102). For example, beacon instructions 213 and/or repeated pingback instructions 214 may cause client application 212 to send a beacon request 304 and/or pingback message when a user jumps to a location in media 102 (e.g., a specific time within media 102). For example, a user may wish to resume playback of a video at the location where the user previously stopped watching the media (e.g., 10:00 minutes from the start of the video, etc.). In some other examples, the user may wish to skip a portion of the media (e.g., skip the currently playing song). Example beacon instructions 213 and/or repeated pingback instructions 214 cause client application 212 to include the time in media 102 to which the user jumped, the skip request, and/or another user interaction in the beacon request 304 and/or pingback message.

In response to receiving the beacon request 304 and/or pingback message, the impression monitor 132 records the impression by recording the media ID information (and any other relevant identifying information), timestamp, and/or any other information contained in the beacon request 304 and/or pingback message (e.g., jump time, skip request, etc.). In the example shown, the impression monitor 132 records the impression regardless of whether the beacon request 304 and/or pingback message indicates a user ID (e.g., based on the panelist monitor cookie 218) that matches the user ID of a panelist (e.g., one of the panelists 114 and 116 of FIG. 1 ). However, if the user ID (e.g., the panelist monitor cookie 218) matches the user ID of a panelist (e.g., one of the panelists 114 and 116 of FIG. 1 ) set by the ratings entity subsystem 106 and therefore stored in the records of the ratings entity subsystem 106, then the recorded impression will correspond to the panelist of the impression monitor 132. If the user ID does not correspond to a panelist of the impression monitor 132, the impression monitor 132 will still benefit from recording the impression even if it will not have a record of the user ID for the impression reflected in the beacon request 304 and/or pingback message (and therefore, corresponding demographic data). When no beacon request 304 and/or pingback message is received for a media ID and a particular client device 202, 203 for a threshold time, the example impression monitor 132 generates a persistent impression for the media based on the recorded impressions received from the client device 202, 203 for the media ID (e.g., based on the beacon request 304 and/or pingback message). The example persistent impression includes an estimated time that the recorded impression was presented by the client device 202, 203 based on the recorded impression (e.g., based on adjacent playback, jumping within the media, pausing the media, skipping portions of the media, etc.).

3 , in order to compare or supplement the panelist demographic data of the impression monitor 132 with the demographic data at the partner site (e.g., for accuracy or completeness) and/or to enable the partner site to attempt to identify the client and/or record the impression, the impression monitor 132 returns a beacon response message 306 (e.g., a first beacon response) to the client application 212 of the client 202, 203, the response message including an HTTP 302 redirect message and (e.g.,) the URL of the participating partner at the second Internet domain. In the example shown, the HTTP 302 redirect message instructs the client application 212 of the client 202, 203 to send a second pingback message 308 to one of the specific partners (e.g., partner A 206 or B 208). In other examples, instead of using an HTTP 302 redirect message, redirection may be accomplished using, for example, an iframe source instruction (e.g., <iframe src="">) or any other instruction that may instruct the client application to send a subsequent beacon request and/or pingback message (e.g., second beacon request and/or pingback message 308) to a partner. In the illustrated example, the impression monitor 132 utilizes its rules/ML engine 230 ( FIG. 2 ) to determine the partner specified in the beacon response 306 based on, for example, empirical data indicating which partner should most likely have the demographics of the user ID and, therefore, be preferred. In other examples, the same partner is always identified in the first redirect message, and that partner always redirects the client 202, 203 to the same second partner when the first partner has no recorded impressions. In other words, a set hierarchy of partners is defined and followed so that partners are "daisy-chained" together in the same predetermined order, rather than attempting to guess the most likely database owner to identify an unknown client 203.

Before sending the beacon response 306 to the client application of the client 202, 203, the impression monitor 132 of the illustrated example replaces the site ID (e.g., URL) of the ad publisher 302 with a modified site ID (e.g., an alternative site ID) corresponding to the ad publisher 302 that is discernible only to the impression monitor 132. In some example implementations, the impression monitor 132 may also replace the host website ID (e.g., www.acme.com) with another modified site ID (e.g., an alternative site ID) corresponding to the host website that is discernible only to the impression monitor 132. In this way, the source of the advertisement and/or host content is masked relative to the partner. In the illustrated example, the impression monitor 132 maintains a publisher ID mapping table 310 that maps the original site ID of the ad publisher with the modified (or alternative) site ID created by the impression monitor 132 to obscure or hide the ad publisher identifier from the partner site. In some examples, the impression monitor 132 also stores the host website ID in association with the modified host website ID in the mapping table. In addition, the impression monitor 132 encrypts all of the information received in the pingback message 304 and the modified site ID to prevent any intercepting party from decoding the information. The impression monitor 132 of the illustrated example sends the encrypted information in the beacon response 306 to the client application 212. In the illustrated example, the impression monitor 132 uses encryption that can be decrypted by the selected partner site specified in the HTTP 302 redirect.

In some examples, the impression monitor 132 also sends URL scraping instructions 320 to the client device 202, 302. In these examples, the URL scraping instructions 320 cause the client device 202, 203 to "scrape" the URL of the webpage or website associated with the tagged ad 102. For example, the client device 202, 203 can perform the scraping of the webpage URL by reading the text presented or displayed at the URL address bar of the client application 212. The client device 202, 203 then sends the scraped URL 322 to the impression monitor 132. In the example shown, the scraped URL 322 indicates the host website (e.g., http://www.acme.com) that was visited by the user of the client device 202, 203 and displayed the tagged ad 102. In the example shown, the tagged ad 102 is displayed via an ad iFrame with the URL "my.advertiser.com", which corresponds to the advertising network (e.g., publisher 302) that provides the tagged ad 102 on one or more host websites. However, in the example shown, the host website indicated in the crawled URL 322 is "www.acme.com," which corresponds to the website visited by the user of the client device 202 , 203 .

URL scraping is particularly useful in cases where the publisher is an ad network from which advertisers purchase ad space/time. In these cases, the ad network dynamically selects from a subset of host websites visited by users that display ads via iFrames (e.g., www.caranddriver.com, www.espn.com, www.allrecipes.com, etc.). However, the ad network cannot predict with certainty the host website that will display an ad at any given time. Additionally, the URL of the ad iFrame that presents the tagged ad 102 may not be used to identify the subject of the host website presented by the client application 212 (e.g., www.acme.com in the example of FIG. 3 ). Therefore, the impression monitor 132 has no way of knowing the host website on which the ad iFrame is displaying the tagged ad 102.

The URL of the host website (e.g., www.caranddriver.com, www.espn.com, www.allrecipes.com, etc.) can be used to determine the subject interests (e.g., cars, sports, cooking, etc.) of the users of the client devices 202, 203. In some examples, the audience measurement entity can use the host website URL to correlate with user/panelist demographics and interpolate the recorded impressions of the larger population based on the demographics and subject interests of the larger population and based on the demographics and subject interests of the users/panelists who recorded impressions. Thus, in the example shown, when the impression monitor 132 does not receive the host website URL or is unable to identify the host website URL based on the beacon request and/or pingback message 304, the impression monitor 132 sends a URL crawling instruction 320 to the client devices 202, 203 to receive a crawled URL 322. In the example shown, if the impression monitor 132 can identify the host website URL based on the beacon request and/or pingback message 304, the impression monitor 132 does not send URL fetch instructions 320 to the client device 202, 203, thereby conserving network and computer bandwidth and resources.

In response to receiving the beacon response 306, the client application of the client 202, 203 sends a beacon request 308 and/or a pingback message to the designated partner site (in the example shown, Partner A 206 (e.g., a second Internet domain)). The beacon request 308 and/or pingback message includes the encrypted parameters from the beacon response 306. Partner A 206 (e.g., Facebook) decrypts the encrypted parameters and determines whether the client device 202, 203 matches a registered user of the service provided by Partner A 206. This determination involves requesting the client 202, 203 to pass any stored cookies set by Partner A 206 (e.g., one of the partner cookies 216 of FIG. 2 ) and attempting to match the received cookies with the cookies stored in Partner A 206's record. If a match is found, Partner A 206 positively identifies the client 202, 203. As a result, the Partner A 206 site records an impression associated with the identified client's demographic information. This log (including the undetectable source identifier) is then provided to the ratings entity for processing into the GRP (as discussed below). In the event that Partner A 206 cannot identify the client 202, 203 in its records (eg, no matching cookie), Partner A 206 does not record the impression.

In some example implementations, if the user ID does not match a registered user of partner A 206, partner A 206 may return a beacon response 312 (e.g., a second beacon response) including a failure or no-match status, or may not respond at all, thereby terminating the process of Figure 3. However, in the example shown, if partner A 206 cannot identify the client 202, 203, partner A 206 returns a second HTTP 302 redirect message to the client 202, 203 in the beacon response 312 (e.g., a second beacon response). For example, if partner A site 206 has logic (e.g., similar to the rules/ML engine 230 of Figure 2) to specify another partner (e.g., partner B 208 or any other partner) that may have demographic data for the user ID, the beacon response 312 may include an HTTP 302 redirect (or any other suitable instruction that results in a redirected communication) and a URL of the other partner (e.g., at a third Internet domain). Alternatively, in the daisy chain method described above, the partner A site 206 may always redirect to the same next partner or database owner (e.g., partner B 208 at a third Internet domain or the non-partner database owner subsystem 110 of FIG. 1 at a third Internet domain) whenever it cannot identify the client 202, 203. When redirecting, the partner A site 206 of the illustrated example utilizes encryption to encrypt parameters such as ID, timestamp, and referrer, which can be decrypted by the next designated partner.

As a further alternative, if the Partner A site 206 does not have logic to select the next most suitable partner that may have demographic data for the user ID and is unable to effectively daisy-chain to the next partner by storing instructions to redirect to partner entities, the beacon response 312 may redirect the client 202, 203 to the impression monitor 132 with a failure or no match status. In this way, the impression monitor 132 may use its rules/ML engine 230 to select the next most suitable partner to which the client application of the client 202, 203 should send the beacon request and/or pingback message (or, if no such logic is provided, simply select the next partner in a hierarchical (e.g., fixed) list). In the example shown, the impression monitor 132 selects the Partner B site 208, and the client application of the client 202, 203 sends the beacon request and/or pingback message to the Partner B site 208, such that the parameters are encrypted in a manner that can be decrypted by the Partner B site 208. Partner B site 208 then attempts to identify client 202, 203 based on its own internal database. If the cookie obtained from client 202, 203 matches a cookie in Partner B 208's records, Partner B 208 positively identifies client 202, 203 and records an impression associated with the demographic data of client 202, 203 for later provision to Impression Monitor 132. In the event Partner B 208 is unable to identify client 202, 203, Partner B 208 may use the same process of failure notification or further HTTP 302 redirection to provide another next Partner site with an opportunity to identify the client, and so on in a similar manner until a Partner site identifies client 202, 203 and records an impression, until all Partner sites have been exhausted without identifying a client, or until a predetermined number of Partner sites have failed to identify client 202, 203.

Utilizing the process illustrated in FIG3 , impressions (e.g., media impressions, etc.) can be mapped to corresponding demographic data for the media on a minute-by-minute basis. Additionally, impressions can be mapped to corresponding demographic data even when the impressions are not triggered by a panelist associated with an audience measurement entity (e.g., the ratings entity subsystem 106 of FIG1 ). During the impression collection or merging process, the panel collection platform 210 of the ratings entity can collect distributed impressions recorded by (1) the impression monitor 132 and (2) any participating partners (e.g., partners 206 , 208 ) and determine demographic data for various portions of the media. As a result, the example methods and apparatus disclosed herein deliver comprehensive TV-comparable last night metrics for online program promotions, provide similar last night audience data (including unique audiences, stream counts, and age and gender coverage of TV programs viewed online), and provide a more comprehensive view of online and TV audiences for program content and associated advertising campaigns. The example methods and apparatus provide continuous weighted and TV-comparable ratings reporting for videos. The data collected using the example methods and apparatus disclosed herein covers a much larger population with richer demographic information than was previously possible. Thus, by merging the resources of distributed databases as described above, an accurate, consistent, and meaningful online GRP can be generated. The example structures of Figures 2 and 3 generate online GRPs based on a large number of combined demographic data databases distributed between unrelated parties (e.g., Nielsen and Facebook). The end result looks like the users attributed with recorded impressions are part of a large virtual panel formed by registered users of the audience measurement entity, because the selection of participating partner sites can be tracked as if they were members of the audience measurement entity panels 114, 116. This is achieved without violating the Internet's cookie privacy protocols.

Periodically or aperiodically, impression data collected by partners (e.g., partners 206, 208) is provided to the ratings entity via the panel collection platform 210. As described above, some user IDs may not match panelists of the impression monitor 132, but may match registered users of one or more partner sites. During the data collection and merging process that combines demographic data and impression data from the ratings entity subsystem 106 and partner subsystems 108 and 110 of Figure 1, the user IDs of some impressions recorded by one or more partners may match the user IDs of impressions recorded by the impression monitor 132, while other user IDs (and likely many other user IDs) will not match. In some example implementations, the ratings entity subsystem 106 may use demographic-based impressions from the matching user ID logs provided by the partner sites to access and/or improve the accuracy of its own demographic data (if necessary). For demographic-based impressions associated with unmatched user ID logs, the ratings entity subsystem 106 may use the impressions (e.g., ad impressions, content impressions, etc.) to derive demographic-based online GRPs, even if the impressions are not associated with panelists of the ratings entity subsystem 106. The example ratings entity applies the demographic data of the impressions to the portion of the media determined to be presented at the client device based on the pingback message and the corresponding impression information.

As briefly mentioned above, the example methods, devices, and/or products disclosed herein can be configured to protect user privacy when sharing demographic information (e.g., account records or registration information) between different entities (e.g., between ratings entity subsystem 106 and database owner subsystem 108). In some example implementations, a double encryption technique can be used based on the respective secret keys of each participating partner or entity (e.g., subsystems 106, 108, 110). For example, ratings entity subsystem 106 can encrypt its user ID (e.g., email address) using its secret key, and database owner subsystem 108 can encrypt its user ID using its secret key. For each user ID, the corresponding demographic information is then associated with the encrypted version of the user ID. Each entity then exchanges its demographic data lists using the encrypted user IDs. Since neither entity knows the other's secret key, they cannot decrypt the user ID, and thus the user ID remains private. Each entity then proceeds to perform a second encryption of each encrypted user ID using its respective key. Each twice-encrypted (or doubly-encrypted) user ID (UID) will be in the form of E1(E2(UID)) and E2(E1(UID)), where E1 represents encryption using the secret key of the ratings entity subsystem 106 and E2 represents encryption using the secret key of the database owner subsystem 108. Under the rule of exchange encryption, the encrypted user IDs can be compared based on E1(E2(UID))=E2(E1(UID)). Therefore, the encryptions of the user IDs present in both databases will match after the double encryption is completed. In this way, the user records of the group members can be compared for matches with the user records of the database owner (e.g., the identifiers of registered social network users) without the collaborating entities revealing the user IDs to each other.

The ratings entity subsystem 106 performs daily impression and UUID (cookie) integration based on the impression and cookie data collected by the impression monitor 132 of Figure 1 and the impressions recorded by the partner site. In the example shown, the ratings entity subsystem 106 may perform daily impression and UUID (cookie) integration based on the cookie information collected by the ratings entity cookie collector 134 of Figure 1 and the logs provided to the group collection platform 210 by the partner site. Figure 4 depicts an example ratings entity impression table 400, which shows the amount of impressions for the monitored users. Similar tables may be compiled for one or more of ad impressions, content impressions, or other impressions. In the example shown, the ratings entity impression table 400 is generated by the ratings entity subsystem 106 for an advertising campaign (e.g., one or more of the ads 102 of Figure 1) to determine the frequency of daily impressions for each user.

To track the frequency of impressions per unique user per day, the ratings entity impressions table 400 is provided with a frequency column 402. A frequency of 1 indicates that an ad in an advertising campaign was exposed to a unique user once per day, while a frequency of 4 indicates that one or more ads in the same advertising campaign were exposed to a unique user four times per day. To track the number of unique users to whom impressions are attributed, the ratings impressions table 400 is provided with a UUID column 404. A value of 100,000 in the UUID column 404 indicates 100,000 unique users. Thus, the first entry in the ratings entity impressions table 400 indicates that 100,000 unique users (i.e., UUID=100,000) were exposed to a particular ad 102 once per day (i.e., frequency=1).

To track impressions based on exposure frequency and UUID, the ratings entity impression table 400 is provided with an impression column 406. Each impression count stored in the impression column 406 is determined by multiplying the corresponding frequency value stored in the frequency column 402 by the corresponding UUID stored in the UUID column 404. For example, in the second entry of the ratings entity impression table 400, the frequency value of 2 is multiplied by 200,000 unique users, thereby determining that 400,000 impressions are attributed to a particular advertisement 102.

5 , in the illustrated example, each of the collaborative database owner subsystems 108 , 110 of partners 206 , 208 generates a database owner ad campaign level age/gender and impression composition table 500 daily and reports it to the GRP report generator 130 of the ratings entity subsystem 106 . Similar tables may be generated for content and/or other media. Additionally or alternatively, media other than advertising may be added to the table 500 . In the illustrated example, as shown in FIG5 , partners 206 , 208 tabulate the distribution of impressions by age and gender composition. For example, referring to FIG1 , the database owner database 142 of the collaborative database owner subsystem 108 stores recorded impressions and corresponding demographic information for registered users of partner A 206 . The database owner subsystem 108 of the illustrated example processes the impressions and corresponding demographic information using rules 144 to generate the DP summary tables 146 , including the database owner ad campaign level age/gender and impression composition table 500 .

Age/gender and impression composition table 500 is provided with an age/gender column 502, an impression column 504, a frequency column 506, an impression composition column 508, and a time period or media portion (e.g., subset) column 510. The example age/gender column 502 of the illustrated example indicates different age/gender demographic groups. The example impression column 504 of the illustrated example stores a value indicating the total impressions of a particular advertisement 102 ( FIG. 1 ) for the corresponding age/gender demographic group. The example frequency column 506 of the illustrated example stores a value indicating the frequency of user exposure to the advertisement 102 that contributed to the impressions in the impression column 504. The example impression composition column 508 of the illustrated example stores the percentage of impressions for each age/gender demographic group. The example time period column 510 specifies the portion or subset of the media to which the rating applies. For example, the impressions for the 30th minute of the media represented in table 500 are different from the impressions for the 1st minute of the media.

In some examples, database owner subsystems 108 and 110 may perform demographic accuracy analysis and adjustment on the demographic information before tabulating the final results of impression-based demographic information in the database owner campaign-level age/gender and impression composition tables. This is done to address a problem faced by online audience measurement processes: the way registered users represent themselves to online data owners (e.g., partners 206 and 208) is not necessarily truthful (e.g., trustworthy and/or accurate). In some cases, example methods for online measurement that determine demographic attributes of audiences through account registration with these online database owners can lead to inaccurate demographic-exposure results if they rely on registered users self-reporting personal/demographic information during account registration on the database owner's site. There may be many reasons why users report incorrect or inaccurate demographic information when registering for the database owner's service. Self-reported registration processes used to collect demographic information on database owner sites (e.g., social media sites) do not facilitate determining the authenticity of self-reported demographic information. To analyze and adjust inaccurate demographic information, the ratings entity subsystem 106 and the database owner subsystems 108, 110 may use the example methods, systems, apparatus and/or products disclosed in U.S. patent application serial number 13/209,292, entitled “Methods and Apparatus to Analyze and Adjust Demographic Information,” filed on August 12, 2011, which is incorporated herein by reference in its entirety.

6 , in the example shown, the ratings entity subsystem 106 generates a panelist campaign level age/gender and impression composition table 600 on a daily basis. Similar tables may be generated for content and/or other media. Additionally or alternatively, media other than advertising may be added to table 600. As shown in FIG6 , the example ratings entity subsystem 106 tabulates the distribution of impressions by age and gender composition in the same manner as described above in conjunction with FIG5 . As shown in FIG6 , the panelist campaign level age/gender and impression composition table 600 also includes an age/gender column 602, an impression column 604, a frequency column 606, an impression composition column 608, and a time period or media portion column 610. In the example shown in FIG6 , impressions are calculated based on the PC and TV panelists 114 and the online panelists 116.

After creating the campaign-level age/gender and impression composition tables 500 and 600 of Figures 5 and 6, the ratings entity subsystem 106 creates the combined campaign-level age/gender and impression composition table 700 shown in Figure 7. Specifically, the ratings entity subsystem 106 combines the impression composition percentages from the impression composition columns 508 and 608 of Figures 5 and 6 to compare, for example, minute-by-minute differences in age/gender impression distributions between ratings entity panelists and social network users.

As shown in Figure 7, the combined campaign-level age/gender and impression composition table 700 includes an error weight column 702 that stores the mean squared error (MSE) indicating the difference between the impression compositions of the ratings entity panelists and the database owner's users (e.g., social network users). The weighted MSE can be determined using Equation 4 below.

Formula 4

Weighted MSE=(α*IC _(RE) + (1-α)IC _(DP) )

In Equation 4 above, the weighting variable (α) represents the ratio of MSE(SN)/MSE(RE) or some other function that weights components inversely proportional to their MSE. As shown in Equation 4, the weighting variable (α) is multiplied by the impression composition of the ratings entity (IC _(RE) ) to generate the ratings entity weighted impression composition (α*IC _(RE) ). The impression composition of the database owner (e.g., social network) (IC _(DP) ) is then multiplied by one and the difference between the weighting variable (α) to determine the database owner weighted impression composition ((1-α)IC _(DP) ).

In the example shown, the ratings entity subsystem 106 can smooth or correct for differences in impression composition by weighting the distribution of the MSE. The MSE value accounts for sample size variations or fluctuations in the data caused by small sample sizes. The example table 700 can also include impression information for other time periods of the media (e.g., 2, 3, 4 minutes, etc.).

8 , the ratings entity subsystem 106 determines the coverage and error-corrected impression composition in the age/gender impression distribution table 800. The age/gender impression distribution table 800 includes an age/gender column 802, an impression column 804, a frequency column 806, a coverage column 808, an impression composition column 810, and a time period or media portion column 812. The impression column 804 stores error-weighted impression values corresponding to impressions tracked by the ratings entity subsystem 106 (e.g., the impression monitor 132 and/or the panel collection platform 210 based on impressions recorded via the web client recorder 222). Specifically, the values in the impression column 804 are derived by multiplying the weighted MSE value from the error-weighted column 702 of FIG. 7 by the corresponding impression value from the impression column 604 of FIG.

Frequency column 806 stores the frequency of impressions tracked by database owner subsystem 108. The frequency of the impressions is entered into frequency column 806 from frequency column 506 of database owner campaign-level age/gender and impression composition table 500 of FIG. 5 . For age/gender groups missing from table 500 , the frequency value is taken from ratings entity campaign-level age/gender and impression composition table 600 of FIG. 6 . For example, database owner campaign-level age/gender and impression composition table 500 does not have less than 12 (<12) age/gender groups. Therefore, a frequency value of 3 is taken from ratings entity campaign-level age/gender and impression composition table 600 .

Reach column 808 stores reach values representing the reach of one or more content and/or ads 102 ( FIG. 1 ) for various age/gender groups. Reach values are determined by dividing each impression value from impression column 804 by the corresponding frequency value from frequency column 806. Impression composition column 810 stores a value indicating the percentage of impressions per age/gender group. In the example shown, the resulting total frequency in frequency column 806 is equal to the total impressions divided by the total reach. Example table 800 may also include impression information for other time periods of media (e.g., 2, 3, 4 minutes, etc.).

The time period or media portion column 812 indicates a time period or portion or subset of the media (e.g., first minute, second minute, first 30 seconds, second 30 seconds, first 1/10 of the media, second 1/10 of the media, etc.). The example table 800 can be organized according to the time period column 812, and each time period in the media can be measured for various demographic groups (e.g., age/gender groups). Therefore, the example ratings entity subsystem 106 generates table 800 to describe the minute-by-minute audience (or period-by-period audience, where the period can be any length of time or percentage) characteristics of the media.

Flowcharts representing example machine-readable instructions for implementing the example ratings entity subsystem 106 are shown in Figures 9, 10, 11, 12, and 14-16. In this example, the machine-readable instructions comprise a program for execution by a processor (e.g., processor 1812 shown in the example processor platform 1800 discussed below in conjunction with Figure 18). The program may be embodied in software stored on a tangible computer-readable storage medium associated with processor 1812 (e.g., a CD-ROM, floppy disk, hard drive, digital versatile disk (DVD), Blu-ray disc, or memory), although the entire program and/or portions thereof may alternatively be executed by a device other than processor 1812 and/or embodied in firmware or dedicated hardware. Furthermore, while the example program is described with reference to the flowcharts shown in Figures 9, 10, 11, 12, and 14-16, many other methods of implementing the example ratings entity subsystem 106 may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the described blocks may be changed, eliminated, or combined.

As described above, the example processes of Figures 9, 10, 11, 12, and 14-16 can be implemented using coded instructions (e.g., computer and/or machine-readable instructions) stored on a tangible computer-readable storage medium (e.g., a hard drive, flash memory, read-only memory (ROM), compact disk (CD), digital versatile disk (DVD), cache, random access memory (RAM), and/or any other storage device or storage disk that stores information for any duration (e.g., for an extended period of time, permanently, for a brief instance, for temporary buffering, and/or for cached information). As used herein, the term tangible computer-readable storage medium is expressly defined to include any type of computer-readable storage device and/or storage disk, and does not include propagating signals and does not include transmission media. As used herein, "tangible computer-readable storage medium" and "tangible machine-readable storage medium" are used interchangeably. Additionally or alternatively, the example processes of Figures 9, 10, 11, 12, and 14-16 may be implemented using coded instructions (e.g., computer and/or machine readable instructions) stored on a non-transitory computer and/or machine readable medium (e.g., a hard drive, flash memory, read-only memory, compact disk, digital versatile disk, cache, random access memory, and/or any other storage device or storage disk that stores information for any duration (e.g., for an extended period of time, permanently, for a brief instance, for a temporary buffer, and/or for cached information). As used herein, the term non-transitory computer readable medium is expressly defined to include any type of computer readable device and/or storage disk, and does not include propagating signals and does not include transmission media. As used herein, when the phrase "at least" is used as a transitional term in the preamble of a claim, it is also open ended, just as the term "comprising" is open ended.

9 , the ratings entity subsystem 106 of FIG1 may perform the depicted processing to collect demographic and impression data from partners and evaluate accuracy and/or adjust the demographic data of its panelists 114, 116 themselves. The example processing of FIG9 collects demographic and impression data of registered users of one or more partners (e.g., partners 206 and 208 of FIG2 and FIG3 ) that overlap with panelists of the ratings entity subsystem 106 (e.g., panelists 114 and 116 of FIG1 ), as well as demographic and impression data from partner sites corresponding to users who are not registered panelists of the ratings entity subsystem 106. The collected data is combined with other data collected at the ratings entity to determine an online GRP. The example processing of FIG9 is described in conjunction with the example system 100 of FIG1 and the example system 200 of FIG2 .

Initially, the GRP report generator 130 ( FIG. 1 ) receives per-user impressions 235 ( FIG. 2 ) from the impression monitor 132 (block 902 ). The GRP report generator 130 receives aggregated demographic data based on impressions (e.g., the partner campaign-level age/gender and impression composition table 500 of FIG. 5 ) from one or more partners (block 904 ). In the example shown, the GRP report generator 130 does not receive the user IDs of the registered users of the partners 206 , 208 . Instead, the partners 206 , 208 remove the user IDs and aggregate the impression-based demographic data into the partner campaign-level age/gender and impression composition table 500 at the demographic bucket level (e.g., males aged 13-18, females aged 13-18, etc.). However, in the event that the partners 206 , 208 also send user IDs to the GRP report generator 130, these user IDs are exchanged in a format encrypted, for example, based on the double encryption technique described above.

For examples in which the impression monitor 132 modifies the site ID and sends the modified site ID in the beacon response 306, the partners record impressions based on those modified site IDs. In these examples, the impressions collected from the partners in box 904 are impressions recorded by the partners for the modified site IDs. When the ratings entity subsystem 106 receives impressions with modified site IDs, the GRP report generator 130 identifies the site ID of the impression received from the partner (box 906). For example, the GRP report generator 130 uses the site ID map 310 (Figure 3) generated by the impression monitoring system 132 during beacon reception and response processing (e.g., discussed above in conjunction with Figure 3) to identify the actual site ID that corresponds to the modified site ID in the impression received from the partner.

The GRP report generator 130 receives impression-based demographic data per panelist from the panel collection platform 210 (e.g., the impression-based panelist demographic data table 250 of FIG. 2 ) (block 908). In the example shown, as shown in the impression-based panelist demographic data table 250 of FIG. 2 , the impression-based demographic data per panelist is the impressions recorded in association with the respective user IDs of the panelists 114, 116 ( FIG. 1 ).

The GRP report generator 130 removes duplicate impressions between the per-panelmember impression-based group demographic data 250 received from the group collection platform 210 at block 908 and the per-individual-user impressions 235 received from the impression monitor 132 at block 902 (block 910). In this way, duplicate impressions recorded by both the impression monitor 132 and the web client recorder 222 ( FIG. 2 ) will not skew the GRP generated by the GRP generator 130. Additionally, by utilizing the per-panelmember impression-based group demographic data 250 from the group collection platform 210 and the per-individual-user impressions 235 from the impression monitor 132, the GRP generator 130 benefits from impressions from redundant systems (e.g., the impression monitor 132 and the web client recorder 222). In this way, if one of the systems (e.g., one of the impression monitor 132 or the network client recorder 222) misses one or more impressions, a record of those impressions can be obtained from the recorded impressions of another system (e.g., the other of the impression monitor 132 or the network client recorder 222).

The GRP report generator 130 generates an aggregation of the impression-based panel demographic data 250 (block 912). For example, the GRP report generator 130 aggregates the impression-based panel demographic data 250 into demographic buckets (e.g., males aged 13-18, females aged 13-18, etc.) to generate the panelist ad campaign-level age/gender and impression composition table 600 of FIG.

In some examples, the GRP report generator 130 does not use the per-panel member impression-based panel demographic data from the panel collection platform 210. In these cases, the ratings entity subsystem 106 does not rely on a network client recorder (e.g., the network client recorder 222 of FIG. 2 ) to determine the GRP using the example process of FIG. 9 . Instead, in these cases, the GRP report generator 130 determines the panel member's impressions based on the per-individual user impressions 235 received from the impression monitor 132 at block 902 and uses the results to aggregate the impression-based panel demographic data at block 912. For example, as discussed above in conjunction with FIG. 2 , the per-individual user impressions table 235 stores the panel member user IDs associated with the total impressions and the campaign ID. Thus, the GRP report generator 130 can determine the panel member's impressions based on the per-individual user impressions 235 without using the impression-based panel demographic data 250 collected by the network client recorder 222.

The GRP report generator 130 combines the aggregated impression-based demographic data from the collaborators 206, 208 (received at block 904) and the panelists 114, 116's own demographic data (generated at block 912) with the received demographic data (block 914). For example, the GRP report generator 130 of the illustrated example combines the aggregated impression-based demographic data to form the combined campaign-level age/gender and impression composition table 700 of FIG. 7.

The GRP report generator 130 determines the distribution of the impression-based demographic data of block 914 (block 916). In the example shown, the GRP report generator 130 stores the distribution of the impression-based demographic data in the age/gender impression distribution table 800 of FIG. 8 . In addition, the GRP report generator 130 generates an online GRP based on the impression-based demographic data (block 918). In the example shown, the GRP report generator 130 uses the GRP to create one or more GRP reports 131. In some examples, the ratings entity subsystem 106 sells or provides the GRP reports 131 to advertisers, publishers, content providers, manufacturers, and/or any other entities interested in such market research. The example process of FIG. 9 then ends.

Turning now to FIG10, the example flow diagram depicted can be executed by client devices 202, 203 (FIGS. 2 and 3) to route beacon requests (e.g., beacon requests 304, 308 of FIG3) to a network service provider to record impressions based on demographic data. Initially, the client device 202, 203 receives tagged content and/or tagged advertisements 102 (block 1002) and sends a beacon request 304 to the impression monitor 132 (block 1004) to give the impression monitor 132 (e.g., at a first Internet domain) an opportunity to record the impression of the client device 202, 203. The client device 202, 203 starts a timer based on the time to wait for a response from the impression monitor 132 (block 1006).

If the timeout has not expired (block 1008), the client device 202, 203 determines whether it has received a redirect message from the impression monitor 132 (e.g., via the beacon response 306 of FIG. 3) (block 1010). If the client device 202, 203 has not received a redirect message (block 1010), control returns to block 1008. Control remains at blocks 1008 and 1010 until: (1) the timeout expires, in which case control passes to block 1016; or (2) the client device 202, 203 receives a redirect message.

If the client device 202, 203 receives the redirect message at block 1010, the client device 202, 203 sends a beacon request 308 to the partner specified in the redirect message (block 1012) to give the partner an opportunity to record the impression of the client device 202, 203. During the first instance of block 1012 for a particular tagged advertisement (e.g., tagged advertisement 102), the partner specified in the redirect message (or, in some examples, the non-cooperative database owner 110) corresponds to a second internet domain. During subsequent instances of block 1012 for the same tagged advertisement, as the beacon request is redirected to other partners or non-cooperative database owners, these other partners or non-cooperative database owners correspond to third, fourth, fifth, and so on internet domains. In some examples, as described below in conjunction with FIG. 13 , the redirect message may specify an intermediary (e.g., an intermediary server or a subdomain server) associated with the partner and/or client device 202, 203 to send the beacon request 308 to the intermediary based on the redirect message.

The client device 202, 203 determines whether to attempt to send another beacon request to another partner (block 1014). For example, the client device 202, 203 can be configured to send a specific number of beacon requests in parallel (e.g., sending beacon requests to two or more partners substantially simultaneously, rather than sending one beacon request to a first partner at a second internet domain, waiting for a reply, and then sending another beacon request to a second partner at a third internet domain, waiting for a reply, etc.) and/or wait for a redirect message to be returned from the current partner to which the client device 202, 203 sent the beacon request at block 1012. If the client device 202, 203 determines that it should attempt to send another beacon request to another partner (block 1014), control returns to block 1006.

If the client device 202, 203 determines that it should not attempt to send another beacon request to another partner (block 1014) or after the timeout expires (block 1008), the client device 202, 203 determines whether it has received a URL fetch instruction 320 ( FIG. 3 ) (block 1016). If the client device 202, 203 has not received a URL fetch instruction 320 (block 1016), control passes to block 1022. Otherwise, the client device 202, 203 fetches the URL of the host website presented by the client application 212 (block 1018), the host website displaying the tagged content and/or advertisements 102 or generating a large amount of tagged content and/or advertisements 102 (e.g., pop-up windows). The client device 202, 203 sends the crawled URL 322 to the impression monitor 132 (block 1020), and control then passes to block 1022, where the client device 202, 203 determines whether to end the example process of FIG. 10. For example, if the client device 202, 203 is turned off or placed in standby mode, or if its client application 212 (FIGS. 2 and 3) is closed, the client device 202, 203 ends the example process of FIG. 10. If the example process is not ended, control returns to block 1002 to receive another content and/or tagged advertisement. Otherwise, the example process of FIG. 10 ends.

In some examples, the real-time redirect message from the impression monitor 132 may be omitted from the example processing of Figure 10, in which case the impression monitor 132 does not send a redirect instruction to the client device 202, 203. Instead, the client device 202, 203 refers to its partner priority cookie 220 to determine the partners (e.g., partners 206 and 208) to which it should send redirects and the order of these redirects. In some examples, the client device 202, 203 sends redirects to all partners listed in the partner priority cookie 220 substantially simultaneously (e.g., one by one, but continuously without waiting for a reply). In some such examples, box 1010 is omitted, and at box 1012, the client device 202, 203 sends a redirect to the next partner based on the partner priority cookie 220. In some such examples, blocks 1006 and 1008 may also be omitted, or blocks 1006 and 1008 may be retained to provide time for the impression monitor 132 to provide the URL crawling instructions 320 at block 1016 .

Returning to FIG11 , the example flowchart may be executed by the impression monitor 132 ( FIGS. 2 and 3 ) to record impressions and/or redirect a beacon request to a network service provider (e.g., a database owner) to record impressions. Initially, the impression monitor 132 waits until it receives a beacon request (e.g., beacon request 304 of FIG3 ) (block 1102 ). The impression monitor 132 of the illustrated example receives the beacon request via the HTTP server 232 of FIG2 . When the impression monitor 132 receives the beacon request (block 1102 ), it determines whether a cookie (e.g., panelist monitor cookie 218 of FIG2 ) is received from the client device 202 , 203 (block 1104 ). For example, if the panelist monitor cookie 218 is pre-set in the client device 202 , 203 , the beacon request sent by the client device 202 , 203 to the panelist monitoring system will include the cookie.

If the impression monitor 132 determines at block 1104 that it did not receive a cookie in the beacon request (e.g., no cookie was previously set on the client device 202, 203), the impression monitor 132 sets a cookie (e.g., the panelist monitor cookie 218) on the client device 202, 203 (block 1106). For example, the impression monitor 132 may use the HTTP server 232 to send a response back to the client device 202, 203 to "set" a new cookie (e.g., the panelist monitor cookie 218).

After setting the cookie (block 1106) or if the impression monitor 132 receives the cookie in the beacon request (block 1104), the impression monitor 132 records the impression (block 1108). The impression monitor 132 of the illustrated example records the impression in the per-user impression table 235 of FIG. 2 . As described above, the impression monitor 132 records the impression regardless of whether the beacon request corresponds to a user ID that matches the user ID of a panelist (e.g., one of panelists 114 and 116 of FIG. 1 ). However, if the user ID comparator 228 ( FIG. 2 ) determines that the user ID (e.g., panelist monitor cookie 218) matches the user ID of a panelist (e.g., one of panelists 114 and 116 of FIG. 1 ) that was set by the ratings entity subsystem 106 and therefore stored in the records of the ratings entity subsystem 106, then the recorded impression will correspond to the panelist of the impression monitor 132. For these examples where the user ID matches the user ID of a panelist, the impression monitor 132 of the illustrated example records the panelist identifier along with the impression in the per-user impression table 235, and then the audience measurement entity associates the known demographic data of the corresponding panelist (e.g., a corresponding one of panelists 114, 116) with the recorded impression based on the panelist identifier. This association between panelist demographic data (e.g., age/gender column 602 of FIG. 6 ) and recorded impression data is illustrated in the panelist campaign-level age/gender and impression composition table 600 of FIG. 6 . If the user ID comparator 228 ( FIG. 2 ) determines that the user ID does not correspond to a panelist 114, 116, then the impression monitor 132 will still benefit from recording the impression (e.g., an ad impression or a content impression) even though it does not have a user ID record (and therefore, corresponding demographic data) for the impression reflected in the beacon request 304.

The impression monitor 132 selects the next collaborator (block 1110). For example, the impression monitor 132 may use the rules/ML engine 230 (FIG. 2) to select one of the collaborators 206 or 208 of FIG. 2 and FIG. 3 for the initial redirection, either randomly or based on an ordered list or ranking of the collaborators 206 and 208 according to the rules/ML engine 230 (FIG. 2), and select the other of the collaborators 206 or 208 for subsequent redirections during subsequent executions of block 1110.

The impression monitor 132 sends a beacon response (e.g., beacon response 306) including an HTTP 302 redirect (or any other suitable instruction to cause a redirected communication) to the client device 202, 203 to forward the beacon request (e.g., beacon request 308 of FIG. 3 ) to the next partner (e.g., partner A 206 of FIG. 2 ) (block 1112) and start a timer (block 1114). The impression monitor 132 of the illustrated example uses the HTTP server 232 to send the beacon response 306. In the illustrated example, the impression monitor 132 sends the HTTP 302 redirect (or any other suitable instruction to cause a redirected communication) at least once to at least allow the partner site (e.g., one of partners 206 or 208 of FIG. 2 and FIG. 3 ) to also record an impression of the same ad (or content). However, in other example implementations, the impression monitor 132 may include rules (e.g., as part of the rules/ML engine 230 of FIG. 2 ) to exclude some beacon requests from being redirected. The timer set at block 1114 is used to wait for real-time feedback from the next collaborator in the form of a failure status message indicating that the next collaborator did not find a match for the client device 202, 203 in its records.

If the timeout has not expired (block 1116), the impression monitor 132 determines whether it has received a failure status message (block 1118). Control remains at blocks 1116 and 1118 until: (1) the timeout expires, in which case control passes to block 1102 to receive another beacon request; or (2) the impression monitor 132 receives a failure status message.

If the impression monitor 132 receives a failure status message (block 1118), the impression monitor 132 determines whether there is another partner to which the beacon request should be sent (block 1120) to provide another opportunity to record an impression. The impression monitor 132 may select the next partner based on intelligent selection processing using the rules/ML engine 230 of FIG. 2 or based on a fixed hierarchy of partners. If the impression monitor 132 determines that there is another partner to which the beacon request should be sent, control returns to block 1110. Otherwise, the example process of FIG. 11 ends.

In some examples, real-time feedback from collaborators may be omitted from the example process of FIG. 11 , and the impression monitor 132 does not send redirect instructions to the client devices 202, 203. Instead, the client device 202, 203 refers to its collaborator preference cookie 220 to determine the collaborators (e.g., collaborators 206 and 208) to which it should send redirects and the order in which these redirects should be sent. In some examples, the client device 202, 203 simultaneously sends redirects to all collaborators listed in the collaborator preference cookie 220. In some such examples, blocks 1110, 1114, 1116, 1118, and 1120 are omitted, and at block 1112, the impression monitor 132 sends a confirmation response to the client device 202, 203 without sending the next collaborator redirect.

Turning now to FIG. 12 , an example flow chart can be executed to dynamically designate a preferred network service provider (or active partner) from which to request impression recording using the example redirection beacon request process of FIG. 10 and FIG. 11 . The example process of FIG. 12 is described in conjunction with the example system 200 of FIG. 2 . An initial impression associated with content and/or advertising delivered by a particular publisher site (e.g., publisher 302 of FIG. 3 ) triggers the beacon instruction 214 ( FIG. 2 ) (and/or beacon instructions at other devices) to request that a preferred partner record an impression (block 1202 ). In the example shown, the preferred partner is initially Partner A site 206 ( FIG. 2 and FIG. 3 ). The impression monitor 132 ( FIG. 1 , FIG. 2 , and FIG. 3 ) receives feedback on non-matching user IDs from the preferred partner 206 (block 1204). The rule/ML engine 230 ( FIG. 2 ) updates the preferred partner for the non-matching user ID based on the feedback received at block 1204 (block 1206). In some examples, during the operation of block 1206, the impression monitor 132 also updates the collaborator priority of the preferred collaborators in the collaborator priority cookie 220 of FIG. 2 . Subsequent impressions trigger the beacon instruction 214 (and/or the beacon instructions at other devices 202 , 203 ) to send a request to record an impression to a correspondingly different preferred collaborator based specifically on each user ID (block 1208 ). That is, some user IDs in the panelist monitor cookie 218 and/or the collaborator cookie 216 may be associated with one preferred collaborator, while other user IDs are now associated with different preferred collaborators due to the operation at block 1206 . The example process of FIG. 12 then ends.

FIG13 illustrates an example system 1300 that can be used to determine media (e.g., content and/or advertising) exposure based on information collected by one or more database owners. Example system 1300 is another example of systems 200 and 300 shown in FIG2 and FIG3 , in which intermediaries 1308 and 1312 are provided between client devices 1304 and collaborators 1310 and 1314. Those skilled in the art will appreciate that the descriptions of FIG2 and FIG3 and the corresponding flow charts of FIG8-12 are applicable to system 1300 including intermediaries 1308 and 1312.

According to the example shown, publisher 1302 sends an advertisement or other media content to client device 1304. Publisher 1302 may be publisher 302 as described in conjunction with FIG3 . Client device 1304 may be panelist client device 202 or non-panelist device 203 as described in conjunction with FIG2 and FIG3 , or any other client device. The advertisement or other media content includes a beacon that instructs the client device to send a request to impression monitor 1306 as described above.

The impression monitor 1306 can be the impression monitor 132 described in conjunction with Figures 1-3. The impression monitor 1306 of the illustrated example receives a beacon request from the client device 1304 and sends a redirect message to the client device 1304 to instruct the client to send the request to one or more of broker A 1308, broker B 1312, or any other system (e.g., another broker, a partner, etc.). The impression monitor 1306 also receives information about partner cookies from one or more of broker A 1308 and broker B 1312.

In some examples, impression monitor 1306 may insert a client identifier, created by impression monitor 1306 and identifying client device 1304 and/or its user, into the redirect message. For example, the client identifier may be an identifier stored in a cookie set at the client by impression monitor 1306 or any other entity, an identifier assigned by impression monitor 1306 or any other entity, or the like. The client identifier may be a unique identifier, a quasi-unique identifier, or the like. In some examples, the client identifier may be encrypted, obfuscated, or altered to prevent tracking of the identifier by intermediaries 1308, 1312 or collaborators 1310, 1314. According to the illustrated example, the client identifier is included in the redirect message to client device 1304 so that client device 1304 sends the client identifier to intermediaries 1308, 1312 when client device 1304 follows the redirect message. For example, the client identifier may be included in a URL included in the redirect message so that client device 1304 sends the client identifier to intermediaries 1308, 1312 as a parameter of a request sent in response to the redirect message.

The example intermediaries 1308, 1312 shown receive redirected beacon requests from the client device 1304 and send information about the requests to the partners 1310, 1314. The example intermediaries 1308, 1312 can be made available on the content delivery network (e.g., one or more servers of the content delivery network) to ensure that the client can send requests quickly without causing significant interruption in access to content from the publisher 1302.

In the examples disclosed herein, a cookie set in a domain (e.g., "partnerA.com") can be accessed by a server in a subdomain (e.g., "intermediary.partnerA.com") corresponding to the domain (e.g., the root domain "partnerA.com") in which the cookie is set. In some examples, the reverse is also true: a cookie set in a subdomain (e.g., "intermediary.partnerA.com") can be accessed by a server in a root domain (e.g., the root domain "partnerA.com") corresponding to the subdomain (e.g., "intermediary.partnerA.com") in which the cookie is set. As used herein, the term domain (e.g., internet domain, domain name, etc.) includes a root domain (e.g., "domain.com") and subdomains (e.g., "a.domain.com," "b.domain.com," "c.d.domain.com," etc.).

In order to enable the example intermediaries 1308 and 1312 to receive cookie information associated with partners 1310 and 1314, respectively, subdomains of partners 1310 and 1314 are assigned to intermediaries 1308 and 1312. For example, partner A 1310 may register an Internet address associated with intermediary A 1308 with a subdomain in the domain name system associated with partner A 1310's domain. Alternatively, the subdomain may be associated with the intermediary in any other manner. In these examples, when client 1304 sends a request to intermediary A 1308, a cookie set for partner A 1310's domain name is sent from client device 1304 to intermediary A 1308, which is assigned the subdomain associated with partner A 1310's domain.

The example brokers 1308, 1312 send a beacon request message including a campaign ID and the received cookie information to the partners 1310, 1314, respectively. This information may be stored at the brokers 1308, 1312 so that it can be sent to the partners 1310, 1314 in batches. For example, the received information may be sent at the end of the day, the end of the week, after a threshold amount of information has been received, etc. Alternatively, the information may be sent immediately upon receipt. The campaign ID may be encrypted, obfuscated, altered, etc. to prevent the partners 1310, 1314 from identifying the content to which the campaign ID corresponds or to otherwise protect the identity of the content. A lookup table of campaign ID information may be stored at the impression monitor 1306 so that impression information received from the partners 1310, 1314 can be correlated with the content.

The intermediaries 1308 and 1312 of the illustrated example also send an indication of the availability of partner cookies to the impression monitor 1306. For example, when a redirected beacon request is received at intermediary A 1308, intermediary A 1308 determines whether the redirected beacon request includes a cookie for partner A 1310. When the cookie for partner A 1310 is received, intermediary A 1308 sends a notification to the impression monitor 1306. Alternatively, intermediaries 1308 and 1312 may send information regarding the availability of partner cookies regardless of whether a cookie is received. In the event that the impression monitor 1306 includes a client identifier in the redirect message and the client identifier is received at intermediaries 1308 and 1312, intermediaries 1308 and 1312 may include the client identifier with the information regarding the partner cookie sent to the impression monitor 1306. The impression monitor 1306 may use the information regarding the presence of the partner cookie to determine how to redirect future beacon requests. For example, the impression monitor 1306 may choose not to redirect the client to an intermediary 1308, 1312 associated with a partner 1310, 1314 for which it has determined that the client does not have a cookie. In some examples, information about whether a particular client has cookies associated with a partner may be periodically refreshed to take into account cookie expiration and setting of new cookies (e.g., recent login or registration at one of the partners).

Intermediaries 1308 and 1312 may be implemented by servers associated with a content statistics entity (e.g., the content statistics entity providing impression monitor 1306). Alternatively, intermediaries 1308 and 1312 may be implemented by servers associated with partners 1310 and 1314, respectively. In other examples, the intermediaries may be provided by a third party, such as a content delivery network.

In some examples, intermediaries 1308, 1312 are provided to prevent direct connections between partners 1310, 1314 and client device 1304, prevent some information from redirected beacon requests from being sent to partners 1310, 1314 (e.g., prevent REFERRER_URL from being sent to partners 1310, 1314), reduce network traffic at partners 1310, 1314 associated with redirected beacon requests, and/or send a real-time or near real-time indication to impression monitor 1306 of whether partner cookies are provided via client device 1304.

In some examples, the intermediaries 1308, 1312 are trusted by the collaborators 1310, 1314 to prevent confidential data from being sent to the impression monitor 1306. For example, the intermediaries 1308, 1312 may remove identifiers stored in collaborator cookies before sending information to the impression monitor 1306.

Partners 1310, 1314 receive beacon request information from intermediaries 1308, 1312, including a campaign ID and cookie information. Partners 1310, 1314 determine the identity and demographics of the user of client device 1304 based on the cookie information. Example partners 1310, 1314 track impressions for the campaign ID based on the determined demographics associated with the impressions. Based on the tracked impressions, example partners 1310, 1314 generate reports (described previously). The reports can be sent to impression monitor 1306, publisher 1302, advertisers that supply advertisements provided by publisher 1302, media content centers, or other persons or entities interested in the reports.

FIG14 is a flow diagram representing example machine-readable instructions that may be executed to process redirected requests at an intermediary. The example process of FIG14 is described in conjunction with example intermediary A 1308. Some or all of the blocks may additionally or alternatively be performed by example intermediary B 1312 of FIG13, one or more of partners 1310, 1314, or other partners described in conjunction with FIG1-3.

According to the illustrated example, intermediary A 1308 receives a redirected beacon request from client device 1304 (block 1402). Intermediary A 1308 determines whether client device 1304 sent a cookie associated with partner A 1310 in the redirected beacon request (block 1404). For example, when a domain name that is a subdomain of partner A 1310 is assigned to intermediary A 1308, client device 1304 sends the cookie set by partner A 1310 to intermediary A 1308.

When the redirected beacon request does not include a cookie associated with partner A 1310 (block 1404), control passes to block 1412 (described below). When the redirected beacon request includes a cookie associated with partner A 1310 (block 1404), broker A 1308 notifies impression monitor 1306 of the presence of the cookie (block 1406). The notification may additionally include information associated with the redirected beacon request (e.g., source URL, campaign ID, etc.), an identifier of the client, etc. In the illustrated example, broker A 1308 stores the campaign ID and partner cookie information included in the redirected beacon request (block 1408). Broker A 1308 may additionally store other information associated with the redirected beacon request (e.g., source URL, referrer ID, etc.).

The example broker A 1308 then determines whether the stored information should be sent to partner A 1310 (block 1408). For example, broker A 1308 may determine that the information should be sent immediately, may determine that a threshold amount of information has been received, may determine that the information should be sent based on the time of day, etc. When broker A 1308 determines that the information should not be sent (block 1408), control passes to block 1412. When broker A 1308 determines that the information should be sent (block 1408), broker A 1308 sends the stored information to partner A 1310. The stored information may include information associated with a single request, information associated with multiple requests from a single client, information associated with multiple requests from multiple clients, etc.

According to the example shown, broker A 1308 then determines whether the client device 1304 should contact the next broker and/or partner (block 1412). When no cookie associated with partner A 1310 is received, the example broker A 1308 determines that the next partner should be contacted. Alternatively, broker A 1308 may determine that the next partner should be contacted whenever a redirected beacon request associated with a partner cookie or the like is received.

When broker A 1308 determines that the next partner (e.g., broker B 1314) should be contacted (block 1412), broker A 1308 sends a beacon redirect message to the client device 1304 indicating that the client device 1304 should send the request to broker B 1312. After sending the redirect message (block 1414) or when broker A 1308 determines that the next partner should not be contacted (block 1412), the example process of FIG. 14 ends.

While the example of FIG14 illustrates an approach in which each intermediary 1308, 1312 selectively or automatically sends a redirect message that sequentially identifies the next intermediary 1308, 1312, other approaches may also be implemented. For example, a redirect message from impression monitor 1306 may identify multiple intermediaries 1308, 1312. In this case, the redirect message may instruct client device 1304 to send requests to each intermediary 1308, 1312 (or a subset) sequentially, may instruct client device 1304 to send requests to each intermediary 1308, 1312 in parallel (e.g., using JavaScript instructions that support parallel execution of requests), etc.

Although the example of FIG14 is described in conjunction with broker A, some or all of the blocks of FIG14 may be performed by broker B 1312, one or more of partners 1310, 1314, any other partner described herein, or any other entity or system. Additionally or alternatively, multiple instances of FIG14 (or any other instructions described herein) may be executed in parallel at any number of locations.

Turning now to FIG. 15 , an example flow diagram is depicted that may be executed by client devices 202 , 203 ( FIG. 2 and FIG. 3 ) to send pingback messages (eg, pingback messages 304 , 308 of FIG. 3 ) to an impression monitor and a database owner.

The example client device 202 of FIG3 receives tagged media (e.g., a webpage including the tagged media 102) (block 1502). The example client application 212 requests repeated pingback instructions 214 (e.g., from the beacon server 215 of FIG3 based on the beacon instructions 213) (block 1504). The example client application 212 receives repeated pingback instructions (e.g., the repeated pingback instructions 214 of FIG3) (block 1506).

The example client application 212 determines whether a threshold (e.g., a minimum viewing period) has been reached (block 1507). For example, the repeated pingback instructions 214 may require a minimum viewing period (e.g., an impression qualification period) to exist before the first pingback is sent. If the minimum viewing period has not been reached, control continues to loop to block 1507. The minimum viewing period may be configurable based on, for example, characteristics of the tagged media (e.g., the length of the tagged media, the demographics of the intended viewers of the tagged media, etc.) and/or the preferences or requirements of the media publisher (e.g., the publisher may not consider the tagged media valid for providing an impression until a certain length of the media has been viewed).

When the minimum viewing period is reached (box 1507), the example client application 212 sends a pingback message (e.g., pingback message 306 of Figure 3) to an impression monitor (e.g., impression monitor 132 of Figure 3) (box 1508). The example pingback message includes a cookie corresponding to the ratings entity (e.g., user ID), an identifier of the media (e.g., media ID), a timestamp, and/or an event (if applicable). The example client application 212 also sends a pingback message (e.g., pingback message 308 of Figure 3) to the database owner (e.g., partner A 206, partner B 208 of Figure 3) (box 1510). The example pingback message 308 includes a cookie corresponding to the database owner (e.g., user ID), media ID, and/or a timestamp.

The example client application 212 starts a timer (e.g., a countdown timer). The example timer provides an interval for the client application 212 to send pingback messages. In some examples, the client application 212 uses different timers for pingback messages to the impression monitor 132 and to the database owners 206 and 208. In some examples, the impression server redirects the client application 212 to the database owner, so only one timer is used (i.e., the timer triggers a request to the impression server, which results in the redirection to the database owner). The example client application 212 determines whether the timer has expired (block 1514). If the timer has not expired (block 1514), the example client application 212 determines whether a media event has occurred (block 1516). Example media events include pausing media, jumping to a location in the media, and/or skipping a portion of the media. If a media event has occurred (block 1516) and/or if the timer has expired (block 1514), control returns to block 1508 to send the pingback message.

If no media event has occurred (block 1516) and the timer has not expired (block 1514), the example client application 212 determines whether the media has been closed (block 1518). For example, the media can be closed when the user stops the media, navigates to different media, and/or closes the application presenting the media (e.g., a browser window and/or tab). If the media has not been closed (block 1518), control returns to block 1514. When the media has been closed (block 1518), the example instructions of FIG. 15 end.

16 , an example flowchart may be executed by the impression monitor 132 ( FIGS. 2 and 3 ) to record pingbacks (e.g., pingback messages) and/or calculate ratings information based on pingback messages and demographic information. The example client application 212 sets a watchdog timer (block 1602 ). The example watchdog timer determines when a sufficient amount of time has passed without a pingback message so that an impression can be calculated from the received pingback message. The impression monitor 132 waits until it receives a pingback message (e.g., pingback message 304 of FIG. 3 ) (block 1604). The example impression monitor 132 receives the pingback message via the HTTP server 232 of FIG. 2 . When the impression monitor 132 receives the pingback message (block 1604), it determines whether a cookie (e.g., panelist monitor cookie 218 of FIG. 2 ) has been received from the client device 202 , 203 (block 1606). For example, if the panelist monitor cookie 218 is pre-set in the client device 202, 203, the pingback message sent by the client device 202, 203 to the panelist monitor system will include the cookie.

If the impression monitor 132 determines at block 1606 that it did not receive a cookie in the pingback message (e.g., no cookie was previously set on the client device 202, 203), the impression monitor 132 sets a cookie (e.g., the panelist monitor cookie 218) on the client device 202, 203 (block 1608). For example, the impression monitor 132 may use the HTTP server 232 to send a response back to the client device 202, 203 to "set" a new cookie (e.g., the panelist monitor cookie 218).

After setting the cookie (block 1608) or if the impression monitor 132 receives the cookie in the pingback message (block 1606), the impression monitor 132 records the pingback message (block 1610). The impression monitor 132 of the illustrated example records the pingback message in the media impression table 235 of FIG. 2 . As described above, the impression monitor 132 records the pingback message regardless of whether the pingback message corresponds to a user ID that matches the user ID of a panelist (e.g., one of the panelists 164 and 166 of FIG. 1 ). However, if the user ID comparator 228 ( FIG. 2 ) determines that the user ID (e.g., panelist monitor cookie 218) matches the user ID of a panelist (e.g., one of the panelists 164 and 166 of FIG. 1 ) set by the ratings entity subsystem 106 and thus stored in the records of the ratings entity subsystem 106, the recorded pingback message will correspond to the panelist of the impression monitor 132. For these examples where the user ID matches the user ID of a panelist, the impression monitor 132 of the illustrated example records the panelist identifier along with the pingback message in the media impression table 235. Subsequently, the audience measurement entity associates known demographic data of the corresponding panelist (e.g., a corresponding one of panelists 164, 166) with the recorded pingback message based on the panelist identifier. This association between panelist demographic data (e.g., age/gender column 602 of FIG. 6 ) and recorded impression data is illustrated in the panelist campaign-level age/gender and impression composition table 600 of FIG. 6 . If the user ID comparator 228 ( FIG. 2 ) determines that the user ID does not correspond to panelist 164, 166, then the impression monitor 132 will still benefit from recording the pingback message (e.g., media impression) even though it does not have a user ID record (and therefore, corresponding demographic data) for the impression reflected in the pingback message 304. After recording the pingback message (block 1610 ), control returns to block 1602 to reset the watchdog timer.

When no pingback message is received (block 1604), the example impression monitor 132 determines whether the watchdog timer has expired (block 1612). If the watchdog timer has not expired (block 1612), control returns to block 1604 to determine whether a pingback message has been received.

When the watchdog timer expires (block 1612), the example impression monitor 132 calculates impressions from the pingback messages (block 1614). For example, the impression monitor 132 of FIG. 3 determines the portion of media presented to the user and the adjacent viewing portion (e.g., determined from sequential pingback messages at a specified interval) based on information in the pingback messages (including any jumps or other events).

The example impression monitor 132 and/or ratings entity combines the impressions with demographic information from the database owner (eg, Partners A 206 , B 208 of FIG. 3 ) (block 1616 ).

The example impression monitor 132 and/or the ratings entity divides the impression information (e.g., persistent impression information) based on the type of media presented in the persistent impression (box 1618). For example, the impression monitor 132 may determine that the persistent impression is associated with one or more advertisements as a first media type and with program content as a second media type. By dividing the time period associated with the persistent impression based on the media type presented in the persistent impression, the example impression monitor 132 and/or the ratings entity may determine separate ratings information for separate media types. Additionally and/or alternatively, the example impression monitor 132 and/or the example ratings entity may determine ratings information for the media types of interest (e.g., only the first media type, only the second media type, only for additional media types presented in the persistent impression, and/or any combination of two or more media types). For example, the example impression monitor 132 and/or ratings entity may ignore time spent viewing a first media type (e.g., advertisements) when calculating views of a second media type (e.g., content or program views), and/or may ignore time spent viewing a second media type when calculating views of a first media type.

The resulting segmented and/or unsegmented persistent impression information includes the portion presented at the client device and demographic data associated with the client device. An example impression monitor 132 and/or ratings entity calculates demographic characteristics for the media portion (and/or media type of the media portion) based on the persistent impressions and demographic information (block 1620). For example, the impression monitor 132 may determine a first demographic characteristic for a first media type in the media and a second demographic characteristic for a second media type in the media. In some examples, the impression monitor 132 and/or ratings entity calculates granular minute-by-minute ratings information (e.g., unique audiences and corresponding demographic groups) using the persistent impressions and demographic information in combination with persistent impressions and demographic information for other devices that presented the media.

Figure 17 depicts an example impression log 1700 that records impressions for user IDs and media IDs. The example impression log 1700 of Figure 17 records a timestamp, media ID, user ID, and event for a received pingback message. The example timestamp indicates the time when the pingback message was generated. In the example impression log 1700 of Figure 17, the entries are arranged in timestamp order. The example entries are grouped based on user ID and media ID. If such information is provided in the corresponding pingback message, the example entry also specifies the event. The example impression monitor 132 and/or the ratings entity determines that the entry in the example log corresponds to a persistent impression of the media. The example impression monitor 132 also determines that the persistent impression does not apply to a specific portion (e.g., a specific minute) of the media (e.g., after one minute and 40 seconds of playback, playback jumps to the 4 minute 30 second mark of the media, meaning that the time period from 1 minute 41 seconds to 4 minutes 29 seconds is skipped). As a result, the persistent impression and demographic data corresponding to the user ID are not included in the ratings for the skipped portion.

FIG18 is a block diagram of an example processor system 1810 that can be used to implement the example devices, methods, products, and/or systems disclosed herein. As shown in FIG18 , processor system 1810 includes a processor 1812 connected to an interconnection bus 1814. Processor 1812 can be any suitable processor, processing unit, or microprocessor. Although not shown in FIG18 , system 1810 can be a multi-processor system and, therefore, can include one or more additional processors that are identical or similar to processor 1812 and that are communicatively connected to interconnection bus 1814.

18 is coupled to a chipset 1818, which includes a memory controller 1820 and an input/output (I/O) controller 1822. The chipset provides I/O and memory management functions, as well as a number of general and/or special registers, timers, etc., that can be accessed or used by one or more processors coupled to the chipset 1818. The memory controller 1820 performs functions that enable the processor 1812 (or multiple processors, if multiple processors are present) to access system memory 1824, mass storage 1825, and/or optical media 1827.

In general, system memory 1824 may include any desired type of volatile and/or non-volatile memory, such as static random access memory (SRAM), dynamic random access memory (DRAM), flash memory, read-only memory (ROM), etc. Mass storage 1825 may include any desired type of mass storage device, including a hard drive, an optical device, a tape storage device, etc. Optical media 1827 may include any desired type of optical media, such as a digital versatile disk (DVD), a compact disk (CD), or a Blu-ray disk. The instructions of any of Figures 9-12 and Figures 14-16 may be stored on any tangible medium represented by system memory 1824, mass storage device 1825, and/or any other medium.

The I/O controller 1822 performs functions that enable the processor 1812 to communicate with peripheral input/output (I/O) devices 1826 and 1828 and a network interface 1830 via an I/O bus 1832. The I/O devices 1826 and 1828 may be any desired type of I/O device, such as a keyboard, a video display or monitor, a mouse, etc. For example, the network interface 1830 may be an Ethernet device, an asynchronous transfer mode (ATM) device, an 802.11 device, a digital subscriber line (DSL) modem, a cable modem, a cellular modem, etc., that enables the processor system 1810 to communicate with another processor system.

Although memory controller 1820 and I/O controller 1822 are shown in FIG. 18 as separate functional blocks within chipset 1818 , the functions performed by these blocks may be integrated within a single semiconductor circuit or may be implemented using two or more separate integrated circuits.

Although the above disclosure uses cookies to send identification information from a client to a server, any other system for sending identification information from a client to a server or other device can be used. For example, the identification information or any other information provided by any cookie disclosed herein can be provided by an Adobe client identifier, identification information stored in an HTML5 database, etc. The methods and apparatus described herein are not limited to implementations using cookies.

US Patent No. 8,370,489 is incorporated herein by reference in its entirety.

Although example methods, devices, systems, and products are disclosed above that include (among other components) firmware and/or software executed on hardware, it should be noted that these methods, devices, systems, and products are merely illustrative and should not be considered limiting. For example, it is contemplated that any one or all of these hardware, firmware, and/or software components could be implemented solely in hardware, solely in firmware, solely in software, or in any combination of hardware, firmware, and/or software. Therefore, although example methods, devices, systems, and products are described below, these examples are not the only way to implement these methods, devices, systems, and products.

Although certain example methods, apparatus, systems, and articles of manufacture have been disclosed herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all methods, apparatus, systems, and articles of manufacture fairly falling within the scope of the claims either literally or under the doctrine of equivalents.

Claims (18)

1. A method for monitoring online media presentation, the method comprising the following steps: sending, by logic circuitry of the audience measurement entity, via a network, pingback instructions that, when executed by a client device, cause the client device to send a pingback message in response to presentation of a portion of an item of media transmitted to the client device via the network; receiving, by the logic circuitry of the audience measurement entity, via the network, a first pingback message of the pingback messages sent by the client device in response to executing the pingback instruction, wherein a plurality of the first pingback messages correspond to different ones of the portions of the item of media presented at the client device; sending, by the logic circuitry of the audience measurement entity, a response message to the client device via the network in response to one of the first pingback messages sent by the client device, the response message causing the client device to send a second pingback message to a database owner; determining, by the logic circuitry of the audience measurement entity, the portion of the item of media presented at the client device based on at least the one of the first pingback messages; obtaining, at the logic circuitry of the audience measurement entity, demographic information associated with the client device from a database owner, the demographic information being obtained in response to the second pingback message; determining, by the logic circuitry of the audience measurement entity, a first demographic characteristic associated with a first one of the portions of the item of media based on one of the first pingback messages and the demographic information; determining, by the logic circuitry of the audience measurement entity, a number of impressions for respective ones of the portions of the item of media based on the first pingback message and based on third pingback messages received from other client devices; and A respective demographic characteristic corresponding to the impression is determined by the logic circuitry of the audience measurement entity based on the first demographic characteristic, the first pingback message, and the third pingback message. 2. The method of claim 1, wherein the step of obtaining the demographic information is based on a cookie provided to the client device by the audience measurement entity, the first pingback message including the cookie. 3. A method according to claim 1, wherein the item of media includes content and advertisements, the first portion of the portion of the item of media includes the advertisements, and the step of determining the first demographic characteristic associated with the first portion of the portion of the item of media includes the step of determining the first demographic characteristic associated only with the advertisements. 4. The method of claim 1 , wherein at least a first one of the first pingback messages includes a time relative to a specified point in the item of media, the method further comprising the step of determining a first impression of one of the portions of the item of media in the impression based on the time and based on at least a second one of the first pingback messages. 5 . The method of claim 1 , wherein the portion of the item of media corresponds to discrete intervals of the item of media, and a plurality of pingback messages in the first pingback message correspond to respective ones of the discrete intervals. 6. The method of claim 5, wherein the step of determining the respective demographic characteristics corresponding to the impressions comprises the step of determining impressions of the impressions that are attributed to demographic groups. 7. The method of claim 1 , wherein a plurality of the first pingback messages correspond to different portions of the item of media presented at the client device, the one of the first pingback messages being received in response to presentation of a corresponding portion of the different portions of the item of media at the client device. 8. The method of claim 7, wherein the first pingback message identifies the different portion of the item of media presented at the client device. 9. A method for monitoring online media presentation, the method comprising the following steps: sending, by logic circuitry of an audience measurement entity, via a network, pingback instructions that, when executed by a client device, cause the client device to send a first pingback message to the logic circuitry of the audience measurement entity in response to presentation of a portion of an item of media transmitted to the client device via the network; receiving, by the logic circuitry of the audience measurement entity, a first pingback message sent by the client device when the client device executes the pingback instruction, the first pingback message corresponding to presentation of the item of media at the client device, the first pingback message identifying the item of media and a corresponding time within the item of media or a corresponding duration within the item of media, respectively; determining, by the logic circuitry of the audience measurement entity, a portion of the item of media presented at the client device based on the time or the duration identified in the first pingback message; sending, by the logic circuitry of the audience measurement entity, a response message to the client device via the network in response to a corresponding one of the first pingback messages sent by the client device, the response message causing the client device to send a second pingback message to a database owner; obtaining, at the logic circuitry of the audience measurement entity, demographic information associated with the client device in response to the second pingback message; determining, by the logic circuitry of the audience measurement entity, a plurality of impressions of a first portion of the portions of the item of media based on a corresponding one of the first pingback messages; and Demographic characteristics associated with the plurality of impressions of the first one of the portions of the item of the media are determined by the logic circuitry of the audience measurement entity based on the corresponding one of the first pingback messages and the demographic information. 10. A method for monitoring online media presentation, the method comprising the following steps: sending, by logic circuitry of the audience measurement entity, via a network, pingback instructions that, when executed by a client device, cause the client device to send a pingback message in response to presentation of a portion of an item of media transmitted to the client device via the network; receiving, by the logic circuitry of the audience measurement entity, via the network, a first pingback message of the pingback messages sent by the client device in response to executing the pingback instruction, wherein a plurality of the first pingback messages correspond to different ones of the portions of the item of media presented at the client device, a first one of the portions of the item of media having a first media type and a second one of the portions of the item of media having a second media type; determining, by the logic circuitry of the audience measurement entity, the first portion of the portion of the item of media presented at the client device based on a first pingback message of the first pingback messages; obtaining, at the logic circuitry of the audience measurement entity, demographic information associated with the client device; determining, by the logic circuitry of the audience measurement entity, a first number of impressions for the first portion of the portion of the item of the media based on the first pingback message and second pingback messages received from other client devices; determining, by the logic circuitry of the audience measurement entity, a first demographic characteristic corresponding to the first number of impressions based on the demographic information, the first pingback message, and the second pingback message; determining, by the logic circuitry of the audience measurement entity, a second number of impressions for the second portion of the portion of the item of the media based on the first pingback message and the second pingback message; and A second demographic characteristic corresponding to the second number of impressions is determined by the logic circuitry of the audience measurement entity based on the demographic information, the first pingback message, and the second pingback message. 11. An audience measurement entity device, the audience measurement entity device comprising: A communication interface, which: sending, via a network, pingback instructions that, when executed by a client device, cause the client device to send a pingback message in response to presentation of a portion of an item of media transmitted to the client device via the network; receiving a first one of the pingback messages sent by the client device based on the pingback instruction, a plurality of the first pingback messages corresponding to different ones of the portions of the item of media presented at the client device; sending a response message to the client device in response to one of the first pingback messages sent by the client device, the response message causing the client device to send a second one of the pingback messages to a database owner; and receiving demographic information associated with the client device from the database owner, the demographic information received based on the second pingback message; and An impression monitor, which is implemented by the processor as: determining the portion of the item of media presented at the client device based on at least one of the first pingback messages; determining a first demographic characteristic associated with a first one of the portions of the item of media presented at the client device based on at least one of the first pingback message and the demographic information; determining a plurality of impressions for respective ones of the portions of the item of media based on the first pingback message and based on third pingback messages received from other client devices; and A respective demographic characteristic corresponding to the impression is determined based on the first demographic characteristic, the first pingback message, and the third pingback message. 12. The audience measurement entity device of claim 11, wherein the communication interface receives the demographic information based on a cookie provided by the audience measurement entity device to the client device, the first pingback message including the cookie. 13. The audience measurement entity device according to claim 11, further comprising a rule engine for selecting the database owner, wherein the communication interface sends the response message to the client device as a redirect message. 14. An audience measurement entity device according to claim 11, wherein the item of media includes content and advertisements, the first portion of the portion of the item of media includes the advertisements, and the impression monitor determines the first demographic characteristic associated with the first portion of the portion of the item of media by determining the first demographic characteristic associated only with the advertisements. 15. The audience measurement entity device according to claim 11, wherein at least a first pingback message of the first pingback messages includes a time based on a specified point in the item of the media, and the impression monitor identifies a first impression of one of the parts of the item of the media in the impression based on the time and based on at least a second pingback message of the first pingback messages. 16. The audience measurement entity of claim 11, wherein the portion of the item of media corresponds to discrete intervals within the item of media, and the plurality of pingback messages of the first pingback message correspond to respective ones of the discrete intervals. 17. The audience measurement entity of claim 11, wherein the impression monitor determines the respective demographic characteristics corresponding to the impression by determining impressions attributed to a demographic group among the impressions. 18. A method for monitoring online media presentation, the method comprising the following steps: sending, by a processor of the audience measurement entity, via a network, pingback instructions that, when executed by a client device, cause the client device to send a pingback message in response to presentation of a portion of an item of media transmitted to the client device via the network; receiving, by the processor of the audience measurement entity, a first pingback message of the pingback messages from the client device, the first pingback message identifying the item of media, the first pingback message identifying a first time period within a duration of the item of media; In response to the first pingback message, the processor of the audience measurement entity sends a redirect message to the client device, so that the client device sends a request to a database owner; receiving, by the processor of the audience measurement entity from the database owner in response to the redirect message, first demographic information corresponding to the client device; receiving, by the processor of the audience measurement entity, a second pingback message from the client device, the second pingback message identifying the item of media and a second time period within the duration of the item of media, the second time period being different from the first time period; determining, by the processor of the audience measurement entity, a demographic characteristic associated with the client device based on the first demographic information; The processor of the audience measurement entity determines, based on the first pingback message and the demographic characteristics, a first number of impressions for the first time period within the duration of the media item corresponding to the demographic characteristics; and the processor of the audience measurement entity determines, based on the second pingback message and the demographic characteristics, a second number of impressions for the second time period within the duration of the media item corresponding to the demographic characteristics.