Patent Description:
Data security and user privacy are vital in systems and devices connected to public networks, such as the Internet. The enhancement of user privacy has led many developers to change the ways in which user data is handled. For example, some browsers are planning to deprecate the use of third-party cookies.

<CIT> describes a method for maintaining user privacy in advertisement networks may include receiving first persona data associated with a first user from at least one publisher system. The first persona data may be generalized to form first generalized persona data. A session key may be generated. The first generalized persona data and the session key may be encrypted with a first public key of an advertisement network system to form a first ciphertext. The first ciphertext and first user identity data may be communicated to a mediator system. The first user identity data may be associated with first user's identity. A first encrypted targeted advertisement may be received based on the first generalized persona data from the advertisement network system via the mediator system. The first encrypted targeted advertisement may be decrypted with the session key to form a first targeted advertisement. A system and computer program product are also disclosed.

"Anonymization Techniques for Privacy Preserving Data Publishing: A Comprehensive Survey" describes systematically categorizing existing anonymization techniques into relational and structural anonymization, and present an up to date thorough review on existing anonymization techniques and metrics used for their evaluation.

This specification describes technologies that enable the selection of content relevant to a user without compromising user privacy or data security. To select relevant content while enhancing user privacy, content platforms can predict which user attribute buckets are relevant to a user. A user attribute can describe any characteristic of a user, such as age, education, shoe size, and so on. A user attribute bucket is a value or range of values for the characteristic. For example, the age ranges "<NUM> to <NUM>" and "<NUM> to <NUM>" are user attribute buckets for the age range attribute, which is a type of attribute. Users are assigned to user attribute buckets based on individual interactions between the user and the content platform and/or its affiliates, and not based on user tracking across resources of multiple different content platforms or different domains. Instead, a content platform can predict, for each individual request for content received from a client device of a user, one or more user attribute buckets for the user based on the request and contextual data received with the request. The content platform can then request that the client device update information stored at the client device that is related to user attribute buckets specific to that content platform.

Each content platform can use information that is related to user attribute bucket predictions, and that is stored at the client device, to eliminate or limit what content is selected for a user, and, in some cases, the information can be used to determine preferred content. In some cases, provider-specific logic available to the client device can also be used when determining content. As users interact repeatedly with the content platform and/or its affiliates, predictions relating to user attribute buckets are reinforced, and the confidence of the user's attribute predictions can increase. Since each content platform's user attribute bucket information for a user is stored at the client device of the user, no entity outside of the client device has access to cross site data (e.g., information about the user's activity across multiple web sites published by different publishers), thereby enhancing user privacy.

In general, one innovative aspect of the subject matter described in this specification can be embodied in methods including the operations of receiving, from a client device of a user and by a content platform, a digital component request that requests one or more digital components for display at the client device and that includes contextual data related to an environment in which the digital component will be displayed; assigning, by the content platform and based on the contextual data, the user to one or more user attribute buckets, wherein each of the one or more user attribute buckets is associated with at least one type of user attribute and corresponds to a particular value or value range for the type of user attribute; selecting, based on the contextual data and each user attribute bucket to which the user is assigned, multiple candidate digital components for distribution to the client device; and providing, by the content platform and to the client device, digital component response data that (i) initiates an update, based on each user attribute bucket to which the user is assigned, to aggregated user attribute data for the user stored at the client device and (ii) enables the client device to select, from among the multiple candidate digital components, a given digital component to display to the user based on the aggregated user attribute data, wherein the digital response data includes the plurality of digital components and data indicating each user attribute bucket to which the user is assigned. Other implementations of this aspect include corresponding apparatus, systems, and computer programs, configured to perform the aspects of the methods, encoded on computer storage devices.

These and other implementations can each optionally include one or more of the following features. In one aspect, the digital component response data includes, for each user attribute bucket to which the user is assigned, a confidence score that indicates a confidence in a prediction that an actual user attribute of the user matches the particular value or is within a value range corresponding to the user attribute bucket.

In some aspects, the aggregated user attribute data for the user stored at the client device includes user attribute buckets to which the user is assigned in response to multiple digital component requests and based on respective digital component response data received in response to the plurality of digital component requests.

In some aspects, the digital component response data includes a filter logic module that includes executable instructions configured to produce a confidence score that indicates a confidence in a prediction that an actual user attribute of the user matches the particular value or is within a value range corresponding to the user attribute bucket. The filter logic processes the aggregated user attribute data at the client device to produce a respective confidence score for each of a plurality of user attribute buckets.

In some aspects, the digital component response data includes a reference to a filter logic module located on a separate computing system that is configured to produce a confidence score that indicates confidence in a prediction that an actual user attribute of the user matches the particular value or is within a value range corresponding to the user attribute bucket. The filter logic processes the aggregated user attribute data at the client device to produce a respective confidence score for each of a plurality of user attribute buckets.

In some aspects, the client device is configured to determine, for each of a plurality of user attribute buckets, a membership measure based on a number of times that the user has been assigned to the user attribute bucket. The client device can be configured to determine, for each of a plurality of user attribute buckets, a confidence that score that indicates a confidence in a prediction that an actual user attribute of the user matches the particular value or is within a value range corresponding to the user attribute bucket based at least in part based on the membership measure for the user attribute bucket. The client device selects a given digital component to display to the user based at least in part based on the membership measure for each user attribute bucket.

In some aspects, the contextual data includes at least one of coarse location information of the client device or data identifying a resource with which the given digital component will be displayed.

Using the techniques described in this specification, user specific information that may be useful in selecting content for a user and/or for removing some content from consideration, is maintained on the user's client device, where its use can be controlled by the user. In addition, content platforms can supply proprietary filter logic that can be applied at the client device or at a trusted server to filter content before it is considered for display to a particular user based on predictions relating to user attributes. Therefore, using the techniques of this specification, information is displayed to users that is likely to be relevant to the user without compromising the user's privacy. In addition, as a user continues to interact with a content platform, confidence in predictions can increase, improving the likelihood that relevant content is displayed.

Historically, third-party cookies (e.g., cookies from a different domain than the resource being rendered by a client device) have been used to collect data from client devices across the Internet. However, some browsers and device platforms block the use of third-party cookies and third-party cookies are increasingly being removed from use, thereby preventing the collection of data using third party cookies. This creates a challenge when attempting to utilize collected data to make inferences, segment data, or otherwise utilize data to enhance online browsing experiences, e.g., by selecting content relevant to users based on the data collected using third party cookies. In other words, without the use of third-party cookies, much of the data previously collected is no longer available, which prevents computing systems from being able to use that data to group users based on shared user attributes or activities performed by the users at particular web pages or other resources, to enhance the online experience for users, and/or to display relevant content to users.

The techniques described herein can solve hurdles that may arise from the eradication of third-party cookies. For example, content platforms can add a user to one or more user attribute buckets each time a request for content is sent to the content platform from the client device of the user. The user attribute information is then transmitted to the client, and stored in aggregate only at the client device, so user privacy is preserved. If the user is already a member of a user attribute bucket, the new predictions can be used at the client device to update a metric (e.g., a count and/or combined confidence score) related to the number of times the user has been added to the group, increasing the accuracy of the user attribute predictions for the user.

However, steps can be taken to ensure that the content platform cannot correlate multiple requests for content from the same user and therefore cannot track users across multiple requests, multiple web sites, or multiple domains. For example, metrics related to user attribute buckets of a user are stored only at the client device of the user and such data is not shared with content platforms, thereby preserving user privacy. Instead, by maintaining at the client device information related to the user attribute buckets to which a particular content platform added the user over time, information related to user attributes of the user across multiple requests, web sites, domains, etc., can be used to select relevant content for the user without exposing such information anywhere other than the user's device, where such information can be controlled by the user. This enables accurate selection of relevant content for users without exposing user data to other parties. Enabling such accurate selection prevents distribution of irrelevant content to users that the users would not interact with, which reduces wasted bandwidth in sending such irrelevant content to client devices. Aggregated over millions of client devices, such bandwidth savings are substantial.

Using the techniques described in this document, user attribute information can be updated at client devices of the users without transmitting third-party cookies across a public network, e.g., the Internet. By doing so, user privacy is protected, network bandwidth consumption is reduced (e.g., since cookies are no longer sent), and computational resources of the server that would receive and process the cookies is reduced.

Machine learning models can be used to predict user attribute buckets based on contextual data included in a single request for content. As the machine learning models operate on contextual data of a single request, such machine learning models can be executed by the content platforms rather than by the client device of the user, which, since content platforms typically employ include more powerful computational resources (e.g., server class computers), enables more complex machine learning models (e.g., neural networks having greater numbers of layers and/or neurons) to be used relative to those that can effectively run on client devices. In addition, this structure increases the speed at which the machine learning models are executed, which is critical in selecting and delivering additional content (e.g., digital components) with primary content of web pages or applications. For example, delays in receiving content can cause errors in web pages and native applications that request such content. In addition, digital components can be stored on the client device for selection and display to the user of the client device, which further reduces the latency in selecting and displaying a digital component.

Predicting user attribute buckets for users at the server, and using those predictions to determine which digital components might be of interest to a user can reduce the consumption of computing resources. For example, only the digital components that are more likely to be of interest to a user will be transmitted to the user's device, reducing the impact on the network of transmitting less relevant digital components, along with impact to the computing resources on the server required to transmit such digital components, and to the client device required to receive and store the digital components. Further, the client device selects from among a smaller number of digital components, again reducing resource impact. The client device can also use the user attribute buckets when selecting a digital component to display, e.g., using the user attribute buckets to filter out less relevant digital components, reducing the likelihood that computing resources will be used to display irrelevant digital components.

In general, this document describes systems and techniques for selecting digital components for display at client devices in ways that protect user privacy by determining relevant content based on user attributes without providing user information to unaffiliated web sites. Ensuring the privacy of personal data is a requirement of many computing systems, especially those connected to public networks such as the Internet. Some consumers who do not trust that strong privacy protection will be enforced by a system will simply choose not to use that system.

However, while it is important to protect user privacy, it remains beneficial to display to a user content relevant to or of interest of users. The techniques described in this specification use predictions relating to user attributes based on contextual data related to resources viewed by the user, without enabling content platforms or other entities to track the user's activity across multiple web sites or other resources.

<FIG> is a block diagram of an example environment <NUM> in which digital components <NUM> are selected by client devices <NUM> in a privacy preserving manner. The environment <NUM> includes a data communication network <NUM>, such as a local area network (LAN), a wide area network (WAN), the Internet, a mobile network, or a combination thereof. The data communication network <NUM> connects client devices <NUM> to a content platform, which can include supply side platforms (SSPs) <NUM> and/or demand side platforms (DSPs) <NUM>. The network <NUM> can also connect the various content platforms to one another and/or to digital component providers <NUM>, e.g., to servers of the digital component providers <NUM>. Thus, content platforms can distribute digital components of multiple digital component providers to client devices <NUM>. Further, while the digital component providers <NUM> are illustrated as outside the content platform, a content platform can both contain digital component providers <NUM> and communicate with digital component providers <NUM> via the network <NUM> that are outside the content platform.

A client device <NUM> is an electronic device that is capable of communicating over the network <NUM>. Example client devices <NUM> include personal computers, server computers, mobile communication devices, e.g., smart phones and/or tablet computers, and other devices that can send and receive data over the network <NUM>. A client device <NUM> can also include a digital assistant device that accepts audio input through a microphone and outputs audio output through speakers. The digital assistant can be placed into listen mode (e.g., ready to accept audio input) when the digital assistant detects a "hotword" or "hotphrase" that activates the microphone to accept audio input. The digital assistant device can also include a camera and/or display to capture images and visually display information. The digital assistant can be implemented in different forms of hardware devices including, a wearable device (e.g., watch or glasses), a smart phone, a speaker device, a tablet device, or another hardware device. A client device <NUM> can also include a digital media device, e.g., a streaming device that plugs into a television or other display to stream videos to the television, a gaming device, or a virtual reality system.

A gaming device is a device that enables a user to engage in gaming applications, for example, in which the user has control over one or more characters, avatars, or other rendered content displayed in the gaming application. A gaming device typically includes a computer processor, a memory device, and a controller interface (either physical or visually rendered) that enables user control over content rendered by the gaming application. The gaming device can store and execute the gaming application locally, or execute a gaming application that is at least partly stored and/or served by a cloud server (e.g., online gaming applications). Similarly, the gaming device can interface with a gaming server that executes the gaming application and "streams" the gaming application to the gaming device. The gaming device may be a tablet device, mobile telecommunications device, a computer, or another device that performs other functions beyond executing the gaming application.

A client device <NUM> can include applications <NUM>, such as web browsers and/or native applications, to facilitate the sending and receiving of data over the network <NUM>. A native application is an application developed for a particular platform or a particular device (e.g., mobile devices having a particular operating system). Although operations may be described as being performed by the client device <NUM>, such operations may be performed by an application <NUM> running on the client device <NUM> and/or by an operating system running on the device.

The applications <NUM> can display electronic resources, e.g., web pages, application pages, or other application content, to a user of the client device <NUM>. The electronic resources can include digital component slots for displaying digital components <NUM> with the content of the electronic resources. A digital component slot is an area of an electronic resource (e.g., web page or application page) for displaying a digital component <NUM>. A digital component slot can also refer to a portion of an audio and/or video stream (which is another example of an electronic resource) for playing a digital component <NUM>.

An electronic resource is also referred to herein as a resource for brevity. For the purposes of this document, a resource can refer to a web page, application page, application content displayed by a native application, electronic document, audio stream, video stream, or other appropriate type of electronic resource with which a digital component <NUM> can be displayed.

As used throughout this document, the phrase "digital component" refers to a discrete unit of digital content or digital information (e.g., a video clip, audio clip, multimedia clip, image, text, or another unit of content). A digital component <NUM> can electronically be stored in a physical memory device as a single file or in a collection of files, and digital components <NUM> can take the form of video files, audio files, multimedia files, image files, or text files and include advertising information, such that an advertisement is a type of digital component <NUM>. For example, the digital component <NUM> may be content that is intended to supplement content of a web page or other resource displayed by the application <NUM>. More specifically, the digital component <NUM> may include digital content that is relevant to the resource content (e.g., the digital component <NUM> may relate to the same topic as the web page content, or to a related topic). The provision of digital components <NUM> can thus supplement, and generally enhance, the web page or application content.

A client device <NUM> can also include, or be coupled to, a digital component repository <NUM>, which can be any storage system appropriate for storing digital components <NUM>. For example, the digital component repository <NUM> can be a persistent storage system such as a database or file system, or a transient storage system such as a dedicated area of random access memory (RAM).

When the application <NUM> loads a resource that includes a digital component slot, the application <NUM> can generate a digital component request <NUM> that requests a digital component <NUM> for display in the digital component slot. In some implementations, the digital component slot and/or the resource can include code (e.g., scripts) that cause the application <NUM> to request a digital component <NUM> from an SSP <NUM>. A digital component request <NUM> sent by a client device <NUM> can include non-sensitive data, such as contextual data, generic keyword and/or a query string. However, sensitive data can be excluded from the digital component request <NUM>.

Further to the descriptions throughout this document, a user may be provided with controls (e.g., user interface elements with which a user can interact) allowing the user to make an election as to both if and when systems, programs, or features described herein may enable collection of user information (e.g., information about a user's social network, social actions, or activities, profession, a user's preferences, or a user's current location), and if the user is sent content or communications from a server. In addition, certain data may be treated in one or more ways before it is stored or used, so that personally identifiable information is removed. For example, a user's identity may be treated so that no personally identifiable information can be determined for the user, or a user's geographic location may be generalized where location information is obtained (such as to a city, ZIP code, or state level), so that a particular location of a user cannot be determined. Thus, the user may have control over what information is collected about the user, how that information is used, and what information is provided to the user.

As described above, a digital component request <NUM> can include contextual data, which is generally considered non-sensitive. The contextual data can describe or otherwise relate to the environment in which a selected digital component <NUM> will be displayed. The contextual data can include, for example, coarse location information indicating a general location of the client device <NUM> that sent the digital component request <NUM>, the day of week and/or hour of day in the locale of the client device, a resource (e.g., website or native application, which can be associated with a set of topics) with which the selected digital component <NUM> will be displayed, a spoken language setting of the application <NUM> or client device <NUM>, the number of digital component slots in which digital components <NUM> will be displayed with the resource, the types of digital component slots, text and/or images that are, or will be, displayed, and other appropriate contextual information.

An SSP <NUM> is a technology platform implemented in hardware and/or software that automates the process of obtaining digital components <NUM> for the resources. Publishers of resources can use an SSP <NUM> to manage the process of obtaining digital components <NUM> for digital component slots of its resources. Each publisher can have a corresponding SSP <NUM> or multiple SSPs <NUM>. Some publishers may use the same SSP <NUM>.

A DSP <NUM> is a technology platform implemented in hardware and/or software that automates the process of distributing digital components <NUM> for display with the resources and/or applications. A DSP <NUM> can interact with multiple supply-side platforms SSPs on behalf of digital component providers <NUM> to provide digital components <NUM> for display with the resources of multiple different publishers. Digital component providers <NUM> can create (or otherwise publish) digital components <NUM> that are displayed in digital component slots of publisher's resources.

The DSP <NUM> (or SSP <NUM>) can further provide to client devices <NUM> one or more filter logic modules <NUM> that can be encoded as computing instructions that indicate, for each DSP <NUM>, whether a particular digital component <NUM> is responsive to a digital component request <NUM>, and more specifically, whether the digital component <NUM> should be removed or filtered from consideration, and /or, as noted above, whether the digital component <NUM> should be preferred, or "boosted," for display. The client device <NUM> can use the filter logic to filter digital components <NUM> from the list of digital components <NUM> that are considered for display on a client device <NUM>. The filter logic in the filter logic module <NUM> can be expressed in any appropriate programming language, such as Python or JavaScript, a rules language, or any other appropriate technique for determining a confidence measure. In some implementations, the filter logic module <NUM> can include a reference (e.g., a Uniform Resource Locator) to a trusted computing resource that provides the computing instructions and returns a result to the client device <NUM>.

Additionally, the DSP <NUM> can provide to a client device <NUM> user attribute buckets <NUM> relevant to a DC request <NUM>. As described above, a user attribute describes any characteristic of a user, such as age, gender, education, shoe size, and so on. A user attribute bucket is a value or range of values for the characteristic. For example, "high school" and "college" are example values for an education characteristic (which is an example type of user attribute), and the age ranges "<NUM> to <NUM>" and "<NUM> to <NUM>" are example ranges of values for the age range attribute (which is another type of user attribute). Examples of characteristics can include age, shoe size, income, and education level, among many other examples.

The user attribute buckets <NUM> can be expressed in any appropriate data format. For example, user attribute buckets <NUM> can be expressed in JavaScript Object Notation (JSON) that includes a reference to the DSP providing the user attribute buckets <NUM>, and one or more tokens (e.g., alphanumeric strings) that represent valid values for a user attribute bucket. For example, tokens for an "age" user attribute bucket <NUM> might include "<NUM>-<NUM>," "<NUM>-<NUM>," "<NUM>-<NUM>," and so on. If a second attribute group includes education tokens such as "high school," "college," and "other" (other education tokens can also be included), the user attribute buckets <NUM> can be expressed as a multidimensional vector such as {{"<NUM>-<NUM>,", "<NUM>-<NUM>", "<NUM>-<NUM>"}, {"high school", "college", "other"}}. In some examples, an attribute group can include an "unknown" user attribute bucket that can be used for attributes that cannot be determined from the contextual data, or if the determination of a user attribute bucket is sufficiently weak (e.g., the confidence is below a configured threshold such as <NUM>%, <NUM>%, <NUM>%, etc.).

In some implementations, the DSP <NUM> can provide a user attribute bucket confidence index that indicates a predicted likelihood that a user is a member of a user attribute bucket. For example, if a DSP <NUM> determines that there is <NUM>% confidence that the user is a member of a first user attribute bucket of "medium" shoe size (which may have options of {"small", "medium", "large"}), <NUM>% confidence that a user is a member of a second user attribute bucket of age <NUM>-<NUM>, <NUM>% confidence that the user is a member of a third user attribute bucket of "college" for education level having options of {"high_school", "college", "graduate", "other"}, and so on, the DSP <NUM> can provide both the user attribute buckets <NUM> and the user attribute bucket confidence index for each. In the example above, the DSP <NUM> can provide the following {{<NUM>, <NUM>, <NUM>}, {<NUM>, <NUM>, <NUM>}, {<NUM>, <NUM>, <NUM>, <NUM>}} to indicate a <NUM>% confidence that the user wears medium size shoes, a <NUM>% confidence the user is <NUM>-<NUM> and a <NUM>% confidence in a college education level. In some cases, the DSP <NUM> can provide confidence levels for more than one attribute. For example, in the example above, if the DSP <NUM> determined a <NUM>% confidence wears small shoes, a <NUM>% confidence wears medium shoes and a <NUM>% confidence in the user wears large shoes, the DSP might provide {{<NUM> ,<NUM>, <NUM>},{<NUM>, <NUM>, <NUM>}, {<NUM>, <NUM>, <NUM>, <NUM>}}, where {<NUM> ,<NUM>, <NUM>} represents the confidence for small (<NUM>%), medium (<NUM>%) and large (<NUM>%) shoes; {<NUM>, <NUM>, <NUM>} represents <NUM>% confidence of the <NUM>-<NUM> age bracket, with no predictions for other age brackets; and {<NUM>, <NUM>, <NUM>, <NUM>} represents a <NUM>% confidence that the education level is college, with no predictions for other education levels. In some implementations, the information can be provided as "key/value" pairs, such as (Age_18_25, <NUM>) which can indicate a <NUM>% confidence that the user is age <NUM> to <NUM>.

Client devices <NUM> can store indications of user attribute buckets <NUM>, including aggregate indications of user attribute buckets <NUM>. For each user of the client device <NUM>, the client device <NUM> can store, for each content platform and for each user attribute bucket, a membership measure that can be an indication of the frequency that that user attribute bucket has been encountered, e.g., the frequency at which the user has been assigned to the user attribute bucket. For example, if DSP <NUM> D<NUM> assigns users to three user attributes, I<NUM>, I<NUM>, I<NUM>, e.g., corresponding to shoe size, age and education (others can also be used), the client device <NUM> can begin with a count of zero for each user attribute bucket for each of I<NUM>, I<NUM>, I<NUM>, which can be expressed as a vector that includes zero values for each user attribute bucket for each user attribute: {{<NUM>, <NUM>, <NUM>},{<NUM>, <NUM>, <NUM>}, {<NUM>, <NUM>, <NUM>, <NUM>}}. In this example, there are three user attribute buckets for I<NUM> and I<NUM>, and four user attribute buckets for I<NUM>, and each user attribute bucker has a value of zero. If the content platform first provides an indication of user attribute buckets <NUM> for DSP <NUM> Di that includes values for (or an indication that the user has been assigned to) user attribute buckets for attributes I<NUM> and I<NUM>, the client device can increment the vector entries for those user attribute buckets, e.g., such that the vector becomes {{<NUM>, <NUM>, <NUM>},{<NUM>, <NUM>, <NUM>}, {<NUM>, <NUM>, <NUM>, <NUM>}}. In this example, the user has been assigned to the first user attribute bucket for attribute I<NUM> and to the second user attribute bucket for attribute I<NUM>, resulting in those values being incremented from a zero to a one. If the DSP Di provides user attribute bucket confidence indices, the client device can sum the indices, or combine the indices using other techniques such as using a measure of central tendency. If the content platform then provides a second indication of the same user attribute buckets <NUM> for D<NUM>, the client device can increment the corresponding vector entries such that the vector becomes {{<NUM>, <NUM>, <NUM>},{<NUM>, <NUM>, <NUM>}, {<NUM>, <NUM>, <NUM>, <NUM>}}. In this example, the first user attribute bucket <NUM> in the first user attribute I<NUM> is a stronger signal of the user attribute bucket as compared to the other user attributes buckets <NUM> for other user attributes. In other words, if user attribute I<NUM> corresponds to shoe size and user attribute I<NUM> corresponds to age, there is a stronger confidence that the prediction of the user's shoe size is correct relative to the prediction of the user's age and education (third user attribute I<NUM>). Note that a second DSP, D<NUM>, can have different user attributes, including a different number of user attributes, e.g., I<NUM>. I<NUM>, and the values in the vector for D<NUM> are not influenced by the information in Di and vice versa. Thus, user information relating to interactions between a user and each DSP is isolated, maintaining user privacy.

The DSP <NUM> can further determine and provide attribute groups associated with digital components <NUM> provided by the DSP <NUM>. Attribute groups associated with digital components <NUM> can be expressed analogously to attribute groups associated with users, e.g., as token, vectors, confidence values, and so on. In some implementations, the user attribute bucket information can include negative associations that indicate that a digital component <NUM> should not be displayed to users in a particular user attribute bucket. For example, a particular digital component <NUM> might be associated with education of "high school" and an age "<NUM>-<NUM>," and another digital component <NUM> might be associated with "not small shoes," indicating that the digital component <NUM> should be filtered when the user is predicted to wear small shoes.

The DSP <NUM> can associate attribute buckets with digital components <NUM> using various techniques. For example, a digital component provider <NUM> can specify one or more user attribute buckets for the digital component <NUM> when the content provider <NUM> provides the digital component <NUM> to the DSP <NUM>. In another example, the DSP <NUM> can train and use a machine learning model that is configured to take a digital component <NUM> as input and to determine one or more user attribute buckets for the digital component <NUM>, e.g., one or more user attribute buckets that are predicted to be relevant to the digital component <NUM> or which users having a user attribute that matches the user bucket are likely to find relevant. Such techniques can also be combined. For example, if a digital component provider <NUM> does not provide user attribute buckets for a digital component <NUM>, the DSP <NUM> can use a machine learning model to determine user attribute buckets for the digital component <NUM> provided by the digital component provider <NUM>.

The user attribute buckets for a digital component <NUM> can be used as distribution criteria for filtering the digital component from digital component selection processes and/or for selecting the digital component from multiple available digital components. For example, a content platform or client device <NUM> can filter a digital component from selection for a user that is assigned to a particular user attribute bucket if the digital component has distribution criteria that specifies that the digital component is only eligible when the user for which a digital component is being selected is not assigned to the particular attribute bucket. In another example, a digital component can have distribution criteria that indicates that the digital component is eligible for selection for users that are assigned to a particular user attribute bucket. If the user for which a digital component is being selected is not assigned to the particular user attribute bucket (or the confidence for that bucket is less than a threshold), the digital component can be filtered from consideration in the selection process.

An example process for selecting and providing a digital component <NUM> for display at a client device <NUM> is illustrated in stages A - E, which illustrate a flow of data between the components of the environment <NUM>.

In stage A, the application <NUM> sends a digital component request <NUM> over the network <NUM> to a content platform, such as an SSP <NUM>. As described above, the application <NUM> can send a digital component request to request a digital component <NUM> for display in a digital component slot of a resource being displayed by the application <NUM>. The digital component request <NUM> can include contextual data. In stage B, the SSP <NUM> forwards the digital component request <NUM> to one or more DSPs <NUM>.

In stage C, each DSP <NUM> can determine or predict that the user of the client device <NUM> which sent the request is a member of one or more particular user attribute buckets <NUM>, and provide data identifying those user attribute buckets <NUM> to the SSP <NUM>. For example, the DSP <NUM> can determine or predict the user attribute buckets <NUM> for the user based on the contextual data of the digital component request <NUM>.

The DSP <NUM> can also send one or more filter logic modules <NUM> that can be used by the client device <NUM> to determine whether to filter digital components <NUM> that are not responsive to the digital component request <NUM>. In addition, the DSP <NUM> can send digital components <NUM> that are potentially responsive to the digital component request <NUM> for consideration by the client device <NUM> and the user attribute buckets associated with the digital components <NUM>. The client device <NUM> can store or cache such digital components <NUM> in its digital component repository <NUM>. In some cases, the DSP <NUM> can determine that the client device <NUM> already possesses, or has access to, the responsive digital components <NUM> and/or filter logic module(s) <NUM>, and therefore does not have to provide the digital components <NUM> and/or filter logic module(s) <NUM>.

In stage D, the SSP <NUM> sends data identifying the user attribute buckets <NUM> determined or predicted for the user, digital components <NUM>, and/or filter logic module(s) <NUM> as received from the DSP <NUM>. In some implementations, the SSP <NUM> can filter digital components <NUM> and/or selection parameters prior to sending the digital components <NUM> and/or selection values to the client device <NUM>. For example, the SSP <NUM> can filter digital components <NUM> and/or selection parameters based on publisher controls specified by the publisher of the resource being displayed by the application <NUM>. In a particular example, a publisher of a web page about a particular event may define, as a publisher control, that digital components <NUM> related to another event may not be displayed with this web page. The SSP <NUM> can filter based on rules or other data provided by the publisher.

The client device <NUM> can receive from the SSP <NUM> the digital components <NUM>, filter logic module(s) <NUM> and the data identifying the user attribute buckets <NUM> for the user. The client device <NUM> can aggregate the user attribute buckets <NUM> with previously received user attribute bucket information to create aggregate user attribute bucket information, e.g., by incrementing values in a vector, as described above.

In stage E, the client device <NUM> can use the aggregate user attribute bucket information associated with a user, user attribute buckets associated with the digital component <NUM>, and/or the filter logic module(s) <NUM> provided by the various DSPs to select a digital components to display to a user of the client device <NUM>. For example, the client device <NUM> can use this information and/or modules to filter a digital component <NUM> from among the received digital components <NUM> such that the digital component <NUM> is not considered for display to the client device <NUM>. The determination of whether to filter a component can use various techniques. In some implementations, the client device <NUM> can obtain distribution criteria (e.g., which may be in the form of rules) relating to a digital component <NUM>, e.g., distribution criteria provided by the supplier of the digital component <NUM>. For example, distribution criteria can specify that a digital component <NUM> is to be filtered from consideration if the user is predicted to be <NUM> to <NUM> years old or if the prediction that the user is <NUM> to <NUM> is stronger than a configured threshold (e.g., <NUM>% confidence).

In some implementations, the client device <NUM> can execute, for each DSP, one or more filter logic module(s) <NUM> provided by that DSP. Each such filter logic module <NUM> can evaluate the likelihood that a user is not interested in a digital component <NUM> (e.g., will not interact with the digital component <NUM>). To make such a determination, the filter logic module <NUM> can access the aggregate user attribute bucket information for that DSP and the user attribute bucket information for the digital component <NUM>, and use the aggregate user attribute bucket information to produce a confidence score ("score" for brevity) that indicates the confidence of the DSP that a particular user will have not have interest in a particular digital component <NUM>. The client device <NUM> can use the score to filter digital components <NUM> from consideration (e.g., removing from consideration all digital components <NUM> for which the score satisfies a threshold), select a digital component <NUM> from among the digital components <NUM> that were not filtered, and display the selected digital component <NUM> on the client device <NUM>.

In some implementations, the client device <NUM> can use the user attribute bucket information and/or the score to select the digital component <NUM>. For example, one digital component <NUM> might have a strong affiliation for individuals with a high school education who are <NUM>-<NUM> and another digital component <NUM> might have a strong affiliation with individuals with a college education who are <NUM>-<NUM>.

In some implementations, the client device <NUM> can send a message to the content platform indicating which digital component <NUM> was displayed. In some implementations, the client device <NUM> can send a message to the content platform indicating that a digital component <NUM> was filtered. In some implementation, the client device <NUM> can provide additional data that can enable reporting functions, provided that data are aggregated and privacy preserving.

In some implementations, an application running on the client device <NUM> processes the user information and selects digital components based on the user information and/or filter modules. This application can be an application <NUM> that displays primary content and/or digital components to users or a trusted application, e.g., the operating system, a secure environment provided by the operating system, a secure web browser, or another application. In some implementations, this trusted application can run in trusted execution environment (TEE) of the client device <NUM>.

<FIG> is a flow diagram of an example process for privacy-preserving content selection. For convenience, the process <NUM> will be described as being performed by the components of a system for privacy-preserving content selection, e.g., client devices <NUM> and content platforms <NUM>, <NUM> of <FIG> appropriately programmed to perform the process <NUM>. Operations of the process <NUM> can also be implemented as instructions stored on one or more computer readable media, which may be non-transitory, and execution of the instructions by one or more data processing apparatus can cause the one or more data processing apparatus to perform the operations of the process <NUM>. One or more other components described herein can perform operations of the process <NUM>.

A client device of a user provides (<NUM>) and the content platform receives (<NUM>) a digital component request that requests one or more digital components for display at the client device. As described above, content platforms can distribute digital components provided by multiple digital component providers. Although in this example a single content platform is shown, the digital component request can be provided to multiple content platforms, e.g., to multiple DSPs. An application running on the client device can generate and send the digital component request.

The client device can provide and the content platform can receive the request using any appropriate technique. For example, the digital component request can be transmitted and received using HyperText Transport Protocol (HTTP) or HTTP-Secure (HTTP-S). In another example, the content provider can include an Application Programming Interface (API), which, when called by the client device, enables the client device to provide a digital component request to a content platform.

The request can include contextual data describing or otherwise relating to an environment in which the digital component will be displayed. The contextual data can include coarse location information that identifies a location of the client device, a description of a resource with which the given digital component will be displayed, the type of the client device (e.g., smart phone or gaming device), and/or other types of contextual data.

The content platform can assign (<NUM>) the user of the client device to one or more user attribute buckets. The content platform can select the user attribute buckets for assignment based, at least in part, on the contextual data. In some implementations, the content platform can include a model that uses the contextual data to determine which user attribute buckets, if any, to which the user can be added. The model can take any appropriate form. For example, the model can be a machine learning model (e.g., a deep neural network (DNN), a logistic regression model, a decision tree or other suitable machine learning models) that is configured to output user attribute buckets based on contextual data. The content platform can process an input that includes the contextual data using the machine learning model, and the model can produce as output indicators associated with user attribute buckets. The indicators can be user attribute bucket identifiers that uniquely identify the user attribute buckets. The output can also include a user attribute bucket confidence index that indicates the likelihood that the user of the client device should be added to each of the one or more user attribute buckets. In another example, the model can be a set of rules that include conditions and results such that, when a condition is satisfied, a result is produced. The conditions can depend on the contextual data, and the results can be user attribute bucket(s) to which users are assigned.

In one example, the content platform can train a machine learning model to predict user attributes of a user based on contextual data received in a single digital component request. The model can be trained, for example, based on labeled training data. The labeled training data can include, for each of multiple sets of contextual data, one or more labels that each indicate a user attribute. When the content platform receives a digital component request that includes contextual data, the content platform can provide the contextual data as input to the machine learning model and receive, as an output of the machine learning model, one or more attribute bucket identifiers that each identify a user attribute bucket corresponding to an attribute that is likely to be an attribute of a user for which such contextual data was received.

The machine learning model can also be trained to output a user attribute bucket confidence index for each user attribute bucket. This user attribute bucket confidence index for a user attribute bucket can indicate a level of confidence that a user for which the contextual data was received has the attribute corresponding to the user attribute bucket. The user attribute bucket confidence index can be based on the contextual data.

In some implementations, a content platform can use multiple machine learning models, e.g., one for each user attribute bucket created by the content platform. A machine learning model for a user attribute bucket can be trained to output a user attribute bucket confidence index score for the user attribute bucket based on the contextual data of a digital component request, e.g., similar to how a machine learning model is trained to output confidence scores for multiple user attribute buckets. In some implementations, a single model can be used to output confidence for multiple features (e.g., age and shoe size).

As the machine learning models are executed by content platforms rather than client devices, the machine learning models can be executed on server class computers or machine learning accelerators (e.g., graphics processing units (GPUs), application specific integrated circuits (ASICs), or tensor processing units (TPUs)). This enables more complex and more powerful machine learning models to be used to predict the user attribute buckets for users.

The content platform can then select one or more user attribute buckets for the user based on the user attribute bucket confidence indices. For example, the content platform can indicate to the client device that the client device is to add the user to each user attribute bucket that has a user attribute bucket confidence index above a specified threshold, which can be zero. In another example, the content platform can indicate to the client device that the client device should add the user to a specified number of user attribute buckets having the highest user attribute bucket confidence indices, e.g., the top five, ten, or other number of the highest scoring user attribute buckets.

In some implementations, the determination can include a user attribute bucket confidence index that indicates a likelihood that a user has an attribute associated with a user attribute bucket, as described above. For example, a value of <NUM> can indicate near certainty that a user attribute bucket applies to the user, a value of <NUM> can indicate near certainty that the user attribute bucket does not apply to the user, and values between <NUM> and <NUM> can indicate relative confidence, e.g., <NUM> indicating <NUM>% certainty that the user attribute bucket applies to the user. In some implementations, the determination can include a confidence index range. For example, a confidence index range can be "below. <NUM>", "over. <NUM>", and "over. <NUM>, among many other examples. The content platform can provide to the client device the level of certainty for each user attribute bucket.

In some implementations, the content platform can determine, for one or more of the selected user attribute buckets to which the user has been assigned, a membership measure (e.g., membership count) that is based on (e.g., indicates) a number of times that the user has been assigned to the given user attribute bucket. For example, if a user had previously been assigned to a user attribute bucket twice, and in response to a current digital component request, the content platform again assigns the user to the user attribute bucket, the content platform can determine that the user has been assigned to the user attribute bucket three times. Such an increased number of assignments can increase the confidence that the user is properly assigned to the user attribute bucket.

In some implementations, the content platform can determine the membership measure based on confidence. For example, if the user was previously assigned to a user attribute bucket twice with confidence values of <NUM> and <NUM>, the user is currently assigned to the user attribute bucket with confidence <NUM>, the content platform can assign a membership measure of <NUM>, which is the sum of the three confidence values (i.e., <NUM> + <NUM> + <NUM>). Although a sum is used here, other aggregation techniques can be used such as an average or other measure of central tendency. Other techniques for updating membership measures can also be used, such as using a decaying average for the confidence indices.

The content platform can select (<NUM>) one or more digital components for distribution to the client device. The content platform can select the digital component(s) based on the user attribute buckets associated with each digital component, contextual data of the digital component request and/or the user attribute bucket(s) to which the user of the client device was assigned (e.g., based on the current digital component request). For example, the content platform can select one or more digital component(s) that are relevant to topics of the resource with which the digital component(s) may be displayed. In another example, the content platform can select one or more digital component(s) that are relevant to one or more user attribute buckets to which the user has been assigned, e.g., if the digital component is associated with an "<NUM>-<NUM>" user attribute bucket and the user has been assigned to that bucket. In a third example, the content platform can select multiple digital components that are relevant to topics, then filter out digital components not predicted to be of interest to the user attribute buckets assigned to the user and/or digital components that are configured to be excluded from consideration for one or more user attribute buckets. For example, if a digital component is associated with the "<NUM>-<NUM>" user attribute bucket, and the user is not assigned to that bucket, the content platform can filter the digital component from consideration. Filtering digital components that are likely to be irrelevant to a user before they are transmitted to the user's client device reduces the use of network bandwidth, and eliminates the processor resources that would have been used for the network transmission at both the content platform and at the client device.

To select the digital component(s), the content platform can use a machine learning model. For example, a machine learning model can be trained to output, for each of multiple digital components, a relevancy score that indicates a level of relevancy of the digital component to the environment indicated by the contextual data of the digital component request. The content platform can select a specified number of digital components (e.g., a number specified by the digital component request) based on the relevancy scores. The content platform can process an input that includes the contextual information using the machine learning model, and the model can produce an output that describes one or more selected digital components. In some implementations, the model used to determine user attribute buckets can be the same model that is used to determine digital components. For example, such a model can be a DNN configured to produce outputs that describe zero or more user attribute buckets and zero or more digital components. As described above, the content platform can then filter from the list of digital components selected by the machine learning model, digital components.

The content platform provides (<NUM>), to the client device, digital component response data, and the client device receives (<NUM>) the response data. The response data can be configured to initiate an update, based on each user attribute bucket to which the user is assigned, to aggregated user attribute data for the user stored at the client device. For example, the response data can include a request for an application running on the client device to update the aggregated user attribute data for the user. This aggregated user attribute data can be specified to the content platform. For example, user attribute data provided by multiple content platforms may not be combined.

The response data can also be configured to enable the application to select, from among multiple candidate digital components, a given digital component to display to the user based on the aggregated user attribute data. For example, an application running on the client device can be configured to select a digital component from multiple digital components provided by multiple content platforms.

The digital response data can include the digital components selected by the content platform, and in some implementations, providing the digital component(s) can include providing data identifying the digital component without providing the digital component itself. For example, the content platform can provide, for each digital component, a resource locator (e.g., Uniform Resource Locator (URL) or Uniform Resource Identifier (URI)) for a resource from which the client device can download the digital component. The digital response data can further include the user attribute buckets associated with each digital component.

The digital component response data can also include data indicating each user attribute bucket to which the user is assigned. In some implementations, the digital component response data includes an indication that a user was assigned to each of the one or more user attribute buckets. In some implementations, the digital component response data can include, for each user attribute bucket to which the user is assigned, a confidence score that indicates a confidence in a prediction that an actual user attribute of the user matches the particular value or value range corresponding to the user attribute bucket.

In addition, the digital component response data can include a filter logic module that includes executable instructions that are configured to produce a determination that indicates whether a digital component should be filtered from consideration. The client device can execute the filter logic in the filter logic module to determine whether to remove one or more digital components from consideration. In some implementations, the digital component response data can include a reference to (e.g., resource locator for) a filter logic module located on a separate computing system instead of, or in addition to, including the executable instructions. The client device <NUM> can provide anonymized data to the filter logic module on the separate computer system, which can execute the filter logic module and return the results. Providing a reference to a filter logic module can reduce the computing load on the client device. In another example, the client device <NUM> can download the filter module from a network location based ont eh reference.

The content platform can provide the digital component response data and/or the selected digital component(s) using any appropriate technique. For example, if the content platform received the digital component request as an HTTP or HTTP-S GET request, the content platform can provide an HTTP or HTTP-S response that includes the selected digital component and instruction data in the response body. The client device can receive (<NUM>) the digital component and instruction data using the corresponding receiving technique, such as receiving an HTTP or HTTP-S response.

The client device can update (<NUM>) the aggregate user attribute data. The client device can update, for each of the one or more user attribute buckets, a membership measure that indicates that the user has been added to the user attribute bucket. In some implementations, techniques such as counting instances of a user attribute bucket appearing or summing confidence scores can be used. In another example, the client platform can use a decaying approach where more recently received user attribute buckets indications (user group confidence indices or instance counts) are weighted more heavily. Decay can be, for example, linear or exponential.

As described above, in some implementations, the client device can maintain a vector for each DSP that indicates the number of times each user attribute bucket has been identified for a user and for that DSP. The client device can update that vector in response to receiving the digital component and instruction data. In some implementations, the vector can include user attribute bucket confidence indices that reflect the likelihood that the user of a client device should be added to a user attribute bucket. The client device can aggregate (e.g., determine the sum, average, or other measure of central tendency) the user group confidence indices received from the content platform to create an aggregate user group confidence index for each user attribute bucket.

In some implementations, the client device can receive from the content platform instructions for managing the aggregate user attribute data maintained for that content platform. For example, the content platform can deliver to the client device an indication that user attribute bucket data (e.g., counts, aggregate weights, etc.) should be reset (e.g., to zero) for that content platform. In response to receiving such instructions, the client device can manage the aggregate user attribute data according to the instruction (e.g., by resetting the counts for all user attribute buckets for the content platform to zero).

The client device can select (<NUM>) the digital component for display. The client device can include any received digital component in a digital component selection process, including digital components received in the digital component response data, digital components received in previously received digital component response data, and digital components received in other ways (e.g., loaded by the user of the client device). The client device can add the received digital component(s) to a collection of digital components received in response to the digital component request (per operation <NUM>) for use selecting a digital component. The client device can store the digital components in a digital component repository or in other appropriate storage systems. The collection can include digital components received in response to multiple digital component requests. For example, the collection can include digital components received over a defined time period, e.g., the last week, the last month, or another appropriate time period.

In some implementations, the client device can first filter from the selection process any digital components that do not correspond to the user attribute buckets. The client device can compare the user attribute buckets associated with each digital component, and remove from consideration any digital component that is associated with a user attribute that is not associated with the user. For example, if a digital component is associated with user attribute A and the user is not associated with the user attribute bucket for A, then the client device can remove the digital component from consideration. In another example, if the digital component is associated with a user attribute bucket that indicates that the digital component should not be shown to a user with a particular user attribute, the client device can filter the digital component from consideration. In some implementations, the client device can evaluate a filter logic module, as described above, and filter digital components based on the results.

In some implementations, the client device can enforce a magnitude of association between the user and the user attribute that is associated with a digital component. Returning to the example above, if a digital component is associated with user attribute A, and the value associated with the user attribute bucket for A is below a configured threshold, the client device can remove the digital component from consideration. In some implementations, the client device can filter from consideration all digital components except the N digital components where the user attribute bucket has the highest score. Such techniques can also be used in combination. For example, the system can filter from consideration all digital components for which the user attribute bucket has a score below a threshold, then further filter from consideration all but N digital components.

The client device can enforce more complex rules. For example, a rule might specify that a digital component should be filtered if none of the user attribute buckets for the user match any user attribute buckets associated with the digital component; that a digital component should be filtered unless all user attribute buckets match; that a digital component should be filtered unless a majority of user attribute buckets match; that a digital component should be filtered unless a configured number of user attribute buckets match; that a digital component should be preferred for display based on user attribute bucket data; and so on. In addition, as described above, the client device can execute filter logic provided by a DSP.

The client device can display (<NUM>) the selected digital component using various techniques. For example, the client device can insert the digital component in a digital component slot of content being displayed. In another example, the client device can display the digital component by rendering the digital component in a graphical user interface window, in a web browser, or in another application. In further examples, if the digital component includes video, the client device can render the digital component in a video player application, and if the digital component includes audio, the client device can render the digital component in an audio player application.

<FIG> is a block diagram of an example computer system <NUM> that can be used to perform operations described above. The system <NUM> includes a processor <NUM>, a memory <NUM>, a storage device <NUM>, and an input/output device <NUM>. Each of the components <NUM>, <NUM>, <NUM>, and <NUM> can be interconnected, for example, using a system bus <NUM>. The processor <NUM> is capable of processing instructions for execution within the system <NUM>. In one implementation, the processor <NUM> is a single-threaded processor. In another implementation, the processor <NUM> is a multi-threaded processor. The processor <NUM> is capable of processing instructions stored in the memory <NUM> or on the storage device <NUM>.

In one implementation, the input/output device <NUM> can include one or more of a network interface devices, e.g., an Ethernet card, a serial communication device, e.g., and RS-<NUM> port, and/or a wireless interface device, e.g., and <NUM> card. In another implementation, the input/output device can include driver devices configured to receive input data and send output data to other input/output devices, e.g., keyboard, printer and display devices <NUM>.

Embodiments of the subject matter and the functional operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described in this specification can be implemented using one or more modules of computer program instructions encoded on a computer-readable medium for execution by, or to control the operation of, data processing apparatus. The computer-readable medium can be a manufactured product, such as a hard drive in a computer system or an optical disc sold through retail channels, or an embedded system. The computer-readable medium can be acquired separately and later encoded with the one or more modules of computer program instructions, such as by delivery of the one or more modules of computer program instructions over a wired or wireless network. The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, or a combination of one or more of them.

The apparatus can include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, a runtime environment, or a combination of one or more of them. In addition, the apparatus can employ various different computing model infrastructures, such as web services, distributed computing and grid computing infrastructures.

A computer program (also known as a program, software, software application, script, or code) can be written in any suitable form of programming language, including compiled or interpreted languages, declarative or procedural languages, and it can be deployed in any suitable form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

Processors suitable for the execution of a computer program include, by way of example, special purpose microprocessors. Devices suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM (Erasable Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

To provide for interaction with a user, embodiments of the subject matter described in this specification can be implemented on a computing device capable of providing information to a user. The information can be provided to a user in any form of sensory format, including visual, auditory, tactile or a combination thereof. The computing device can be coupled to a display device, e.g., an LCD (liquid crystal display) display device, an OLED (organic light emitting diode) display device, another monitor, a head mounted display device, and the like, for displaying information to the user. The computing device can be coupled to an input device. The input device can include a touch screen, keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computing device. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any suitable form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any suitable form, including acoustic, speech, or tactile input.

Embodiments of the subject matter described in this specification can be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described is this specification, or any combination of one or more such back-end, middleware, or front-end components. The components of the system can be interconnected by any suitable form or medium of digital data communication, e.g., a communication network.

While this specification contains many implementation details, these should not be construed as limitations on the scope of what is being or may be claimed, but rather as descriptions of features specific to particular embodiments of the disclosed subject matter. Thus, unless explicitly stated otherwise, or unless the knowledge of one of ordinary skill in the art clearly indicates otherwise, any of the features of the embodiments described above can be combined with any of the other features of the embodiments described above.

In certain circumstances, multitasking and/or parallel processing may be advantageous.

Claim 1:
A computer-implemented method, comprising:
receiving (<NUM>), from a client device of a user and by a content platform, a digital component request that requests one or more digital components for display at the client device and that comprises contextual data related to an environment in which the digital component will be displayed;
assigning (<NUM>), by the content platform and based on the contextual data, the user to one or more user attribute buckets, wherein each of the one or more user attribute buckets is associated with at least one type of user attribute and corresponds to a particular value or value range for the type of user attribute;
selecting (<NUM>), based on the contextual data and each user attribute bucket to which the user is assigned, a plurality of candidate digital components for distribution to the client device; and
providing (<NUM>), by the content platform and to the client device, digital component response data that initiates an update, based on each user attribute bucket to which the user is assigned, to aggregated user attribute data for the user stored at the client device and wherein an application running on the client device is configured to select, from among the plurality of candidate digital components, a given digital component to display to the user based on the aggregated user attribute data.