Patent Application
20150220945
In their efforts to improve the effectiveness of marketing strategies, retailers have employed predictive analysis techniques. As input data for predictive analysis, retailers have acquired consumer data from commercially available data sources, or have relied on the data sources themselves to perform the predictive analysis. However, commercially available consumer data, though abundant, is not always ideally relevant to retailers' marketing goals and approaches.
Features and advantages of some embodiments of the present invention, and the manner in which the same are accomplished, will become more readily apparent upon consideration of the following detailed description of the invention taken in conjunction with the accompanying drawings, which illustrate preferred and exemplary embodiments and which are not necessarily drawn to scale, wherein:
In general, and for the purpose of introducing concepts of embodiments of the present invention, a merchant may request data analytic services from a data services division of a payment network operator. In particular, the merchant may request one or more predictive analyses using both merchant-supplied data and transaction data that is available to the payment network operator. The merchant may provide a set of de-identified transaction data for its customers to the payment network operator's data services division. The data services division may obtain de-identified transaction data generated within the payment network. The data services division may filter the network transaction data to remove therefrom data that does not relate to customers of the merchant. The data services division may probabilistically analyze the merchant data and the filtered network data in a manner that allows for linkage of network data to merchant data while assuring that the data subject to analysis remains de-identified. The data services division may then perform predictive analysis in a manner requested by the merchant. One or more predictive models may be employed for the predictive analysis/analyses. For the predictive models, the independent variable(s) may be attributes of the filtered network data that has been linked to the merchant data. The dependent variable may be an attribute of the merchant data or of other data supplied by the merchant. The results of the predictive analysis may take the form of predictive scores, which may be appended to the merchant data. The merchant may use the predictive scores in marketing and/or promotional campaigns.
Embodiments of the present invention relate to systems and methods for analyzing transaction data. More particularly, embodiments relate to systems and methods for analyzing transaction data using data from a first transaction data provider (e.g., such as a payment card network) and data from a second transaction data provider (e.g., such as a merchant or group of merchants) in a way which ensures that personally identifiable information (“PII”) is not revealed or accessible during or after the analysis.
A number of terms are used herein. For example, the term “de-identified data” or “de-identified data sets” are used to refer to data or data sets which have been processed or filtered to remove any PII. The de-identification may be performed in any of a number of ways, although in some embodiments, the de-identified data may be generated using a filtering process which removes PII and associates a de-identified unique identifier (or de-identified unique “ID”) with each record (as will be described further below).
The term “payment card network” or “payment network” is used to refer to a payment network or payment system such as the systems operated by MasterCard International Incorporated (which is the assignee hereof), or other networks which process payment transactions on behalf of a number of merchants, issuers and cardholders. The terms “payment card network data” or “network transaction data” are used to refer to transaction data associated with payment transactions that have been processed over a payment network. For example, network transaction data may include a number of data records associated with individual payment transactions that have been processed over a payment card network. In some embodiments, network transaction data may include information identifying a payment device or account, transaction date and time, transaction amount, and information identifying a merchant or merchant category. Additional transaction details may be available in some embodiments.
Features of some embodiments of the present invention will now be described by first referring to
System 100 includes a probabilistic engine 102 in communication with a reporting engine 104 to generate reports, analyses, and data extracts associated with data matched by the probabilistic engine 102. In some embodiments, the probabilistic engine 102 receives or analyzes data from several data sources, including network transaction data 106 (e.g., from payment transactions made or processed over a payment card network) and merchant transaction data 112 (e.g., from purchase transactions conducted at one or more merchants). The data from each data source 106, 112 is pre-processed before it is analyzed using the probabilistic engine 102. In some embodiments, the data is used to first create an anonymized data extract 108, 114 in which any PII is removed from the data. Pursuant to some embodiments, the anonymized data extract 108, 114 is created by generating a de-identified unique identifier code that is derived from a unique transaction identifier of each transaction in the source data 106, 112. For example, with respect to the network transaction data 106, a function may be applied to a transaction identifier associated with each transaction and transaction record to create a de-identified unique identifier associated with each transaction. In some embodiments, the function may be a hash function or other function so long as the unique identifier cannot by itself be linked to the individual transaction record (for example, an entity that has access to the anonymized data extract 108 is not able to identify any PII associated with a de-identified unique identifier in the extract 108).
The merchant transaction data 112 may be provided to an entity operating the system of the present invention via a secure file transfer (e.g, via sFTP or the like) and associated with a unique merchant identifier. The merchant transaction data 112 may include sales ledger data in a pre-defined format that contains information associated with a plurality of transactions conducted at the merchant including, for example, transaction date/time/spend, store location and a unique identifier associated with the transaction (such as, for example, a customer unique identifier). In some embodiments, the customer unique identifier (“UID”) is selected such that it is not personally identifiable (although it may be personally identifiable with additional information known to the merchant). The customer UID, in some embodiments, is delivered using a de-identified unique identifier generated from the transaction data received from the merchant point of sale systems for continuity between transactions, and is selected to be persistent across transactions. For example, the customer UID may show up numerous times throughout a file provided by a merchant (e.g., the UID may be associated with transactions performed at different store locations, at different times, and with different transaction amounts). In some embodiments, the merchant data extract is tender agnostic, and includes transactions conducted with cash, payment cards, or the like. In general, the number of merchant transactions in the merchant data extract should be higher than the number of payment network transactions extracted by data extract 108 for the merchant as the merchant data extract includes transactions conducted with different tenders including payment network transactions.
Pursuant to some embodiments, the type of data extracted by modules 108, 114 depends on the type of information to be analyzed by the system 100. For example, the data extract 108 may be an extract of the same type of information to be provided by a merchant in data extract 114 (e.g., such as transaction date and time, transaction amount, store location and frequency data). In some embodiments, the data extract may be a sample of a larger set of data, or it may be an entire data set. Further, when extracting payment network data (at 108), information associated with the merchant for which an analysis is to be performed may be used to limit the extract. For example, if an analysis is to be performed for a specific merchant, the extract 108 may be limited to transactions performed at that specific merchant (including all locations or all locations in a specific geographical region). As a specific illustrative example, extract 108 may include a number of records of data, each including a de-identified unique ID, a transaction date, a transaction time, a transaction amount or spend, a store location identifier (identifying a specific store or merchant location), and an aggregate merchant identifier (identifying a specific merchant chain or top level identifier associated with a merchant). Those skilled in the art, upon reading this disclosure, will appreciate that other data fields may also be included depending on the nature of the analysis to be performed.
With respect to the data extract 114 of merchant transaction data 112, in some embodiments, the extract retrieves data elements including a customer UID, a transaction date, a transaction time, a transaction spend, and a store location ID (although those skilled in the art will appreciate that additional or other fields may be extracted depending on the nature of the analysis to be performed).
In some embodiments, the function or process of generating an anonymized data extract 108, 114 may be performed by an entity providing the data. For example, the anonymized data extract 108 may be generated by, or on behalf of, the payment association or the payment network and provided as an input or batch file to an entity operating system 100. As another example, the anonymized data extract 114 may be generated by, or on behalf of, a merchant (or group of merchants) wishing to receive reports or analyses from the system 100.
The system 100 also includes pattern analysis modules 110, 116. Pattern analysis modules 110, 116 may include data, rules or other criteria which define different patterns identified for analysis. Each pattern may be identified by a unique pattern identifier which may be, for example, a random number. Each pattern may be a unique pattern of date/time/spend, store location, and transaction frequency (or other combinations of data for which pattern analysis is desired). The pattern analysis modules 110, 116 may be code or applications which are designed for pattern analysis or may be part of an analysis system or module.
In use, pattern analysis module 110 generates a file, table or other extract of data that is used as an input to the probabilistic engine 102 and which is based on the anonymized and extracted network transaction data. The pattern analysis module 110 may be operated to generate a file, table or other extract of data that includes a number of transactions filtered by an aggregate merchant identifier (e.g., a group of transactions associated with a particular merchant or retail chain across different stores or locations). The module 110 may also summarize and profile the data by each unique combination of transaction date/time/spend, location, and frequency. A new profile identifier may be assigned for each pattern, and the data provided for input to the probabilistic engine 102 may have the de-identified unique ID removed before provision to the engine 102. In some embodiments, the removed unique ID and the assigned profile identifier may be stored in a separate lookup table 118 for later use by the reporting engine 104.
The pattern analysis module 116 generates a file, table or other extract of merchant transaction data that is used as an input to the probabilistic engine 102 and which is based on the anonymized and extracted merchant transaction data provided by module 114. The pattern analysis module 116 may be operated to generate a file, table or other extract of data which has been cleansed to ensure standard formatting of the merchant data for use by the probabilistic engine 102. The cleansing may include the removal of any unnecessary data provided by the merchant. For example, in one specific embodiment, the merchant data may be cleansed to remove all fields other than a customer UID, a transaction date, a transaction time, a transaction spend, and a location ID. The pattern analysis module 116 may further operate to summarize the data by UID to ascertain a frequency of transactions in the merchant data file, and to further summarize and profile data by each combination of transaction date/time/spend, location, and frequency. Upon generation of the extract, a new merchant profile identifier may be assigned to the extract. The merchant profile identifier and the UID are removed from the file output from the pattern analysis module 116. A separate lookup table 120 may be created to store the dropped UID and the merchant profile identifier for later use by the reporting engine 104.
Pursuant to some embodiments, the probabilistic engine 102 operates to perform an inferred match analysis to assess the inferred linkage for uniqueness and direct linkage. This allows further assurance of anonymity and avoids use of any PII. Pursuant to some embodiments, a uniqueness probability is derived from the relationship between the number of unique IDs for the Network Profile and the unique Merchant Profiles. As the probability of a direct link, (driven by uniqueness), approaches 100%, the risk of divulging or revealing some PII increases. For data analysis to identify product or marketing effectiveness, a pattern match of 100% is ideal. However, as the uniqueness of the match approaches 0%, the product or marketing effectiveness decreases significantly. By using features of the present invention to identify the uniqueness probability using anonymized transaction data, embodiments allow marketers, product developers, and analysts to identify trends or actual patterns and to adjust marketing, product development and other features accordingly.
In general, as used herein, the term “direct linkage” refers to the relationship between the probability match and the uniqueness probability. 100% “direct linkage” occurs when the probability match is 100% and the uniqueness probability is 100%. To avoid potentially revealing PII, in some embodiments, it may be desirable to reject any matches where there is 100% direct linkage. Pursuant to some embodiments, the primary inferred match is those records having the highest probabilities within a predetermined acceptance range.
Pursuant to some embodiments, the output of the processing performed by system 100 may be an analysis or report which is generated by the reporting engine 104. To facilitate the reporting and to ensure that PII is not divulged, the reporting engine may use the lookup tables 118, 120 to assign each de-identified merchant profile (from table 120) to one network profile (from table 118). This ensures that the de-identified customers remain de-identified.
As used herein, a module of executable code could be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network. In addition, entire modules, or portions thereof, may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like or as hardwired integrated circuits.
In some embodiments, the modules of
Reference is now made to
In the process 200, network transaction data is extracted from a transaction datastore 106 and a pattern analysis is performed to produce a file for input to probabilistic engine 102. The process 200 begins at 202 where a payment network data extract is performed to provide de-identified data from the payment network associated with a particular merchant or group of merchants. The de-identified data extract may include an extract of fields for payment network transactions, including: a de-identified unique ID (generated as described above), an aggregate merchant ID, a transaction date, a transaction time, a transaction spend, and a location ID. In the case where the payment network is the network operated by MasterCard International Incorporated, the data extract will include a number of transactions conducted using MasterCard-branded payment cards.
Processing continues at 204 where the de-identified data extracted at 202 is filtered, producing a filtered output file having a number of transactions for a particular merchant or group of merchants, resulting in a file of payment network transactions conducted at those merchants and each including: a de-identified unique ID, a transaction date, a transaction time, a transaction spend, and a location ID.
Processing continues at 206 where a pattern analysis is performed to identify a frequency of transactions. The pattern analysis may result in the creation of a file including, for each transaction, a de-identified unique ID, a transaction date, a transaction time, a transaction spend, a location ID, and a frequency variable.
Processing continues at 208 where data is provided to the probabilistic engine 102 including a number of transactions each including a number of fields such as: transaction date, transaction time, transaction spend, a location ID, a frequency variable, and a profile ID. The profile ID is associated with an entry in a lookup table created to store the profile ID in association with the de-identified unique ID for each transaction. In this way, data may be input to the probabilistic engine 102 without any identifier (e.g., the de-identified unique ID is removed from the data input to the probabilistic engine 102, and instead a lookup is provided external to the probabilistic engine 102).
Similar processing is performed on the merchant data. For example, as shown in
The data extract from 302 is then filtered and cleansed at 304 to produce a data file including, for each transaction in the extract, a customer UID, a transaction date, a transaction time, a transaction spend and a location ID.
Processing continues at 306 where the filtered data from 304 is processed using a pattern matching system to derive frequency data associated with the filtered and extracted merchant data. The pattern matching causes the creation of a file having, for each transaction, a customer UID, a transaction date, a transaction time, a transaction spend, a location ID and a frequency variable. A portion of this data is provided as the merchant input to the probabilistic engine 102 at 308, including, for each transaction, a transaction date, a transaction time, a transaction spend, a location ID, a frequency, and a merchant profile ID. The merchant profile ID is associated with a lookup table that is created to associate the customer UID with the pattern or data output at 306. In this way, merchant transaction data may be input to the probabilistic engine 102 without any customer identifier (e.g., the customer UID is removed from the data input to the probabilistic engine 102, and instead a lookup is provided external to the probabilistic engine 102).
By providing such anonymized data to the probabilistic engine 102, a number of analyses and reports may be generated without revealing any PII or other sensitive information. For example, the probabilistic engine 102 may be operated to establish a linkage between a merchant's sales ledger and the de-identified payment network transaction data. The linkage is a probability score between the merchant data and the payment network transaction data based upon spending patterns provided by the merchant along with spending patterns observed in the payment network transaction data. The linkage, on its own, does not necessarily provide any intrinsic value; however, the inferred match is a necessary component to build out merchant applications by providing a link (on a transaction level) between a merchant data file and a payment network data file. As a result, merchants may enjoy the use of a number of analytic and modeling applications including the ability to generate aggregate reports, probability scores and model algorithms. There will be described below examples of predictive analytics that may be applied to the linked data to provide valuable insights to the merchant about their customers' activities and/or propensities.
The two inputs provided to the probabilistic engine 102 include profiles at the network profile level (from pattern analysis 110) and profiles at the merchant profile level (from pattern analysis 116). The profiles may range in quantity of unique accounts (e.g., unique records associated with an account, or the like) from x to 1, and unique transactions from >x to 1.
An illustrative example of a portion of data associated with a network profile is shown in
Pursuant to some embodiments, the probabilistic engine 102 operates to match the merchant profile data with the network profile data with some level of probability. The level of probability, as used herein, is referred to as “the pattern match”. The pattern match could range from 0 to 1 (i.e., 0 to 100%). In addition to the pattern match, the probability of uniqueness could range from 0 to 1.
Network profiles and merchant profiles are linked in a many-to-many fashion and given some level of probability for each pattern match (e.g., 100 network profiles and 100 merchant profiles result in 10,000 probabilities). The match may not be exact—for example, the network profile may say that the spending associated with a specific transaction involved a credit card payment, while the merchant record may have a profile that indicates that the transaction was a cash transaction. These discrepancies may be matched and assigned a match probability. The linking is not actual—instead, a probability match is assigned ranging from 0 to 1 for each combination of records. An illustration of the many-to-many pattern match is shown in
Pursuant to some embodiments, the operation of the system 100 may be based on several assumptions or rules to protect PII. Such assumptions or rules may include ensuring that the combined data set (including network data and merchant data) is not disclosed to the merchant, all applications are specific to a merchant and are not to be shared with other parties, algorithms or scores are created using matched data and no algorithm or score is created using single transaction matches.
Pursuant to some embodiments, the techniques described above may be used in conjunction with a number of different applications. For example, in one embodiment, an aggregated report is produced based on a merchant data file, with an inferred match modeling link to different merchant unique identifiers. In some embodiments, enhanced and aggregated reports may be produced, with inferred match links to merchant unique identifiers utilizing additional “SKU” data from the merchant (e.g., where the SKU level data is received in the merchant transaction data at 112). In some embodiments, data append services may be delivered at the de-identified merchant unique identifier level. Data may be produced as an aggregated metric/probability score. Further, pursuant to some embodiments, an algorithm may be provided designed to score a list outside of a payment network (e.g. for or about a merchant or other third party).
Thus, embodiments of the present invention allow merchants, networks, and others to accurately generate and investigate transaction profiles, without need for added controls to protect and secure PII. Although a number of “assumptions” are provided herein, the assumptions are provided as illustrative but not limiting examples of one particular embodiment—those skilled in the art will appreciate that other embodiments may have different rules or assumptions.
Pursuant to some embodiments, systems, methods, means, computer program code and computerized processes are provided to generate inferred match or linkage between de-identified data in different transaction data sets. In some embodiments, the systems, methods, means, computer program code and computerized processes include receiving a first set of de-identified transaction data from a first transaction data source, receiving a second set of de-identified transaction data from a second transaction data source, filtering the first and second sets of de-identified transaction data to identify transactions associated with at least a first entity and to create first and second filtered data sets, removing data associated with an identifier field for each of the transactions in the first filtered data set to create a de-identified first data set, removing data associated with an identifier field for each of the transactions in the second filtered data set to create a de-identified second data set, and processing the first and second de-identified data sets using a probabilistic engine to establish a linkage between data in each data set.
For further background, a conventional card-based payment system (such as that operated by MasterCard International Incorporated) will now be described.
Thus the transaction in question may originate at a POS (point of sale) device 702 located in a merchant store (which is not separately indicated). A payment card 704 is shown being presented to a reader component 706 associated with the POS device 702.
The payment card 704 is often implemented as a magnetic stripe card, although alternatively, or in addition, the payment card 704 may include capability for being read by proximity RF (radio frequency) communication with an integrated circuit (IC) chip (not separately shown). The primary account number (PAN) for the payment card account represented by the payment card 704 may be stored on the magnetic stripe (not separately shown) and/or the IC chip (if present) for reading by the reader component 706 of the POS device 702.
In some installations, the reader component 706 may be configured to perform either or both of magnetic stripe reading and reading of IC chips by proximity RF communications. Thus, the payment card 704 may be swiped through a mag stripe reading portion (not separately shown) of the reader component 706, or may be tapped on a suitable surface of the reader component 706 to allow for proximity reading of its IC chip.
In some transactions, instead of a card-shaped payment device, such as the payment card 704, a suitable conventional payment-enabled mobile phone or a payment fob may be presented to and read by the reader component 706.
According to practices employed by some merchants, the POS device 702 may in some embodiments be implemented as a suitably programmed smart phone or tablet computer having a small mag stripe reading accessory attached thereto.
A computer 708 operated by an acquirer (acquiring financial institution) is also shown as part of the system 700 in
The payment network 710 may be for example the well-known Banknet system operated by MasterCard International Incorporated, which is the assignee hereof.
The components of the system 700 as depicted in
In the course of receiving and relaying the authorization requests and responses, the payment network 710 may receive and store large quantities of transaction data, including for each one of many transactions, the PAN, the date and time of the transaction, the transaction total amount, the merchant, and the store location. This transaction data, referred to above and below as payment network transaction data, may serve as the raw material for the network profiles referred to in the above description of an inferred match process.
Also shown in
Also shown in
Further details of the operations of the data analysis system 800 will be described below with reference to
The transaction analysis computer 900 may be conventional in its hardware aspects but may be controlled by software to cause it to function as described herein. The transaction analysis computer 900 may include a computer processor 902 operatively coupled to a communication device 903, a storage device 904, an input device 906 and an output device 908.
The computer processor 902 may be constituted by one or more conventional processors. Processor 902 operates to execute processor-executable steps, contained in program instructions described below, so as to control the transaction analysis computer 900 to provide desired functionality.
Communication device 903 may be used to facilitate communication with, for example, other devices (such as the merchant block 804 and the network transaction data store 802 shown in
Input device 906 may comprise one or more of any type of peripheral device typically used to input data into a computer. For example, the input device 906 may include a keyboard and a mouse. Output device 908 may comprise, for example, a display and/or a printer.
Storage device 904 may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., magnetic tape and hard disk drives), optical storage devices such as CDs and/or DVDs, and/or semiconductor memory devices such as Random Access Memory (RAM) devices and Read Only Memory (ROM) devices, as well as so-called flash memory. Any one or more of such information storage devices may be considered to be a computer-readable storage medium or a computer usable medium or a memory.
Storage device 904 stores one or more programs for controlling processor 902. The programs comprise program instructions (which may be referred to as computer readable program code means) that contain processor-executable process steps of the transaction analysis computer 900, executed by the processor 902 to cause the transaction analysis computer 900 to function as described herein.
The programs may include one or more conventional operating systems (not shown) that control the processor 902 so as to manage and coordinate activities and sharing of resources in the transaction analysis computer 900, and to serve as a host for application programs (described below) that run on the transaction analysis computer 900.
The programs stored in the storage device 904 may also include a data preparation application program 910 that controls the processor 902 to enable transaction analysis computer 900 to pre-process one or both of the data sets received from the network transaction data store 802 and the merchant block 804. For example, the data preparation application program 910 may filter the payment network transaction data by removing data for all cardholders who have not engaged in at least one transaction with the merchant/client represented by block 804. In addition or alternatively, the data preparation application program 910 may if necessary cleanse the merchant transaction data set so that it is in a suitable format for the inferred match process and does not contain any extraneous data.
Another program that may be stored in the storage device 904 is data linkage process application program 912. The data linkage process application program 912 may control the processor 902 to enable the transaction analysis computer 900 to perform the inferred match process described above with reference to
The storage device 904 may also store a linked data analysis application program 914. The linked data analysis application program 914 may process that network transaction data that has been linked to merchant transaction data so as to develop information about the merchant's customers that may be of interest to the merchant. For example, and in accordance with aspects of the present invention, the linked data analysis application program 914 may include predictive analytics capabilities as described below in connection with
The storage device 904 may further store an append engine program 916. The append engine program 916 may append to the merchant transaction data set customer-level information produced by predictive analytics performed by the linked data analysis application program 914.
The storage device 904 may also store, and the transaction analysis computer 900 may also execute, other programs, which are not shown. For example, such programs may include a reporting application, which may respond to requests from system administrators for reports on the activities performed by the transaction analysis computer 900. The other programs may also include, e.g., data communication software, database management software, device drivers, etc.
The storage device 904 may also store one or more databases 918 required for operation of the transaction analysis computer 900. Such databases may store, for example, at least on a temporary basis, the anonymized network transaction data set and the anonymized merchant transaction data set, and/or one or more subsets thereof, as needed for the processing by application programs 910, 912, 914 and 916.
At 1002 in
At 1004 in
At 1006, the transaction analysis computer 900 receives the above-mentioned anonymized payment network transaction data set from the network transaction data store 802.
At 1008, the transaction analysis computer 900 filters the anonymized payment network transaction data, by, for example, removing from that data set all data relating to cardholders who are not customers of the merchant/client. In addition, the transaction analysis computer 900 also may perform data conditioning/cleansing on the anonymized merchant transaction data set. Further data conditioning may also be performed on the anonymized payment network transaction data set.
At 1010, the transaction analysis computer 900 applies an inferred match process, as described above with reference to
As is familiar to those who are skilled in the art, predictive analysis typically involves applying a predictive model to a data set. The prediction is performed by the predictive model on the basis of one or more independent variables, and with respect to a dependent variable. In accordance with aspects of the present invention, the data set with respect to which the predictive analysis is to be made is formed from the linkage of filtered payment network transaction data to merchant transaction data. The independent variable or variables for the predictive model may be selected (block 1012,
To give a concrete example, let it be assumed that the merchant/client has requested that the payment network data analysis division provide predictions about which active customers of the merchant are likely to reduce their levels of purchases from the merchant over the next three months. On the basis of such predictions, the merchant may plan to select the indicated customers for special promotions to stimulate those customers to maintain or increase their current level of activity with the merchant. The payment network data analysis division may select one or more attributes of the payment network transaction data that are believed likely to provide predictive insight into the type of change in activity level that is of interest to the merchant/client. For example, the attribute(s) selected may be indicative of one or more spending habits of the customers as reflected in the payment network transaction data, including data derived from purchase transactions that did not involve the merchant/client. Previous experience by the individuals building the predictive model and/or previous analyses may be suggestive of which independent variable(s) to select to achieve significant predictive power with the model. The dependent variable may be selected to be a customer activity level as indicated by the merchant transaction data and/or customer-level supplied data from the merchant. The payment network data analysis division may select one or more types of predictive model (block 1016,
It is contemplated that other types of predictive models may be used in addition to or instead of those types listed above. Predictive Model Markup Language (PMML) may be used to describe and define the desired predictive model(s). The raw data provided in the linked payment network transaction data and merchant transaction data (or other merchant-supplied data) may be pre-processed to improve its suitability for processing by the selected predictive model(s). For example, various aspects of the data may be aggregated, averaged or binned to simplify and/or optimize the variables submitted for processing by the predictive model(s). In some cases, raw data may be pre-processed to produce trend data that indicates trends (such as increasing or decreasing spending) indicated by the raw data. It may be the case that only certain variables present in or derived from the payment network transaction data may be deemed likely to have predictive power; alternatively, the predictive power or lack thereof of a given variable may have been indicated in an earlier iteration of the process of building and testing the predictive model(s).
In some embodiments, a subset of the payment network transaction data/merchant data linked data-set may be used to train the selected predictive model and another subset of the linked data-set may be used to validate the effectiveness of the model after training is complete. The effectiveness of the model, as applied to the test subset, may be evaluated. Depending on the results of the evaluation, one or more other types of predictive model may be trained, tested and evaluated and/or one or more other independent variables may be selected in addition to or instead of those originally selected. In some embodiments, one, two or more of such models may be employed to make predictions on current data from the linked data-set, as indicated at 1018 in
As indicated at 1020 in
In some embodiments, the payment network data services division may engage in consultation with the merchant/client to discuss the estimated accuracy and/or other properties of the predictive model(s) employed, and/or to suggest and/or discuss possible strategies for using the predictive scores or classifications appended to the merchant transaction data set.
In an example given above, the merchant/client requested predictions as to likelihoods that customers would decrease their spending with the merchant/client. In other examples, the merchant/client may request predictions about other customer behaviors, such as how likely customers may be to visit the merchant/client's physical store and/or websites, and/or the customer's likelihood to respond with increased purchases in response to sales or promotions.
At least a portion of the process of
With the processes as described above, payment network transaction data is linked to a merchant's customer transaction data by inferred matching using operations on only de-identified data sets. The linkage occurs in a manner that protects customer privacy while permitting predictive analysis to be done on the linked data sets.
Independent variables are selected from the payment network transaction data portion of the linked data set to produce predictions and/or classifications relative to customers of the merchant/client. For this purpose, the dependent variable for the predictive analysis is taken from the attributes of the anonymized merchant transaction data or other data supplied by the merchant. The output data from the predictive analysis may be appended to the merchant transaction data set, and returned to the merchant/client to support and enhance the merchant's marketing, advertising and/or promotional efforts. The predictive analysis using payment network transaction data may provide insights and/or actionable predictions not available from analysis based on conventional sources of consumer data.
As used herein and in the appended claims, the term “anonymized transaction data” includes transaction data from which identifying information has been removed, as well as transaction data that for any other reason lacks identifying information.
As used herein and in the appended claims, the term “computer” should be understood to encompass a single computer or two or more computers in communication with each other.
As used herein and in the appended claims, the term “processor” should be understood to encompass a single processor or two or more processors in communication with each other.
As used herein and in the appended claims, the term “memory” should be understood to encompass a single memory or storage device or two or more memories or storage devices.
The flow charts and descriptions thereof herein should not be understood to prescribe a fixed order of performing the method steps described therein. Rather the method steps may be performed in any order that is practicable.
As used herein and in the appended claims, the term “payment card system account” includes a credit card account or a deposit account that the account holder may access using a debit card. The terms “payment card system account” and “payment card account” are used interchangeably herein. The term “payment card account number” includes a number that identifies a payment card system account or a number carried by a payment card, or a number that is used to route a transaction in a payment system that handles debit card and/or credit card transactions. The term “payment card” includes a credit card or a debit card.
Although the present invention has been described in connection with specific exemplary embodiments, it should be understood that various changes, substitutions, and alterations apparent to those skilled in the art can be made to the disclosed embodiments without departing from the spirit and scope of the invention as set forth in the appended claims.
