JP7474294B2 - How to link online behavior to offline payment transactions - Google Patents

Description

The present disclosure relates to tracking consumer behavior, and more particularly, to correlating consumers' online behavior with their offline payment transactions.

Various methods are known for tracking a consumer's online behavior (e.g., exposure to online advertising activities, online payment transactions, etc.). Various methods are also known for tracking a consumer's offline payment transactions.

The consumer intelligence that can be obtained from separately tracking a given consumer's online behavior and that consumer's offline payment transactions is limited.

Therefore, there is a need for improved tracking methods, systems, and devices, or at least alternatives.

In one aspect, a computer-implemented method for associating a consumer's online behavior with an offline payment transaction is provided. The method includes, in at least one processor, generating a first mapping between a consumer identifier and a consumer's payment card identifier, generating a second mapping between the consumer identifier and a consumer's online behavior identifier associated with visiting a web page, receiving data reflecting an offline payment transaction, the data including the payment card identifier, and identifying an association between the online behavior and the offline transaction by processing the generated first mapping, the generated second mapping, and the received data.

In another aspect, a computer system is provided for associating a consumer's online behavior with an offline payment transaction. The system includes at least one processor and a memory storing instructions that, when executed by the at least one processor, cause the system to generate a first mapping between a consumer identifier and a consumer's payment card identifier, generate a second mapping between the consumer identifier and a consumer's online behavior identifier in association with visiting a web page, receive data reflecting an offline payment transaction, the data including the payment card identifier, and identify an association between the online behavior and the offline transaction by processing the generated first mapping, the generated second mapping, and the received data.

Many additional features and combinations of the embodiments described herein will be apparent to those of skill in the art upon reading this disclosure.

FIG. 2 is a network diagram illustrating a network interconnecting a link server, a partner server, multiple consumer devices, and multiple data sources, according to an embodiment. 2 is a high-level block diagram of the hardware components of the link server of FIG. 1, according to an embodiment. 2 is a high-level block diagram of the software components of the link server of FIG. 1 according to an embodiment. FIG. 2 is a schematic diagram illustrating associating a user with a payment card according to an embodiment. FIG. 2 is a schematic diagram illustrating associating a user with an offline payment transaction according to an embodiment. FIG. 2 illustrates a schematic diagram of a data flow for associating a user with an offline payment transaction according to an embodiment. FIG. 2 illustrates a schematic diagram of a data flow for associating a user with an offline payment transaction according to an embodiment. FIG. 2 illustrates a schematic diagram of a data flow for associating a user with an offline payment transaction according to an embodiment. FIG. 2 is a diagram that illustrates generally associating users with offline payment transactions with respect to measuring advertising campaign effectiveness, according to an embodiment. FIG. 2 is a diagram illustrating a schematic data flow for associating users with offline payment transactions for measuring advertising campaign effectiveness, according to an embodiment.

FIG. 1 illustrates a network 8 that interconnects a link server 10, a partner server 14, a number of consumer devices 16, and a number of data sources 18, according to an embodiment. As described in more detail herein, the link server 10 is configured to generate data records that reflect links between the online behavior of a number of consumers and their offline payment transactions.

In an embodiment, the link server 10 may be operated by a payment processor and may be configured to process online payment transactions in a known manner. In one example, the link server 10 may provide one or more payment processing application programming interfaces (APIs) and/or one or more hosted payment pages (HPPs) that may be used by the merchant partners to process online payment transactions in a known manner.

The link server 10 is connected to and interoperates with a partner server 14 in a manner detailed herein. The partner server 14 may be operated by a partner (or client) of the operator of the link server 10. Such a partner may be, for example, a merchant, an operator of a demand side platform, an operator of an ad exchange platform, etc. For ease of illustration, only one partner server 14 is shown. However, there may be multiple partner servers 14, each operated by, for example, a different partner.

The link server 10 is interconnected to a number of consumer devices 16, each of which may be operated by a consumer. Each consumer device 16 may be any networked computing device capable of accessing web content. For example, the consumer devices 16 may be personal computers, workstations, servers, portable computers, mobile devices, laptop computers, etc.

The link server 10 is interconnected to a number of data sources 18. The link server 10 may be connected to the data sources 18 via a network 8. The link server 10 may also be directly connected (e.g., via a port or a wired link) to the data sources 18. The data sources 18 are configured to maintain data reflecting offline transactions conducted by consumers. Thus, the data sources 18 include storage media suitable for storing such data. The data sources 18 may also be configured with a network interface suitable for transmitting data reflecting offline transactions to the link server 10, for example, via the network 8.

Network 8 may be any network capable of carrying data, including the Internet, Ethernet, plain old telephone service (POTS) lines, public switched telephone network (PSTN), integrated services digital network (ISDN), digital subscriber line (DSL), coaxial cable, optical fiber, satellite, mobile, wireless (e.g., Wi-Fi, WiMAX), SS7 signaling networks, fixed lines, local area networks, wide area networks, and others, including any combination thereof.

The link server 10 may be connected to an electronic data store 12. The data store 12 is configured to store data received at or generated by the link server 10. For example, the data store 12 may store data reflecting offline transactions, e.g., received from a data source 18. The data store 12 may also store various tables, including, e.g., identifiers and mappings of users, their online transactions, payment cards, partners, advertising campaigns, etc., as described in more detail below.

The data store 12 may include a conventional relational database, such as a MySQL™, Microsoft™ SQL, or Oracle™ database. The data store 12 may also include another type of database, such as, for example, an object-oriented database or a NoSQL database. Thus, the link server 10 may include a conventional database engine (not shown) for accessing the data store 12 using queries expressed using, for example, a conventional query language, such as SQL, OQL, etc.

In an embodiment, the link server 10 may be configured to exchange (e.g., send and/or receive) web content (e.g., user identifiers, pixel tags, etc.) with one or more partner servers 14 or one or more consumer devices 16. In this embodiment, the link server 10 may include a conventional HTTP server application (e.g., Apache HTTP Server, Nginx, Microsoft IIS, etc.) that adapts the link server 10 to exchange such web content.

The link server 10 may be embodied in any networked computing device, such as a personal computer, a workstation, a server, a portable computer, a mobile device, a laptop computer, etc. In embodiments, the link server 10 may be implemented as a physical or virtual instance using various distributed resource technologies, such as "cloud computing". Potential benefits to "cloud computing" include ease of adding/removing resources, load balancing, etc.

FIG. 2 is a block diagram illustrating hardware components of a link server 10 according to an embodiment. As shown, the link server 10 includes at least one processor 130, memory 132, at least one I/O interface 134, and at least one network interface 136.

Each processor 130 may be any type of processor, such as, for example, any type of general-purpose microprocessor or microcontroller, a digital signal processing (DSP) processor, an integrated circuit, a field programmable gate array (FPGA), a reconfigurable processor, or any combination thereof.

Memory 132 may be any type of electronic memory located internally or externally, such as, for example, random access memory (RAM), read only memory (ROM), compact disc read only memory (CDROM), electro-optical memory, magneto-optical memory, erasable programmable read only memory (EPROM) and electrically erasable programmable read only memory (EEPROM), ferroelectric RAM (FRAM®), etc. In an embodiment, data store 12 may reside in memory 132.

Each I/O interface 134 allows the link server 10 to communicate with input and output devices, such as peripheral devices or external storage devices. Such peripheral devices may include one or more input devices, such as a keyboard, mouse, camera, touch screen, and microphone, and may also include one or more output devices, such as a display screen and speakers. In an embodiment, the I/O interface 134 may function as a data communication interface, enabling the link server 10 to receive data, for example, from a data source 18.

Each network interface 136 enables the link server 10 to communicate with other components (e.g., one or more partner servers 14 and/or data sources 18), send data to and/or receive data from such other components, and access and connect to network resources over one or more networks (e.g., network 8).

FIG. 3 illustrates various application modules that may be executed on the link server 10 and adapted to function in the manner disclosed herein. As shown, these modules include a tracker generation module 110, a card matching module 112, a partner matching module 114, an offline data matching module 116, and a report generation module 118.

Each of these modules may be implemented in a high level programming language, such as a procedural language, an object-oriented language, a scripting language, or any combination thereof. For example, each of these modules may be implemented using C, C++, C#, Perl, Java, JavaScript, etc. Each of these modules may also be implemented in assembly or machine language. Each of the modules may be in the form of an executable program, a script, a statically linkable library, or a dynamically linkable library.

The tracker generation module 110 is configured to generate one or more tracking elements for tracking a consumer's online behavior.

The tracker generation module 110 generates a unique identifier, which may be referred to herein as a "PayID," for each consumer device to be tracked (e.g., each consumer device 16). The PayID may be generated in any conventional manner, and may be, for example, a numeric identifier, an alphanumeric identifier, etc.

The tracker generation module 110 can provide the PayID to the card match module 112 or the partner match module 114 for the purpose of creating a cookie containing the PayID on the consumer's browser when the consumer visits a web page hosted on the link server 10 (e.g., a hosted payment page) or a web page hosted on a third party server (which may be a partner server 14). In one embodiment, the tracker generation module 110 can provide the PayID to a third party server (which may be a partner server 14) for the purpose of creating a cookie containing the PayID on the consumer's browser when the consumer visits a web page hosted on the third party server.

The card match module 112 is configured to generate a mapping between consumers and their payment cards. In particular, the card match module 112 generates a card match table 500 (FIG. 5), which stores mappings that each map between a particular consumer's identifier (i.e., PayID) and a unique identifier (i.e., Card ID) of a payment card used by that consumer. The card match table 500 may be stored, for example, in the data store 12 (FIG. 1).

The card matching module 112 is configured to generate such a mapping in a variety of ways. By way of example, two such ways are detailed below: (i) when a third party server (e.g., acting as a merchant website) utilizes a hosted payment page provided by the link server 10, and (ii) when a third party server (e.g., acting as a merchant website) utilizes a payment application programming interface provided by the link server 10.

In the hosted payment page example, when the hosted payment page is loaded by a consumer operating a consumer device 16, the card matching module 112 reads the PayID from a cookie stored in the consumer's browser, or if no cookie exists, the card matching module 112 calls the tracker generation module 110 to generate a new PayID for the consumer, and a cookie with the PayID is stored on the consumer's browser (assuming cookies are enabled).

A hidden field tag can be included on the hosted payment page to hold the value of the PayID. When the payment form is submitted, the Card ID the consumer has on file and the PayID in the hidden field tag are passed to the card verification module 112.

The card matching module 112 then stores both the PayID and the payment card information ("Card ID") that the consumer entered on the hosted payment page in the card matching table 500.

In an example application programming interface, as shown in FIG. 4, in a payment flow, a pixel tag is provided (e.g., by a third party server) on a web page 400. When this web page is accessed by a consumer using a consumer device 16, the pixel tag generates a request to the link server 10 along with other relevant information, as described in more detail below. In the illustrated embodiment, the pixel tag is image-based, requesting a 1×1 pixel size image. This image may be invisible to the user (e.g., transparent or hidden from view). In other embodiments, JavaScript-based pixel tags may be used. In yet other embodiments, other types of tags may be used.

When a consumer operating a consumer device 16 loads a web page 400 having a pixel tag, a unique identifier for the particular online transaction (i.e., a transaction ID or "T.ID") is generated, and the pixel tag sends a request along with the T.ID to the card verification module 112.

In one example, the pixel tag may be in the following format:

Thus, in this example, the pixel tag includes the URL of the link server 10 and the parameter T.ID that is passed to the card matching module 112. Other parameters may also be included in the pixel tag and passed to the card matching module 112.

When the card match module 112 receives the pixel request, it generates (or retrieves) the PayID, stores the T.ID and PayID in a table 402 (e.g., in the data store 12) for matching purposes, and responds with a 1x1 pixel size image. If it was necessary to create a new PayID for the consumer (e.g., by calling the tracker generation module 110), the PayID is stored in the consumer's browser as a cookie.

When the payment page form is submitted by the consumer, the Card ID and T. ID are sent to the card verification module 112 through the application programming interface and stored in a separate table 404 (e.g., in the data store 12).

Periodically, the card match module 112 initiates a process to associate the T.IDs in tables 402 and 404, thereby creating a mapping between the PayID and Card ID for a particular consumer. If a mapping between a particular PayID and Card ID does not already exist in the card match table 500, the card match module 112 creates a new record in the card match table 500 to store the mapping.

In an embodiment, as an alternative to using cookies, device fingerprinting may be utilized to create a unique PayID for each consumer device 16 that needs to be tracked. Device fingerprinting may be based, for example, on the device's Media Access Control (MAC) address, the particular operating system (and version) running on the device, the particular browser (and version) running on the device, or others, including combinations thereof. Such information to generate the device fingerprint may be collected in known manner.

The PayID generated using device fingerprinting may be stored in the card match table 500 and the partner match table 502.

The partner matching module 114 is configured to generate mappings between consumers and their online actions. Among other things, the partner matching module 114 generates a partner match table 502 (FIG. 5) that stores mappings, each mapping including an identifier for a particular consumer assigned by the link server 10 (i.e., PayID), a unique identifier for that consumer assigned by the partner (i.e., Partner Unique User/Consumer ID, or "PUID"), and an identifier for a particular online action taken by a particular consumer (Action ID or "BhID"). The mappings may also include the name of the partner.

As shown in FIG. 6A, a pixel tag 60 is provided to a third party server (which may be a partner server 14). This pixel tag 60 is served by the third party server to a consumer operating a consumer device 16 on a corresponding online page 62 where the consumer is performing various online activities such as viewing an advertisement, watching a video, reading an article, playing a game, conducting an online search, doing research, purchasing or browsing for a product/service, communicating through an online service (e.g., an instant messaging service), etc.

In one example, the pixel tag 60 may be in the following format:

Thus, in this example, the pixel tag 60 includes the URL of the link server 10, the parameter P (the partner name), the parameter PUID, and the parameter BhID, which are passed to the partner match module 114 via the pixel request 64. Other parameters may also be included in the pixel tag 60 and passed to the partner match module 114.

In an embodiment, a partner may choose to omit the parameter PUID to avoid generating a PUID. In this case, the partner may utilize the pixel tag 60 in the manner described above without inserting a value for the parameter PUID. In this situation, the partner matching module 114 will assume that any request received from that partner is related to the activity being tracked and will use a NIL value for PUID.

In an embodiment, the pixel request 64 can omit the parameter BhID. In this embodiment, the partner match module 114 can instead receive the BhID information from a partner (e.g., the partner that generated the PUID described above) via a behavior log file 66. For example, the behavior log file 66 can be received from a partner server 14 operated by the partner. The behavior log file 66 includes the mapping of BhIDs to PUIDs logged by the partner.

Upon receiving the behavior log file 66, the partner match module 114 processes the behavior log file 66 to populate the partner match table 502 with the mappings between BhIDs and PUIDs. Optionally, in this embodiment, the partner match module 114 can use two tables instead of the partner match table 502: one table for storing the mappings between BhIDs and PUIDs, and a separate table for storing the mappings between PUIDs and PayIDs.

Advantageously, in this embodiment, it is not necessary to provide a pixel tag 60 in association with each action. Instead, the pixel tag 60 may be provided at the first instance or periodically.

As will be appreciated, the third party server referenced in connection with the partner matching module 114 may be different than the third party server referenced in connection with the card matching module 112.

As noted, when a particular consumer visits a web page 62 that has a pixel tag 60, a pixel request 64 is sent to the partner matching module 114.

The partner match module 114 receives the pixel request 64. In response, the following actions by the partner match module 114 are possible:
Action A. If it is a new consumer (i.e. no link server 10 cookie exists) :
1. Call the tracker generation module 110 to generate a new unique PayID.
2. Create a Link Server 10 cookie (with the PayID stored) on the consumer's browser.
3. Store the following in the Partner Match Table 502: Partner Name (P), PayID, PUID, BhID (if BhID was received in the pixel request 64) and any other information related to that partner (e.g., date and timestamp of the request).
4. Respond with a 1x1 pixel size image (or redirect to partner server 14).
Action B. If it is an existing consumer (i.e. the link server 10 cookie exists in the consumer's browser) :
1. The link server 10 reads the cookie and obtains the PayID stored in the cookie.
2. Search Partner Match Table 502 to determine if there is already a match between the PUID and PayID.
3. If there is no match:
- Store the following in the Partner Match Table 502: Partner Name (P), PayID, PUID, BhID (if BhID was received in the Pixel Request 64) and any other information related to that partner (e.g. date and timestamp of the request).
- Respond with a 1x1 pixel size image (or redirect to the partner server 14).
4. If a match exists:
- Store the following in the Partner Match Table 502: Partner Name (P), PayID, PUID, BhID (if BhID was received in the pixel request 64), and any other information related to that partner (e.g., date and timestamp of the request). As will be appreciated, it may be desirable to store separate records for matches of the same behavior, as this allows the number of times an action has occurred (e.g., an ad is viewed) to be determined.
- Respond with a 1x1 pixel size image (or redirect to the partner server 14).

As shown in FIG. 6B, in an embodiment, pixel tag 60 may be replaced with partner pixel tag 60'. Notably, this embodiment avoids any requirement for a third party server (which may be partner server 14) to directly provide a pixel tag associated with link server 10 on web page 62. Instead, the third party server (which may be partner server 14) may provide a pixel tag 60' associated with partner server 14 on web page 62 and then redirect web page 62 to send the request to link server 10.

In one example, the partner pixel tag 60' may be in the following format:

Thus, in this example, the pixel tag 60' includes the URL of the partner server 14 and a parameter partner id that identifies the entity to which redirection is to be provided (e.g., the operation of the link server 10). When the pixel tag 60' is loaded on the consumer's browser of the consumer device 16, the browser sends a request to the partner server 14 using the above URL (along with the parameter partner id). The partner server 14 generates/reads its PUID for that consumer and stores the PUID in a cookie on the consumer's browser. The partner server 14 provides a response 68 back to the consumer's browser in the redirect pixel request (rather than a 1x1 pixel size image).

The response 68 to the consumer's browser is configured to redirect the consumer's browser to the link server 10 to initiate a pixel request 70.

In one example, the pixel request 70 may be made using a URL of the following form:

Thus, in a manner similar to pixel request 64, redirected pixel request 70 includes the URL of link server 10, parameter P (partner name), parameter PUID, and parameter BhID that are passed to partner match module 114. Upon receiving redirected pixel request 70, partner match module 114 can perform action A or action B described above.

In an embodiment, the redirect pixel request 70 can omit the behavioral ID (BhID). The partner match module 114 can generate a mapping between BhID and PUID using the behavioral log file 66 in the manner described above.

As shown in FIG. 6C, in an embodiment, a particular consumer identifier common to several partners (i.e., a "Common ID") may be used in place of the PUID. For example, the Common ID may be an identifier from an ad exchange such as Doubleclick by Google®, Facebook® Exchange, or others.

In this embodiment, the operation of the partner matching module 114 is substantially the same as described above with respect to PUIDs, with the following differences:

As shown, pixel tag 60 may be replaced with pixel tag 60″. In one example, pixel tag 60″ may be of the following format:

Thus, in this example, the pixel tag 60" includes a common ID instead of a PUID. As will be appreciated, the format of the common ID may vary depending, for example, on the particular ad exchange involved. This common ID is passed to the partner matching module 114 via the pixel request 64. The pixel tag 60" also includes a parameter P (partner name).

The partner matching module 114 records the parameters P, PayID, and Common ID, as well as any other relevant information, in the partner match table 502.

The pixel tag 60" omits the BhID. The partner match module 114 can use the behavior log file 66 in the manner described above to generate a mapping between BhIDs and Common IDs. As shown, the partner can maintain a match table 72 that includes a mapping between PUIDs and Common IDs that can be used by the partner to generate the behavior log file 66.

In an embodiment, the pixel tag 60" may be replaced with a common partner pixel tag (not shown). The common partner pixel tag may include a URL of a common partner server that may be configured to redirect the pixel request to the link server 10 in the manner described above.

The offline data matching module 116 is configured to generate a mapping between consumers' online behavior and their offline payment transactions. In particular, the offline data matching module 116 generates such a mapping using the card match table 500 and the partner match table 502, as well as offline transaction data received from one or more data sources 18.

The offline transaction data may be stored in a transaction data table 504 and may include the consumer's Card Id, purchase amount, and other relevant information.

5 illustrates an exemplary mapping generated by the offline data matching module 116. For example, as shown, a consumer with PayID XYZAB may be mapped to Card ID 5xx5678 in the card match table 500 (e.g., mapped by the card match module 112). The same consumer may be matched to a particular online behavior "X" as shown in the partner match table 502 (e.g., mapped by the partner match module 114). For example, the particular online behavior may correspond to visiting a particular web page, represented by a particular BhID in the partner match table 502. The same consumer may also be matched to a particular offline transaction (in the amount of $60) as shown in the transaction data table 504 based on the consumer's associated Card ID. In this manner, the consumer's online behavior is mapped to his/her offline transactions.

In a particular embodiment, the link server 10 may be configured to facilitate measurement of advertising effectiveness. In this embodiment, the particular online behavior of interest may be, for example, viewing an ad from a particular advertising campaign promoted by a particular ad exchange.

In this embodiment, the partner matching module 114 is configured to generate a mapping between consumers and the particular advertising activity campaigns seen by those consumers. Thus, the partner matching module 114 is configured to use an ad campaign ID (Ad.ID) instead of a behavior ID (BhID). In another embodiment, an Ad ID that uniquely identifies a particular ad, or an Ad ID that uniquely identifies a particular ad served by a particular partner, may be used instead of an ad campaign ID to provide greater tracking granularity.

Thus, a pixel tag of the following format may be used to provide the partner matching module 114 with the ad campaign ID and PUID to allow a match between them:

Furthermore, the partner match table 502 may be replaced with a partner match table 502' configured to store Ad. IDs instead of BhIDs, as shown in FIG. 7.

In an embodiment, if a partner (e.g., a demand-side platform) cannot directly provide pixel tags but can maintain a match table with an ad exchange (e.g., with Google's DoubleClick Ad Exchange), the partner can provide data containing Ad. IDs and corresponding Common IDs to the offline data matching module 116. Using the Common ID, the offline data matching module 116 determines the associated PayID in the partner match table 502/502' and, for each record, matches it with the Card ID in the card match table 500.

Once the corresponding Card IDs are known for a particular ad campaign being tracked, these Card IDs can be matched, for example, to offline (e.g., in-store, over the phone, in-app, etc.) payment transaction data from the same merchants participating in the ad campaign.

Figure 8 illustrates generally the operation of the link server 10 with respect to measuring the effectiveness of advertising activities, as described above.

As shown, various entities (e.g., merchants/ad agencies, data providers, campaign platforms/demand side platform operators, ad exchanges) can interoperate in a known manner to implement advertising activity campaigns. The operation of the link server 10 is substantially similar to that described with reference to FIG. 6C for an embodiment using Common IDs.

As will be appreciated, a particular ad exchange may use any number of common IDs for a particular consumer. For example, as shown in FIG. 8, an ad exchange may use two different common IDs for a particular consumer, namely, G. ID(P1) and G. ID(P2). In this case, a unique one of the common IDs may be selected for use in connection with the link server 10. The selected common ID, e.g., G. ID(P1), may be used in both the pixel request to the link server 10 and in the behavior log file sent to the link server 10 to facilitate matching in the manner disclosed above.

3, the report generation module 118 may be configured to generate various reports based on correlating the consumer's online behavior with the offline payment transactions. For example, the report generation module 118 may generate one or more reports containing the following information:
- the total number of traceable individuals who made an offline purchase (vs. the total number of traceable individuals who did not make a purchase);
- Categorization by source of transaction (e.g. online vs. in-store vs. phone, etc.);
- Total sales amount of offline transactions and determination of return on investment (assuming costing information will be provided by the merchant or business partner); and - "share of wallet" representing the average percentage of consumers' total spend at traceable merchants, including trends benchmarked over time at merchants and across all shoppers.

Other relevant information may also be included in the report.

Such reports may be presented electronically by the report generation module 118, for example, via a partner web portal. Such reports may also be presented in paper format.

In an embodiment, operation of the link server 10 associates consumers' online actions or behavior with their offline (e.g., in-store or mail order/phone order) payment transactions without the consumer's and/or merchant's direct involvement.

In an embodiment, operation of link server 10 can facilitate measurement of a merchant's online advertising activities that contribute to offline (e.g., in-store or mail order/telephone order) sales.

In an embodiment, operation of the link server 10 can facilitate the generation of analytics reports for merchants or other clients to understand how various online actions and behaviors of consumers visiting online/mobile sites relate to their offline spending.

In an embodiment, operation of the link server 10 can facilitate targeting of online advertisements to customers of merchants who transact with them offline.

In an embodiment, operation of the link server 10 can facilitate a low-friction omnichannel approach for merchants to provide a seamless shopping experience to their customers, whether the customers are shopping online from a desktop or mobile device, by phone, or in a brick-and-mortar store.

Accordingly, link server 10 may be operated in numerous contexts and for numerous purposes, including, for example, ad campaign performance measurement, analytics for merchants or business partners, targeted advertising activities, etc.

Embodiments of the devices, systems and methods described herein may be implemented in a combination of both hardware and software. These embodiments may be implemented on programmable computers, each computer including at least one processor, a data storage system (including volatile or non-volatile memory, or other data storage elements, or a combination thereof), and at least one communication interface.

Program code is applied to input data to perform functions described herein and to generate output information. The output information is applied to one or more output devices. In some embodiments, the communication interface may be a network communication interface. In embodiments in which elements may be combined, the communication interface may be a software communication interface, such as for inter-process communication. In still other embodiments, there may be a combination of communication interfaces implemented as hardware, software, and combinations thereof.

Throughout the above discussion, numerous references will be made to servers, services, interfaces, portals, platforms, or other systems formed from computing devices. It should be appreciated that use of such terms is deemed to represent one or more computing devices having at least one processor configured to execute software instructions stored on a computer-readable, tangible, non-transitory medium. For example, a server may include one or more computers operating as a web server, database server, or other type of computer server in such a manner as to perform the described roles, responsibilities, or functions.

The following discussion provides a number of exemplary embodiments. Although each embodiment represents a single combination of inventive elements, other examples may include all possible combinations of the disclosed elements. Thus, if one embodiment includes elements A, B, and C and a second embodiment includes elements B and D, other remaining combinations of A, B, C, or D may also be used.

The terms "connected" or "coupled to" can include both direct couplings (where the two elements being coupled to each other abut one another) and non-direct couplings (where at least one additional element is positioned between the two elements).

The technical solutions of the embodiments may be in the form of a software product. The software product may be stored in a non-volatile or non-transitory storage medium, which may be a compact disk read-only memory (CD-ROM), a USB flash disk, or a removable hard disk. The software product includes some instructions that enable a computing device (personal computer, server, or network device) to execute the methods provided by the embodiments.

The embodiments described herein are implemented by physical computer hardware, including computing devices, servers, receivers, transmitters, processors, memory, displays, and networks. The embodiments described herein provide useful physical machines, and computer hardware facilities configured among other things. The embodiments described herein are directed to electronic machines and methods implemented by electronic machines adapted to process and convert electromagnetic signals representing various types of information. The embodiments described herein relate broadly and generally to machines and their use, and the embodiments described herein have no meaning or practical applicability outside of their use with computer hardware, machines, and various hardware components. For example, using mental steps to substitute physical hardware configured among other things to implement various actions for non-physical hardware may substantially affect the way the embodiments work. Such computer hardware limitations are obvious essential elements of the embodiments described herein, and they cannot be omitted or substituted for mental means without having a significant effect on the operation and structure of the embodiments described herein. The computer hardware is essential to implement the various embodiments described herein, and is not merely used to perform the steps in a quick and efficient manner.

Although the embodiments have been described in detail, it should be understood that various changes, substitutions and alterations may be made herein without departing from the scope defined by the appended claims.

Moreover, the scope of the present application is not intended to be limited to the particular embodiments of the processes, machines, manufactures, compositions, means, methods, and steps described herein. As one of ordinary skill in the art will readily recognize from the present disclosure, any currently existing or later developed processes, machines, manufactures, compositions, means, methods, or steps that perform substantially the same function or achieve substantially the same results as the corresponding embodiments described herein may be utilized. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufactures, compositions, means, methods, or steps.

As can be appreciated, the examples described and shown above are intended to be illustrative only.

The contents of the claims as originally filed are described below as examples.
[Example 1]
1. A computer-implemented method for associating online consumer behavior with offline payment transactions, comprising:
In at least one processor,
generating a first mapping between an identifier of the consumer and an identifier of a payment card of the consumer;
generating a second mapping between the identifier of the consumer and an identifier of the consumer's online behavior associated with visiting a web page;
receiving data reflecting an offline payment transaction, the data including the identifier of the payment card;
and identifying an association between the online behavior and the offline payment transaction by processing the generated first mapping, the generated second mapping, and the received data.
[Example 2]
2. The method of example 1, further comprising receiving the identifier of the consumer via a browser cookie.
[Example 3]
2. The method of example 1, further comprising receiving the identifier of the consumer via a hosted payment page.
[Example 4]
2. The method of example 1, further comprising receiving the identifier of the consumer via an application programming interface for processing an online payment transaction.
[Example 5]
5. The method of example 4, wherein the identifier of the consumer is received in association with a transaction identifier for an online payment transaction.
[Example 6]
5. The method of example 4, wherein the identifier of the transaction is received via a pixel tag.
[Example 7]
The method of example 6, wherein the pixel tags include image-based pixel tags.
[Example 8]
The method of example 6, wherein the pixel tags include Javascript-based pixel tags.
[Example 9]
2. The method of example 1, further comprising generating the identifier for the consumer.
[Example 10]
2. The method of example 1, further comprising receiving the identifier of the online behavior via a pixel tag.
[Example 11]
2. The method of example 1, further comprising receiving the identifier of the online behavior via a log file.
[Example 12]
2. The method of example 1, wherein the first mapping is generated in association with an online payment transaction.
[Example 13]
2. The method of example 1, wherein the online behavior includes viewing an advertisement, and the identifier for the online behavior includes an identifier for an advertising campaign.
[Example 14]
2. The method of example 1, further comprising generating a report based on the association between the online behavior and the offline payment transactions.
[Example 15]
2. The method of example 1, wherein the data is received via a network interface.
[Example 16]
1. A computer system for correlating online consumer behavior with offline payment transactions, comprising:
At least one processor;
a memory storing instructions that, when executed by the at least one processor, cause the computer system to:
generating a first mapping between an identifier of the consumer and an identifier of a payment card of the consumer;
generating a second mapping between the identifier of the consumer and an identifier of the consumer's online behavior associated with visiting a web page;
receiving data reflecting an offline payment transaction, the data including the identifier of the payment card;
processing the generated first mapping, the generated second mapping, and the received data to identify an association between the online behavior and the offline payment transaction;
A system including a memory and
[Example 17]
17. The system of example 16, wherein the online behavior includes viewing an advertisement, and the identifier for the online behavior includes an identifier for an advertising campaign.
[Example 18]
17. The system of example 16, wherein the first mapping is generated in association with an online payment transaction.

Claims (7)

1. A computer-implemented method for generating a mapping between one or more unique identifiers of a device associated with a consumer and an identifier of a card of said consumer, the method employing a server capable of executing various modules including a card matching module, a network interconnecting a link server and the consumer device, the method comprising:
a third party server providing a pixel tag on a web page associated with an online transaction , the pixel tag including a unique identifier associated with the online transaction, the unique identifier for the online transaction being generated by at least one of a merchant, a partner, or a payment processor hosting an online payment page associated with the online payment transaction;
the consumer device accessing the web page sending (i) the card identifier associated with the unique identifier of the online transaction , and (ii) a unique transaction identifier generated by at least one of the merchant, the partner, or the payment processor, associated with the unique identifier of the online transaction to a card verification module via an application programming interface, wherein the card identifier and the transaction identifier are stored in a first data table ;
at the web page, the consumer device sending a request to the card verification module via the pixel tag, the request including the unique transaction identifier ;
when the card verification module receives the request, the card verification module reads the one or more unique identifiers of the consumer device included in the request and stores the unique transaction identifier and the one or more unique identifiers of the consumer device in a second data table;
the card verification module executes a process to associate the unique transaction identifiers in the first and second data tables to create a mapping in a third data table between the one or more unique identifiers and the identifier of the payment card.
Method. The method of claim 1, wherein the pixel tag is image-based and requests an image of size 1x1 pixel. The method of claim 1, wherein the pixel tags are image-based and invisible to the consumer. The method of claim 1, wherein the pixel tag is a JavaScript-based pixel tag. The method of claim 1, wherein the one or more unique identifiers are stored in a browser used by the device to load the web page. The method of claim 5, wherein the one or more unique identifiers are stored in a cookie in the browser. The method of claim 1 , wherein the one or more unique identifiers include a device fingerprint of the device based on one or more device media accesses.

Images