GB2529486A

GB2529486A - Identifier mapping

Info

Publication number: GB2529486A
Application number: GB1415007.2A
Authority: GB
Inventors: Christopher Towl
Original assignee: Dunnhumby Ltd
Current assignee: Dunnhumby Ltd
Priority date: 2014-08-22
Filing date: 2014-08-22
Publication date: 2016-02-24
Also published as: GB201415007D0; WO2016027083A1

Abstract

Mapping a user identifier to a supply-side identifier to retrieve data identifying a user based on an identifier relating to a programmatic content delivery system. A client device (110) has an application (250), such as a web browser, to access content on a network, such as the Internet. The client device (110) interacts with a programmatic content delivery system (which may comprise a supply-side server (130), at least one demand-side server (140), and a content server (150)) to supply content to the application (250) based on a first identifier (such as a demand-side identifier and/or a supply-side identifier) derived from request data for the content request. The client device (110) also interacts with an association server (160). The association server (160) is arranged to receive an association request with data indicating an item and a second identifier, wherein the second identifier identifies the user in data accessible to the association server. A mapping engine (610) is used to map the first identifier to the second identifier in response to a request from one of the client device (110) and the programmatic content delivery system (130, 140, 150), wherein the programmatic content delivery system is arranged to embed one of the first identifier and the second identifier in content supplied to the application (250), and wherein the application (250) is arranged to use the content to initiate an association request to the association server (160). The programmatic content may comprise a portion (220) of a network accessible document (210), such as a web page, which may comprise an image (410) (which may comprise an advertisement) and an activatable element (420) (which may comprise a hyperlink for a URL pointing to the association server (160) or the mapping engine (610)). The identifiers may be cookies. The invention has application in real time bidding (RTB) programmatic marketing.

Description

IDENTIFIER MAPPING

Technical Field

The present invention relates to a mapping of data to enable a client device to make a request to associate one or more items over a computer network. In certain, but not all, embodiments the invention relates to a provision of adapted content that enables a client device to make a request to an association server on behalf of a user using the mapping.

Background

Nearly half the world's population has access to the interconnected network of computers commonly referred to as the Internet. Access to content, such as text, graphics, video and audio information, is possible from a variety of computing devices, including smart phones, tablets, laptops, desktops and so-called smart televisions.

The complexity of a request for content is often hidden from a user of such a computing device. For example, a smart phone application may appear to be operating locally but may in fact be assembling content from a variety of different network sources for presentation to the user. Likewise, a web-page may appear to be an atomic unit provided from a single network location to a user's desktop device; however, in reality the web-page may be constructed dynamically and involve communication with a number of different entities on the network. As more users access services provided over the Internet, there is an increased need for simplicity of interaction. This simplicity is often counterintuitively enabled by increased technical complexity that is transparent to the user.

For example, one challenge when implementing Internet systems is the stateless nature of the Hypertext Transfer Protocol (HTTP) that enables document access. Each request for content is an independent transaction that is unrelated to any previous request. While this has an advantage of simplicity, and flexibility on unreliable networks, it does mean that HTTP does not provide a means to store data between requests to maintain state. This has consequences for a user; there is no inbuilt mechanism within HTTP to store a user's activity between network locations and requests. This makes it difficult to supply services to a user, e.g. there is no simple way within HTTP of determining that a common user, via an application on a client device, is behind two successive requests.

To work around the stateless nature of HTTP most servers store a small amount of data (e.g. up to 41(B) on a client device, This data is commonly referred to as a "cookie", On receipt of a first FITTP request from an application such as a web-browser on the client device, a server typically sends an HTTP response with a "Set-Cookie" header that instructs the web-browser to store a string parameter of the form "name=value" in local storage on the client device, The next time the web-browser sends an HTTP request to the same server it adds a "Cookie" header comprising the parameter in the "name=value" form. The server can then use this data to determine state; in effect the use of "cookies" enable a stateful protocol to be constructed on top of stateless I-ITTP, As "cookies" are a work-around, they have certain limitations. Firstly, each "cookie" is limited to a particular domain. A web-server hosting "exampe.com" is only able to set "cookies" for "example.com" and the same web-server only receives "cookies" for requests to "example.com". While having security advantages, this does mean that state is limited to a particular domain. For example, "service.com" cannot access any state stored via "cookies" set by "example.com". This leads to a silo-like arrangement for the provision of network services making interaction between servers difficult, Secondly, "cookies" typically identify a combination of user, application and client device; if a user uses a different web-browser or client device a different set of "cookies" will be stored. This can lead to inaccurate identification and inconsistent state on the server and client device, Likewise, user activity such as activating a "Back" button in a web-browser can also lead to inconsistent state. Thirdly, as setting of a "cookie" is dependent on both application and client device, this can create problems for client devices other than a desktop computer, Additionally, different jurisdictions may set limits on "cookie" use; these may requiring technical adaptations, For example, a mobile device in Asia may store state in a different way to a desktop computer in France.

Certain technical solutions to work around the proNems discussed above include Intemet Protocol (IP) address tracking, making use of "GET" method parameters embedded in a uniform resource locator (URL), using hidden HyperText Markup Language (HTML) forms, using local Javascript or HTML storage and/or using other HTTP header parameters. Each has associated disadvantages.

As discussed above, it is desired to develop technical solutions that result in a simplified and feature-rich experience for a user accessing network-based applications and services while overcoming the limitations of the technical protocols and systems that provide the infrastructure for the network.

Summary

Aspects of the present invention are set out in the appended claims.

Further features and advantages of the invention will become apparent from the following description of certain examples, which are provided with reference to the accompanying drawings.

Brief Description of the Drawimzs

Figure is a schematic diagram of a system for supplying content to a client device according to an example; Figure 2 is a schematic diagram showing how content is supplied to the client device according to the example; Figure 3 is a sequence diagram showing a communication flow between one or more elements of the system of Figure 1; Figure 4A is a schematic diagram showing a portion of content that is supplied to the client device in a first example; Figure 4B is a schematic diagram showing a portion of content that is supplied to the client device in a second example; Figure 5 is a schematic diagram showing a graphical interface for an association server according to an example; Figure 6 is a schematic diagram showing a mapping engine communicatively-coupled to one or more components of the system of Figure 1 according to a first

example;

Figure 7 is a sequence diagram showing a communication flow between one or more elements of the system shown in Figure 6; Figure 8 is a schematic diagram showing a mapping engine communicatively-coupled to one or more components of the system of Figure 1 according to a second

example;

Figure 9 is a sequence diagram showing a communication flow between one or more elements of the system shown in Figure 8; Figure 10 is a flow diagram showing a method of supplying content to a client device according to an example; and Figure II is a schematic diagram showing an exemplary computer system for supplying content to a client device according to an example.

Detailed Description

Example System for Supply c'f Content Figure 1 is a schematic diagram of a system 100 for supplying content to a client device 110 according to an example. The example is provided for ease of explaining certain apparatus and methods and is not limiting; variations, exclusions and additions are possible. As the diagram is schematic certain simplifications and abstractions have been applied for ease of explanation; these would be understood by a person skilled in the art.

The system 100 comprises client device HO, a page sewer 120, a supply-side sewer 130, a plurality of demand-side sewers 140, a content sewer 150 and an association sewer 160. The client device 110 is communicatively-coupled to each of the page sewer t20, the supply-side server 130, the content server 150 and the association server 160. For example, the client device 110 may be communicatively-coupled via one or more networks, such as the collection of networks referred to as the Internet, The supply-side sewer 140 is communicatively-coupled to each of the three illustrated demand-side servers 140. There may be any number of demand-side sewers and one or more supply-side sewers 130. In certain cases that are not shown, an arbitration sewer may be communicatively-coupled between the supply-side and demand sewers. In certain cases, the content sewer 150 may form part of a content delivery network, e.g. a distributed system of sewers for supplying content, In Figure I, a first demand-side sewer 140-A is communicatively-coupled to the content sewer 150. Any of the other demand-side servers 140-B, C may be communicatively-coupled to the content server 150 or other content servers not shown in the Figure. In certain cases, the communicative-coupling described above may be by way of one or more intermediate devices, such as the described arbitration server and/or one or more servers S between the client device 110 and the supply-side server 130.

Although the components of system 100 have been shown as single discrete entities in Figure 1 for ease of explanation, in certain implementations the functional operations of such entities may be provided by a plurality of associated components.

For example, in a high-load case a plurality of computer devices may each implement a plurality of server applications that in-turn are each capable of handling HTTP requests on behalf of a domain. These server applications may represent duplications of functional computer program code that access common database and/or cache resources. Likewise, the content sewer may comprise one or more sewers arranged to supply content.

Certain components of the system 100 of Figure 1 may be referred to as a real-time bidding (RTB) or a programmatic content delivery system. For example, in Figure 1, the programmatic content delivery system may comprise one or more of: the supply-side server 130, at least one demand-side server 140 and a content server 150. The association server 160 is typically not within the programmatic content delivery system as it is not involved in the supply of content to the client device 10. The client device communicates with the programmatic content delivery system so as to conditionally supply content to the client device 110. The programmatic content delivery system enables particular content to be selected for supply to the client device 110. This content may be selected based on characteristics determined from a user operating an application on the client device; for example, a user of a web-browser or mobile application. The programmatic content delivery system may be dynamic, i.e. operate in real-time or near real-time (e.g. a second or millisecond time scale). The programmatic content delivery system allows one of a plurality of content sewers to supply content to the client device 110, wherein the supply of content by a particular content server may be subject to certain data conditions being met. For example, the supply-side server 130 may retrieve data indicative of certain anonymous characteristics of one or more of the user, the application and the client device 110 and this data maybe matched against data indicative of required characteristics that is stored on each demand-side server 140. In certain cases, data dependent on at least one of the application and the client, such as a "cookie", is supplied from the client device 110 to the programmatic content delivery network arid this data is used to select content for supp'y to the client device lift Example (?/SYcIem Operalion Figure 2 builds on Figure 1 to illustrate how content may be supplied to the client device 110 in the system 100 according to an example. A method of supplying content consistent with the example of Figure 2 is shown in Figure 3. Figure 3 is in the form of a sequence diagram. This shows an exemplary communication flow between the components shown in Figure] In Figure 2 a user of client device 110 accesses a network-accessible document 210 using an application 250. This is shown in block 305 of Figure 3. The application 250 maybe a web-browser andlor the network-accessible document 210 may be a web-page. In other examples, application 250 may be any application capaNe of making network requests, such as HTTP requests, and the network-accessible document 210 may comprise any content that can be supplied to the client device 110 over a network.

The user may access the network-accessible document 210 by entering or activating a URL, e.g. by typing "http://www.example.com" into a browser. The application 250 may then institute a HTTP "GET" request with parameters associated with the host "www.example.com". The request may be mapped by underlying protocols, such as Transmission Control Protocol / Internet Protocol (TCP/IP) to a function call on an HTTP server, which in this case is page server UO. Page server 120 then retrieves and/or generates network-accessible document 210 and provides its data as part of an HTTP response 230 back to application 250. The application 250 then renders the response data to display it to the user, e.g. renders the document 2] 0 in a web-browser window that is displayed upon a screen or monitor coupled to the client device 210. In certain cases, the network-accessible document 210 comprises an HTML document.

In Figure 2, network-accessible document 210 comprises a portion 220, shown as P' in the Figure. This portion 220 is not provided by page server 120. Instead, it comprises data that is processed by the application 250 such that the portion is retrieved from a further server communicatively-coupled to the client device 110. For example, this data may comprise a URL of the supply-side server 130 or other suitable intermediate device. The application 250 thus makes a further HTTP request from the client device 110. This is shown by the communication between blocks 305 and 310 in Figure 3. This request, or a derivative request generated based on this request, is then received by supply-side server 130. If the application 250 is communicating with the supply-side server 130 for the first time, a supply-side identifier is communicated to the application 250 from the supply-side sewer 130. This supply-side identifier may be stored as a "cookie" by the application 250 in a local storage device coupled to the client device 110. This "cookie" may be dependent on at least one of the application 250 and the client device 110, e.g. each browser on a tablet device may have a different associated supply-side identifier stored as a "cookie", For example, it may be set as a "cookie" with a form: "ssid=123ABC", e.g. stored as a string token comprising one or more characters, such as Unicode characters. In one example, a supply-side identifier may comprise an 18-digit numeric string. If the application 250 has communicated with the supply-side sewer 130 before, then the HTTP request may comprise the supply-side identifier, e.g. as header data of the form -"Cookie: ssidl23ABC". In the latter case, the supply-side identifier may be used to retrieve characteristics of a user from at least one database accessible to the supply-side server 130. For example, the string "1 23ABC" may be used as an index in at least one table of a database; wherein the table may store data such as location, age, browser-type, client-device, domain-history etc..

In one case, after the supply-side server 130 has received a request to supply the portion 220, this request being at least initiated by the application 250 -a so-called "initial request" -it publishes data that is at least dependent on one or more of the applicalion and the client device 110. For example, this may be data associated with the user of the client device 110 in the form of the supply-side identifier, This is shown as block 310 in Figure 3. Publication may be active and/or passive. In one case (e.g. an "active" or "push" case), the supply-side sewer 130 may communicate at least the data associated with the user to one or more of the plurality of demand-side servers 140, e.g. may have stored a network address or URL of each demand-side server and may make a HTTP or other application programming interface (API) request to those servers with the supply-side identifier as a URL parameter. In another case, (e.g. a "passive" or "poll" case) the supply-side server 130 may make at least the data associated with the user available as a network resource; one or more of the plurality of demand-side servers 140 are then able to access this resource. In the latter case, access of the data may require authenticating a demand-side server 140. As discussed, in one case, the data associated with the user comprises at least the aforementioned supply-side identifier. In certain cases, the data may also comprise data indicative of user characteristics. The data published by the supply-side server 130 may also comprise data indicative of characteristics of one or more of the network-accessible document 210, the application 250 and the client device 110, e.g. the URL, the domain, placement information for the portion, an age-range for the document, browser-type (e.g. user-agent parameters), type of client device (e.g. desktop, make of smartphone etc.), operating system of client device (and/or operating system version), additional applications installed on the client device 110 (and/or version numbers), time spent on the IJRL domain, time of day, number of page views at the domain in the current session, a category for the document, one or more OpenRTB parameters etc..

Following receipt of data published by the supply-side server 130, each appropriate demand-side server 140 processes this data. In one variation, a first level of filtering may be applied by the supply-side server 130, for example certain demand-side servers 140 may be selected for receipt of the data based on comparisons applied by the supply-side server 130 to data received from the application 250. In another variation, a demand-side server 140 may perform a similar first level of filtering and communicating with the supply-side server 130 if its filtering provides a positive result indicating that it is interested in the present request. This first level of filtering may or may not be implemented in any particular system.

In the present example, the first demand-side server 140-A receives data from the supply-side server t30 at block 315 of Figure 3. At block 325, the first demand-side server MO-A communicates with the supply-side server 130 to indicate, responsive to the data published by the supply-side server 130, that the demand-side server NO-A intends to allocate handling of the request for portion 220. Although not shown in Figure 3, one or more of the other demand-side servers 40-B, C may also communicate with the supply-side server 130 in a similar manner.

In one case, to indicate that it intends to allocate handling of the request, the first demand-side server 140-A first accesses data indexed by a demand-side identifier.

This data may comprise data indicative of one or more characteristics of the user and/or the user's device configuration, e.g. location, age, browser-type, client-device, domain-history etc.. These may be characteristics as described above in the context of the supply-side server HO. In certain cases, the supply-side server 130 only supplies the supply-side identifier and does not retrieve data indicative of user characteristics, leaving this to the demand-side servers 140. In other cases, the supply-side server 130 may publish certain data indicative of user characteristics that is complemented by data retrieved by each demand-side server 140. For example, the supply-side server 30 may only supply a coarse evel of location that may be refined and/or replaced by more fine-grained detail from databases accessible to each demand-side server 140. Either and/or a mixture of cases is possible. Data published by the supply-side server 130 may comprise, amongst others, one or more of data representative of a particular website; data representative of content to be supplied, data representative of user characteristics; data representative of geographic information; data representative of client device 110; and data representative of application 250.

In one case, returning to block 320 of Figure 3, the first demand-side server 140 extracts a supply-side identifier from the data published by the supply-side sewer 130.

For example, the supply-side sewer 130 may make an HTTP "GET" or "POST" request to each of a set of registered demand-side servers 140, wherein the request comprises "ssid=1 23ABC" as a parameter. Following extraction of the supply-side identifier this is then mapped to the demand-side identifier. For example, this may be achieved, amongst others, using a look-up table, key-value store or database.

The demand side identifier is then used by the first demand-side server 140-A to access data indicative of one or more characteristics of the user. In certain cases, the demand-side identifier may be omitted in favour of a look-up based directly on the supply-side identifier. Any accessed data is then compared against requests received by the demand-side server from third-parties who wish to supply content to the user, Each request received from third-parties may have data indicative of limits to be applied, e.g. a maximum cost to be paid to supply the content or a maximum number of times to supply the content. For example, a third-party request may comprise "supply content X to 30 unique users per day that live in San Diego at a maximum cost of 0.3 cost units", which in data terms may be stored as: "{ content': http://contentserver. com/X', user_no': 30', location': San Diego', cost': 0.3')". The data published by the supply-side server 130 may also comprise a cost as well as the supply-side identifier, which may be matched against the third-party request, e.g. "{ssid': I23ABC; cost': 0.2') -in this example the received supply-side cost is lower than the cost limit set as part of the demand-side third-party request.

The mapping between supply-side identifier and demand-side identifier may be constructed by a process known as "cookie-syncing", This may comprise the following process. If a demand-side server 140 receives a supply-side identifier that does not have a mapping to a demand-side identifier, a demand-side identifier is generated, e.g. of the form: "dsid=XYZ999", and mapped to the supply-side server, e.g. by saving the mapping in a look-up table. The demand-side identifier may also comprise a string token. In this case of no initial mapping, the demand-side server 140 is not selected to allocate the request for content but a reference to the demand-side server 140 is provided to the client device 110 by the supply-side server 130. For example, one of the other demand-side servers 140B, C may be selected to allocate handling of the request but references to each of the plurality of demand-side servers 140 involved in the selection process may be returned to the client device 110. In one case, the reference may be associated with one or more pixels of an image, e.g. an HTv1IL "<img>" (image) tag may be supplied to the application 250 in response to the request for content, wherein the "<img>" tag has a height and a width of one pixel and a source ("src") URL that comprises a path on a demand-side server. In this latter case, the application 250 makes a request to the URL of the demand-side server when rendering the "<img>" tag. The "<img>" tag may comprise a further portion of portion 220, i.e. the majority of the portion 220 comprises content supplied by way of another demand-side server.

The demand-side server then sends a "Set-Cookie: dsidXYZ999" header in response to the request. This stores the demand-side identifier as a "cookie" on the client device 110. As a user navigates the Internet the demand-side identifier may be further exchanged with the demand-side server to build up a state pattern for the user.

In one implementation, at block 320, a demand-side server 140 also returns a reference to content on an associated content server 150. This is supplied together with their indication to allocate handling of the request. For example, the reference may be a redirect URL.

Returning to Figure 3, at block 330 the first supply-side server 130 selects a demand-side server PlO to be used to allocate handling of the request for content from the client device 110. This may be determined by a matching operation or a heuristic.

For example, in Figure 2, each of the plurality of demand-side servers 140 may indicate that they wish to allocate handling of the request, e.g. due to a matching of third-party request data and demand-side user characteristics data. However, only a single demand-side server will be selected to allocate handling of the request in practice. In one case, together with an indication that they wish to allocate handling of the request, each demand-side server 140 may respond with data indicative of a price and the demand-side server that supplies the highest price is selected to allocate handling of the request.

In the example of Figures 2 and 3, the first demand-side server 140-A is selected. In block 335 of Figure 3, in response to this selection, a redirect UIRL supplied by the first demand-side server 140-A is communicated to the client device 110. This may be performed by the supply-side server 130 as shown in Figure 3, At block 345, the application 250 on the client device 110 interprets, and makes a request to, the redirect TJRL. In this example, the redirect LIRE references content server 150. Content server 150 receives this redirect request at block 350. In response content server 150 assembles content for supply to the client device 10 for rendering as portion 220. At block 355 the assembled content is then returned in a response to the client device 110, as shown by arrow 240 in Figure 2. At block 360 in Figure 3, the application 250 receives the response and renders portion 220 as part of network-accessible document 210. The complete network-accessible document 210 may thus now be displayed to a user on a screen or monitor of the client device 110 by application 250. This process may only take a few milliseconds in practice. In this sequence, content server 150 thus handles the request for the portion 220 of content, as allocated by the first demand-side server 140-A by way of selection by the supply-side server 130. In this case the selection of the first demand-side server 140-A by the supply-side server 130 is indicated by the supply of the redirect UIRL to the client device 110. In any case, this process represents the supply of content using a programmatic content delivery system.

The example described above represents one implementation; other implementations may provide a functionally equivalent process with different method blocks. For example, in other implementations, instead of sending a redirect URL to the client device at block 335, the supply-side server 130 may communicate again with the selected demand-side server 140. The selected demand-side server 140 may then communicate with the content server 150 to retrieve content to be returned to the client device. In certain case, this content may be supplied via the supply-side server 130 or supplied directly to the client device t to.

Example of Adapted Content and Pro vision According to certain methods and apparatus described herein, content that is provided to the client device by way of the RTB or programmatic content delivery system is adapted to allow state to be maintained across a plurality of disparate domains.

This adapted content may be configured for user interaction without intermpting navigation of other content, e.g. without redirecting a page viewed by way of the application on the client device, By interacting with the adapted content, a user is able to instruct a data association operation on a third-party server without additional authentication. The resultant process is thus simplified for the user. The data association is also able to be instructed without storing additional information on the client device and without additional client-to-server requests. The process is thus more secure and provides fewer opportunities for malicious manipulation.

According to an example, the content that is supplied to the client device comprises data identifying the user of the client device, e.g. either a first identifier or a second identifier, and data identifying at least one item associated with the content, The data identifying the user results from a function applied to the supply-side identifier for the user and it is used, either directly or indirectly, to index the user in data accessible to an association server. In response to this adapted content, the application of the client device is able to use the adapted content to generate a request for direct or indirect communication to the association server. This request generates data associating the user and one or more selected items at the association sewer.

Figures 4A and 4B are schematic diagrams 400, 450 showing two respective examples of a portion 220 of content that is supplied to the client device. In these simple cases, the portion 220 comprises an image 410 associated with an item. For example, amongst others, the item may be a product, service md/or event. This item may be an item related to the content, for example, amongst others, the content may promote, preview, publicise and/or advertise the item. In one case, the image 410 may comprise a picture and/or illustration of the item. In other cases, other indications of an item may be provided, such as a written description, a video and/or audio segment, or the item may be indirectly associated with the content, e.g. the item may be a product that appears in a particular frame of a video. In more complex examples, the content may be associated with a plurality of items, e.g. a plurality of images or list of items may form part of the content. One or more of these plurality of items may be selectable by the user via the application 250, e.g. by way of displayed checkboxes or other activatable elements.

In Figures 4A and 4B, the portion 220 also comprises an activatable element.

This activatable element may comprise a button or hyperlink element, In general, the activatable element is capable of being activated by a user through application 250; for example, by clicking with a mouse, touching a portion of a touchscreen or otherwise selecting the element. In Figure 4, a pointer 430 associated with an input device may be used to activate activatable element 420.

In the first example of Figure 4A, the activatable element 420 is associated with a reference to an association sewer. In this case, the reference is at least a portion of a URL 440 defined in an HTML anchor element ("<a></a>"). The reference comprises data identifying the user in the form of a user identifier -"a6eF29X" -that identifies the user of the application 250 to the association sewer. This user identifier may be a second identifier, wherein one or more of the supply-side and demand-side identifiers comprise a first identifier. For example, the user identifier may be a unique user identifier that is used to index a user record in one or more databases accessible to the association server. In the first example of Figure 4A, the user identifier differs from both the supply-side identifier and the demand-side identifier. The reference also includes data identifying the item indicated by image 410. In this case, the data identifying the item comprises a product identifier, which may be a unique product identifier for an inventory system accessible to the association server. In other examples, a plurality of product identifiers relating to selected items may be supplied.

In this case, the reference UIRL points to the association server -"www.as.com". This association server is association server 160 as illustrated in Figures 1 and 2. Finally, in Figure 4A, the reference also includes a path -"If' on the association server that indicates the location of a network-accessible frmnction interface configured to initiate a function on the association server. The function may be the function that generates the data associating the user and the item at the association server. The path may thus comprise an API for the association server, wherein one or more parameters supplied to the API follow the 1" in the TJRL and are identified by "name=value" pairs. Further parameters that are not shown in Figure 4A may also be provided, and other HTTP methods other than "GET" may also be used to access the function.

In certain cases the URL 440 shown in Figure 4A may be embedded as a parameter, e.g. a string, within one or more frirther IJRLs. For example, a first URL may direct a request to an intermediate server, where the UIRL 440 is extracted and used to initiate a further request. This may be the case, for example, where additional intermediate servers collect statistics relating to activation of the activatable element 420.

Figure 4B shows a second example that is a variation of the first example. In the second example, the activatable element 420 is associated with a reference to a mapping engine rather than the association server, In one case, the mapping engine acts as an intermediary device between the client device and the association server. As such in Figure 4B, the URL 445 defined in the HTIVIL anchor element ("<a><Ia>") points to the mapping engine -"www.me.com". In the example of Figure 4B, the URL 445 points to a path -"If' on the mapping engine that indicates the location of a network-accessible function interface configured to initiate a function on the mapping engine. In comparison with Figure 4A, the reference comprises data identifying the user in the form of a first identifier. In this case, the first identifier comprises a demand-side identifier; however, it may comprise a supply-side identifier in other examples, such as cases where a demand-side server uses the supply-side identifier as an index. In Figure 4B, the first identifier is the demand-side identifier "XYZ999" from the above-described example. The product identifier is the same as Figure 4A.

In the case of Figure 4B, the URL 445 is used to initiate a function on the mapping engine that maps the first identifier -"XYZ999" -to the second identifier of Figure 4B -"a6eF29X". In one case, following the mapping, the mapping engine initiates a request in relation to the association server in a similar manner to the case of Figure 4A, This is described in more detail with reference to Figures 8 and 9 below.

First Example ojMapping Engine Adapted content, for example as described above with reference to Figures 2, 3, 4A and 4B, may be assembled by one or more of the first demand-side server NO-A at block 320 and the content server 150 at block 355. In one case the data identifying the item is associated with the content for the portion 220; for example, a product identifier may be embedded within an HTML document representative of the portion 220. As such a matching process at the first demand-side server 140-A to identify content that matches data published by the supply-side server 130 may also identify an accompanying product identifier. If the content is represented as a IJRL reference at the first demand-side server 140-A, e.g. a redirect URL for the content, then that URL reference may identify an HTML document representative of the portion 220 hosted by the content server 150, this document containing the embedded product identifier. In certain cases, such as the case of Figure 4A, the content for the portion 220 may also include a reference to the association server 160 and a reference to the network accessible function on said server, e.g. the path as shown in Figure 4A. In this example, data identifying the user may be inserted into the content, for example via a string substitution for the HTML document, A first method for retrieving the data identifying the user based originally on the supply-side identifier is described below with reference to Figure 6 and 7.

Figure 6 shows an adapted system 600 that is based on the system 100 of Figure 1. In this system 600, one or more of the demand-side server 140-A and the content server 150 are communicatively-coupled to a mapping engine 610. The mapping engine is, according to a first example, configured to retrieve the data identifying the user for inclusion within the content supplied to the client device.

In a first case, the demand-side server 140-A is communicatively-coupled to the mapping engine 610. At block 720 in Figure 7, the demaM-side server 140 receives a supply-side identifier. This is mapped to a demand-side identifier by the demand-side server 140. In certain cases, there may be no mapping, in which case the demand-side identifier may comprise the supply-side identifier. In any case, a first identifier, such as the demand-side identifier, is sent to the mapping engine with a request to map this first identifier to the data identifying the user, i.e. a second identifier such as the user identifier shown in Figure 4A. At block 730, the mapping engine 610 receives the request and the first identifier, In response, the mapping engine 610 accesses, at block 740, a look up table 710 to map the first identifier to the second identifier. As described previously, in certain cases, a key-value store or database may alternatively be used to implement the mapping. Having retrieved the data identifying the user at block 750, this is returned by the mapping engine 6 tO at block 760 to the demand-side server 140.

At block 770, the demand-side server may then provide the data identifying the user as a URL parameter in the redirect IJRL for the content server 150. In this case, the content server 150 may extract the data identifying the user from the redirect URL parameters and insert it into the content identified by the redirect URL, In a second case, the content sewer 150 is communicatively-coupled to the mapping engine 610. At block 720 in Figure 7, the content server 150 receives one or more of a supply-side identifier and a demand-side identifier, i.e. a first identifier. For example, these may be received as parameters that form part of a redirect request.

Alternatively, in some cases, the demand-side server 140 may communicate with the content sewer 150 to pass these parameters. In certain cases, only a demand-side identifier may be passed, wherein this may also comprise the supply-side identifier, The first identifier is then sent to the mapping engine with a request to map this identifier to the data identifying the user, i.e. a second identifier. At block 730, the mapping engine 610 receives the request and the first identifier. As above, in response the mapping engine 610 accesses, at block 740, a look up table 710 to map the first identifier to the data identifying the user. Having retrieved the data identifying the user at block 750, this is returned by the mapping engine 610 at block 760 to the content sewer 150, At block 770, the content server 150 inserts the received data identifying the user into the content to return to the client device.

Second Example of Mapping Engine A second example 800 of a mapping engine 810 is shown in Figure 8. The mapping engine 810 of the second example may be used as an alternative to the mapping engine 610 shown in Figure 6. In certain cases, a combination of the two examples may be applied.

In the case of Figure 8, the client device 110 is communicatively-coupled to the mapping engine 810. The mapping engine 810 is then communicatively-coupled to the association server 160. As set out previously, the communicative couplings between these components may be indirect, e.g. one or more intermediate network devices may be located between the illustrated components.

Before the process of Figure 9 begins, the application of the client device 110 receives adapted content similar to that illustrated in Figure 4B. In this case, the content comprises a first identifier in the form of one or more of the supply-side identifier and the demand-side identifier. At block 920 of Figure 9, an activatable element of the content is activated. For example, the user may click on a button such as 420. This initiates a request based on data embedded in the content, such as the URL 445 shown in Figure 4B, At block 930 this request is received by the mapping engine 810. In response, the mapping engine 810 extracts the first identifier and accesses, at block 940, a look-up table 910 to map the first identifier to the second identifier, e.g. to an identifier that is used to index data on the association server. Having retrieved the second identifier at block 950, this is returned to the mapping engine at block 960. In the example of Figure 9, the mapping engine uses the second identifier to make a request to the association server 160 at block 970. This request may be direct or indirect, In a direct case, the request may resemble a request defined by the URL 440 in Figure 4A.

The mapping engine 810 may be arranged to generate the request to the association server 160 using the second identifier and data indicative of at least one item from the one or more items selected by way of the application. At block 980, the association server 160 receives the request and uses the second identifier and data indicative of at least one item to instruct generation of association data associating a user of the application and the one or more s&ected items.

In a variation of the process of Figure 9, the mapping engine 810 may return request parameters to the client device 110 at block 970, wherein the client device 110 is able to make the request received at block 980 using the received request parameters.

Example (?/Identcfier Mapping An example of how look-up table 710 or 910, or an equivalent data structure or function, may be constructed will now be described. In one case, a data set comprising a list of demand-side identifiers and associated user characteristics are retrieved. For each demand-side identifier the associated user characteristics are matched against a data set of user records used by the association server 160. This may comprise a probabilistic match. For example data fields such as location and age may be probabilistically matched, e.g. if age range in one data set is 3 5-45 and age is recorded as 37 in the second data set then there is match on that fields. If a certain number and/or set of data fields match then the demand identifier and the data identifying the user may be associated in the look-up table 710. In certain cases, a probabilistic mismatch may be used to prevent the mapping between a first identifier and a second identifier; for example, if a mapping is accessed but user characteristics do not probabilistically match a range of user characteristics associated with one or more of the first and second identifiers, a mapping may be denied and an error returned. This may be used to increase security, for examp'e, a mapping may be denied if probabilistic device and/or access profiles associated with one of the identifiers do not match user characteristics associated with a current session.

In another example, a variation of the previous'y described "cookie syncing" may be employed. For example, the association server 160 may include a one-pixel image tag within network accessible documents provided by the association server.

When a user accesses these documents, e.g. visits a particular web-page on the association server 160 and authenticates themselves using application 250, data identifying the user may be sent to the demand-side server as part of a call-back URL.

If a demand-side identifier exists this will also be sent to the demand-side server as a "cookie" header. The demand-side identifier and the data identilying the user can then be mapped. The process could also be performed with the roles ofthe association server and the demand-side server reversed.

In yet another example, a third identifier may be used to constmct a mapping between the first and second identifier. For example, each of the first identifier and the second identifier may be associated with a third identifier. The third identifier may then be used to make the association. This may be performed by a third party, for example a data management platform. The third identifier may comprise a manufacturer identifier such as one associated with a tablet or smartphone. This may be changeable by a user.

A third identifier may also be published as a portion of an HTTvIIL document, e.g. hidden from a user but machine readable. As such it can be associated with both the first and second identifier and used to construct a mapping.

Example a/Accessing the Association Server In each of the cases above, following supply of adapted content, a request is initiated by the application 250 by way of the content. For example, turning to Figure 3, a user activates activatable element 420 of Figures 4A and 4B at block 365. This results in a request being received at the association server 160. This communication may be either direct, e.g. from the client device 110 to the association server 160 based on the example of Figures 4A, 6 and 7, or indirect based on an intermediate mapping as described with reference to Figures 4B, S and 9, In both cases, a request is received at the association server with data comprising a second identifier and data indicating one or more selected items. On receipt at the association server 160, the request instructs the generation of data associating the user, by way of the second identifier, and data identifying one or more selected items. For example, this may comprise the generation of a database record comprising a user identifier and a product identifier. As described above, such a second identifier in the form of a user identifier may be used by the association server 160 to index accessible data, for example it may comprise a database or object key in a database or datastore accessible to the association server 160.

Data associating the data identifying the user and the data identifying the item associated with the content may be used in a number of ways. For example: - * The item may comprise an audio and/or video file, wherein the association is representative of adding the file to a playlist managed by the user.

* The item may comprise a product or service to be purchased, wherein the association is representative of adding the product or service to an online "shopping basket", a data structure storing items for later purchase.

* The item may comprise an event the user wishes to attend, wherein the association is representative of adding the event to a calendar or the like.

* The item may comprise an activity to do, wherein the association is representative of adding the activity to a todo list.

* The item may comprise another network-accessible document, such as an article, web-page or book, wherein the TJRL of that document is added to a "favourites" list for the user.

* The item may comprise an application, wherein the application is added to a "download" list for the user.

In one case, activating the activatable element 420 instructs a request that does not redirect the application 250 from the current content. For example, if the user is viewing main document 210 as shown in Figure 2, clicking on the activatable element 420 does not redirect the application 250 from the main document 210, such that the main document 210 continues to be rendered on a screen or monitor of the client device 110. This may be achieved by configuring the request initiated by the activatable element 420 as an Asynchronous JavaScript and eXtended Markup Language (AJAX) request; for example an XI\'ILHttpRequest may be used. Data returned by this request following successful association at the association server 160 may be used to update the portion 220 and display feedback for the activation to the user, e.g. update a counter or display a "success" message or image.

Example of View big Data at the Association Server S Figure S is an example 500 of a network-accessible document 510 returned by the association server 160 to the client device 110. For example, it may illustrate the result of a user directing the application 250 to the domain of the association server 160.

This may occur at an arbitrary point in time following activation of the activatable element, e.g. it could occur on a following day or week. In certain cases, before the network-accessible document 510 shown in FigureS is displayed to a user, the user has to authenticate themselves to the association server 160, e.g. by supplying a username and password to "log in", This additional secure sign-in process may be required to prevent accidental, fraudulent, or malicious usage of the described features, e.g. a malicious party fraudulently using data identifying the user to associate the user with unwanted items. In general, the data shown in Figure 5 may comprise data accessible to the association server 160, which is only viewable by a user following an authentication procedure. Without the authentication procedure the user is anonymous to the association server 160.

The network-accessible document 510 of Figure 5 comprises a list 520 of items that have been associated with the data identifying the user, This list 520 may be rendered using the data generated by the association server 160 at block 370 and/or block 980. As can be seen in Figure 5, following activation of activatable element 420 and block 370/980, item 410 is now in the list 520 belonging to the user, For example, this list may comprise a playlist, shopping list or basket, favourites list, read-later list etc.. In certain cases, the list 520 may be actionable. In Figure 5, an action button 540 is provided for the list, If the list is a playlist, the action may be to play the media items in the list; if the list is a shopping basket, the action may be to "checkout" the items and complete an c-commerce operation to pay for the items and arange delivery. In the former case, the association server 160 may be administered by a media provider; in the latter case, the association server 160 nay be administered by a retailer. In any case, as described above, purchasing items or actioning changes via this action burton may require an additional secure sign-in process to authenticate the user. The list 520 may be the result of navigation of a plurality of network-accessible documents 20 hosted at different domains and/or paths over a period of time. In certain cases, items that have been added to the list 520 by the described methods may be temporarily quarantined before being added to a primary list. For example, the action button 540 may add the items to a primary list or items may be flagged to a user by using a particular set of formatting. This provides the user with the option to remove an item from their list should they so wish.

Figure 10 shows a flow chart that summarises certain processes described herein. The method of Figure 10 may be computer-implemented. There is a first block 1010 of receiving a first identifier, The first identifier is derived from request data received from an application of a client device, such as application 250 on client device 110. The request data is associated with a request for content to be supplied to the application by a programmatic content delivery system. It is dependent on at least the application. The first identifier may be received from a demand-side server or a client device. The request may comprise an 1-ITTP request. The first identifier may be received by a mapping engine 610 or 810.

Returning to Figure 10, there is a second block 1020 of mapping the first identifier to a second identifier. The second identifier is used in data accessible to an association sewer, The data accessible to the association sewer is only accessible to the application following an authentication procedure such as a log-in procedure. The mapping may comprise applying a function to data characterising the user from the supply-side server, e,g, may result from a mapping from a supply-side identifier to a demand-side identifier to an association server identifier. The second identifier may be used to index the user in data accessible to the association server, e.g. in a local database or datastore, The application of the client device is able to use the content to instruct the association sewer to generate data associating the user and one or more items, e,g, it may add the item to a list belonging to the user. Any list may be later actionable by the user by communicating with the association server; for example, the association sewer may host a web-site that the user accesses by way of the application on the client device, fin Figure is a schematic diagram 1100 of a server device 1110 according to an example. This server device 1110 may implement one or more components as shown in Figures 1, 6 and 8 including mapping engine 610 or 810. The server device 1110 comprises at least one processor 1120, a network interface 1130 and a computer-readable storage medium 1140. The computer-readable storage medium may comprise a storage medium, such as a solid-state drive (SSD) or other semiconductor-based RAM; a ROM, for example a CD ROM or a semiconductor ROM; a magnetic recording medium, for example a floppy disk or hard disk; optical memory devices in general; etc.. The storage medium 1140 may store computer programs adapted for putting the described examples into practice. The program may be in the form of non-transitory source code, object code, a code intermediate source and object code such as in partially compiled form, or in any other non-transitory form suitable for use in the implementation of processes and/or components described herein. In the example of Figure lithe computer-readable storage medium comprises a first module arranged to implement a mapping component 1150 and look-up data 1160. In other examples, look-up data 1160 may be remotely accessible. The mapping component 1150 may implement the method of Figure 10.

Certain methods, apparatus and systems, as described herein, provide a technical mechanism that enables a user to associate items th a user account without disrupting navigation of the World Wide Web. This mechanism adapts existing technical infrastructure such that additional user authentication is not required; for example, a user need not log-in to the association server before activating the activatable element in the content, Hence, a user may simply start using application 250 to navigate network-accessible documents and interact with the content portion 220.

The presently described mechanism leverages existing RTB or programmatic content delivery technology. This technology has a wide coverage -it is estimated over 90% of Internet users in at least the United States have at least one supply-side identifier stored on their client device(s). In most cases the user is unaware of this. By mapping this supply-side identifier to data identifying a user as used by a third-party server such as the association server 160, state representing the presence of a particular user can be stored even though a stateless protocol is used that limits local data storage to a particular domain (i.e. a particular party). No further data needs to be stored on the client device, e.g. no data in addition to that which is typically already stored on the client device, increasing simplicity and security. In effect, a single identifier is correlated across a plurality of computer devices within the system to implement cross-platform state. By manipulating the content portion 220 and its assembly, modifications to existing infrastructure may be minimised, increasing ease of technical implementation. As is shown in the described examples, the adaptations can be made within existing RTB or programmatic content delivery process flows, meaning that additional client-to-server calls are minimised from the client device 110, e.g. beyond those traditionally used in the delivery of a content portion.

Examples of the presently described mechanism enable responses to a content portion, e.g. via a click, to facilitate changes to a user's account, When the user next visits a website associated with the account, the requisite change has been made. In effect the content portion, and/or any message within said portion, is instantly actionable. For example, in a retailer implementation, an item offered for sale in the content portion at a particular offer price may be added to a user's shopping basket at that offer price following a click on the content portion. In this case, users can make purchases online quickly and easily through the content portion -so-called "click-to-basket" functionality, As such, certain examples described herein overcome a problem of access and use of association server state, One advantage of mapping from a supply-side identifier to a demand-side identifier to an association user identifier is that multiple profiles for a common user may all be transparently mapped onto a common user account accessible to the association server, For example, a user may have one supply-side identifier for browsing on a smart phone, another for browsing on a home desktop device and a third for accessing services on a work laptop device, Each of these supply-side identifiers may be mapped to a common user identifier for the association server. A similar situation may apply for demand-side identifiers. In this case the multiple mappings in effect correlate disparate user state resulting from the limitations of the infrastmcture of the Internet.

The presently described examples are surprising as the prevailing model in the art is to use content portions as passive display components. The user is simply expected to view (or listen to for audio/video) these components and at most click the component to be transported to a different domain. At the different domain the user may then view more detail about the item. This is suitable for high-cost items such as cars and items available via several different domains, In this comparative case, an aim is to influence S the user rather than allow them to perform an action. Hence, there is no motivation to provide actionable content.

In comparison with other technologies, the presently described mechanisms have certain advantages. One comparable technology provides a content portion with JavaScript elements. When placed on a web-page, a user can click on the content portion. However, this technology requires a user to first authenticate themselves to a third party server before the content is actionable. Hence, when a user clicks on the content portion they are presented with a log-in page. Once logged in the third-party sewer needs to store a "cookie" on the user's computer to store state representative of the user. If the user clicks on the content portion after logging in, the third-party sewer receives a command to add an item to a shopping basket together with a user identifier as a "cookie" header in the request. The third-party sewer then retrieves user information based on the stored "cookie" data and uses this to make a call to a retailer to add the item to a shopping basket implemented by a retailer server (e.g. an association server), It is clear that this comparative technology requires additional authentication and intermediate third-party sewers to add an item displayed in a content portion to a shopping basket -the use of these components are avoided and/or minimised when using certain examples described herein.

In comparison with other technologies, certain examples described herein also have an advantage of a better user-machine interaction, For example, in comparative cases a user may need to authenticate themselves each time they wish to associate an item, This may be cumbersome for the user and represents an inefficient use of a client device, Moreover, multiple authentication sessions increase a security risk. If a user is required to enter a username and password every time an association is required then sensitive data is repeatedly transmitted over networks and the risk of interception, either on the client device or over the network is increased. In comparison, examples as described herein may not require additional and/or repeated authentication, e.g. this may only be performed when accessing associated data. As such, certain examples described herein reduce a security risk.

The above examples are to be understood as illustrative. In certain contexts a content portion is sometimes referred to as a banner, a creative, a rectangle or a page portion. Further examples are envisaged. For example, there may be at least the following variations. A demand-side server and at east a content server may be combined in a single server architecture. In this case, this single server may return the content to the supply-side server as part of a response to published data from the supply-side server, e.g. as well as or instead of a redirect URL. Multip'e servers may provide one function and/or domain. Data identifying the user may also include data identifying a particular class or category associated with the user, e.g. a particular list for association, Data identifying a user need not be a user identifier but can take the form of any data that can be used to identify a user on an association server. The term "user" may include other categorisations associated with a user, such as a household. Where "data indicative of one or more characteristics of the user" has been described it should be understood that these may be any characteristics associated with the user. For example, they may comprise characteristics of one or more of the application and the client device that are taken to be representative of a particular user and/or they may comprise recorded characteristics that are derived from historic data indexed by the aforementioned characteristics, In one case, data representative of characteristics of a user may comprise metrics derived from measured use of one or more of the application and the client device and/or recorded data associated with the user that is correlated with an identifier, Although certain examples have been described where a "cookie" is used by a supply-side server to identify one or more of a user, application and client device, other techniques may alternatively be used, For example, data sent together with a request from an application, such as HTTP headers and/or information on the configuration of one or more of the application and the client device, may be used to characterise a user, application and/or client device. For example, a particular combination of IP address and HTTP headers may be mapped to a particular supply-side identifier at the supply-side server, Likewise, similar techniques may be applied by a demand-side server as well as or instead of the use of a "cookie" to store a demand-side identifier.

In one case, a demand-side server may communicate with a supply-side sewer a plurality of times to indicate that the demand-side server intends to allocate handling of the request. For example, if the supply-side sewer indicates that it intends to allocate handling of the request to another demand-side server, a demand-side sewer may generate and respond with revised data, It is to be understood that any feature described in relation to any one example may be used alone, or in combination with other features described, and may also be used in combination with one or more features of any other of the examples, or any combination of any other of the examples. In each of the Figures and accompanying description certain features may be omitted, added or modified while still providing equivalent overall functionality as described. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the invention, which is defined in the accompanying claims.

Claims

Claims 1. A system comprising: a client device comprising an application accessed by a user, the client device being communicatively-coupled to a network and the application being arranged to access content on the network; a programmatic content delivery system communicatively-coupled to the client device and aranged to supply content in response to a content request from the application over the network, the programmatic content delivery system being arranged to select content for supply to the application based on a first identifier derived from request data for the content request; an association server communicatively-coupled to the client device and arranged to receive an association request comprising data indicative of at least one item and a second identifier, the second identifier identifying the user in data accessible to the association server, the association server being arranged to generate data associating the user and the at least one item in response to the association request; and a mapping engine arranged to map the first identifier to the second identifier in response to a request from one of the client device and the programmatic content delivery system, wherein the programmatic content delivery system is arranged to embed one of the first identifier and the second identifier in content supplied to the application, and wherein the application is arranged to use the content to initiate an association request to the association server.
2. The system of claim 1, wherein the programmatic content delivery system comprises: a supply-side server communicatively-coupled to the client device and arranged to receive, from the application over the network, a request for content and to, in response, publish data that is at least dependent on one or more of the application and the client device; a demmd-side server communicatively-coupled to the supply-side server and arranged to receive the data published by the supply-side server, the demand-side sewer being further arranged to process the data published by the supply-side server and in response conditionally indicate that the demand-side server intends to allocate handling of the request; and a content server communicatively-coupled to the demand-side server and the client device, the content server arranged to supply content to the client device in response to an indication from the demand-side server, the indication being sent by the demand-side server in response to the demand-side server being selected by the supply-side server to allocate handling of the request, the content server being arranged to supply content comprising data indicative of at least one item associated with the content and one of the first identifier and the second identifier.
3, The system of claim I or claim 2, wherein: the association server comprises a network-accessible function interface configured to initiate a function to generate the data associating the user and the item; and the content comprises at least data indicative of a uniform resource identifier that identifies the network-accessible function interface of the association server, the uniform resource identifier having associated parameters representative of one or more of the first identifier aiid the second identifier and the data indicative of at least one item.
4. The system of claim 2, wherein: the first identifier comprises a demand-side identifier derived from the data published by the supply-side server.
5. The system of any of claims ito 4, wherein: the mapping engine uses a look-up table to correlate the first identifier and the second identifier.
6. A computer-implemented method comprising: receiving a first identifier, the first identifier being derived from request data received from an application of a client device, the request data being associated with a request for content to be supplied to the application by a programmatic content delivery system and being dependent on at least the application; and mapping the first identifier to a second identifier, the second identifier being used in data accessible to an association server, the data accessible to the association server being accessible to the application following an authentication procedure, wherein one of the first identifier and the second identifier is embedded in content supplied to the application by the programmatic content delivery system in response to the request for content, the content being conditionally supplied by the programmatic content delivery system using at least the first identifier, the content comprising data indicative of one or more items associated with the content, and wherein the second identifier and data indicative of at least one item selected from the one or more items by way of the application are received by the association sewer and are used to instruct generation of association data associating a user of the application and the one or more selected items.
7. The computer-implemented method of claim 6, wherein the programmatic content delivery system comprises at least a supply-side server and a demand-side sewer, wherein the request for content is received by the supply-side server and the supply of content is arranged by the demand-side sewer in response to the demand-side sewer being selected by the supply-side server to allocate handling of the request, wherein the first identifier comprises at least one of a supply-side identifier used by the supply-side server and a demand-side identifier used by the demand-side server.
8. The computer-implemented method of claim 6 or claim 7, wherein the second identifier comprises an index in a database accessible to the association server.
9. The computer-implemented method of any of claims 6 to 8, wherein the content comprises at least a uniform resource identifier containing one of the first identifier and the second identifier and the data indicative of one or more items.
10, The computer-implemented method of claim 9, wherein the uniform resource identifier identifies a network-accessible function interface configured to perform the mapping of the first identifier to a second identifier.
1] The computer-implemented method of claim 9, wherein the uniform resource identifier identifies a network-accessible function interface configured to instruct generation of the association data.
12. The computer-implemented method of claim 6 to 11, wherein the request for content is initiated when the user accesses a network-accessible document using the application, the network-accessible document comprising a first portion supplied by a document server and a second portion associated with a request to the programmatic content delivery system.
13. The computer-implemented method of claim 7, wherein the supply-side server instmcts storage of the supply-side identifier on the client device when the application first communicates with the supply-side server, the supply-side identifier being communicated to the supply-side server by the application as the request data when the application subsequently communicates with the supply-side server.
14. The computer-implemented method of claim 7, wherein the first identifier comprises the demand-side identifier and wherein the supply-side server provides data that is used to identify the demand-side server to the application in a case where the demand-side server has not been selected to conditionally supply content with respect to a previous request, said data comprising the supply-side identifier as a parameter, and said data initiating communication between the application and the demand-side server, the demand-side server extracting the supply-side identifier from the communication for use in mapping the supply-side identifier to the demand-side identifier.
15. The computer-implemented method of any one of claims 6 to 14, wherein the content comprises at least a portion of a network-accessible document to be displayed by the application of the client device.
16. The computer-implemented method of claim 12, wherein the programmatic content delivery system uses the first identifier to determine data indicative of one or more characteristics of a user accessing the application, wherein the programmatic content delivery system determines a portion of a network-accessible document for supply as content based on the data indicative of one or more characteristics of the user, the portion of the network-accessible document comprising media data identifying the one or more items for presentation to the user and one or more respective item identifiers that are used to index the one or more items in data accessible to the association server, wherein one of the first identifier and the second identifier is inserted into the portion of the network-accessible document and the portion of the network accessible document is sent to the client device as the content for presentation to the user via the application.
17. The computer-implemented method of any one of claims 6 to 16, wherein an item from the one or more items comprises: an audio and/or video file, wherein the data associating the user and the item is representative of adding the file to a playlist managed by the user; a product or service, wherein the data associating the user and the item is representative of adding the product or service to a data structure storing items for later purchase; an event, wherein the data associating the user and the item is representative of adding the event to a calendar; and an activity, wherein the data associating the user and the item is representative of adding the activity to a todo list. fin 3 3
18, A computer program arranged to implement the method of any one of claims 6 to 17.
19. A mapping engine comprising: an interface arranged to receive a first identifier, the first identifier being derived from request data received from an application of a client device, the request data being associated with a request for content to be supplied to the application by a programmatic content delivery system and being dependent on at least the application; and a mapping component arranged to map the first identifier to a second identifier, the second identifier being used in data accessible to an association server, the data accessible to the association server being accessible to the application following an authentication procedure, wherein one of the first identifier and the second identifier is embedded in content supplied to the application by the programmatic content delivery system in response to the request for content, the content being conditionally supplied by the programmatic content delivery system using at least the first identifier, the content comprising data indicative of one or more items associated with the content, and wherein the second identifier and data indicative of at least one item from the one or more items selected by way of the application are received by the association server and are used to instruct generation of association data associating a user of the application and the one or more selected items.
20. The mapping engine of claim t9, wherein the mapping engine is communicatively-coupled to the client device, and wherein the interface is arranged to receive the first identifier and the data indicative of at least one item as part of a request initiated by way ofthe content supplied to the application by the programmatic content delivery system.
21. The mapping engine of claim 19 or claim 20, wherein the mapping engine is communicatively-coupled to the association server and wherein the mapping engine further comprises: a request generator arranged to generate an association request for communication to the association server, the association request comprising the second identifier and the data indicative of at least one item.
22. The mapping engine of claim 9, wherein the mapping engine is communicative'y-coupled to the programmatic content delivery system, wherein the interface is arranged to receive the first identifier from the programmatic content delivery system and the mapping engine is arranged to respond with the second identifier, wherein the content supplied to the client device by the programmatic content delivery system further comprises the second identifier, and wherein the content is arranged to initiate a request from the application of the client device comprising the second identifier and the data indicative of at least one item.
23. The mapping engine of any of claims 19 to 22, wherein the programmatic content delivery system comprises one or more of a supply-side server, a demand-side server and a content server.
24. A content-provision server comprising: a network interface to receive a request for content to supp'y to an application on a client device, the content-provision server forming part of a network comprising the client device, a supply-side sewer, a demand-side sewer and an association server, the supply-side server being communicatively-coupled to the client device and being arranged to receive an initial request for content to supply to the application and to select a server to allocate handling of the request, the demand-side server being communicatively-coupled to the supply-side server and arranged to receive data associated with the user published by the supply-side server, the data comprising a supply-side identifier for the user used by the supply-side sewer, the demand-side server being further arranged to process the data published by the supply-side server and in response conditionally indicate that the demand-side sewer intends to allocate handling of the request, and the demand-side server being further arranged to select content for supply to the application based on data indicative of one or more characteristics of the user, said data being determined based on the supply-side identifier, said content comprising an item identifier that identifies an item associated with the content in relation to data accessed by the association server; and a content assembler to retrieve a user identifier used by the association sewer that maps onto the supply-side identifier and to insert the user identifier into the content for supply to the application, wherein the application of the client device is able to use the content to make a request to the association server using the user identifier and the item identifier, the request generating data associating the user and the item at the association server.