JP2022176191A - System, device, and method for associating online action with offline payment transaction - Google Patents

Abstract

PROBLEM TO BE SOLVED: To identify association between online action and offline transaction.

SOLUTION: Disclosed is a system, a method, and a device for associating an online action of a consumer with offline payment transaction. A first mapping is generated between an identifier of the consumer and an identifier of a payment card of the consumer. A second mapping is generated between the identifier of the consumer and an identifier of the online action of the consumer in association with visit to a web page. Data reflecting the offline payment transaction is received, and the data includes the identifier of the payment card. The association between the online action and the offline transaction is identified by processing the generated first mapping, the generated second mapping, and the received data.

SELECTED DRAWING: Figure 8

COPYRIGHT: (C)2023,JPO&INPIT

Description

TECHNICAL FIELD This disclosure relates to tracking consumer behavior and, more particularly, to associating consumers' online behavior with their offline payment transactions.

Various methods are known for tracking consumer online behavior (eg, exposure to online advertising activities, online payment transactions, etc.). Various methods of tracking consumer offline payment transactions are also known.

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.

Accordingly, a need exists for improved tracking methods, systems and devices, or at least alternatives.

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

In another aspect, a computer system is provided for associating consumer online behavior with offline payment transactions. 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 command between the consumer's identifier and the consumer's payment card identifier. to generate a first mapping and generate a second mapping between identifiers of the consumer and identifiers of the consumer's online behavior associated with visiting a web page to reflect offline payment transactions data that includes a payment card identifier, and processing the generated first mapping, the generated second mapping, and the received data to generate online behavior and offline transactions; identify associations between

Many additional features and combinations of the embodiments described herein will become apparent to those skilled in the art after reading this disclosure.

1 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; FIG. 2 is a high-level block diagram of hardware components of the link server of FIG. 1, according to an embodiment; FIG. 2 is a high-level block diagram of software components of the link server of FIG. 1, according to an embodiment; FIG. FIG. 4 schematically illustrates associating a user with a payment card, according to an embodiment; FIG. 4 schematically illustrates associating a user with an offline payment transaction, according to an embodiment; FIG. 4 schematically illustrates a data flow for associating a user with an offline payment transaction, according to an embodiment; FIG. 4 schematically illustrates a data flow for associating a user with an offline payment transaction, according to an embodiment; FIG. 4 schematically illustrates a data flow for associating a user with an offline payment transaction, according to an embodiment; FIG. 4 schematically illustrates associating users with offline payment transactions in relation to measuring advertising campaign effectiveness, according to an embodiment; FIG. 4 schematically illustrates a data flow for associating users with offline payment transactions for measuring advertising campaign effectiveness, according to an embodiment;

FIG. 1 shows a network 8 interconnecting a link server 10, a partner server 14, multiple consumer devices 16, and multiple data sources 18, according to an embodiment. As detailed herein, the link server 10 is configured to generate data records reflecting the link between the online behavior of multiple consumers and their offline payment transactions.

In embodiments, 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, link server 10 includes one or more payment processing application programming interfaces (APIs) and/or one or more hosted payment pages (HPPs) that can be used by merchant partners to process online payment transactions. ) can be provided in a known manner.

Link server 10 is connected to and interoperates with partner server 14 in a manner detailed herein. Partner server 14 may be operated by a partner (or client) of the operator of link server 10 . Such partners may be, for example, merchants, demand-side platform operators, ad exchange platform operators, and the like. Only one partner server 14 is shown for clarity of illustration. However, for example, there may be multiple partner servers 14 each operated by a different partner.

Link server 10 is interconnected to a plurality of consumer devices 16, each of which can be operated by a consumer. Each consumer device 16 may be any networked computing device capable of accessing web content. For example, consumer device 16 may be a personal computer, workstation, server, portable computer, mobile device, laptop computer, or the like.

Link server 10 is interconnected to multiple data sources 18 . Link server 10 may be connected to data source 18 via network 8 . Link server 10 may also be connected directly (eg, via a port or wired link) to data source 18 . Data source 18 is configured to maintain data reflecting offline transactions made by consumers. Accordingly, data source 18 includes storage media suitable for storing such data. Data source 18 may also be configured with a network interface suitable for transmitting data reflecting offline transactions, for example, over network 8 to link server 10 .

Network 8 includes 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, fiber optic , satellite, mobile, wireless (eg, Wi-Fi, WiMAX), SS7 signaling networks, fixed line, local area networks, wide area networks, and others, including any combination thereof. It can be any network possible.

Link server 10 may be connected to electronic data store 12 . Data store 12 is configured to store data received at or generated by link server 10 . For example, data store 12 may store data reflecting offline transactions, such as received from data sources 18 . Data store 12 may also store various tables including, for example, identifiers and mappings of users, their online transactions, payment cards, partners, advertising campaigns, etc., as detailed below.

Data store 12 may include conventional relational databases such as MySQL(TM), Microsoft(TM) SQL, Oracle(TM) databases, and the like. Data store 12 may also include other types of databases, such as, for example, object-oriented databases or NoSQL databases. Thus, the link server 10 includes a conventional database engine (not shown) for accessing the data store 12 using queries expressed using conventional query languages such as SQL, OQL, for example. be able to.

In embodiments, the link server 10 exchanges (eg, transmits and and/or receive). In this embodiment, the link server 10 implements a conventional HTTP server application (eg, Apache HTTP Server, nginx, Microsoft IIS, etc.) that adapts the link server 10 to interact with such web content. can contain.

Link Server 10 may be embodied in any networked computing device, such as personal computers, workstations, servers, portable computers, mobile devices, laptop computers, and the like. 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 link server 10 according to an embodiment. As shown, 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, for example, any type of general purpose microprocessor or microcontroller, digital signal processing (DSP) processor, integrated circuit, field programmable gate array (FPGA), reconfigurable processor, or any combination thereof. any type of processor.

Memory 132 may include, for example, random access memory (RAM), read only memory (ROM), compact disc read only memory (CDROM), electro-optic memory, magneto-optic memory, erasable programmable read-only memory (EPROM), and electronic memory. It may be any type of electronic memory, located internally or externally, such as erasable programmable read only memory (EEPROM), ferroelectric RAM (FRAM®), and the like. In embodiments, 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 can include one or more input devices such as keyboards, mice, cameras, touch screens and microphones, and can also include one or more output devices such as display screens and speakers. . In embodiments, I/O interface 134 may function as a data communication interface that allows link server 10 to receive data from data source 18, for example.

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

FIG. 3 shows various application modules that can be executed on the link server 10 and adapted to function in the manner disclosed herein. As shown, these modules include tracker generation module 110 , card verification module 112 , partner verification module 114 , offline data verification module 116 , and 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, or the like. Each of these modules may also be implemented in assembly or machine language. Each of the modules may be in the form of executable programs, scripts, statically linkable libraries, or dynamically linkable libraries.

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

Tracker generation module 110 generates a unique identifier, which may be referred to herein as a "PayID," for each consumer device to be tracked (eg, each consumer device 16). A PayID may be generated in any conventional manner, and may be, for example, a numeric identifier, an alphanumeric identifier, or the like.

The tracker generation module 110 causes the consumer to visit 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 the partner server 14). At some point, the PayID can be provided to card verification module 112 or partner verification module 114 for the purpose of creating a cookie on the consumer's browser containing the PayID. In one embodiment, the tracker generation module 110 is used for the purpose of creating a cookie containing the PayID on the consumer's browser when the consumer visits a web page hosted on a third-party server (partner server 14) can provide the PayID to that third party server.

Card verification module 112 is configured to generate a mapping between consumers and their payment cards. Among other things, the card matching module 112 generates a card matching table 500 (FIG. 5), which identifies a particular consumer's identifier (i.e., PayID) and the unique identifier (i.e., PayID) of the payment card used by that consumer. That is, it stores the mapping that maps between the Card ID) and the Card ID). Card match table 500 may be stored, for example, in data store 12 (FIG. 1).

Card verification module 112 is configured to generate such mappings in a variety of ways. By way of example, two such ways are detailed below. (i) when a third party server (e.g., operating as a merchant website) utilizes a hosted payment page provided by Link Server 10; and (ii) a third party server (e.g., operating as a merchant website). when the party server utilizes the 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 consumer device 16, card verification module 112 retrieves the PayID from a cookie stored in the consumer's browser, or if the cookie is If not, the card verification module 112 calls the tracker generation module 110 to generate a new PayID for the consumer, and the cookie with the PayID is added to the consumption (assuming cookies are enabled). stored on the user's browser.

A hidden field tag can be included on the hosted payment page to hold the value of PayID. When the payment form is submitted, the Card ID registered by the consumer 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”) entered by the consumer on the hosted payment page in the card matching table 500 .

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

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

In one example, a pixel tag may be of the form:

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

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

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

Periodically, card verification module 112 checks the T.300 in tables 402 and 404. Initiates the process of associating IDs, thereby creating a mapping between a particular consumer's PayID and Card ID. If a mapping between a particular PayID and Card ID does not already exist in card match table 500, card match module 112 creates a new record in card match table 500 to store that mapping.

In embodiments, as an alternative to using cookies, device fingerprinting may be utilized to create a unique PayID for each consumer's device 16 that needs to be tracked. Device fingerprinting included, for example, the media access control (MAC) address of the device, the specific operating system (and version) running on the device, the specific browser (and version) running on the device, combinations thereof. May be based on others. Such information for generating device fingerprints may be collected in known manner.

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

Partner matching module 114 is configured to generate a mapping between consumers and their online behavior. Among other things, the partner matching module 114 generates a partner matching table 502 (FIG. 5) that stores mappings, each mapping being a specific consumer identifier (i.e., PayID) assigned by the link server 10, a partner-assigned a unique identifier for that consumer (i.e., Partner Unique User/Consumer ID, or “PUID”), and an identifier for a particular online activity performed by a particular consumer (Behavior ID or “BhID”); )including. The mapping can also include the partner's name.

As shown in FIG. 6A, pixel tags 60 are provided to a third party server (which may be partner server 14). This pixel tag 60 is supplied by a third-party server to the consumer operating the consumer device 16 on the relevant online page 62, where the consumer can perform various online activities, such as viewing advertisements, Watching videos, reading articles, playing games, conducting online searches, researching, purchasing or browsing products/services, online services (e.g. instant messaging services), etc.

In one example, pixel tag 60 may be of the following form.

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

In embodiments, a partner may choose to omit the parameter PUID to avoid PUID generation. In this case, the partner can utilize the pixel tag 60 in the manner described above without inserting the value of 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 the NIL value for the PUID.

In embodiments, the pixel request 64 may omit the parameter BhID. In this embodiment, partner verification module 114 may instead receive BhID information from the partner (eg, the partner that generated the PUID described above) via activity log file 66 . For example, activity log file 66 may be received from a partner server 14 operated by that partner. Behavior log file 66 contains mappings of BhIDs and PUIDs logged by partners.

Upon receiving the behavior log file 66, the partner matching module 114 processes the behavior log file 66 to populate the partner matching table 502 with BhID to PUID mappings. Optionally, in this embodiment, partner match module 114 replaces partner match table 502 with two tables: one for storing BhID to PUID mappings, and a PUID to PayID mapping. A separate table can be used to store the .

Advantageously, in this embodiment it is not necessary to supply a pixel tag 60 in association with each action. Alternatively, pixel tags 60 may be supplied at the first instance or periodically.

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

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

Partner matching module 114 receives pixel request 64 . In response, the following actions by partner matching module 114 are possible.
Action A. If it is a new consumer (i.e. no Linked Server 10 cookie exists) :
1. Invoke 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 partner match table 502: partner name (P), PayID, PUID, BhID (if BhID was received in pixel request 64) and any other information related to that partner (e.g. date of request). and timestamp).
4. Respond with a 1×1 pixel size image (or redirect to partner server 14).
Operation B. If it is an existing consumer (i.e. the LinkServer 10 cookie is present in the consumer's browser) :
1. The link server 10 cookie is read to obtain the PayID stored in the cookie.
2. Search partner match table 502 to determine if there is already a match between PUID and PayID.
3. If no match exists:
- Store in partner match table 502: partner name (P), PayID, PUID, BhID (if BhID was received in pixel request 64) and any other information related to that partner (e.g. date and timestamp).
- Respond with a 1x1 pixel size image (or redirect to partner server 14).
4. If a match exists:
- Store in partner match table 502: partner name (P), PayID, PUID, BhID (if BhID was received in pixel request 64), and any other information related to that partner (e.g. date and timestamp). As will be appreciated, it may be desirable to store separate records for the same behavioral match, as this allows the number of times an action (e.g., an ad is seen) to occur can be determined. .
- Respond with a 1x1 pixel size image (or redirect to partner server 14).

As shown in FIG. 6B, in an embodiment pixel tag 60 may be replaced with a partner pixel tag 60'. Among other things, this embodiment circumvents any requirement for a third party server (which may be partner server 14 ) to directly supply pixel tags associated with link server 10 on web page 62 . Alternatively, the third party server (which may be partner server 14) supplies the pixel tag 60' associated with partner server 14 on web page 62 and then redirects web page 62 to fulfill the request. can be sent to the link server 10.

In one example, 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 (eg, link server 10 operation) for which redirection is to be provided. When the pixel tag 60' is loaded onto the consumer's browser on the consumer device 16, the browser sends a request to the partner server 14 using the above URL (with the parameter partner id). The partner server 14 generates/reads that 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 with a 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 the pixel request 70 .

In one example, a pixel request 70 may be made using a URL of the 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 passed to partner matching module 114 . Upon receiving redirected pixel request 70, partner matching module 114 may perform action A or action B described above.

In embodiments, the redirect pixel request 70 may omit the behavior ID (BhID). Partner verification module 114 may use behavior log file 66 to generate a mapping of BhIDs to PUIDs in the manner described above.

As shown in FIG. 6C, in embodiments, a specific consumer identifier that is common to multiple partners (ie, 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 partner verification 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 form.

Thus, in this example, the pixel tag 60'' includes a Common ID instead of a PUID. This Common ID is passed to partner matching module 114 via pixel request 64. Pixel tag 60'' also includes parameter P (partner name).

Partner match module 114 records parameter P, PayID, and Common ID, as well as any other relevant information, in partner match table 502 .

The pixel tag 60″ omits the BhID. The partner matching module 114 can use the behavior log file 66 in the manner described above to generate a mapping between the BhID and the Common ID. As shown: Partners can maintain a match table 72 containing a mapping of PUIDs to Common IDs that can be used by partners to generate activity log files 66 .

In an embodiment, pixel tag 60″ may be replaced with a common partner pixel tag (not shown). This common partner pixel tag is configured to redirect pixel requests to link server 10 in the manner described above. can include the URL of a common partner server to obtain.

Offline data matching module 116 is configured to generate a mapping between consumers' online behavior and their offline payment transactions. Among other things, offline data matching module 116 uses offline transaction data received from card match table 500 and partner match table 502 and one or more data sources 18 to generate such mappings.

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

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

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

In this embodiment, partner matching module 114 is configured to generate a mapping between consumers and specific advertising campaigns viewed by those consumers. Thus, partner matching module 114 is configured to use ad campaign ID (Ad.ID) instead of 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, is replaced with an ad campaign ID to provide greater tracking granularity. may be used instead of

Accordingly, pixel tags of the following form may be used to provide ad campaign IDs and PUIDs to partner matching module 114 to allow matches between them.

In addition, the partner match table 502, as shown in FIG. 7, uses Ad. It can be replaced by a partner match table 502' configured to store IDs.

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

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

FIG. 8 schematically illustrates the operation of the link server 10 with respect to measuring advertising campaign effectiveness, as described above.

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

As will be appreciated, a particular ad exchange may use any number of Common IDs for a particular consumer. For example, as shown in Figure 8, an ad exchange may create two different Common IDs for a particular consumer, namely G. ID (P1) and G.I. ID (P2) can be used. In this case, a unique one of the Common IDs may be selected for use in connection with the link server 10. Selected Common ID, eg, G.I. ID (P1) may be used both in pixel requests to link server 10 and in activity log files sent to link server 10 to facilitate matching in the manner disclosed above.

Referring again to FIG. 3, report generation module 118 may be configured to generate various reports based on correlating consumer online behavior with offline payment transactions. For example, the report generation module 118 can generate one or more reports having the following information.
- the total number of identifiable individuals who made offline purchases (versus the total number of identifiable individuals who did not make a purchase),
- categorization by the source of the transaction (e.g. online versus store versus telephone, etc.);
- Determining the total sales value of offline transactions and return on investment (assuming costing information that will be provided by merchants or business partners); and - Over time at merchants and for all shoppers. 'Share of Wallet' showing the average percentage of consumer spending at traceable merchants to total consumer spending, including benchmarked trends.

Other relevant information may also be included in the report.

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

In embodiments, the operation of the link server 10 may, without the consumer's and/or merchant's direct involvement, transfer the consumer's online actions or activities to their offline (e.g., in-store or mail order/telephone order). ) with payment transactions.

In embodiments, the operation of the link server 10 may facilitate measuring a merchant's online advertising activity that contributes to offline (eg, in-store or mail order/telephone order) sales.

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

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

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

Accordingly, the link server 10 may be operated in multiple contexts and for multiple purposes, including, for example, ad campaign effectiveness measurement, analytics for merchants or business partners, targeted advertising activity, and the like.

Embodiments of the devices, systems and methods described herein can 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 and a data storage system (volatile or nonvolatile 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 the functions described herein and generate output information. 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 one 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 discussion above, numerous references will be made to servers, services, interfaces, portals, platforms, or other systems formed from computing devices. Use of such terms refers to one or more computing devices having at least one processor configured to execute software instructions stored on a computer-readable, tangible, non-transitory medium. It should be recognized that For example, a server can include one or more computers operating as web servers, database servers, or other types of computer servers in a manner that performs the described roles, responsibilities, or functions.

The discussion below provides a number of exemplary embodiments. While each embodiment represents a single combination of inventive elements, other examples may include all possible combinations of the disclosed elements. Therefore, 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. There is

The terms “connected” or “coupled to” are used to refer to direct coupling (two elements that are connected to each other touch each other) and indirect coupling (at least one (where two additional elements are located).

The technical solutions of the embodiments may be in the form of software products. The software product may be stored on a non-volatile or non-transitory storage medium, which may be a compact disc read only memory (CD-ROM), USB flash disk, or removable hard disk. The software product contains some instructions that enable a computing device (personal computer, server, or network device) to perform 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 specifically configured computer hardware installations. Embodiments described herein are directed to electromechanical machines and electromechanical implemented methods adapted to process and transform electromagnetic signals representing various types of information. The embodiments described herein relate broadly and generally to machines and their uses, and the embodiments described herein relate to computer hardware, machines, and their use with various hardware components. has no meaning or factual applicability outside the scope of the use of For example, using mental steps to substitute physical hardware that is specifically configured to implement various effects in place of non-physical hardware can materially affect how embodiments work. Sometimes. Such computer hardware limitations are an obvious essential element of the embodiments described herein, and without material impact on the operation and structure of the embodiments described herein, They cannot be omitted or replaced by mental means. Computer hardware is required to implement the various embodiments described herein, and is not merely used to perform 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 can be made herein without departing from the scope defined by the appended claims. is.

Moreover, the scope of the present application is not intended to be limited to the particular embodiments of the process, machine, manufacture, composition of matter, means, methods and steps described in the specification. As those skilled in the art will readily recognize from this disclosure, there are currently existing embodiments that perform substantially the same function or achieve substantially the same results as the corresponding embodiments described herein. Any process, machine, article of manufacture, composition of matter, means, method or step that exists or is later developed may be utilized. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods or steps.

As can be understood, the examples described and shown above are intended to be exemplary only.

The contents of the claims as originally filed are described below as examples.
[Example 1]
A computer-implemented method for associating consumer online behavior with offline payment transactions, comprising:
in at least one processor,
generating a first mapping between the consumer's identifier and the consumer's payment card identifier;
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, said data including said identifier of said payment card;
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. Method.
[Example 2]
2. The method of example 1, further comprising receiving said identifier of said consumer via a browser cookie.
[Example 3]
2. The method of example 1, further comprising receiving said identifier of said consumer via a hosted payment page.
[Example 4]
2. The method of example 1, further comprising receiving said identifier of said consumer via an application programming interface for processing online payment transactions.
[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]
7. The method of embodiment 6, wherein the pixel tags comprise image-based pixel tags.
[Example 8]
7. The method of example 6, wherein the pixel tag comprises a Javascript-based pixel tag.
[Example 9]
2. The method of example 1, further comprising generating the identifier of the consumer.
[Example 10]
2. The method of example 1, further comprising receiving the identifier of the online activity via a pixel tag.
[Example 11]
2. The method of example 1, further comprising receiving the identifier of the online activity 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 activity includes viewing an advertisement, and wherein the identifier of the online activity includes an identifier of 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 transaction.
[Example 15]
2. The method of example 1, wherein the data is received via a network interface.
[Example 16]
A computer system that associates consumer online 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 the consumer's identifier and the consumer's payment card identifier;
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 containing memory and .
[Example 17]
17. The system of example 16, wherein the online activity includes viewing an advertisement, and wherein the identifier of the online activity includes an identifier of 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 (15)

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 comprising: A server is used that can use a variety of modules, including modules, and a network interconnects the link server and consumer devices, the method comprising:
providing a pixel tag to a web page associated with an online transaction;
When the form is submitted by the consumer, the identifier for the card and a unique transaction identifier generated by at least one of a merchant, partner, or payment processor are sent to a card verification module via an application programming interface. transmitted and stored in a first data table;
At the web page that contains the form or is loaded after submitting the form, sending a request with the pixel tag to the card verification module, the request including the unique transaction identifier. , a step of sending;
When the card verification module receives the request, the card verification module generates or reads the one or more unique identifiers of the consumer device, and performs one or more of the unique transaction identifier and the consumer device. storing the plurality of unique identifiers in a second data table;
The card matching module associates the unique transaction identifiers in the first and second data tables with the one or more unique identifiers and the identifier of the payment card in a third data table. performing a process to create a mapping between
Method. 2. The method of claim 1, wherein the pixel tag is image-based and requires an image of 1x1 pixel size. 2. The method of claim 1, wherein the pixel tag is image-based and invisible to the consumer. 2. The method of claim 1, wherein the pixel tag is a JavaScript-based pixel tag. 2. 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. 6. The method of claim 5, wherein the one or more unique identifiers are stored in cookies of the browser. 2. The method of claim 1, wherein the one or more unique identifiers comprise device fingerprints of the device based on one or more device media accesses. 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 the consumer, the method comprising:
a card verification module generating or reading the one or more unique identifiers when a web page associated with an online transaction is loaded by the device;
passing the one or more unique identifiers to hidden field tags included in the web page; and when a form is submitted by the device, the identifier of a payment card and the identifier in the hidden field tags. passing one or more unique identifiers to the card verification module;
said card verification module storing said one or more unique identifiers and said payment card identifiers in one or more database data tables;
Method. 9. The method of claim 8, wherein the one or more unique identifiers are stored in a browser used by the device to load the web page. 10. The method of claim 9, wherein the one or more unique identifiers are stored in cookies of the browser. 9. The method of claim 8, wherein the one or more unique identifiers comprise device fingerprints of the device based on one or more device media accesses. 1. A computer-implemented method for creating a mapping between one or more unique identifiers of a consumer device and identifiers of a consumer's online behavior, the method comprising:
When a consumer visits a web page, a link server provides a pixel tag associated with the link server to a third party server, the pixel tag including the URL of the link server, the third party a first identifier assigned by a consumer server and a second identifier associated with the consumer's behavior;
receiving the URL, the first identifier, and the second identifier of the link server at a partner matching module via a pixel request;
In response to said pixel request, said partner matching module:
not reading a third identifier associated with the consumer if the consumer is a new consumer, the third identifier being one or more unique identifiers associated with an online transaction; said partner matching module,
a tracker generation module generating the third identifier;
creating a new linked server cookie in the consumer's browser that includes the third identifier;
storing at least a third party's name, said first identifier, said second identifier and said third identifier in a data table;
responding with an image of 1×1 pixel size;
If the consumer is not a new consumer, the partner verification module reads the third identifier from a cookie residing in the consumer's web browser, the partner verification module:
searching the data table to determine if second and third matching identifiers already exist;
if no match exists, storing at least the third party's name, the first identifier, the second identifier, and the third identifier in the data table;
responding with an image of 1×1 pixel size;
otherwise, if there is a match,
storing at least the third party's name, the first identifier, the second identifier, and the third identifier in the data table;
responding with an image of 1×1 pixel size; and adjusting the
the data table is used to generate the mapping;
Method. 13. The method of claim 12, wherein the partner is a hosting company, a demand-side platform operator, or an ad exchange platform. 13. The method of claim 12, wherein the third party server does not assign the first identifier and the partner verification module stores a zero value for the first identifier. 13. The method of claim 12, wherein the pixel request does not include the second identifier, and wherein the partner matching module receives the second identifier from the third party via a behavior log file.

Images