HK1208279B - Methods and apparatus to share online media impressions data - Google Patents

Description

Method and apparatus for sharing online media impression data

Related applications

This patent claims priority to U.S. Provisional Patent Application No. 61/658,233, filed June 11, 2012, U.S. Provisional Patent Application No. 61/810,235, filed April 9, 2013, and Australian Patent Application No. 2103204865, filed April 12, 2013, all of which are incorporated by reference.

Technical Field

The present disclosure relates generally to monitoring media and, more particularly, to methods and apparatus for determining impressions using distributed demographic information.

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 the 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 different media content based on the collected media measurement data.

Over the years, the technology for monitoring user 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 providing content services on the Internet may use known techniques to record the number of requests received for their content at their servers.

BRIEF DESCRIPTION OF THE DRAWINGS

1 depicts an example system that generates an Audience Measurement Entity (AME) to partner cookie mapping based on redirection from an AME to a partner database owner (DP).

2 depicts an example message flow diagram corresponding to the example system of FIG. 1 for generating an AME to partner cookie mapping based on a redirection from an AME to a partner DP.

3 depicts another example system that generates an AME to partner DP1 cookie mapping based on a redirect from AME to partner DP1 and also sends a request to a second partner DP (partner DP2) to identify a registered user of partner DP2.

4 depicts an example message flow diagram corresponding to the example system of FIG. 3 for generating an AME to partner DP1 cookie mapping based on a redirect from AME to partner DP1 and also sending a request to a second partner DP (partner DP2) to identify a registered user of partner DP2.

5A is a flow diagram representative of example machine readable instructions that may be executed to collect distributed demographic information from first and second partner database owners in conjunction with collecting online campaign ratings (OCR) data from the first partner DP.

FIG. 5B illustrates an example process of the system of FIG. 1 implementing the instructions of FIG. 5A .

6A is a flow diagram representative of example machine readable instructions for an OCR collection process that may be executed to collect distributed demographic information from first and second partner database owners without collecting OCR data from the first partner DP.

FIG. 6B illustrates an example process of the system of FIG. 1 implementing the instructions of FIG. 6A .

7A is a flow diagram representative of example machine readable instructions that may be executed to perform user-level cookie synchronization processing.

FIG. 7B illustrates an example process of the system of FIG. 1 implementing the instructions of FIG. 7A .

8A is a flow diagram representative of example machine readable instructions that may be executed to perform impression-level cookie synchronization processing.

FIG8B illustrates an example process of the system of FIG1 implementing the instructions of FIG8A.

9 is a flow diagram representative of example machine readable instructions that may be executed to implement the example browser of FIGs. 1-4, 5B, 6B, 7B, and/or 8B to implement mapping of the browser's AME cookie to a partner DP cookie.

10 is a flow diagram representative of example machine readable instructions that may be executed to implement the example AME server of FIGs. 1-4, 5B, 6B, 7B, and/or 8B to initiate mapping of AME cookies to partner DP cookies.

11 is a flow diagram representative of example machine readable instructions that may be executed to implement the example AME server of FIGs. 1-4, 5B, 6B, 7B, and/or 8B to associate demographic data obtained from partner DPs with online activity monitoring information.

12 is a flow diagram representative of example machine readable instructions that may be executed to implement the example Partner DP Server of FIGs. 1-4, 5B, 6B, 7B, and/or 8B to map AME cookies to Partner DP cookies.

13 is a flow diagram representative of example machine readable instructions that may be executed to implement the example beacon instruction generator of FIG. 1 to generate beacon instructions (eg, tags) to be served by a web server (eg, the web server of FIG. 1 ).

14 is an example processor system that may be used to execute the example instructions of FIGS. 5A through 13 to implement the example devices and systems disclosed herein.

Wherever possible, the same reference numbers will be used throughout the drawings and written description to refer to the same or like parts.

DETAILED DESCRIPTION

Over the years, the technology for monitoring user access to internet resources (e.g., web pages, content, advertisements, and/or other media) has evolved significantly. In the past, this monitoring was primarily performed using server logs. Specifically, an entity providing media (e.g., content and/or advertisements) services on the internet would record the number of requests received for its media 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 media from the server, thereby increasing server log counts. Secondly, media is sometimes 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 media. Consequently, server logs are prone to both over-counting and under-counting errors.

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 above-mentioned server-side log monitoring technology. For example, Blumenau discloses a technology in which beacon instructions are used to mark Internet media (e.g., content and/or advertisements) to be tracked. Specifically, the monitoring instructions are associated with the HTML of the media to be tracked. When a client requests the media, both the media and the beacon instructions are downloaded to the client. Therefore, each time the media is accessed (whether from the server or from the cache), the beacon instructions are executed. U.S. Patent 6,108,637 is incorporated herein by reference in its entirety.

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

However, it is important to link demographic data to monitoring information. To address this issue, audience measurement companies create 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 a cookie on the panel member's computer that enables the audience measurement entity to identify the panel member each time they access tagged media, 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 tagged media. However, the panel size of audience measurement entities is still small compared to the general user population. Therefore, there is a problem of how to increase the panel size while ensuring that the panel 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 such as Facebook and Myspace. These database owners set cookies on their subscribers' computers, allowing them to identify users when they visit their websites.

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 collect more extensive internet usage and demographic data. However, achieving this goal presents audience measurement entities with several challenges. For example, there's the issue of how to access the database owner's data without compromising the privacy of subscribers, panelists, or owners of the media being tracked. Another challenge is accessing this data given technical limitations imposed by internet protocols that prevent audience measurement entities from accessing cookies set by database owners. In the examples disclosed herein, beacon processing is expanded to include partner database owners and utilize these partners as temporary data collectors. For example, the audience measurement entity and/or beacon instructions (e.g., Java, JavaScript, or any other computer language or script) can redirect a client browser to request a partner database owner to record an impression. This allows the partner database owner to provide demographic information corresponding to the audience member corresponding to the client browser if the partner database owner knows the audience member corresponding to the client browser. In these examples, since a redirect message is generated each time the client browser presents media embedded with the beacon instructions, the number of redirect messages to the partner database owner can be significant. Example techniques for redirecting to one or more partner database owners to leverage distributed demographic data in the impression collection process are disclosed in International PCT Application No. PCT/US2011/052623, entitled “Methods and Apparatus to Determine Impressions Using Distributed Demographic Information,” filed on September 21, 2011, which is incorporated herein by reference in its entirety. Additionally, example techniques for collecting impressions and leveraging distributed demographic data stored at one or more partner database owners are disclosed in International PCT Application No. PCT/US2011/065881, entitled “Methods and Apparatus to Determine Media Impressions Using Distributed Demographic Information,” filed on December 19, 2011, which is incorporated herein by reference in its entirety.

Example methods, devices, and/or products disclosed herein utilize cookie mapping technology to collect audience exposure data, wherein an Audience Measurement Entity (AME) cookie for a particular audience member is mapped to a partner database owner cookie (partner cookie) once during the cookie's lifetime (e.g., while the cookie is valid on the client machine and/or has not been deleted or replaced). This allows AME to redirect the client browser to the particular database owner only once (during the cookie's lifetime) to ensure that the partner cookie is mapped to the AME cookie in the client browser. Once the cookie mapping is complete, AME can monitor the media exposure of one or more panelists and/or non-panelists audience members based on the AME cookie using the client browser, and receive demographic information about the audience member from the partner based on the AME to partner cookie mapping. This reduces the number of redirects required by the database owner (e.g., only once during the lifetime or lifetime of the AME and partner cookies). By reducing the number of redirects, there are fewer interruptions, less disruption, and/or less background processing that negatively impacts the performance of the client browser, thereby improving the overall user experience for the audience member. Network traffic is also reduced, thereby improving the overall efficiency of the network environment by reducing network congestion and latency. Additionally, the amount of processing required of the database owner is reduced. Additionally, the amount of data (e.g., the number of impressions) shared with the database owner is reduced.

Using the AME to partner cookie mapping, an audience measurement entity can request demographic information from partner database owners whose partner cookies are mapped to their AME cookies in the AME to partner cookie mapping. In response, the partner 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 people who accessed the tagged media. Because clients are identified against a vast database of users that far exceeds the number of people in traditional audience measurement panels, the data obtained from this process is extremely accurate, reliable, and detailed. In some examples, by agreeing to participate in a collaborative audience measurement effort, partner database owners can be provided with audience demographic and exposure information collected by other partner database owners. In this way, partner database owners can use the information provided by other partner database owners to supplement their own audience exposure metrics.

The example methods, devices, and products disclosed herein can be used to determine media impressions (e.g., content impressions and/or ad impressions) and media exposure (e.g., content exposure and/or ad exposure) using demographic information from various databases distributed across the internet (e.g., various website owners, service providers, streaming providers, etc.). The example methods, devices, and products disclosed herein not only enable a more accurate correlation of internet media exposure with demographic data, but also effectively expand the panel size and extend the panel beyond the population of participants in the audience measurement and/or ratings entity (ratings emity) to include people registered in other internet databases (e.g., databases of social media sites such as Facebook, Twitter, Google, etc., and/or any other internet site such as Yahoo!, Amazon.com, etc.). This expansion effectively leverages the media tagging capabilities of ratings entities and the use of databases from non-ratings entities (e.g., social media and/or other websites) to create a large, demographically accurate panel, thereby providing accurate and reliable measurements of exposure to internet media, such as content, advertisements, and/or programs.

Traditionally, audience measurement entities (also referred to herein as "ratings entities") determine the demographic reach of media (e.g., advertising and content programming) 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 those panelists' media exposure (e.g., advertising/content exposure) with different demographic markets. Unlike conventional techniques in which audience measurement entities rely solely on their own panelist data to collect demographic-based audience measurement data, the example methods, devices, and/or products disclosed herein enable audience measurement entities to utilize demographic information from 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 measurement. This growth also enables audience measurement entities to monitor individuals who are not members of an audience measurement panel but who have shared their demographic data with a database owner. Any entity with a database that identifies demographic data for a group of individuals can collaborate with an audience measurement entity. These entities, referred to as "database owners," include entities such as Facebook, Google, Yahoo!, MSN, Twitter, Apple iTunes, Experian, and others.

The example methods, devices, and/or products disclosed herein may be implemented by an audience measurement entity (e.g., any entity focused on measuring or tracking audience exposure to advertising, content, and/or any other media) that collaborates with any number of database owners (e.g., online web service providers) to obtain online media exposure metrics. These database owners/online web 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 site that maintains user registration records.

To increase the likelihood that measured media exposure is accurately attributed to the correct demographic data, the example methods, devices, and/or products disclosed herein use demographic information in the records of an audience measurement entity and demographic information at one or more database owners (e.g., web 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., web service providers).

Using demographic information from different data sources (e.g., high-quality demographic information from a panel of audience measurement entities and/or registered user data from a web service provider) improves the reporting effectiveness of metrics for both online and offline advertising campaigns. The example technology disclosed herein uses online registration data to identify the demographic data of users 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 web 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 database owners) maintain detailed demographic information (e.g., age, gender, geographic location, race, income level, education level, religious beliefs, etc.) collected via the user registration process. An impression corresponds to a household or individual being exposed to the corresponding media (e.g., content and/or advertisement). Therefore, an impression represents that a household or individual was exposed to an advertisement or content or a group of advertisements or content. In internet advertising, the number of impressions or impression count is the total number of times an advertisement or advertising campaign is visited by the web population (eg, visits may be reduced by, for example, pop-up blockers and/or increased by, for example, retrieval from a local cache).

The example methods, devices, and/or products disclosed herein can also report TV and online ratings in a parallel manner (e.g., using Gross Rating Points (GRPs)). For example, the counting disclosed herein enables advertisers to report the number of individuals and users reached by TV and/or online advertisements, individually and/or collectively.

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 this impression data for its panel and 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 GRP metrics for different advertising campaigns. These GRP metrics can be correlated or associated with specific demographic segments and/or markets targeted.

Example methods disclosed herein include sending a first request to an audience measurement entity and sending a second request to cause a database owner to send a cookie mapping from an audience measurement entity cookie corresponding to a client to a database owner cookie. Some example methods further include storing the database owner cookie. In some examples, sending the first request to the audience measurement entity is in response to executing a beacon instruction in a webpage. In some examples, the second request further causes the database owner to send demographic characteristics associated with the client to the audience measurement entity.

Some example methods further include sending a third request to the audience measurement entity and sending a fourth request to cause the second database owner to send a second cookie mapping of the audience measurement entity cookie to the second database owner cookie to the audience measurement entity. In some such examples, the second request causes the database owner to asynchronously send the cookie mapping to the audience measurement entity. Some example methods further include sending a third request to the audience measurement entity, the third request including the cookie mapping.

An example device disclosed herein includes a communication interface and a web browser. The web browser sends a first request to an audience measurement entity via the communication interface and sends a second request via the communication interface to cause a database owner to send a cookie mapping of an audience measurement entity cookie corresponding to a client to the database owner cookie to the audience measurement entity. In some examples, the web browser sends the audience measurement entity cookie in the first request. In some example devices, the web browser sends the first request to the audience measurement entity in response to executing a beacon instruction in a webpage.

In some example devices, the second request further causes the database owner to send demographic characteristics associated with the client to the audience measurement entity. In some examples, the web browser sends a third request to the audience measurement entity and sends a fourth request to the second database owner to cause the second database owner to send a second cookie mapping from the audience measurement entity cookie to the second database owner cookie to the audience measurement entity. In some examples, the second request causes the database owner to asynchronously send the cookie mapping to the audience measurement entity. In some examples, the web browser sends a third request to the audience measurement entity, the third request including the cookie mapping.

Example methods disclosed herein include sending a response to a request, the response including an identification of a first cookie used by an audience measurement entity and an indication of a partner database owner; and receiving, from the partner database owner, a mapping of the first cookie to a second cookie used by the partner database owner and demographic information associated with the second cookie. In some example methods, the mapping and demographic information are received from the partner database owner via asynchronous communication. In some examples, the response includes a redirect message that causes the client device to send the request to the partner database owner.

In some example methods, the mapping is received at a first time, and the demographic information is received at a second time after the first time. Some example methods further include selecting a database owner from a list of database owners based on the website initiating the beacon request. In some examples, selecting the database owner includes determining a quality of demographic information provided by the database owner for an expected demographic group associated with the website. Some example methods further include determining whether the beacon request includes a first cookie, and generating the first cookie when the beacon request does not include the first cookie.

An example device disclosed herein includes: a redirector that sends a response to a request, the response including an identification of a first cookie used by an audience measurement entity and an indication of a partner database owner; and a communication interface that receives, from the partner database owner, a mapping of the first cookie to a second cookie used by the partner database owner and demographic information associated with the second cookie. In some example devices, the communication interface receives the mapping and demographic information from the partner database owner in an asynchronous communication manner.

In some examples, the response includes a redirect message that causes the client device to send the request to the partner database owner. In some examples, the communication interface receives the mapping at a first time and receives the demographic information at a second time after the first time. Some example devices also include a partner selector that selects a database owner from a list of database owners based on the website that initiated the request. In some examples, the partner selector selecting the database owner includes determining the quality of the demographic information provided by the database owner for an expected demographic group associated with the website. Some example devices also include a cookie generator, the redirector determining whether the request includes a first cookie, and when the request does not include the first cookie, the cookie generator generating the first cookie.

Example methods disclosed herein include receiving a first request from a client device, the first request including an audience measurement entity cookie identifier; and determining a cookie mapping of an audience measurement entity cookie associated with the client to a database owner cookie. Some example methods further include sending a redirect message to cause the client to send the cookie mapping to the audience measurement entity. In some such examples, the redirect message includes the database owner cookie identifier, the audience measurement entity cookie identifier, and an indication of an association between the database owner cookie identifier and the audience measurement entity cookie identifier.

Some example methods further include sending a message to the audience measurement entity, the message including the cookie mapping. In some such examples, the message further includes a second cookie mapping between a second audience measurement entity cookie identifier of the second client device and a second database owner cookie associated with the second client device.

Example methods disclosed herein include receiving a first request from a client device, the first request including an audience measurement entity cookie identifier; and providing a cookie mapping to the audience measurement entity associated with the cookie, the cookie mapping including an association between a database owner cookie associated with the client and the audience measurement cookie. In some examples, providing the cookie mapping includes sending a redirect message to cause the client to send the cookie mapping to the audience measurement entity. In some such examples, the redirect message includes a database owner cookie identifier, an audience measurement entity cookie identifier, and an indication of an association between the database owner cookie identifier and the audience measurement entity cookie identifier.

In some example methods, providing the cookie mapping includes sending a message to the audience measurement entity, the message including the cookie mapping. In some such examples, the message also includes a second cookie mapping between a second audience measurement entity cookie identifier for the second client device and a second database owner cookie associated with the second client device.

An example apparatus disclosed herein includes a communication interface that receives a first request from a client device, the first request including an audience measurement entity cookie identifier, and a cookie mapper that determines a cookie mapping of an audience measurement entity cookie associated with the client to a database owner cookie. In some example apparatuses, the communication interface provides the cookie mapping to the audience measurement entity associated with the cookie, the cookie mapping including an association between the database owner cookie associated with the client and the audience measurement cookie.

In some examples, the communication interface provides the cookie mapping by sending a redirect message to cause the client to send the cookie mapping to the audience measurement entity. In some such examples, the redirect message includes a database owner cookie identifier, an audience measurement entity cookie identifier, and an indication of an association between the database owner cookie identifier and the audience measurement entity cookie identifier. In some example devices, the communication interface provides the cookie mapping by sending a message to the audience measurement entity, the message including the cookie mapping. In some such examples, the message also includes a second cookie mapping between a second audience measurement entity cookie identifier of a second client device and a second database owner cookie associated with the second client device.

An example apparatus disclosed herein includes a communication interface that receives a first request from a client device, the first request including an audience measurement entity cookie identifier, and provides a message to the audience measurement entity associated with the cookie, the message including a cookie map including an association between a database owner cookie associated with the client and the audience measurement cookie; and a processor that executes instructions that cause the processor to generate the message.

Example methods disclosed herein include providing instructions to be included in a website, which, when executed, cause a client to initiate a process comprising: sending a first request to an audience measurement entity; and sending a second request to cause a database owner to send a cookie mapping of an audience measurement entity cookie corresponding to the client to a database owner cookie to the audience measurement entity. Some example methods also include receiving information associated with the website and generating instructions based on the information. In some examples, the process also includes receiving a redirect message from the audience measurement entity, the redirect message including an identifier for the audience measurement cookie.

An example device disclosed herein includes a communication interface and a processor that generates instructions to be included in a website and causes the communication interface to provide the instructions to a web server associated with the website. When executed, the instructions cause a client to initiate processing that includes: sending a first request to an audience measurement entity; and sending a second request for a database owner to send a cookie mapping of an audience measurement entity cookie corresponding to the client to a database owner cookie to the audience measurement entity. In some examples, the communication interface receives information associated with the website, and the processor generates the instructions based on the information. In some example devices, the processing also includes receiving a redirect message from the audience measurement entity, the redirect message including an identifier for the audience measurement cookie.

1 depicts an example system 100 for generating an Audience Measurement Entity (AME) to partner cookie mapping based on a redirection from an Audience Measurement Entity (AME) 102 to a partner database owner (DP) 104. FIG2 depicts an example message flow diagram 200 for generating an AME to partner cookie mapping based on a redirection from an AME 102 to a partner DP 104, corresponding to the example system 100 of FIG1 .

In the example of Figure 1, web server 106 provides access to one or more websites. Example system 100 determines AME to partner cookie mapping for a web browser (e.g., example web browser 110) requesting access to a website served by web server 106. Although example web browser 110 is shown for illustration purposes, the example system 100 of Figure 1 can copy and/or repeat the process shown in Figure 1 for web browser 110 and/or other web browsers. The example web browser 110 of Figure 1 is a specific instance of a web browser computer application executed on a specific computing device (e.g., a personal computer, mobile device, such as processing platform 1400 of Figure 14). However, the example implementation of the example system 100 of Figure 1 will typically involve many such browsers.

The example web page available from the example web server 106 of FIG1 is tagged with beacon instructions. In some examples, AME 102 provides the web server 106 with tags or beacon instructions to be included in a website or element of a website (e.g., media, advertisements, and/or other elements of a website) served by the web server 106. The provided beacon instructions may allow and/or require the web server to modify the instructions based on the specific page being tagged and/or based on any arguments and/or other variables present on the web page.

When the example browser 110 requests a web page from the web server 106 (e.g., arrow (1) of FIG. 1 ), the example web server 106 returns the page content with beacon instructions (e.g., arrow (2) of FIG. 1 ). The example beacon instructions of FIG. 1 are provided by AME 102 and/or modified from instructions provided by AME 102 to the web server 106, and include a URL 112 that points to an AME server 114 and specifies (among other things) the media presentation and/or exposure that results from providing the requested page from the web server 106; and an indication (e.g., bold text in URL 112) of the web server or publisher (e.g., web server 106) that provided the beacon instructions (e.g., arrow (3) of FIG. 1 ). In some examples, the web server 106 is controlled by the partner DP 104 or another database owner. In some such examples, the web server 106 includes an identifier or other representation of the partner DP 104 in the URL 112. If the browser 110 previously stored a cookie (eg, an AME cookie) corresponding to the AME 102 (and the cookie has not expired), the example browser 110 provides the AME cookie with the beacon request.

The example AME server 114 includes a beacon request redirector 120, a cookie generator 122, a partner selector 124, a beacon instruction generator 126, and a communication interface 128. When the AME server 114 receives a beacon request from the browser 110, the example beacon request redirector 120 determines whether the beacon request includes an AME cookie. If the beacon request does not include an AME cookie, the example cookie generator 122 creates an AME cookie for the browser 110. If the beacon request includes an AME cookie, the example beacon request redirector 120 determines whether the AME cookie is associated with (e.g., mapped to) a DP cookie value for a DP (e.g., partner DP 104). If the DP cookie exists, the example AME server 114 stores the beacon in association with the browser 110. The AME server 114 may or may not respond to the beacon request. In the example shown, the AME server 114 responds to beacon requests that are not intended to affect the displayed content of the tagged web page or advertisement (e.g., using a transparent 1x1 pixel image or other requested media (e.g., a placeholder)). In some examples, the beacon request does not elicit a response.

If the example AME server 114 of the illustrated example creates an AME cookie for the browser 110, or if there is no DP cookie value associated with (e.g., mapped to) the browser 110 with an existing AME cookie (e.g., the tagged web page or tagged advertisement does not come from a DP server), the example beacon request redirector 120 adds the AME cookie to the URL parameters 116 of the response to the beacon request. The example beacon request redirector 120 sends a redirect response (e.g., an HTTP "302 Found" redirect message) to the browser 110 in response to the beacon request (e.g., arrow (4) of FIG. 1 ). The example URL parameters 116 of FIG. 1 include the address of the partner DP server 108 (e.g., the bold and underlined text in the URL 116 of FIG. 1 ) and the identifier or value of the AME cookie to be mapped to the cookie of the partner DP 104 (e.g., the bold but not underlined text). The example URL parameters 116 also include the address of the partner DP server 108. The example partner selector 124 selects a partner DP server to which the redirect message is to be directed. For example, the partner selector 124 may select one or more of a plurality of partner DPs (e.g., from a list of collaborating partner DPs) based on, for example, expected demographics of the media (e.g., tagged media) served by the web server 106. In some other examples, the partner selector 124 selects a default partner DP and one or more backup partner DPs.

The example beacon instruction generator 126 of FIG1 receives information associated with the example web server 106 and/or the websites to be served by the web server 106. The information may include the address and/or URL range of the web server 106 and/or the media. Based on the information, the example beacon instruction generator 126 generates beacon instructions to be used by the example web server 106 to mark the media served by the web server 106. In some other examples, the beacon instruction generator 126 provides general instructions to the web server 106, which can be modified by the web server 106 based on the media served.

The example communication interface 128 communicatively connects the example AME server 114 to the example browser 110 (e.g., via a network such as the Internet). The example communication interface 128 includes a combination of hardware and software and/or firmware to send and receive communications (e.g., beacon requests and redirect responses). In some examples, the communication interface 128 includes a load balancing feature for dividing large amounts of communications between multiple AME servers 114.

The example browser 110 receives the redirect response to the beacon request and makes a request to the partner DP server 108 based on (e.g., utilizing) the URL 116 (e.g., arrow (5) of FIG. 1 ). If the browser 110 has a cookie for the domain of the partner DP 104, the example browser 110 provides the cookie upon request. The example partner DP server 108 of FIG. 1 includes a cookie mapper 130 and a communication interface 132. The partner DP server 108 determines whether the browser 110 provides the cookie. If the browser 110 provides the cookie upon request, the example partner DP server 108 (e.g., via the cookie mapper 130) identifies the cookie and maps the partner DP cookie to the AME cookie identified in the URL 116 (e.g., stores an association between the partner DP cookie and the AME cookie). The example partner DP server 108 sends a message to the example AME server 114 indicating the mapping between the browser 110's AME cookie and the partner DP cookie (e.g., arrow (6) of FIG. 1 ). The example message includes a URL 118 (eg, in bold text) providing the mapping.

The example cookie mapper 130 may additionally or alternatively be implemented in the AME server 114. As described below, in some examples, the AME server performs mapping between AME cookies and Partner DP cookies based on an AME cookie associated with the browser 110, a Partner DP user identifier, and/or a Partner DP cookie.

The example communication interface 312 communicatively connects the example partner DP server 108 to the example browser 110 (e.g., via a network such as the Internet). The example communication interface 132 includes a combination of hardware and software and/or firmware to send and receive communications (e.g., beacon redirection, cookie mapping, and demographic information). In some examples, the communication interface 132 includes a load balancing feature for dividing a large amount of communications between multiple partner DP servers 108.

In the example of FIG1 , the mapping URL 118 also includes demographic information associated with the browser known to the Partner DP 104 (e.g., demographic information of the browser's user). For example, the user of the browser 110 may have provided demographic information to the Partner DP 104 in exchange for using services provided by the Partner DP 104. In some examples, the mapping URL 118 also includes a timestamp of the mapping and/or a timestamp of another event that led to the mapping to facilitate mapping the AME cookie and/or Partner DP cookie with the impression data. In some other examples, the AME server 114 stores timestamps derived from HTTP messages sent and received during the mapping process. In some examples, the AME cookie is unique, such that a timestamp is not required to match the AME cookie and/or Partner DP cookie with the impression data.

The example AME server 114 of FIG1 stores a mapping between AME cookies and partner DP cookies. The example AME server 114 of FIG1 also stores demographic information of the browser 110 received from the partner DP (if any). For subsequent beacon requests for the same AME cookie received from the browser 110, the example AME server 114 stores the beacon request (and associated page view and/or impression information) and does not redirect the browser 110, thereby reducing traffic to the DP and also reducing the data provided to the DP (e.g., impression counts).

3 depicts another example system 300 that generates an AME to first partner DP cookie mapping based on a redirect from AME to partner DP1, and also sends a request to a second partner DP (partner DP2) to identify a registered user of partner DP2. FIG4 depicts an example message flow diagram corresponding to the example system of FIG3 that generates an AME to partner DP1 cookie mapping based on a redirect from AME to partner DP1, and also sends a request to a second partner DP (partner DP2) to identify a registered user of partner DP2. The example system 300 of FIG3 includes the AME 102, the first partner DP 104, the web server 106, the first partner DP server 108, the example browser 110, and the AME server 114 of FIG1. The example system 300 of FIG3 also includes a second partner DP 302, which includes one or more second partner DP servers 304.

In a manner similar to arrows (1) and (2) of FIG. 1 , the example browser 110 requests a web page from the first web server 106 and receives media (e.g., a web page, an advertisement) with a beacon instruction. The request to the web server 106 may be for any media that is tagged (e.g., a web page, a portion of a web page (e.g., an advertisement)). The web page itself may be tagged and/or the advertisement or other portion within the page may be tagged. The example beacon instruction includes a URL 306 (e.g., in bold) that specifies the web server, publisher, and/or website owner that initiated the beacon instruction. In a manner similar to arrow (3) of FIG. 1 , the example browser 110 makes a beacon request to the example AME server 114 upon receiving the beacon instruction. If the browser 110 previously stored a cookie corresponding to AME 102 (and the cookie has not expired), the example browser 110 provides the AME cookie in response to the beacon request. In the examples of FIG. 1 and FIG. 3 , the AME server 114 does not need to determine whether the AME cookie is expired because the browser 110 does not send (eg, delete) an expired AME cookie (or any expired cookie).

When the example AME server 114 receives a beacon request from the browser 110, the example AME server 114 determines whether the beacon request includes an AME cookie. If the beacon request does not include an AME cookie, the example AME server 114 creates an AME cookie for the browser 110. The AME cookie may expire after a time period, which may be set in the AME cookie, set by the browser 110, and/or may be a general upper limit on the cookie's lifespan. When the AME cookie expires, the example browser 110 discards the AME cookie (e.g., deletes it from storage). The next beacon request from the browser 110 does not include the AME cookie, so the AME server 114 treats the browser 110 as unknown and provisions a new AME cookie. If the beacon request includes an AME cookie, the example AME server 114 determines whether the AME cookie is associated with (e.g., mapped to) the DP cookie value of the DP specified in the URL 112 (e.g., partner DP 104). If the DP cookie exists, the example AME server 114 stores the beacon in association with the browser 110.

If the AME server 114 creates an AME cookie for the browser 110, or if there is no DP cookie value for the browser 110 associated with (e.g., mapped to) an existing AME cookie, the example AME server 114 adds the AME cookie to the URL parameter 308 of the redirect response to the beacon request. The example AME server 114 then sends a redirect response (e.g., an HTTP "302 Found" redirect message) to the browser 110 in response to the beacon request (e.g., in a manner similar to arrow (4) of FIG. 1 ). The example URL parameter 308 of FIG. 3 includes the address of the first partner DP server 108 (e.g., bolded but not underlined text) and the identifier or value of the AME cookie to be mapped to the cookie of the first partner DP 104 (e.g., bolded and underlined text). If the browser 110 previously stored a cookie corresponding to the domain of the first partner DP 104, the example browser 110 includes the first partner DP cookie in the request to the first partner DP server 108.

The example first partner DP server 108 determines whether the request includes the first partner DP cookie. If the request includes the first partner DP cookie, the example first partner DP server 108 sends a message including URL 310 to the AME server 114. URL 310 includes a mapping of the first partner DP cookie to the AME cookie (e.g., bold text). In some examples, the first partner DP server 108 stores the first partner DP cookie for later mapping and transmission to the AME server 114 (e.g., batch transmission). At periodic or aperiodic intervals, the first partner DP server 108 sends multiple messages including URLs (e.g., URL 310) indicating the corresponding mappings of the first partner DP cookie to the AME cookie.

In addition to or as an alternative to mapping the AME cookie to the partner DP cookie of the first partner DP 104 (e.g., the partner DP from which the browser requested the webpage), the example system 300 maps the AME cookie of the browser 110 to the partner DP cookie of the second partner DP 302. The example second partner DP 302 may have information about the user of the browser 110 in addition to or as an alternative to the first partner DP 104. In some examples, the first partner DP 104 may have no information associated with the browser 110, while the second partner DP 302 has available demographic information or other information for the AME 102.

In some examples, the system 300 maps the AME cookie to the second partner DP cookie to enable the second partner DP 302 to record impressions of media (e.g., advertising) campaigns. The example second partner DP 302 provides the impression information tracked via the second partner DP cookie to the example AME 102 along with the mapping of the second partner DP cookie to the example AME cookie of the browser 110. In some examples, the second partner DP 302 also provides demographic information associated with the impression.

To map the browser 110's AME cookie to the second partner DP cookie, the example AME server 114 sends a redirect response to the beacon request, including URL 312, to the second partner DP 302 (e.g., to the second partner DP server 304). For example, the tagged media may include multiple beacons to enable the AME 102 to redirect the browser 110 to multiple partner DPs. Additionally or alternatively, the tagged media may issue only one beacon request, and the AME server 114 may respond with multiple redirect messages. Additionally or alternatively, each DP (e.g., the first partner DP 104, the second partner DP 304, etc.) may respond to the request resulting from the redirect by returning a redirect to another DP. In the example where the AME server 114 sends multiple redirects, the example URL 312 of FIG. 3 is similar to URL 308, except that URL 310 specifies the address of the second partner DP server 304, rather than the address of the first partner DP server 108.

The example URL 310 of the example shown includes an AME cookie value. The example browser 110 receives the redirect response and sends a request to the example second partner DP server 304. If the browser 110 has a cookie for the second partner DP server 304, the browser 110 includes the cookie in the request. The example second partner DP server 304 determines whether the request from the browser 110 includes a cookie. If the request includes a cookie, the example second partner DP server 304 reads a value from the cookie that identifies the browser 110 or a user associated with the browser (e.g., uniquely identifies the user).

Unlike the example first partner DP 104, the example second partner DP 302 of the example shown in FIG3 provides the AME cookie to second partner DP cookie mapping at intervals, rather than immediately when the mapping is generated. For example, the second partner DP 302 stores the mapping between the second partner DP cookie and the mapped AME cookie for later transmission to the AME server 114 (e.g., batch transmission). At periodic or aperiodic intervals, the second partner DP server 304 sends one or more messages including the corresponding mappings of the second partner DP cookie to the AME cookie. The example second partner DP server 304 may send a set of multiple mappings in one or more data files (e.g., arrays or other data structures) via a message. Additionally or alternatively, the second partner DP server 304 may send multiple messages (e.g., dummy HTTP requests), each of which includes a mapping (e.g., a URL containing mapping information). If the example second partner DP server 304 recognizes the user (eg, via a user identifier in a cookie), the example second partner DP server 304 sends a mapping message or other confirmation message to the example AME server 114 (eg, a 200 OK HTTP response message).

The examples of Figures 1-4, 5B, 6B, 7B, and/or 8B are illustrated in conjunction with operations that may be performed by machine-readable instructions executed by one or more servers or computers in the example systems 100, 300 of Figures 1 and 3.

In the examples of Figures 5A, 6A, 7A, and 8A, operations described as being performed by the AME may be implemented by, for example, the AME server 114 of Figures 1 to 4, 5B, 6B, 7B, and/or 8B, and operations described as being performed by the partner DP may be performed by, for example, the partner DP servers 108, 304 of Figures 1 to 4, 5B, 6B, 7B, and/or 8B. In the example of Figure 5A, the first database owner (DP1) agrees to provide cookie-level data, while the second database owner (DP2) refuses to provide cookie-level data but agrees to provide summary data representing the aggregation of its cookie-level data by bucket or category (e.g., male, age 30-40).

Figure 5A is a flow diagram representative of example machine-readable instructions 500 that may be executed to collect distributed demographic information from first and second partner database owners. Figure 5B illustrates an example process of the system 100 of Figure 1 implementing the instructions 500 of Figure 5A.

At block 510, when a browser accesses media (e.g., arrow (1) of FIG. 5B ), beacon instructions included in and/or associated with the media (e.g., arrow (2) of FIG. 5B ) cause the browser to register an impression by sending a beacon request to AME (e.g., arrow (3) of FIG. 5B ). At the operation in processing block 512 , AME collects data about the browser's online activity. For example, AME receives a beacon request from the browser (block 512 a ), collects and/or stores impression data included in or associated with the beacon request (block 512 b ). The data associated with the beacon request may include an AME cookie associated with the browser and/or may identify the media that triggered the beacon request. AME processes the collected impression data based on the corresponding AME cookie received from the browser to, for example, correlate web page views with media exposure (block 512 c ).

In block 514, AME determines which partner DP(s) the browser will be redirected to. The example AME may select partner DP1, partner DP2, and/or one or more additional partner DPs. For example, when the quality of the demographic information of the expected or estimated demographic composition of partner DP1 is higher than that of other partner DPs, AME may select partner DP1 based on the expected or estimated demographic composition of the tagged website. In some other examples, AME may select multiple (e.g., all available) partner DPs (e.g., DP1 and DP2). Based on the result of block 514, the example AME sends a redirect response to the client browser (e.g., arrow (4) of FIG. 5B ) to cause the client browser to send a redirect request to partner DP1 (e.g., arrow (5) of FIG. 5B , initiating blocks 502 a to 502 c) and/or to partner DP2 (e.g., initiating blocks 516 a to 516 d).

In the illustrated example, the operations in processing block 502 are performed by partner DP1 (rather than AME) to collect impression data based on a beacon request received from a web browser on a client computer. For example, after accessing tagged media, the client browser sends a beacon request to AME and is redirected by AME to one or both of partner DP1 and/or partner DP2 (block 514). For the purposes of discussion, assume that partner DP1 receives a message from the client browser based on the redirect (e.g., block 502a). Partner DP1 then accesses tag information (e.g., media information, publisher information, timestamp, etc.) from the message received from the client, thereby collecting and/or storing impression data from the browser (e.g., block 502b). Partner DP1 processes the tag information to associate it with a partner DP1 cookie identifier and/or an AME cookie identifier for users who access the tagged media (block 502c). Thus, the example operations of block 502 enable partner DP1 to collect impression information from panelists and/or non-panelist users who access the tagged media. In addition to or instead of AME collecting the impression information, the impression information may be collected by the partner DP1.

In box 504, partner DP1 compresses the raw impression data collected by partner DP1 (e.g., media information, cookie identifier, timestamp, etc.) to be sent to AME (e.g., arrow (6) of Figure 5B). The impression data provided by partner DP1 to AME includes a mapping between an AME cookie identifier (e.g., an identifier received via tag information) and a partner DP1 cookie identifier (e.g., an identifier of a user known to partner DP1 and stored, for example, by a client device). Figure 5B shows an example table 524, which includes a timestamp, impression information (e.g., media identifier), and an association between the partner DP1 user identifier and the AME cookie identifier. The example partner DP1 sends table 524 to the example AME server in a message corresponding to arrow (6) of Figure 5B. For privacy, the partner DP1 cookie identifier can be anonymous in the impression data provided to AME. The example mapping information enables AME to correlate impression data between multiple partner DPs (e.g., DP1, DP2, etc.). The example blocks 502 and/or 504 of FIG. 5A are repeated and/or continuously executed to repeatedly collect impression data and transmit the data to the AME.

At the operation in processing block 506, partner DP1 generates a cookie-level user demographic data file (block 506a). For example, partner DP1 may generate a file that includes a partner DP cookie identifier to be mapped to an AME cookie and also includes demographic information of the users respectively identified by the partner DP cookies. For example, partner DP1 includes the DP cookie identifier of the user from which the DP cookie was received in association with the tag redirect message (e.g., during a previous reporting period) and demographic information associated with the user. The cookie-level demographic data file is compressed and transmitted to AME (e.g., periodically, aperiodically, in response to a request, at a specified time, etc.) (e.g., block 506b, arrow (7) of FIG. 5B ). An example table 526 is shown in FIG. 5B , which includes demographic information associated with the partner DP1 cookie identifier. The demographic data may be limited to the user for whom the cookie mapping is generated, or may cover a larger set of cookies of the database owner.

At operation 508, AME combines and/or aggregates the impression data and demographic data from partner DP1 (block 508a). For example, AME may associate the demographic information corresponding to each partner DP cookie with the impression data corresponding to each partner DP cookie (e.g., the impression data received from partner DP1 in block 504, the impression data received from other partner DPs, and/or other impression data collected by AME). The example AME summarizes the findings of partner DP1 (e.g., grouping the data by demographic groups and/or segments) (block 508b). The partner DP demographic and impression information and/or its summary may then be input into a calibration engine to facilitate adjustments (e.g., calibration) and/or generation of media impression reports (e.g., online campaign ratings) based on known data (e.g., AME panelist data 520).

At the operation in processing block 516, upon receiving a request resulting from the redirect response from the AME (block 516a), the second partner DP2 (e.g., server 304 of FIG. 3 ) collects and/or stores browser activity information corresponding to a cookie known to the second partner DP2 (e.g., second partner DP 302) (block 516b). Example partner DP2 collects tag information (e.g., impression data) in a manner similar to that of partner DP1, as described above with reference to the operation in block 502. Example partner DP2 processes the impression data based on the partner DP2 cookie (block 516c). Partner DP2 may perform the processing in block 516c in a manner similar to that performed by the AME in block 512c. However, instead of compressing the data, the example second partner DP server 304 periodically aggregates the tag information and sends the tag information to the OCR calibration engine 518 (block 516d). For example, aggregation of data may include grouping impression information and/or demographic information by larger demographic groups rather than providing impression and/or demographic information for individual users and/or individual cookies. The example OCR calibration engine 518 also receives AME panel factors 520 (e.g., weights applied to impression information based on characteristics of a representative AME panel). The example OCR calibration engine 518 generates an OCR report 522 based on AME cookie to partner DP cookie mappings, partner DP demographic data, partner DP activity measurements (e.g., impression data collection), and/or AME activity measurements (e.g., AME panelist and/or non-panelist impression collection). The example instructions 500 may include any number of partner DPs that perform blocks 502 and/or 504 and/or may include any number of partner DPs that perform block 516.

FIG6A is a flow diagram representing example machine-readable instructions 600 that may be executed to collect distributed demographic information from first and second partner database owners without collecting impression data at the first partner DP. FIG6B illustrates an example process of the system 100 of FIG1 implementing the instructions 600 of FIG6A. The example instructions 600 include blocks 506 through 522 of FIG5A (e.g., arrows (1) through (4) of FIG6B). Unlike the instructions 500 of FIG5A, the example instructions 600 cause the AME to collect impression information while relieving partner DP1 of the task of collecting impression information.

The example instructions 600 of FIG6A include instructions, represented by reference numeral 602, that cause AME to redirect the browser to a subdomain of the partner DP1 domain (e.g., a server of AME of FIG1 , such as AME server 604, running under a subdomain of the partner DP1 domain, rather than a server operated by DP1). An example manner of using a subdomain of the partner DP1 domain is described in U.S. patent application Ser. No. 13/239,005, filed Sep. 21, 2011, which is incorporated by reference in its entirety. The example AME server 604 receives a tab redirect (block 602a) from the browser at the partner DP1 subdomain address (arrow (5) of FIG6B). Because it runs under the partner DP1 subdomain, the example AME can receive the partner DP1 cookie directly from the browser. The partner DP1 cookie is merged or mapped to the AME cookie (block 602b) by AME (e.g., by retrieving the AME cookie from the payload in the redirect request). 6A , partner DP1 is relieved of the responsibility of collecting and reporting impression or exposure data. The data collected by AME via the AME server in the DP1 subdomain may be used by the same or a different AME server in block 508 to merge the impression data with the demographic data sent at block 506. The example AME server 604 stores the mapping information and/or sends the mapping information to another AME server 114 (e.g., arrow (6) in FIG6B ).

FIG7A is a flow diagram representing example machine-readable instructions 700 that may be executed to perform user-level cookie synchronization processing. FIG7B illustrates example processing of the system 100 of FIG1 implementing the instructions 700 of FIG7A. User-level cookie synchronization refers to synchronizing the AME cookie associated with a user/device with the partner DP cookie associated with the same user/device. Example instructions 700 include blocks 510, 512, and 516 through 522 of FIG5A.

During the collection process 702, media from the partner DP1 site is tagged to allow a user cookie ID to be mapped to an AME cookie (box 702a). For example, when a registered user of the partner DP1 site visits the partner DP1 site (e.g., by visiting a tagged login page) (arrow (1) in FIG. 7B), the tag associated with the partner DP1 site (arrow (2) in FIG. 7B) causes the browser to send a beacon request to AME, which includes the AME cookie (if available) and a user identifier (e.g., an alphanumeric code or value) of the user that is also known to partner DP1 (box 702b). For example, the user identifier may be carried in the payload of the beacon request. To maintain the privacy of the user, the example user identifier may be arbitrarily defined by the example partner DP1 and/or may change for each mapping of an AME cookie to a partner DP1 cookie for the same user. Furthermore, the user identifier is mapped to the DP1 cookie, but is not itself a DP1 cookie. The example AME stores the association between the user identifier and the received AME cookie. If the received AME cookie does not exist, the example AME stores a new AME cookie at the browser and records the association between the new AME cookie and the user identifier. In some examples where partner DP1 provides a consistent user identifier for a user, AME associates multiple AME cookies with impression data corresponding to the multiple AME cookies based on AME cookies mapped to the same partner DP1 cookie.

Independent of the mapping process 702, the example browser 110 accesses media (e.g., from a media server) at block 510 (arrow (4) of FIG. 7B ). As described above, the example AME collects and stores impression information received from the browser via beacon requests (e.g., block 512, arrows (5) and (6) of FIG. 7B ).

During demographic data processing 704, partner DP1 generates a daily/weekly partner DP1 demographic data table (e.g., table 708 of FIG. 7B ) containing a user ID (e.g., the user ID sent to AME via a beacon request) and key demographic segments (block 704a). Example partner DP1 compresses and/or transmits the demographic data file to AME (e.g., block 704b, arrow (7) of FIG. 7B ). Since partner DP1 knows the association between its users and the user IDs provided to AME, example partner DP1 can match the user IDs with the demographic information of the corresponding users. In the example shown, partner DP1 anonymizes the data to comply with privacy requirements. A mapping file between the AME cookie and the partner DP1 cookie can be created using a mapping between the user (e.g., partner DP1) ID and the AME cookie (e.g., determined by AME from the data provided via block 702) and the partner DP1 demographic data table (e.g., the demographic data file provided by partner DP1). The cookie mapping and/or mapping between user IDs and AME cookies is then used to correlate audience demographics with online media impressions and/or to perform, for example, online campaign and/or impression calculations and reporting. In the example shown, AME applies profile corrections to correct or adjust any demographic data deemed inaccurate.

During the reporting process 706, the partner DP1 demographic data table (e.g., received from processing block 704) is matched (block 706a) with the AME collection table (e.g., the impression information table collected by AME in processing block 512) for aggregation and reporting (block 706b). For example, AME uses the partner DP1 cookie to AME cookie mapping (e.g., received and/or determined from processing block 702 of FIG. 7A and/or arrow (3) of FIG. 7B) to match the demographic data corresponding to the partner DP1 cookie (e.g., received from processing block 704 of FIG. 7A and/or arrow (7) of FIG. 7B) with the activity monitoring data. In this way, the demographic data is linked to the impression data based on the AME cookie ID and/or the user identifier provided by DP1 to associate the demographic data with the activity data. The demographic data and activity data can then be input into the calibration engine to generate reports reflecting the exposure to various demographic groups.

The example instructions 700 of FIG7A do not cause the browser to redirect to the DP1 server. Instead, a cookie mapping between the partner DP1 cookie (and/or the partner DP1 user identifier) and the AME cookie enables the impression data collected by AME to be mapped to the demographic information provided by partner DP1. As a result, the number of redirects is reduced relative to the systems of FIG5A-5B, FIG6A-6B, and FIG8A-8B, thereby reducing network traffic. Additionally, the reduced browser redirects result in an improved user experience, as users experience less delay associated with redirect messages.

FIG8A is a flow diagram representing example machine-readable instructions 800 that may be executed to perform impression-level cookie synchronization processing. FIG8B illustrates example processing of the system 100 of FIG1 implementing the instructions 800 of FIG8A. Impression-level cookie synchronization refers to synchronizing the AME cookie associated with an impression with the partner DP cookie also associated with the same impression. The example instructions 600 include blocks 510 through 522 of FIG5A that implement at least arrows (1) through (4) of FIG8B.

During the collection process 802, partner DP1 receives a redirect from the client browser (e.g., box 802a of Figure 8A, arrow (5) of Figure 8B). The redirect includes the AME cookie as a parameter to be sent to partner DP1 (e.g., in the payload of the request). Partner DP1 receives the redirected request from the client browser and automatically returns a response that contains a mapping between the AME cookie ID (provided by AME via the redirect) and the partner DP1 cookie ID (received from the client browser (when present)) (box 802b, arrow (6) of Figure 8B). In some examples, the response is sent to the client browser, which forwards the data to AME. In other examples, the response is sent directly (e.g., omitting the browser) from partner DP1 to AME (e.g., via asynchronous communication) to avoid additional messages involving the client browser that can degrade the user experience. The example cookie mapping during collection process 802 results in rapid collection of demographic information (e.g., near real-time collection), enabling advertisers to more quickly identify inconsistencies between advertising objectives and advertising results and/or more quickly adjust the delivery and/or serving of advertisements to reach the desired demographic composition.

For example, if an advertiser aims to deliver 10,000 impressions per day to males aged 30-40 by placing ads on websites A and B, but in reality, data collected through the process of FIG8A shows that website A generates 6,000 impressions for males aged 30-40, with the majority of impressions generated by website A being female, the advertiser can increase ad delivery on website B and decrease ad delivery on website A during the time period associated with the demographic target (e.g., a seven-day period to meet the daily target, an hourly period to meet the hourly target, etc.) to achieve its demographic impression target. This switching of ad delivery can potentially be done in real time to achieve the desired advertising target in the current advertising campaign. In the past, demographic results were not available until the advertising campaign was completed, thus resulting in missed targets.

Partner DP1 provides a user table (e.g., table 810 of FIG. 8B ) or other data structure containing partner DP1 cookie identifiers and associated demographic facets to AME (block 804 a, arrows ( 6 ) and/or arrows ( 7 ) of FIG. 8B ) periodically (e.g., hourly, daily, weekly, biweekly, monthly, etc.) or aperiodically (e.g., using mapping information). The cookie identifier provided in the user table corresponds to the cookie identifier mapped to the AME identifier in processing block 802. In the example shown, the data is anonymized (e.g., personal identifying information is removed) to comply with privacy requirements. In the example shown, AME applies profile corrections to correct or adjust any demographic data that is deemed inaccurate.

During reporting processing 806, the example AME uses the mapping received from block 802 to match the partner DP1 demographic data table (e.g., demographic data from block 804) with the AME collection table (e.g., online activity data from block 512) (block 806a) to facilitate aggregation and reporting (block 806b). For example, aggregation of data may include grouping impression information and/or demographic information by larger demographic groups, rather than providing impression and/or demographic information for each user and/or each cookie. In this way, demographic data is linked to impression data based on the partner DP1 cookie ID.

In the operations within processing block 808, the example AME provides the OCR report 522 of FIG. 8A to the media publisher and/or web server (e.g., arrow (8) to web server 106 of FIG. 8B ). In the example of FIG. 8A , the publisher compares the OCR report to the demographic goals (block 808 a). Based on the comparison, the example publisher adjusts the delivery of the media (e.g., shifts the delivery of the media between websites) to achieve the desired goals. Thus, block 808 provides a feedback mechanism to enable advertisers to identify inconsistencies between advertising goals and advertising results and/or to more quickly adjust the delivery and/or serving of advertisements to reach the desired demographic composition.

Although example instructions 500 to 800 are disclosed above with reference to Figures 5A to 8B, any instructions 500 to 800 and/or blocks of Figures 5A to 8B may be combined, divided, rearranged, omitted, eliminated and/or implemented in any other manner to achieve various advantages, such as those described with respect to Figures 5A to 8B.

Although example ways of implementing the systems 100, 300 are shown in Figures 1-4, 5B, 6B, 7B, and/or 8B, one or more of the elements, processes, and/or devices shown in Figures 1-4, 5B, 6B, 7B, and/or 8B may be combined, divided, rearranged, omitted, eliminated, and/or implemented in any other manner. Additionally, the example web server 106, the example AME server 114, 604, the example partner DP server 108, 304, the example browser 110, the example beacon request redirector 120, the example cookie generator 122, the example partner selector 124, the example beacon instruction generator 126, the example communication interface 128, 132, the example cookie mapper 130, and/or (more generally) the example systems 100, 300 of Figures 1-4, 5B, 6B, 7B, and/or 8B may be implemented by hardware, software, firmware, and/or any components of hardware, software, and/or firmware. Thus, for example, any of the example web server 106, the example AME server 114, 604, the example partner DP server 108, 304, the example browser 110, the example beacon request redirector 120, the example cookie generator 122, the example partner selector 124, the example beacon instruction generator 126, the example communication interfaces 128, 132, the example cookie mapper 130 and/or (more generally) the example systems 100, 300 may be implemented by 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 claim of this patent is read to encompass pure software and/or firmware implementations, at least one of the example web server 106, the example AME server 114, 604, the example partner DP server 108, 304, the example browser 110, the example beacon request redirector 120, the example cookie generator 122, the example partner selector 124, the example beacon instruction generator 126, the example communication interface 128, 132 and/or the example cookie mapper 130 is thereby expressly defined as including 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. In addition, the example systems 100, 300 of Figures 1-4, 5B, 6B, 7B and/or 8B may include one or more elements, processes and/or devices in addition to or in place of those shown in Figures 1-4, 5B, 6B, 7B and/or 8B, and/or may include more than one of any or all of the elements, processes and devices shown.

Flowcharts representing example machine-readable instructions for implementing the systems 100 and 300 of Figures 1 through 4, 5B, 6B, 7B, and/or 8B are shown in Figures 9 through 13. In this example, the machine-readable instructions comprise a program for execution by a processor (e.g., processor 1412 shown in the example processor platform 1400 discussed below in conjunction with Figure 14). The program may be embodied in software stored on a tangible computer-readable storage medium associated with processor 1412 (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 1412 and/or embodied in firmware or dedicated hardware. Additionally, while the example program is described with reference to the flowcharts shown in Figures 9 through 13, many other methods of implementing the example systems 100 and 300 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-13 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, briefly, for temporary buffering, and/or for caching 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. 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-13 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, temporarily, for temporary buffering, and/or for caching 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. 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 is a flow diagram representative of example machine readable instructions 900 that may be executed to implement the example browser 110 of FIGs. 1-4, 5B, 6B, 7B, and/or 8B to implement mapping of the browser's AME cookie to a partner DP cookie.

The example browser 110 of FIG1 sends a request for a web page (e.g., to a partner DP and/or to another web page publisher) (block 902). The example browser 110 receives web page code including beacon instructions (e.g., tags provided by AME) (block 904). The example browser 110 executes the beacon instructions (block 906) and generates a beacon request from the beacon instructions (block 908).

The example browser 110 determines whether a cookie for the AME domain is stored (block 910). For example, AME may have previously caused the browser 110 to store a cookie for the AME domain. If a cookie for the AME domain is stored (block 910), the example browser 110 adds the AME cookie to the beacon request (block 912). After adding the AME cookie to the beacon request (block 912), or if no cookie for the AME domain is stored (block 910), the example browser 110 sends the beacon request to the AME server 114 (block 914). Example methods and apparatus for performing any of blocks 902 through 914 are described in U.S. Patent No. 8,370,489, which is incorporated herein by reference in its entirety as if fully set forth herein.

The example browser 110 determines whether a response has been received (block 916). If no response has been received (block 916), the example browser 110 determines whether a response timeout (e.g., a watchdog timer) has expired (block 917). For example, when the browser 110 provides an AME cookie in the beacon request and the AME server 114 determines that the AME cookie is mapped to a partner DP cookie, the example AME server 114 may record the impression and omit transmitting a response to the browser 110. By not responding, the example AME server 114 and browser 110 can reduce network traffic and/or the amount of data sent to the partner DP. If a response timeout has not occurred (block 917), control loops to block 916 to continue waiting for a response to the beacon request. In some examples, a timer is used at block 916 to prevent aborts in an infinite loop. In such an example, if no response is received within the timeout period, control exits block 916 to terminate the instructions of FIG. 9 .

When the response is received (block 916), the example browser 110 determines whether the response is a redirect message (e.g., a 302 FOUND message) (block 918). If the response is a redirect message (block 918), the example browser 110 generates a Partner DP request from the redirect instruction (block 920). For example, the Partner DP request may include the URL of the Partner DP server specified in the redirect message.

The example browser 110 determines whether a cookie for the partner DP domain specified in the redirect is stored (block 922). For example, the partner DP may have previously caused the browser 110 to store a cookie for the partner DP domain. If a cookie for the partner DP domain is stored (block 922), the example browser adds the partner DP cookie to the partner DP request (block 924). After adding the partner DP cookie (block 924), or if the partner DP cookie is not stored (block 922), the example browser 110 sends the partner DP request to the partner DP server 108 (block 926). After sending the partner DP request to the partner DP server (block 926), if the response from the AME server 114 is not a redirect (e.g., a placeholder image such as a 1x1 transparent pixel) (block 918), or if a response timeout occurs (block 917), the example instructions 900 end.

10 is a flow diagram representative of example machine readable instructions 1000 that may be executed to implement the example AME server 114 of FIGs. 1-4, 5B, 6B, 7B, and/or 8B to initiate mapping of AME cookies to partner DP cookies.

The example AME server 114 of FIG. 1 receives a beacon request from a browser (e.g., browser 110 of FIG. 1 ) (block 1002). The example AME server 114 determines whether the beacon request includes an AME cookie (block 1004). If the beacon request does not include an AME cookie (block 1004), the example AME server 114 generates an AME cookie for the browser (block 1006). For example, the AME cookie enables the AME server to track the browser's online activities within AME-tagged web pages. If the beacon request includes an AME cookie (block 1004), the example AME server 114 determines whether the AME cookie has been mapped to a partner DP cookie (block 1008). For example, the AME server 114 may determine whether the AME cookie is mapped to one or more partner DP cookies. If the AME cookie is mapped to a partner DP cookie (block 1008), the example AME server 114 determines whether additional mapping is desired (block 1009). For example, while the AME server 114 may have a mapping between an AME cookie and a first partner DP cookie, it may be desirable to map the AME cookie to a second (or more) partner DP cookies among other partner DPs to improve the quality of demographic information applied to impression data.

If a mapping of AME cookies to partner DP cookies (e.g., the first partner DP cookie and/or additional partner DP cookies) is desired (blocks 1008, 1009), or after generating an AME cookie (block 1006), the example AME server 114 generates a redirect response (block 1010). The example AME server 114 includes an identifier of the AME cookie (e.g., a generated or previously stored cookie) and the address (e.g., URL) of the partner DP to be contacted in the redirect response (block 1012). The example AME server 114 sends the redirect response (e.g., including the AME cookie identifier and partner DP address) to the browser 110 (block 1014). In some examples, blocks 1002 to 1014 represent processing, and blocks 1016 to 1030 represent separate processes executed in parallel. In such examples, the first process ends after block 1014.

Returning to the example of FIG10 , the example AME server 114 determines whether an AME cookie to partner DP cookie mapping has been received (block 1016). The example AME server 114 may wait for a period of time between blocks 1014 and 1016 (e.g., to allow the browser 110 to send a request to the partner DP server 108). If an AME cookie to partner DP cookie mapping is received (block 1016), the example AME server 114 records the AME cookie to partner DP cookie mapping (block 1018). For example, the mapping may include an AME cookie identifier and a corresponding partner DP cookie identifier.

In some examples, blocks 1016 and 1018 constitute a thread that can be executed as a separate process to receive and/or store the mapping between the AME cookie and the partner DP cookie. For example, the AME server 114 can redirect the browser to the partner DP server 108, 304. The partner DP server 108, 304 determines the association between the AME cookie and the partner DP cookie, and instead of immediately sending the mapping to the AME server 114 (e.g., directly or via the browser 110), the example partner DP server 108, 304 processes and/or sends the mapping in batches (e.g., multiple messages, multiple mappings in a file, etc.).

Returning to the example of FIG. 10 , after recording the cookie mapping (block 1018), or if no cookie mapping is received (block 1016), the example AME server 114 determines whether to request a mapping from an additional partner DP (block 1020). For example, the browser 110 may select multiple beacon requests based on the tagging instructions to enable the AME server 114 to redirect requests to multiple partner DPs. If the AME server 114 is to request a mapping from an additional partner DP (block 1020), the example AME server 114 generates a redirect response (block 1022). The example AME server 114 includes the AME cookie (e.g., the generated or received AME cookie) in the redirect response (block 1024). The example AME server 114 sends the redirect request to the browser 110 (block 1026).

In some examples where the AME server 114 will request mappings to additional (eg, multiple) partner DPs (block 1020), the example AME server 114 may simultaneously issue multiple redirect responses to the browser 110 in response to the beacon request.

Returning to the example of FIG. 10 , the example AME server 114 stores the AME cookie to facilitate subsequent matching with Partner DP data (eg, via periodic transmission of Partner DP OCR and/or demographic information) (block 1028 ).

After storing the AME cookie (block 1028), if the AME server 114 does not request a mapping from an additional partner DP (block 1020), or if a cookie mapping to an additional partner DP is not desired (block 1009), then the example instructions 1000 of FIG. 10 end.

Figure 11 is a flowchart representing example machine-readable instructions 1100 that may be executed to implement the example AME server 114 of Figures 1-4, 5B, 6B, 7B and/or 8B to associate demographic data obtained from a partner DP with online activity monitoring information (e.g., impression data and/or exposure data).

The example AME server 114 obtains the AME cookie to partner DP cookie mapping (block 1102). For example, the AME server 114 may receive periodic or aperiodic reports from the partner DP server 108 of FIG. 1 that include the AME cookie to partner DP cookie mapping. Additionally or alternatively, the example AME server 114 may receive a message (e.g., an HTTP message) from the partner DP server 108, 304 (e.g., directly or via the browser 110) that includes the AME cookie to partner DP cookie mapping. The example AME server 114 obtains demographic information corresponding to the partner DP cookie (block 1104).

The example AME server 114 selects an AME cookie to partner DP cookie mapping (block 1106). The example AME server 114 determines whether the partner DP cookie in the selected mapping is mapped to an additional AME cookie (e.g., an AME cookie other than the AME cookie in the selected mapping) (block 1108). For example, multiple AME cookies may be provided to a browser 110 associated with a user, who is then associated with a partner DP cookie. When an AME cookie expires or is deleted by the browser 110, additional AME cookies are provided to the browser 110 and may be mapped to the same partner DP cookie. The example AME server 114 can then correlate the user's impressions by merging the impression data of multiple AME cookies mapped to the same partner DP cookie. If the partner DP cookie is mapped to an additional AME cookie (block 1108), the example AME server merges the mappings of the AME cookies corresponding to the partner DP cookie (block 1110). By merging the mappings, the example AME server 114 can consolidate the activities (e.g., impressions) of the users associated with the browsers.

After merging the mappings (block 1110) or if the partner DP cookie is not mapped to the additional AME cookie (block 1108), the example AME server 114 determines whether the AME cookie (e.g., the selected mapped AME cookie and/or the merged AME cookie) is mapped to the additional partner DP cookie (block 1112). For example, the AME server 114 may request and receive mappings from multiple partner DP servers 108, 304 for a single AME cookie as described above. If the AME cookie is mapped to the additional partner DP cookie (block 1112), the example AME server 114 merges the mappings of the additional partner DP cookie to the AME cookie (block 1114).

After merging the mappings (block 1114), or if there are no additional partner DP cookies mapped to the AME cookie (block 1112), the example AME server 114 determines whether there are additional mappings to consider merging (block 1116). If there are additional mappings (block 1116), control returns to block 1106 to select another AME cookie to partner DP cookie mapping.

When no additional mappings exist (block 1116), the example AME server 114 associates the online activity (e.g., impression data) measured using the AME cookie with the received demographic information corresponding to the partner DP cookie (e.g., based on a merged or unmerged mapping of the AME cookie to the partner DP cookie) (block 1118). For example, by determining the mapping of the AME cookie to the partner DP cookie, the AME server 114 can match the impression data measured in association with the AME cookie with the demographic data received in association with the partner DP cookie. The example AME server 114 associates the AME cookie with any additional online activity measured by the partner DP using the partner DP cookie (block 1120). As a result, the example AME server 114 aggregates the online activity measured by the AME (if any) with the online activity measured by the partner DP that was not measured by the AME, which is further associated with the demographic information provided by the partner DP that was previously unavailable to the AME. The example instructions 1100 then end.

FIG12 is a flow diagram representing example machine-readable instructions 1200 that may be executed to implement the example partner DP server 108, 304 of FIG1-4, FIG5B, FIG6B, FIG7B, and/or FIG8B to map AME cookies to partner DP cookies. For clarity, the example instructions 1200 of FIG12 are described below with reference to the example partner DP server 108.

The example partner DP server 108 of FIG1 receives a request from a browser (e.g., the browser 110 of FIG1 ) (block 1202). The example partner DP server 108 determines whether the request includes a partner DP cookie (block 1204). For example, if the user of the browser 110 has previously established an account or provided information to the partner DP, the example partner DP may have stored a cookie on the computer executing the browser 110.

If the request includes a partner DP cookie (block 1204), the example partner DP server 108 reads the partner DP cookie data (block 1206). For example, the partner DP server 108 can determine a user identifier or other identifying information from the partner DP cookie data. The example partner DP server 108 then identifies the user registered with the partner DP based on the cookie (block 1208).

The example partner DP server 108 generates a mapping response (block 1210). The partner DP server 108 includes the AME cookie to partner DP cookie mapping in the mapping response (block 1212). For example, the partner DP server 108 may include in the mapping response a URL that includes the domain of the AME server 114, an identifier of the AME cookie, and an identifier of the partner DP cookie that is mapped to the AME cookie. The example partner DP server 108 determines whether to include demographic information corresponding to the partner DP cookie in the mapping (block 1214). For example, the partner DP server 108 may provide the demographic information with the mapping and/or may periodically provide the demographic information to the AME 102.

If the partner DP server 108 does not include demographic information in the mapping (block 1214), the example partner DP server 108 sends a mapping response to the AME server 114 or to the browser 110 (block 1216). For example, the partner DP server 108 may send an asynchronous HTTP request to the AME server 114 and/or send a redirect response to the browser 110 to cause the browser to send a request to the AME server 114. The example partner DP server 108 periodically sends data including the AME cookie, the partner DP cookie, and the demographic information to the AME server 114 (block 1218). However, additionally or alternatively, the partner DP server 108 may send the data to the AME server 114 non-periodically or at other intervals. If the partner DP server 108 is to include demographic information (block 1214), the example partner DP server 108 sends a mapping response including the demographic information to the AME server 114 or to the browser 110 (block 1220).

After sending the mapping response including the demographic information (block 1220) or after sending the mapping response and sending the demographic data separately (blocks 1216 and 1218), the example instructions of FIG. 12 end.

Figure 13 is a flow diagram representing example machine-readable instructions 1300 that may be executed to implement the example beacon instruction generator 126 of Figure 1 to generate beacon instructions (e.g., tags) to be served by a web server (e.g., web server 106 of Figure 1) to mark media (e.g., advertisements, web pages, etc.).

The example beacon instruction generator 126 of FIG. 1 receives website and/or web server information (e.g., address information, information describing a website served by the web server 106 of FIG. 1 ) (block 1302). The example beacon instruction generator 126 generates beacon instructions for the website and/or web server (block 1304). In some examples, the beacon instruction generator 126 generates template instructions for a website and/or website element (e.g., for an entire website, for an advertisement or other media that is part of a website, etc.). The example beacon instructions generated by the beacon instruction generator 126 cause a browser or other client device that receives the beacon instructions to initiate a beacon request to facilitate impression measurement and/or the processing disclosed herein that results in mapping an AME cookie to one or more partner DP cookies.

The example beacon instruction generator 126 determines whether the beacon instruction includes modifiable (e.g., customizable) data (block 1306). Example modifiable data can be included in the beacon instruction to customize the beacon instruction for a website, web server, advertising campaign, or other purpose. Example information that can be configured as non-modifiable includes the address of the AME server 114 to which the beacon instruction will initiate communication. If modifiable information is present in the beacon instruction (block 1306), the example beacon instruction generator 126 modifies the modifiable beacon instruction data based on the website and/or web server information (block 1308).

In some examples, beacon instructions include data that can be modified by web server 106 based on the web page provided to browser 110. For example, beacon instructions can provide different data to example browser 110 depending on the identity of the user of browser 110 and/or the timestamp of when the beacon instructions were sent.

After modifying the beacon instruction data (block 1308), or if the beacon instructions are not modifiable (block 1306), the example beacon instruction generator 126 provides the beacon instructions to the web server 106 for inclusion in the media (block 1310). For example, the beacon instruction generator 126 may send the beacon instructions via a communication interface to the web server 106 and/or provide the instructions to a developer or administrator of a website for inclusion in a script and/or code of the web server 106. The example instructions 1300 then end and/or repeat to generate additional beacon instructions for the web server 106 or additional web servers.

14 is a block diagram of an example processor platform 1400 capable of executing the instructions of FIGs. 9-13 to implement the example AME server 114, the example partner DP servers 108, 304, the example browser 110, and/or (more generally) the example systems 100, 300 of FIGs. 1-4, 5B, 6B, 7B, and/or 8B. The processor platform 1400 may be, for example, a server, a personal computer, or any other type of computing device.

The processor platform 1400 of the illustrated example includes a processor 1412. The processor 1412 of the illustrated example is hardware. For example, the processor 1412 may be implemented by one or more integrated circuits, logic circuits, microprocessors, or controllers from any desired family or manufacturer.

The processor 1412 of the illustrated example includes a local memory 1413 (e.g., a cache). The processor 1412 of the illustrated example communicates with a main memory including a volatile memory 1414 and a non-volatile memory 1416 via a bus 1418. The volatile memory 1414 may be implemented by synchronous dynamic random access memory (SDRAM), dynamic random access memory (DRAM), RAMBUS dynamic random access memory (RDRAM), and/or any other type of random access memory device. The non-volatile memory 1416 may be implemented by flash memory and/or any other desired type of memory device. Access to the main memories 1414 and 1416 is controlled by a memory controller.

The processor platform 1400 of the illustrated example also includes an interface circuit 1420. The interface circuit 1420 may be implemented using any type of interface standard, such as an Ethernet interface, a universal serial bus (USB), a PCI express interface, and/or any other communication interface.

In the example shown, one or more input devices 1422 are connected to the interface circuit 1420. The input devices 1422 allow a user to enter data and commands to the processor 1412. For example, the input devices may be implemented through an audio sensor, a microphone, a camera (still or video), a keyboard, buttons, a mouse, a touch screen, a trackpad, a trackball, isopoint, and/or a voice recognition system.

One or more output devices 1424 are also connected to the interface circuit 1420 of the illustrated example. For example, the output device 1424 can be implemented by a display device (e.g., a light emitting diode (LED), an organic light emitting diode (OLED), a liquid crystal display, a cathode ray tube display (CRT), a touch screen, a tactile output device, a light emitting diode (LED), a printer, and/or a speaker). Therefore, the interface circuit 1420 of the illustrated example typically includes a graphics driver card, a graphics driver chip, or a graphics driver processor.

The interface circuitry 1420 of the illustrated example also includes communication devices such as transmitters, receivers, transceivers, modems, and/or network interface cards to facilitate exchanging data with an external machine (e.g., any type of computing device) via a network 1426 (e.g., an Ethernet connection, a digital subscriber line (DSL), a telephone line, a coaxial cable, a cellular telephone system, etc.).

The processor platform 1400 of the illustrated example also includes one or more mass storage devices 1428 for storing software and/or data. Examples of these mass storage devices 1428 include floppy disk drives, hard disk drives, compact disk drives, Blu-ray disk drives, RAID systems, and digital versatile disk (DVD) drives.

The encoded instructions 1432 of Figures 9-13 may be stored in the mass storage device 1428, in the volatile memory 1414, in the non-volatile memory 1416, and/or on a removable tangible computer-readable storage medium (eg, a CD or DVD).

The example methods and apparatus disclosed herein provide demographic information to an audience measurement entity for a larger number of online users than was previously available to the audience measurement entity. The example methods and apparatus disclosed herein reduce the uncertainty associated with the use of statistical methods by increasing the amount of data collected, while maintaining the privacy of individual users. The example methods and apparatus disclosed herein reduce the number of redirects required by a database owner during the lifetime or validity period of an associated cookie. By reducing the number of redirects, the example methods and apparatus disclosed herein reduce background processing that can interrupt, interfere, and/or negatively impact the performance of a client browser, thereby improving the overall user experience for audience members. The example methods and apparatus improve the overall efficiency of a network environment by reducing network congestion and latency associated with collecting and matching exposure information with demographic information.

It should be noted that this patent claims priority from Australian patent application serial number 2013204865 filed on April 12, 2013, the entirety of which is incorporated by reference.

Although certain example methods, apparatus, 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, and articles of manufacture fairly falling within the scope of the claims of this patent.

Claims (47)

1. A method for sharing online media impression data, the method comprising: A response is sent from an audience measurement entity to a first request, the first request identifying media provided to a client device. The response includes an identifier of a first cookie set by the audience measurement entity in the client device and an indication of a database owner. The response also includes information causing the client device to send a second request to the database owner, the second request including the identifier of the first cookie. The audience measurement entity receives network communication, the network communication including a mapping from a first cookie to a second cookie and demographic information, the second cookie being set by the database owner in the client device, and the demographic information being associated with the database owner's second cookie; and The audience measurement entity associates the second cookie and the demographic information with the impression of the media. 2. The method of claim 1, wherein the mapping and the demographic information are received from the database owner in an asynchronous communication manner. 3. The method of claim 1, wherein the response includes a redirection message. 4. The method of claim 1, wherein the mapping is received at a first time and the demographic information is received at a second time after the first time. 5. The method according to claim 1, further comprising: selecting the database owner from the database owner list based on the website that initiated the first request. 6. The method of claim 5, wherein selecting the database owner includes determining the quality of demographic information provided by the database owner for a target demographic group associated with the website. 7. The method of claim 1, further comprising: determining whether the first request includes the first cookie, and generating the first cookie when the first request does not include the first cookie. 8. A device for sharing online media impression data, the device comprising: A redirector sends a response to a first request that identifies media provided to a client device. The response includes an identifier of a first cookie set in the client device by an audience measurement entity and an indication of a database owner. The response causes the client device to send a second request to the database owner, the second request including the identifier of the first cookie. A communication interface that receives network communication from at least one of the client device or the database owner, the network communication including a mapping from a first cookie to a second cookie and demographic information, the second cookie being set by the database owner in the client device, and the demographic information being associated with the database owner's second cookie; and An audience measurement server is used to associate the second cookie and the demographic information with the impression of the media. 9. The device of claim 8, wherein the communication interface receives the mapping and the demographic information from the database owner in an asynchronous communication manner. 10. The device of claim 8, wherein the response includes a redirection message. 11. The device of claim 8, wherein the communication interface receives the mapping at a first time and receives the demographic information at a second time after the first time. 12. The device of claim 8, further comprising a collaborator selector that selects the database owner from a list of database owners based on the website that initiated the first request. 13. The device of claim 12, wherein the collaborator selects the database owner by determining the quality of demographic information provided by the database owner for a target demographic group associated with the website. 14. The device of claim 8, further comprising a cookie generator, wherein the redirector determines whether the first request includes the first cookie, and the cookie generator generates the first cookie when the first request does not include the first cookie. 15. A method for sharing online media impression data, the method comprising: Receive a first request from a client device, the first request including an audience measurement entity cookie set by an audience measurement entity in the client device; Determine the cookie mapping from the audience measurement entity cookie to the database owner cookie, the database owner cookie being set by the database owner in the client device; and The cookie mapping is sent to the client device in a redirect message, which causes the client device to send the cookie mapping to the audience measurement entity. 16. The method of claim 15, wherein the redirect message includes a database owner cookie, the audience measurement entity cookie, and an indication of the association between the database owner cookie and the audience measurement entity cookie. 17. A method for sharing online media impression data, the method comprising: A first request is received from the client device at the database owner, the first request including an audience measurement entity cookie set by the audience measurement entity in the client device; The database owner determines the cookie mapping from the audience measurement entity cookie to the database owner cookie, which is set by the database owner in the client device; and The cookie mapping is sent by the database owner to the audience measurement entity in a Hypertext Transfer Protocol (HTTP) message. 18. The method of claim 17, wherein the message further comprises a second cookie mapping between a second audience measurement entity cookie of the second client device and a second database owner cookie associated with the second client device. 19. A method for sharing online media impression data, the method comprising: Receives first network communication from a client device, the first network communication including an audience measurement entity cookie set by an audience measurement entity in the client device; and The database owner sends a cookie mapping from the Uniform Resource Locator (URL) parameters of the second network communication to the audience measurement entity associated with the audience measurement entity cookie. The cookie mapping includes an association between the database owner cookie set by the database owner in the client device and the audience measurement entity cookie. 20. The method of claim 19, wherein the second network communication is a redirection message that causes the client device to send the cookie mapping to the audience measurement entity. 21. The method of claim 20, wherein the redirect message includes the database owner cookie, the audience measurement entity cookie, and an indication of the association between the database owner cookie and the audience measurement entity cookie. 22. The method of claim 19, wherein the second network communication further includes demographic information in the Uniform Resource Locator (URL) parameter. 23. A device for sharing online media impression data, the device comprising: A communication interface that receives a first request from a client device, the first request including an audience measurement entity cookie set by the audience measurement entity in the client device; A cookie mapper that determines the cookie mapping from the audience measurement entity cookie to the database owner cookie, which is set by the database owner in the client device. The communication interface sends the cookie mapping to the client device in a redirect message, which causes the client device to send the cookie mapping to the audience measurement entity. 24. The device of claim 23, wherein the communication interface sends the cookie mapping in the redirect message by sending the database owner cookie and the audience measurement entity cookie in the Uniform Resource Locator parameter of the redirect message. 25. The device of claim 23, wherein the redirection message includes a database owner cookie, an audience measurement entity cookie, and demographic information. 26. The device of claim 23, wherein the message further includes a second cookie mapping between a second audience measurement entity cookie of the second client device and a second database owner cookie associated with the second client device. 27. An apparatus for sharing online media impression data, the apparatus comprising: A communication interface receives a first request from a client device, the first request including an audience measurement entity cookie set by an audience measurement entity in the client device, and the communication interface sends network communication to the audience measurement entity associated with the audience measurement entity cookie, the network communication's Uniform Resource Locator (URL) parameter including a cookie mapping between a database owner cookie associated with the client device and the audience measurement entity cookie, the database owner cookie being set by a database owner in the client device; and A processor that executes instructions that cause the processor to generate the network communication. 28. A method for sharing online media impression data, the method comprising: Provide instructions to be included in the website, which, when executed, cause a client device to initiate processing, the processing including: Send the first request to the audience measurement entity; and A second request is sent to the database owner to cause the database owner to send a cookie mapping to the audience measurement entity in the Uniform Resource Locator (URL) parameters of the network communication. The cookie mapping identifies the association between the audience measurement entity cookie set by the audience measurement entity in the client device and the database owner cookie set by the database owner in the client device. 29. The method of claim 28, further comprising: receiving information associated with the website and generating the instruction based on the information. 30. The method of claim 28, wherein the processing further comprises: receiving a redirection message from the audience measurement entity, the redirection message including an identifier of the audience measurement entity cookie. 31. A device for sharing online media impression data, the device comprising: Communication interface; and A processor that generates instructions to be included in a website and causes the communication interface to provide the instructions to a web server associated with the website. Upon execution of the instructions, the instructions cause a client device to begin processing, the processing including: Send the first request to the audience measurement entity; and A second request is sent to the database owner, causing the database owner to send a cookie mapping to the audience measurement entity in the Uniform Resource Locator (URL) parameters of the network communication. The cookie mapping is used to identify the association between the audience measurement entity cookie set by the audience measurement entity in the client device and the database owner cookie set by the database owner in the client device. 32. The device of claim 31, wherein the communication interface receives information associated with the website, and the processor generates the instructions based on the information. 33. The device of claim 31, wherein the device further comprises receiving a redirection message from the audience measurement entity, the redirection message including an identifier of the audience measurement entity cookie. 34. A method for sharing online media impression data, the method comprising: Send the first request to the audience measurement entity; and A second request is sent to the database owner to cause the database owner to send a cookie mapping to the audience measurement entity in the Uniform Resource Locator (URL) parameters of the network communication. The cookie mapping includes an association between an audience measurement entity cookie set by the audience measurement entity in the client device and a database owner cookie set by the database owner in the client device. 35. The method of claim 34, further comprising: storing the database owner cookie. 36. The method of claim 34, wherein sending the first request to the audience measurement entity is in response to the execution of a beacon instruction in the webpage. 37. The method of claim 34, wherein the second request further causes the database owner to send demographic characteristics associated with the client device to the audience measurement entity. 38. The method of claim 34, further comprising: Send a third request to the audience measurement entity; and A fourth request is sent to cause the second database owner to send the audience measurement entity cookie to the second database owner cookie, which is a second cookie mapping. 39. The method of claim 34, wherein the second request causes the database owner to asynchronously send the cookie mapping to the audience measurement entity. 40. The method of claim 34, further comprising: sending a third request to the audience measurement entity, the third request including the cookie mapping. 41. An apparatus for sharing online media impression data, the apparatus comprising: Communication interface; and The web browser: Send a first request to the audience measurement entity via the communication interface; and A second request is sent to the database owner via the communication interface, causing the database owner to send a cookie mapping to the audience measurement entity in the Uniform Resource Locator (URL) parameters of the network communication. The cookie mapping is used to identify the association between the audience measurement entity cookie set by the audience measurement entity in the client device and the database owner cookie set by the database owner in the client device. 42. The device of claim 41, wherein the web browser sends the audience measurement entity cookie in the first request. 43. The device of claim 41, wherein the web browser sends the first request to the audience measurement entity in response to the execution of a beacon instruction in the webpage. 44. The device of claim 41, wherein the second request further causes the database owner to send demographic characteristics associated with the client device to the audience measurement entity. 45. The device according to claim 41, wherein the web browser: Send a third request to the audience measurement entity; and A fourth request is sent to the second database owner to cause the second database owner to send the audience measurement entity cookie to the second database owner cookie as a second cookie mapping. 46. The device of claim 41, wherein the second request causes the database owner to asynchronously send the cookie mapping to the audience measurement entity. 47. The device of claim 41, wherein the web browser sends a third request to the audience measurement entity, the third request including the cookie mapping.