Systems and methods for processing consumer information for targeted marketing applications

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is based upon and claims the benefit of priority from U.S. Provisional Patent Application No. 61/376,157 filed on Aug. 23, 2010, entitled “Shared Cookies With Entity-Specific Access Rights,” the entire contents of which are hereby incorporated herein by reference in their entirety. All publications and patent applications mentioned in this specification are herein incorporated by reference in their entirety to the same extent as if each individual publication or patent application was specifically and individually indicated to be incorporated by reference.

BACKGROUND

1. Field

This disclosure relates in general to computer data processing, and in particular to computing systems and methods for coalescing and sharing of consumer data.

2. Description of the Related Art

Content providers often customize their content to consumers. For example, internet websites often customize content in order to increase their conversion rate, which measures the percentage of visitors taking affirmative actions to further engage the sites, such as by signing up for accounts or making purchases. As another example, many content providers implement an account login system that requests demographic information from consumers when they sign up, and uses such information to tailor content to the consumers. An e-commerce site may, for example, display different products based on the visitor's age and gender in order to increase sales. Similarly, on-line advertising networks may customize advertisements based on insights gained from tracking cookies stored on visitors' computers that monitor their browsing histories. The tailoring of content such as advertisements could lead to increased sales.

SUMMARY OF THE DISCLOSURE

Embodiments of the invention include systems and methods that enable the association and aggregation of consumer data gathered from online and offline sources. In particular, several embodiments are directed to linking consumer data in a data source controlled by an entity (e.g., such as a company's CRM (customer relationship management) database) to offline data sources such as demographic data, and/or online data sources such as online interaction data. In one embodiment, the linking is performed in an anonymous manner that preserves data privacy of the consumers, and relies at least in part on the linking of data from various sources associated with the individual consumers. The linking may be based on several identifiers (IDs) associated with the data sources. The systems and methods disclosed herein may perform the linking through one or more batch data operations, one or more real time data operations, and/or one or more of a combination of batch and real time data operations. The systems and methods disclosed herein thus facilitate the association of these disparate data sources and enable various entities to better tailor interactions with the consumers.

In various embodiments of the invention, a shared cookie data management system and method is disclosed. Entitles that use cookies to track data related to consumer information may not share such data for a number of reasons, such as because the data is in a proprietary format. If entities do share, they typically share all or nothing. The various embodiments of the shared cookie data architecture disclosed herein eliminate the need to deploy different types of cookies with different types of scripts for different businesses. In one embodiment, the common, shared cookie can be used across various entities that have approved partner keys (entities that participate in the sharing are called “partners”). The common, shared cookie can contain data from multiple entities/parties, with individual data elements securely governed with access controls. In one embodiment, the data controls can be applied at the partner level or data level. A partner may have limited rights to a partner's data source versus having unlimited rights to that same data source. For example, one partner may have unlimited access to all data, but other partner may have only access to some rights. In one embodiment, the individual partners can define such rights. For example, a partner A may allow a partner B to access all or some of partner A's data, via the common cookie.

In one embodiment, each partner may use a “first party” cookie, which has only the partner's information, as well as a shared common cookie for storing data for sharing. The common cookie can allow third party data appends, based on the rights associated with the partner key. The data appends can be limited, unlimited, structured or free form. For example, a first partner may have data indicting that a user 1 has a high propensity to spend on electronic gadgets, but does not know more. With the sharing, the first partner can allow a second partner, via this third party append feature, to add its data related to user 1 to the shared data. For example, if the second partner has demographic and income range data for user 1, the second partner may indicate in the share cookie that user 1 is interested in premium consumer gadgets.

The data within the shared, common cookie can be updated in real time, at the time of transaction, with the data needed to support the transaction. This allows the common cookie to be utilized for multiple content and advertising purposes, and not limited by the data stored on the cookie or technical limitations of storing data on the cookie. In one embodiment, a partner can dynamically alter content of a shared cookie in real time based on access rights and functionality for transaction. This real time capability of the shared cookie is in contrast to common implementations, where cookies are static and incremental. For example, a shared cookie may have tens or hundreds of data elements with access control associated with at least some of them. Elements may be inserted into the cookie in real time from a database of consumer data which may include many more elements. Thus relevant elements may be provided, in real time, on an as-needed basis. In addition, if a partner has just conducted a transaction with a consumer associated with the cookie, the partner (if it has the proper access rights) can dynamically update those data elements (e.g., add, delete, revise).

BRIEF DESCRIPTION OF THE DRAWINGS

Specific embodiments of the invention will now be described with reference to the following drawings, which are intended to illustrate embodiments of the invention, but not limit the invention:

FIG. 1 is a block diagram illustrating one embodiment of an audience intelligence system and a consumer data processing system;

FIG. 2 is a flow diagram showing a process of integrating online and offline data within the audience intelligence system and the consumer data processing system according to one embodiment;

FIG. 3A is a flow diagram illustrating the processing of mapping offline and online data according to one embodiment;

FIG. 3B is a block diagram that shows the audience intelligence system servicing several partners and leveraging the partners' CRM data according to one embodiment;

FIG. 4 is a flowchart that shows the batch processing of data in one embodiment;

FIG. 5 is a block diagram illustrating an example audience intelligence system that is based on a shared cookie architecture according to one embodiment.

FIG. 6 illustrates example data attributes within the shared cookie architecture according to one embodiment;

FIG. 7 provides two flowcharts illustrating example data processing methods, one in real time mode and one in batch mode, according to one embodiment;

FIG. 8 provides two flowcharts illustrating example data processing methods, one in real time mode and one in batch mode, according to one embodiment;

FIG. 9 is a combined block and flow diagram showing a method for targeting an advertisement using universal tags according to one embodiment; and

FIG. 10 is a block diagram illustrating a computing system in accordance with one embodiment.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

Embodiments of the invention will now be described with reference to the accompanying figures, wherein like numerals refer to like elements throughout. The terminology used in the description presented herein is not intended to be interpreted in any limited or restrictive manner, simply because it is being utilized in conjunction with a detailed description of certain specific embodiments of the invention. Furthermore, embodiments of the invention may include several novel features, no single one of which is solely responsible for its desirable attributes or which is essential to practicing the inventions herein described.

Below are figures that illustrate additional exemplary embodiments of the cookie management and consumer data sharing systems and methods. Any specific entities noted below are provided for illustration purposes only and should be interpreted to cover any other entity in place of, or in addition to, the noted entity. In other embodiments, multiple blocks that are illustrated as being performed by a single entity may be performed by multiple entities and, likewise, groups of blocks that are illustrated as being performed by multiple entities may be performed by a single entity. Additionally, depending on the embodiment, the systems and methods described herein may comprise fewer blocks or components than are illustrated or discussed.

Audience Intelligence System Architecture

FIG. 1 is a block diagram illustrating one embodiment of an audience intelligence system. The systems depicted in FIG. 1 may each be implemented in any suitable computing system, such as, for example, a desktop or laptop computer, a computer server, or a mobile computing device, such as a mobile phone, a PDA, or a smart phone. An example computing system is shown in FIG. 10. In addition, some of the systems may be combined into fewer systems than shown, or divided into more systems than shown. The communications links depicted in FIG. 1 may be through a wired or wireless connections and may be part of a secured network, such as a local area network (LAN) and/or a combination of networks, such as LANs, WANs, MANs and/or the Internet.

As shown, an audience intelligence system 100 is configured to use data from one or more data sources including an audience intelligence cookie profiles data source 108, an online data source 106, an offline to online ID mapping data source 102, and an offline data source 104. The audience intelligence system 100 may communicate with a batch processing system 120, which processes offline data 122. In one embodiment, the batch processing system 120 may also use a number of data sources including a client CRM (customer relationship management) data source 124, a third party data source 126, and a linkage data source 128. In one embodiment, the batch processing system 120 is configured to create mappings of these offline data sources to the online data 106, and such mappings is stored in offline to online ID mapping data source 102, as shown in FIG. 1. The mapping data may then be used by the audience intelligence system 100 for audience targeting and/or other custom advertising solutions. In addition, the linking of a large amount of offline data to online data enables better demographic modeling. The audience intelligence system 100 may use an audience intelligence system ID as the online ID and provide the audience intelligence system ID in a shared cookie to enable sharing of data from the various data sources connected to the audience intelligence system 100. In one embodiment, the batch processing system 120 provides to the audience intelligence system 100 a subset of offline data 122 that is linked to various consumers in the mappings, and the audience intelligence system 100 may store the subset of offline data in the offline data source 104.

In one embodiment, the audience intelligence system 100 is used to provide data related to, or associated with, one or more target audience(s) for a media buying system 130. The media buying system 130 may be, for example, an online ad exchange where online advertisement orders and/or online advertising campaigns can be initiated. As shown in FIG. 1, the media buying system 130 in one embodiment accepts a cookie from an audience intelligence enabled site or partner 110 as an input. The cookie, in one embodiment, provides data and or identifying information of a particular person within the target audience. The cookie may contain an audience intelligence system ID which in one embodiment provides a link to a data profile with the audience intelligence cookie profiles 108, which may be linked to the other data sources 102, 104, and 106. In one embodiment, the profiles include data that can be shared by multiple sites or partners, as will be furthered described below in FIGS. 5-9.

In one embodiment, the media buying system 130 uses that ID information, along with the data provided by the audience intelligence system 100, to customize online and/or offline advertising. Some of the examples are depicted in FIG. 1. For example, the media buying system 130 may support push/pull channels that output the target audience data to one or more of: direct buy clients 132, media exchanges 134, site-side optimizers 136, and offline systems 138. These push/pull channels, in one embodiment, output a variety of advertisements, including for example, an on line display ad 140, a mobile display ad 142, a search ad 144, a rich media ad 146, an on-air ad 148, and/or a direct mail advertisement 150. Other advertising methods and channels not shown in FIG. 1 may also used. For example, advertisements may be served through other consumer interaction channels such as social networks, phone marketing, game console networks, satellite or cable TV systems, and/or wireless communication systems such as wireless phone networks. In addition to customizing advertisements, the consumer data may also be used in other areas such as improving customer relationship management and helping companies better understand their customers and prospective customers.

Online—Off-line Data Mapping

FIG. 2 is a flow diagram showing a process of integrating online and offline data sources within the audience intelligence system and the consumer data processing system 120. The process 200, in one embodiment, includes two processes that together enable the mapping of online to offline data. The first of the two processes in FIG. 2 is labeled using letters and the second is labeled using numerals.

The first process begins, in one embodiment, when a linkage partner's CRM data 202 is sent with partner IDs to the customer data processing system 120, as shown by the letter “A.” The linkage partner could be a retailer, for example. Through this process, the retailer may wish to gain additional insight on its customers, and coordinate online marketing efforts to its customers. Once the data is received, the consumer data processing system 120 may create a mapping between the partner ID (e.g., an ID assigned to a customer by the partner entity) to an offline data ID (e.g., an ID assigned to the same customer by the entity performing the matching). This matching process will be further described below in conjunction with FIG. 3. The partner ID to offline data ID mapping is then sent to the audience intelligence system 100, as shown by the letter “B.” The mapping is used in a real-time data flow to map offline data to online data (shown by the letter “C”), as will be further discussed below.

The second process begins, in one embodiment, when partner media content 206 triggers the start of the mapping process (shown by the number “1”). For example, the trigger could be a pixel request that is a part of a display ad, and the request is directed to a demand-side platform (DSP) 140 of the audience intelligence system. In one embodiment, as a result the trigger, a cookie from the consumer browser may be updated, or if a cookie is not present, a new one may be created. The request received at the DSP may then be sent to a system controller by the linkage partner 204 to redirect and may pass control to the partner (shown by the number “2”). In one embodiment, the linkage partner, now provided with access to the browser cookie data, then determines whether its cookie exists. If such a cookie exists, the partner may trigger a request to the audience intelligence system with the partner ID previously sent for offline data integration by the first process described above (shown by the number “3”). The cookie in one embodiment includes an audience intelligence system ID assigned to the consumer. Finally, with partner ID mapped to the offline data ID, and the association of the mapping to the audience intelligence system ID within the cookie, the mapping is completed (shown by the number “4”). The mapping links the audience intelligence system ID (the online to the offline ID and to the partner ID. In one embodiment, the cookie does not include the data used for targeting. Rather the cookie provides an identifier (e.g., audience intelligence system ID) associated with the mapping.

Mapping Example

FIG. 3A is a flow diagram illustrating the processing of mapping offline and online data according to one embodiment. FIG. 3A tracks an example data mapping from start to finish. The mapping in one embodiment is performed by the batch processing system 120. On the far left hand side of FIG. 3A is the partner CRM data 302. The partner CRM data 124 is to be matched with offline data 304 that is accessed by the batch processing system 120. As shown, the example partner CRM data includes an individual's name, a partner ID for that individual, and an address for that individual. These data fields are provided here for illustrative purposes only and additional and/or other data fields may be used in various embodiments for matching. Within the offline data 122, additional information associated with that individual may be present. In one embodiment, the batch processing system 120 is configured to match that individual's information as indicated by the partner CRM data to the individual's information as indicated by the offline data 122. As shown, the match is performed on the basis of the name and address information (306, 316). However, in various embodiments the matching may be based on other pieces of information. On the basis of that match, a mapping between the partner ID and the offline data ID is created (308, 318). After the mapping is created, optionally the data for the individual may be cleansed and/or augmented with additional data associated with the individual from one or more offline data sources (320). As shown in the example, the individual's name as indicated by the partner CRM data has been cleansed/augmented with a middle initial and the address has been cleansed/augmented with a ZIP code. A phone number has also been added to the record.

As an example, in one embodiment, the offline data 122 may include one or more of the following types of information: (1) custom business data and (2) geographic level demographics that include one or more models, such as models that identify lifestyle attributes associated with a geographic location (e.g., MOSAIC® segmentation from Experian) and/or attitudinal/psychographic attributes associated with a geographic location (e.g., TrueTouch^SM Touch Points segmentation from Experian). In other embodiments, other attributes of an individual may be estimated based on a geographic region of the individual. Other types of offline data may include census data, and/or data items from a demographic database such as an Experian® INSOURCE^SM database.

The partner ID to offline data ID mapping is used by the audience intelligence system in real time to perform a real-time match, as previously shown in FIG. 2. As shown here in FIG. 3A, the audience intelligence system ID 320 for John Doe (“XGFF”) is matched real time with the partner ID 322 assigned to John Doe (“1234”). With the partner ID to offline data ID mapping having been previously created as discussed above, a three-way ID match is now complete. This three-way ID map enables the integration of one or more of: linkage partner CRM data 124, offline data 122, and online data 106. In one embodiment, the linkage partner CRM data can include data that is unique to the partner. For example, if the partner is a brick-and-mortar retailer, the data may include past purchase history and/or preferences of the individual as collected by the retailer. The offline data, for example, may include demographic data related to the demographic attributes of the neighborhood in which the individual resides. The online data, for example, may include purchase history and all browsing history of that individual that have been collected by various other sites. The linking of these three types of data sources enables the audience intelligence system to provide a dynamic and comprehensive set of data that can be used for improving targeted marketing for the partner in the various types of advertising channels such as those shown in FIG. 1. In this particular example where partner is a retailer, the retailer may be able to better tailor their interactions with their customers, online and offline, by merging their own customer data to various offline data and online data about their customers.

FIG. 3B is a block diagram that shows the audience intelligence system servicing several partners and leveraging the partners' CRM data according to one embodiment. As shown, the audience intelligence system 100 services multiple linkage partners 350, 352, 354, and 356. In one embodiment, these partners share a unified cookie platform/system architecture through which a cookie (with an audience intelligence system ID) is tied to an individual and is used for sharing data. The shared cookie for the individual provides, in one embodiment, access to various ID mappings as previously discussed above. With such mappings, the various data sources including offline data sources and online data sources could be tied to the individual. As such, the link data may be used to build profiles for real time targeting applications.

Batch Processing of Offline Data

FIG. 4 is a flow diagram that shows the batch processing of data in one embodiment. In block 401, the batch processing system receives client CRM data (e.g., raw data containing personal identifying information (PII) and non-PII). In block 402, the batch processing system transforms the data (e.g., by formatting it). The transformation may include converting the incoming data into standard formats while also auditing for data validity. This may include the ability to accept different data types such as ASCII, EDCDIC, Binary, and UTF-8, and fixed or variable blocked file inputs, and convert those into standard formats. Domestic and foreign addresses and conversion of foreign data elements into English data elements are also supported in one embodiment. Additionally transforming logic such as dropping or adding certain characters may be used, and custom logic provided by the client may be applied as well.

Then in block 403, the batch processing system applies data hygiene process(es) to the data. The data hygiene may include one or more of the following functions: (1) address standardization (CASS certified process), including LACS, Suite, and DSF, (2) apartment append, (3) advanced address correction (AAC), (4) advanced address correction maximum (AAC Max), (5) NCOA (National Change of Address), COA+ (Change of Address+) and DSF processing, (6) ability to keep or drop invalid records, (7) ability to keep or drop NCOA undeliverable, and (8) ability to apply latitude and longitude data based on the address.

In block 404, the batch processing system may augment the data, for example, by adding additional information associated to the individuals identified in the data. The data augmentation may include capturing the incoming (now transformed/cleansed) address information and appending additional information such as email, phone, IP address, etc. In one embodiment, the incoming data may be point of sale data from in store transactions or data from online sales transaction. In such cases, address and other contact information may be added to the sale data to complete the records. A match confidence level may be returned as a result of the matching/augmentation/hygiene steps.

In block 405, the batch processing system may optionally separate data into tiers, with each tier defining a level of granularity. For example, some offline data maybe mapped at the personal level, some maybe mapped at the household level, and some maybe mapped at the local area level (e.g., area defined by a ZIP code). For example, going back to the example in FIG. 3B, if John Doe cannot be matched to an individual record in the offline data, John Doe may be matched to a household record for the “Doe” household. If a household record does not exist, John Doe may be matched to a local area record such as an area defined by a ZIP code. Alternatively, the partner may specify the level of matching and a combination of matching (personal, household, local area) may be provided together. In block 406, the batch processing system performs online-offline ID mapping process, as previously discussed above in conjunction with FIGS. 2 and 3A. Then in block 407, the batch processing system transmits generated mapping and data packages to the audience intelligence system.

Shared Cookie Architecture

FIG. 5 is a block diagram illustrating an example audience intelligence system that is based on a shared cookie architecture according to one embodiment. In FIG. 5, this embodiment of the audience intelligence system 500 includes an audience database 502, whose data is accessible via a shared audience ID 504. The ID may be embedded in a browser cookie in one embodiment. In one embodiment, to protect the privacy of the person associated with the shared cookie, the shared cookie does not contain any personally identifiable information. In one embodiment, data attributes are stored in the cookie on an as needed basis, with the shared data being delivered from the audience database 502 in real time as further described below.

FIG. 5 also illustrates a number of partners with their associated systems 1 (508) to N (510), each of which may be a computing system controlled by an entity like a retailer store or an ad network or ad exchange that wishes to participate in the sharing of consumer data. Shared audience ID embedded in the shared cookie 504 provides access to the shared consumer data in the audience database 502, and the shared data may be used by the individual entities (partners) participating in the sharing to improve online marketing efforts (e.g., social media marketing, email marketing, online display advertising, etc.). The shared consumer data may also be used in tailoring interactions with consumers in cable and satellite TV systems 514, in wireless phone and data systems 516, and in offline media mailing campaigns 518.

In one embodiment, a partner links its own ID (506, 512) to the shared cookie ID (504) as follows. When a partner writes data to the shared cookie, it also writes an ID (separate from the audience ID) that can be tied back to the partner's own cookie or its CRM system 508. In another embodiment, the partner may perform this action so it can tie its own cookie with all other data assets on the shared cookie. This is useful in a situation where the partner has an extensive cookie data infrastructure already in place and where there are many data assets already accumulated in the partner's own cookie.

In one embodiment, the shared cookie is invoked in a page with embedded data content (e.g., scripting language such as JavaScript) that is used to trigger the cookie read. The data content includes a common or universal tag that is to be used if a site wants to implement the cookie read feature. In one embodiment the common tag each has a unique partner ID. This process is further described below in conjunction with FIG. 9.

In batch mode, a partner uses data that is returned in a batch mode operation as follows. A web server passes transactional information from online process to batch process. When the batch process is performed to get data not on the shared cookie, the batch process links back to cookie through a real time database lookup. In one embodiment, the writing of the data to the cookie maybe delayed until a subsequent request from partner. In another embodiment, the writing can take place in real-time.

The sharing of data can occur as follows according to one embodiment. For example, a first partner may want to monetize data with a second partner. However, the first partner may not want to share all of its consumer in the arrangement. With the shared cookie architecture, the first partner can selectively choose a part of its data to be shared on the shared cookie 504, such as a product category, and prevent from sharing other information it may have on its first party cookie (e.g., cookie 506, 516). This puts the product category data in the shared cookie so the first partner can share data with the second partner. The cookie would be set up with distribution rights.

Shared Cookie Example

FIG. 6 illustrates data attributes within the shared cookie architecture according to one embodiment. As shown, the data structure within the example shared cookie may include a number of key-value attribute pairs (602, 604). Each pair may be associated with data related to a read privilege 606 and/or a modify privilege (608). Here, the “Audience ID” attribute provides a unique ID that identifies the individual associated with the cookie. As discussed above, the unique ID may be associated with a partner/client ID which may be linked to a CRM data source.

The other attributes shown in FIG. 6 each have read and/or modify privilege data. For example, the “Last Visit to Site X” attribute could be read by partner (associated with a client/partner) 1, 2, and 3 but could be modified only by partner 1. Thus, partner 1, 2, and 3 could read this attribute value but only partner 1 could modify it. The sharing of other attributes in this example is illustrated by the other attributes. In this manner, the data values could be selectively shared across partners, and read/write access privileges are controlled/defined by the access privilege data.

In one embodiment, each data attribute is matched to an owner ID, and the data is specific to a machine/user (e.g., identified by the unique “Audience ID” in this example). The data thus need not be stored in the audience database. In one embodiment, the data is stored in the audience database, and certain data elements are inserted into the cookie when a partner requests them, in real time or substantially in real time. For example, in the audience database may be hundreds or thousands of data elements, and a partner may be provided with a subset of those data elements. If a partner is an automobile dealership, data elements relevant to automobile purchases may be inserted into the cookie in real time.

Shared Cookie—Data Processing Flows for Retrieving and Adding Data

FIG. 7 provides two flow diagrams illustrating example methods of accessing the consumer data related to the shared cookie architecture according to one embodiment. Process 700 describes an operation performed in real time or substantially real time, while process 720 describes an operation performed in batch mode.

The real time process 700 begins in block 702 when a consumer visits a website. The visit could be performed by the consumer instructing a browser in a computing device to access the website. Alternatively, the visit may be triggered indirectly when the user visits another site with data content that makes a data request to the site. Regardless, in block 704, the site reads the shared ID from a cookie on the consumer's computing device (e.g., via an embedded Javascript in the site's content). Then in block 706, the site forwards the shared ID to an audience information repository (e.g., the audience database within the audience intelligence system 500) with a specific request for information on the consumer. Then in block 708, the repository uses the shared ID to retrieve the requested information. This may be performed after verifying the site's access rights to the particular information requested (as previously shown in FIG. 6). In block 710, the repository returns the requested information to the site. Finally, in block 712, the site uses the returned information to customize content provided to the consumer.

Alternatively, in batch mode operation, the process 720 begins in block 722 when various consumers visit the website (directly or indirectly, as discussed above). In response to those visits, in block 724, the site reads and collects the shared IDs from cookies on those consumers' computing devices (e.g., via an embedded Javascript in the site's content). Then in block 726, the site forwards the collected shared IDs to the audience information repository (e.g., the audience database within the audience intelligence system) with a specific request for information on the consumers associated with the shared IDs. Then in block 728, the repository uses the shared IDs to retrieve the requested information. This may be performed after verifying the site's access rights to the particular information requested (as previously shown in FIG. 6). Then in block 730, the repository returns the requested information to the site. Then in block 732, the site uses information to tailor interaction with consumers (e.g., classifying consumers, customizing emails, customizing contents for future visits, updating its own customer database).

FIG. 8 provides two flow diagrams illustrating example methods of updating the consumer data related to the shared cookie architecture according to one embodiment. Process 800 describes an operation performed in real time or substantially real time, while process 820 describes an operation performed in batch mode. The real time process 800 begins in block 802 when the consumer visits the website (directly or indirectly). Then in block 804, the website reads the shared ID from a cookie on the consumer's computing device (e.g., via an embedded Javascript). Then in block 806, the site collects information from the consumer. The information may be collected by explicit input (recording information provided by the consumer) and/or through tracking the consumer's interaction with the site. Then in block 808, the site forwards the shared ID to the audience information repository with specific request to store the collected information. Finally in block 810, the repository uses the provided shared ID to store the collected Information (after verifying the site's right to modify that portion of the data associated with the shared cookie).

The batch mode process 820 begins in block 822 when consumers visit the site (directly or indirectly). In response to those visits, in block 824, the site reads shared IDs from the cookies on the consumers' computing devices. Then in block 826, the site collects information from consumers (e.g., via explicit input and/or tracking). Then in block 828, the site forwards the shared IDs and collected information to the audience information repository with a specific request to store the collected information. Finally in block 830, the repository uses shared IDs to store collected information (after verifying the site's right to modify that portion of the data associated with the shared IDs).

Shared Cookie Architecture

FIG. 9 is a combined block and flow diagram showing a method 900 for targeting an advertisement using universal tags according to one embodiment. As illustrated in FIG. 9 and described below, a common cookie may be used by multiple entities (“partners”), e.g., web properties, in order to store and share data elements. Advantageously, the format of the common cookie includes a partner ID associated with each data element (or group of data elements) stored in the cookie so that access rights to the data elements may be allocated on a per-partner basis. For example, a first partner may have access to data elements in particular verticals markets that are provided by the common cookie service provider (and/or one or more third parties), while a second partner may have access to data elements in other verticals, including data stored in the common cookie by certain other partners. Additionally, partners' rights to store data on the common cookie may be customized. Thus, the systems and methods described herein provide partner specific rights to data elements.

In one embodiment, the common cookie server updates a common cookie in real-time to include the data elements that are needed by (and are authorized to be provided to) the requesting partner. Thus, the common cookie may be updated to include (and information that is not important to the requesting partner may be removed from the cookie) the relevant data elements so that the partner can provide targeted content to the user in a landing page, subsequent pages of the web property, and/or later visits to the web property.

Returning to FIG. 9, the process begins at (1) when a partner web page embedded with a universal tag with an encrypted partner key requests services from a universal web server (e.g., audience intelligence system 500 in FIG. 5), which houses universal web services. At (2), based on the partner key, the server determines what read and write services are allowed. At (3), the server writes the allowed content into the universal cookie. Then, at (4), the server executes a partner script and/or an ad tag for any allowed data appends from the partner which will be written to the universal cookie. Then at (5), web services transaction with the partner key may trigger batch service request for offline (batch) process, which is handled by the universal batch server (e.g., the consumer data processing system 120 in FIG. 1) in one embodiment. At (6) the ad server instructions are updated by the offline processes, such as modeling or more extensive data collection efforts.

In certain embodiments, the systems and methods may include one or more of the following components, features, and/or advantages:

• • A common tag with a common cookie is utilized but the instructions are client specific, based on partner key used in the transactions.
  • The common cookie can be used across third parties that have approved partner keys.
  • The common cookie can contain data from multiple parties, all securely governed with access controls. Controls can be applied at the partner level or data level. A partner may have limited rights to a partner's data source versus having unlimited rights to that same data source.
  • The common cookie can allow third party data appends, based on the rights associated with the partner key. The data appends can be limited, unlimited, structured or free form.
  • Along with data from the common cookie service provider, data collected on the common cookie from third party partners can be shared with other partners, based on the rights associated with a partner key. For example, partner A can allow partner B access to all or some of partner A's data, via the common cookie.
  • The data within the common cookie can be updated in real time, at the time of transaction, with the data needed to support the transaction. This allows the common cookie to be utilized for multiple content and advertising purposes, not limited by the data stored on the cookie or technical limitations of storing data on the cookie.
  • The common cookie and pixel management process is integrated to work for almost any partner or client. The integrated set of functions with security enabled access controls minimizes the need to set up client specific deployments for cookie services. One deployment is use of a unique partner key that specifies the services that will be enabled on the cookie as well as for any server side and batch functions.
    Computing Hardware Implementation

FIG. 10 is a block diagram illustrating an example computing system 1030 that may be adapted to implement the various components and/or systems described in the various embodiments. The computing system 1030 includes, for example, a personal computer that is IBM, Macintosh, or Linux/Unix compatible. In one embodiment, the computing system 1030 comprises a server, a desktop computer, a laptop computer, a personal digital assistant, a kiosk, or a mobile device, for example. In one embodiment, the computing system 1030 includes a central processing unit (“CPU”) 1090, which may include one or more conventional microprocessors. The computing system 1030 may further include a memory 1072, such as random access memory (“RAM”) for temporary storage of information and a read only memory (“ROM”) for permanent storage of information, and a mass storage device 1082, such as a hard drive, diskette, or optical media storage device. Typically, the components and modules of the computing system 1030 are connected to the computer using a standard based bus system. In different embodiments, the standard based bus system could be Peripheral Component Interconnect (“PCI”), Microchannel, Small Computer System Interface (“SCSI”), Industrial Standard Architecture (“ISA”) and Extended ISA (“EISA”) architectures, for example. In addition, the functionality provided for in the components and modules of computing system 1030 may be combined into fewer components and modules or further separated into additional components and modules.

The computing system 1030 is generally controlled and coordinated by operating system software, such as Windows Server, Linux Server, Windows XP, Windows Vista, Windows 7, Unix, Linux, SunOS, Solaris, or other compatible server or desktop operating systems. In Macintosh systems, the operating system may be any available operating system, such as MAC OS X. In other embodiments, the computing system 1030 may be controlled by a proprietary operating system. Conventional operating systems control and schedule computer processes for execution, perform memory management, provide file system, networking, I/O services, and provide a user interface, such as a graphical user interface (“GUI”), among other things.

The computing system 1030 includes one or more commonly available input/output (I/O) devices and interfaces 1068, such as a keyboard, mouse, touchpad, and printer. In one embodiment, the I/O devices and interfaces 1068 include one or more display device, such as a monitor, that allows the visual presentation of data to a user. More particularly, a display device provides for the presentation of GUIs, application software data, and multimedia presentations, for example. The computing system 1030 may also include one or more multimedia devices 1062, such as speakers, video cards, graphics accelerators, and microphones, for example. In other embodiments, such as when the computing system 1030 comprises a network server, for example, the computing system may not include any of the above-noted man-machine I/O devices.

In the embodiment of FIG. 10, the I/O devices and interfaces 1068 provide a communication interface to various external devices. In the embodiment of FIG. 10, the computing system 1030 is electronically coupled to the networks 1040 and 1060, both of which may comprise one or more of a LAN, WAN, or the Internet, for example, via a wired, wireless, or combination of wired and wireless, communication links 1063 and 1065. The networks 1040 and 1060 facilitate communications among various computing devices and/or other electronic devices via wired or wireless communication links.

In one embodiment, requests and responses for data and/or data operations are sent to the computing system 1030 over the network 1040 and/or 1060. Similarly, results are returned over the network 1040 and/or 1060. In addition to the devices that are illustrated in FIG. 10, the computing system 1030 may communicate with other data sources or other computing devices. In addition, the data sources may include one or more internal and/or external data sources. In some embodiments, one or more of the databases, data repositories, or data sources may be implemented using a relational database, such as Sybase, Oracle, CodeBase and Microsoft® SQL Server as well as other types of databases such as, for example, a flat file database, an entity-relationship database, and object-oriented database, and/or a record-based database.

In the embodiment of FIG. 10, the computing system 1030 also includes modules that may be executed by the CPU 1090 to perform data operations. For example, in the consumer data processing system, the data operations may include the operations depicted in FIGS. 1-4. The modules may include, by way of example, components, such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. Alternately, one or both of them may be implemented as separate devices, such as computer servers.

In general, the word “module,” as used herein, refers to logic embodied in hardware or firmware, or to a collection of software instructions, possibly having entry and exit points, written in a programming language, such as, for example, Java, Lua, C or C++. A software module may be compiled and linked into an executable program, installed in a dynamic link library, or may be written in an interpreted programming language such as, for example, BASIC, Perl, or Python. It will be appreciated that software modules may be callable from other modules or from themselves, and/or may be invoked in response to detected events or interrupts. Software instructions may be embedded in firmware, such as an EPROM. It will be further appreciated that hardware modules may be comprised of connected logic units, such as gates and flip-flops, and/or may be comprised of programmable units, such as programmable gate arrays or processors. The modules described herein are preferably implemented as software modules, but may be represented in hardware or firmware. Generally, the modules described herein refer to logical modules that may be combined with other modules or divided into sub-modules despite their physical organization or storage.

All of the processes described above may be embodied in, and fully automated via, software code modules executed by one or more general purpose computers. The code modules may be stored in any type of computer-readable medium or other computer storage device. Some of all of the methods may alternatively be embodied in specialized computer hardware. In addition, the components referred to herein may be implemented in hardware, software, firmware, or a combination thereof.

Any process descriptions, elements, or blocks in the flow diagrams described herein and/or depicted in the attached figures should be understood as potentially representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps in the process. Alternate implementations are included within the scope of the embodiments described herein in which elements or functions may be deleted, executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those skilled in the art.

CONCLUSION

The foregoing description details certain embodiments of the invention. It will be appreciated, however, that no matter how detailed the foregoing appears in text, the invention can be practiced in many ways. As is also stated above, it should be noted that the use of particular terminology when describing certain features or aspects of the invention should not be taken to imply that the terminology is being re-defined herein to be restricted to including any specific characteristics of the features or aspects of the invention with which that terminology is associated. The scope of the invention should therefore be construed in accordance with the appended claims and any equivalents thereof.