Patent Application
20150332291
The systems and methods described herein relate to systems for matching data from one data source with data in a different data source to add a data field from matched data sets.
Today, customers in many parts of the world have grown accustomed to using electronic payment to handle transactions. Some examples of electronic payment methods include debit cards, credit cards, and direct (store) credits. In the meantime, point-of-sale or point-of-service (POS) systems have been developed and widely adopted by the retail industry to assist merchants and customers with transactions involving electronic payment. Some advanced POS systems may integrate additional functionalities, such as inventory management and warehousing to help the retail merchants better understand and manage their business. For example, a POS system at a local convenience store may accept a credit card payment from a customer in exchange for goods or services rendered (e.g., for five cases of printing paper purchased). If the store's POS system supports the additional functionality of inventory management, the POS system may also automatically deduct the number of cases of printing paper from the inventory of the store by five.
However, such additional functionalities of POS system are severely limited by the need for cross-platform integration between the POS system and other stand-alone applications. Small businesses typically need to employ third-party solutions to analyze business transaction data in order to deduce any useful sales and marketing insights. In the above example, the local convenience store would have to integrate the POS system with independent accounting applications, financial applications, customer relationship management (CRM) applications, etc. in order to translate sales data into meaningful business performance measurements.
In particular, a major limitation of existing POS systems is that they cannot effectively identify new and returning customers or track customer visits over time. A customer could visit the same restaurant five times in the same week, each time ordering the same menu item. However, barring any careful waiter who takes notice, the restaurant owner might not be able to recognize the identity of the loyal customer, much less to gain any insight about the particular menu item that kept the customer's loyalty or any developing relationship between the customer and any waiter. Third-party solutions that provide analytics for business transactions over time are usually unable to trace the behavior of individual customers across multiple visits because of their inability to identify customers.
As such, existing businesses have to rely on rewards incentives to identify customers. For instance, many retailers have implemented rewards programs that offer membership discounts to customers who provide their identity using a loyalty card. A customer may scan the loyalty card at check-out, thereby linking the customer's identity to the items purchased during a particular transaction. Some third-party solution-providers, such as OpenTable®, take a similar approach by requiring users to establish online identities, which can be integrated with a restaurant owner's existing reservation system. However, these solutions cannot capture the activities of those customers who do not sign up for loyalty cards, or those without an online identity.
Hence, there exists a need to help merchants to identify customers seamlessly during business transactions, without any third-party add-ons or any additional steps necessary by the customers.
The systems and methods described herein include, among other things, systems and methods for identifying customers through their payment information and associating the customers with their ongoing activities at various merchants. Insights may be gained as to what merchants can do to improve the experiences of their customers. While some existing solutions may analyze payment, ticket, menu, labor, or reservation data in isolation, the present systems and methods stitch the various data sources together in a way that individual behavior can be reliably tracked over time. Subsequently, the merchant may discover insights about how various factors under the merchant's control may impact customer retention.
A number of different types of systems and methods will be described with reference to certain figures. However, it is to be understood that these figures are only for illustrative purposes and that other systems and methods may be employed without departing from the scope of the invention.
In one particular system and method described herein, a customer-identifying system includes a merchant POS terminal that can interface with electronic payment mechanisms. The merchant POS terminal may additionally store POS data and run one or more extraction software for retrieving and encrypting the POS data. The merchant software may run on the merchant POS terminal or on a back-office computer connected to the terminal. In an implementation, the merchant POS terminal may be coupled to a payment processor, such as a networked server by First Data®, which generates payment data by interfacing with the payment mechanism of the merchant POS terminal. The payment processor and the extraction software running on the merchant POS terminal may make available the payment data and the POS data, respectively, to a secure server, such that the secure server may poll the payment data and the POS data on a periodic basis. In some embodiments, instead of a polling mechanism, the POS data and the payment data may be streamed in real-time or near real-time from the merchant POS terminal to the secure server. Alternatively, a notification-based system may be implemented, in which the POS data and the payment data are processed and forwarded to the secure server as soon as they are received by the merchant POS system. In some implementations, additional data, such as reservation data, may be polled from third-party services such as online reservation platforms. Alternatively, instead of a polling mechanism, the additional data may be streamed in real-time or near real-time from the online reservation platforms, or be forwarded from the online reservation platforms in a notification-based system.
In some embodiments described herein, one or more services may be provided at the secure server that maps and matches the received POS data and payment data into data clusters. Correlations may be drawn based on common parameters such as names, transaction dates and times, and transaction identifiers. The identity of the customers associated with the POS data and the payment data may be generated based on the data clusters. The customers' identities, payment data, POS data, and any other information may be stored in a data storage of the secure server and be used to compute consumer metrics associated with the identified customers.
In an implementation, the consumer metrics may be dynamically compiled into reports based on the need of the user (e.g., a merchant/retailer), which may be displayed on the user's electronic device.
The methods described herein can be a computer process of any type including a computer program, an application (i.e., app), an application as a service, or any suitable computer program.
The systems and methods described herein are set forth in the appended claims. However, for purpose of explanation, several embodiments are set forth in the following figures.
In the following description, numerous details are set forth for purpose of explanation. However, one of ordinary skill in the art will realize that the embodiments described herein may be practiced without the use of these specific details. In other instances, well-known structures and devices are shown in block diagram form to not obscure the description with unnecessary detail.
The systems and methods described herein include, among other things, computer systems that identify customers using payment and reservation data. The systems extract attributes such as customer names, menu items, and labor data from a merchant's POS system. In addition, the systems connect to third-party solution-providers such as OpenTable® to extract reservation information associated with customers who have established online identities.
In one implementation, the systems maintain one or more data processing servers and data warehouses with a secure cloud service, such as Amazon Web Services (AWS). Various attributes and data extracted from the merchant's POS system and the third-party solution-providers are then matched and analyzed on the secure cloud service.
To present the analytics to the merchants, a suitable web service (such as Amazon Web Services) and a mobile application may be implemented. This enables the conception of marketing strategies to promote specific menu items and of training plans to improve server performance.
The depicted merchant POS 108 may include a payment mechanism 102 and a data repository, such as POS datastore 104. The payment mechanism 102 may accept electronic means of payment such as credit cards or Apple Pay. The POS datastore 104 may store POS data such as order tickets (including basic card information used in the order, such as cardholder name and last four digits of the card number), ticket open and close times, menu items ordered, staff associated with the tickets, table numbers, reservations, and any other ticket information associated with the business transaction. In some embodiments, the ticket information may otherwise be known as check information. The POS datastore 104 may be locally implemented on the merchant POS 108. Alternatively, in the case of a cloud-based merchant POS system, the POS datastore 104 may be located remotely on a cloud server. The merchant accepts payments by integrating its payment mechanism 102 with a third-party payment processor 110, such as First Data®. In some implementations, the payment processor 110 may not be a third-party service, but instead is integrated into the merchant POS 108. Payment data may be sent by the merchant POS 108 to the payment processor 110 via proprietary protocols, and the protocols used may depend on the POS system in use. The parameters of the payment data may include for example: time, date, and amount of a transaction as well as credit card numbers. The payment processor 110 facilitates transactions and payments in a secure environment by connecting to credit card associations to authorize and settle payments. In some implementations, the payment processor 110 may also include functionalities such as fraud detection, customer loyalty programs, and mobile payments. After authorizing and settling a credit card transaction, the payment processor 110 generates credit card reports containing the payment data and makes the credit card reports available to the POS 108 via a secure protocol, such as SSH File Transfer Protocol (SFTP).
Extraction software, such as extraction software 106, may extract POS data from POS datastore 104 at particular intervals, such as once a day or any suitable time interval. In one implementation, the extraction software 106 may be locally installed on the merchant POS 108 to securely retrieve the POS data saved on the POS datastore 104 and transmit the POS data to a secure data storage, such as secure data warehouse 116. Alternatively, if the POS datastore 104 is implemented on the cloud, the POS datastore 104 may post the POS data to the secure data warehouse 116 by way of an application programming interface (API). Sensitive information such as credit card numbers are typically encrypted, hashed, and tokenized in order to ensure compliance with the PCI Data Security Standard (PCI DSS).
Notably, as a security measure, credit card numbers are not typically used directly in identifying customers. Instead, the credit card numbers polled from the credit card reports are hashed by a one-way hash function so that multiple transactions using the same credit card can be linked. In some implementations, the credit card number associated with a first transaction is hashed to a unique hash value. In a subsequent (second) transaction, the same credit card number is hashed again and the same hash value is obtained. By matching the two hash values, the first and second transactions will become linked. As an added measure of security, the one-way hash values are not communicated to or used in any other parts of the system once a link has been made across transactions. Instead, a generated token having a one-to-one relationship with the credit card number may be used as a secure reference. In some embodiments, the token may be generated randomly, by an application of a one-way hash function, truncation, or any other suitable tokenization mechanism. In some implementations, once multiple transactions are linked by the same one-way hash value, a corresponding randomly-generated token is looked up and associated with the transactions. In some implementations, the last four digits of the credit card number may also be associated with the transactions for verification purposes. By using a randomly-generated token rather than the one-way hash value, references to credit card numbers are securely protected against possible reverse hashing.
The secure data warehouse 116 may be a data processing environment that can be implemented on a secure cloud service, such as AWS. An exemplary secure cloud service 230 implemented using AWS is shown in
The credit card reports generated by the payment processor 110 may be available for download via an SFTP server. In some implementations, the payment aggregator 232 downloads the credit card reports from the SFTP server at regular intervals. From the credit card reports, relevant information such as payment data may be parsed and stored into a normalized data structure by Amazon EC2. Additional relevant data extracted by the extraction software 106 may be transmitted to the ticket endpoint 231 via Hypertext Transfer Protocol over Secure Socket Layer (HTTPS). As discussed above, sensitive information may be further encrypted prior to being transmitted to ensure PCI DSS compliance.
Auxiliary data sources, such as reservation datastore 112, may also be incorporated into system 100 by integrating with third-party solution-providers such as OpenTable®. A merchant may receive reservation data from reservation datastore 112 with reservation services 114 over SFTP in a number of formats, including Comma-Separated Values (CSV). Alternatively, the reservation data may be captured locally within the merchant's store environment, thereby bypassing the reservation services 114. For example, each time when a pre-shift reservation report from OpenTable® is printed at the merchant's store, the reservation data contained within the report may be captured by a printer firmware and saved locally. This allows the merchant to obtain and monitor its reservation data without having to interact with any third-part interface.
Once the various data is stored in the raw data storage 234 as described above, a suitable big-data algorithm, such as Map-Reduce, may be applied to aggregate the various data into a complete set representative of each customer visit. In one implementation, the big-data algorithm is carried out using Amazon EMR. For example, the big-data algorithm may match POS data, OpenTable® reservation data, and payment data during each customer visit by comparing various identifiers, such as timestamps, dollar amounts, partial credit card information (e.g., cardholder names and last four digits of credit cards), and table data. In some implementations, false detection or collision may occur during the matching process, and a number of supporting mechanisms are in place to resolve the matching conflicts. For instance, consumers may enroll credit card numbers and their names independently of the payment system, which can be used to resolve duplicates in the matching process. As another example, the system may identify suspected duplicate profiles for the same customer. This identification can be done by comparing POS parameters to correlate highly, such as more than one standard deviation, may be flagged and presented to the merchant to allow the merchant to visually inspect such matched profiles and consider combining the matched profiles into a single profile. This system may allow the merchant to manually de-duplicate customer profiles. Alternatively, cardholder names may be used to de-duplicate multiple card numbers associated with a single name.
For the embodiment depicted in
As described above, the database systems 250 and 252 are typically two separate systems. The POS system 108 stores table 250 that contains the POS data. The POS data includes the data that can be captured by the POS system. The POS system is usually an electronic sales system that collects data about the transaction, and the collected data provide parameters that describe the transaction. As shown in
The POS systems 108 may include a credit card payment system 102 that allows the merchant to have the credit card account number read into the POS system 108, typically by using system 102 that has a magnetic stripe on the credit card. The credit card data is transmitted, as described above, to a payment possessor 110 that can make the payment and record the debit owed by the entity associated with the processed credit card number. The data associated with the debit owed can be recorded by the credit card company as parameters in the secure table 252. These parameters can include the identity of the entity associated with the account, such as the name and the address, the date of the transaction, the cost of the transaction, the time of the transaction and any other data captured as part of processing the payment.
In
In the embodiment depicted in
After the matching-conflict resolution process, a number of supporting algorithms may be implemented to analyze the matched data clusters for each customer visit. For instance, Amazon EMR may compute multiple customer visits by using an elastic Map/Reduce cluster and a redshift service. In general, the matched data set for each customer visit may be used to compute consumer metrics (i.e., compute visits 118) such as retention, menu item price, cost, profit, server name, item popularity, major/minor item category, number of covers at a table, sales per cover, tip percentage, table-turn time, or server shift times. Lastly, the computed consumer metrics may be grouped by a particular dimension, such as a menu item, a server, or a time of day, in order to identify business insights (i.e., compute insights 120).
The merchant may access the identified business insights through any web client, such as customer device 124. The presentation of business insights may be powered by web service 122 running Ruby on Rails or a similar proprietary platform. In some implementations, the web service 122 is run by web server 240 of
For example, the retentive power of a restaurant menu item such as “Fish Tacos” may be computed. In one such analysis, the system stores credit card Primary Account Numbers (PANs) as the payment identifier parameter. The system can identify ticket information that represents the purchase of Fish Tacos. The process can then analyze retentive power, in one practice, by mathematically comparing the number of distinct PANs that returned for Fish Tacos with the overall number of PANS that show the purchase of Fish Tacos as follows:
Such analytics enables the merchant/retailer to conceive marketing strategies to promote specific menu items, and of training plans to improve staff performance. As an example, products having a high retention power and low sales volume may deserve more marketing attention because their uninspiring performance is very likely due to a lack of publicity.
The above-described system architecture offers a number of benefits that were previously unavailable to merchants. For example, the systems and methods described herein allow a merchant to determine whether a particular customer, as identified by their credit card number, ever returned to the merchant, or whether customers who order a certain dish are more likely to return than others. In general, the merchant may identify any factors that impacted a customer's experience, and infer the impact that experience had on the customer, as judged by their likelihood of returning. Furthermore, the systems and methods described herein allow the merchant to interact with a customer in real time. For example, a merchant can recall a customer's identity and profile information whenever she makes a payment or signs in for a reservation. This allows the merchant's staff to greet and interact with the customer in a more powerful way, by automatically recalling the customer's history, personal information, and preferences.
It will be apparent to one of ordinary skill in the art, that although
Plot 303 is an exemplary plot of Retention (customers who returned) vs Popularity (total orders), in which each plotted data point represents a menu item. The plot area of plot 303 is divided into four quadrants that can be used to categorize and label menu items (e.g., “Hidden Gems”, “Underperformers”, “Greatest Hits”, or “One Hit Wonders”). As discussed above in relation to
Table 304 presents the additional information associated with the menu items illustrated in plot 303. In table 204, each menu item is listed against its corresponding Total Orders, Customer Retention Rate, Category, or Time between Visits (days). Together, plot 303 and table 304 allow the merchant/retailer to conceive targeted strategies to promote specific menu items.
In an implementation, the merchant/retailer may select an appropriate menu item class, such as Entrees, by which to filter their menu items. Each menu item's popularity is computed by counting the number of orders that appear on POS ticket records over a preset time period, and retention is determined by computing the percentage of customers who have returned to the restaurant, as identified by their credit card number, after ordering a particular menu item. In table 204, all menu items are categorized according to percentiles for popularity and retentions. The categories may then be used to deduce business insights: items with high retention and high popularity are greatest hits that support the business; items with low retention and low popularity are underperformers that may be removed from the menu; items with high retention and low popularity are hidden gems, the sales of which may be significantly improved with targeted marketing and promotion efforts; and items with low retention and high popularity are one-hit wonders that deserve further investigation—perhaps the item should be cut from the menu, or perhaps the item should be improved to make a better impression on customers.
POS data (including order tickets) and payment data are separately received by ticket endpoint 231 and payment aggregator 232, respectively. Once the POS data and the payment data are securely stored, computational resources 236 performs elastic map/reduce algorithm to generate data clusters representative of each individual visit by Nathaniel Painter In one implementation, the elastic map/reduce algorithm first maps POS data and payment data using a (store, day) key, and then reduces the matched data by comparing date, time, amount of transaction, and the last four digits of the credit card number used in the transaction to assign the reduced data set to a customer ID. As a result, data clusters representative of individual visits by Nathaniel Painter (associated with the customer ID) is saved in raw data storage 234. Two additional computations may be performed on the customer data clusters to arrive at the CRM information displayed in the web report 800. First, an additional elastic map/reduce algorithm may be implemented to compute distributions for merchant stores across multiple customers. This additional elastic map/reduce algorithm establishes store-level benchmarks for the merchant/retailer. Second, a redshift service can be employed to compute customer analytics. In an implementation, the redshift service counts the total number of visits over a time frame, sums the total sales, total covers, and tip over the same time frame, and calculates the maximum and minimum visit times for the first and the latest visit for Nathaniel Painter. Both the store-level benchmarks and the customer analytics are then sent to the web server 240 to be arranged in a web report format. As a result, the customer scorecard as shown in the web report 800 is available for display, which illustrates the total sales, dollar amount of average purchases, total visits, and other CRM data associated with Nathaniel Painter.
At 1012, a merchant/retailer can review reports on various consumer metrics displayed on a client device, such as those shown in
Some embodiments of the above described may be conveniently implemented using a conventional general purpose or a specialized digital computer or microprocessor programmed according to the teachings herein, as will be apparent to those skilled in the computer art. Appropriate software coding may be prepared by programmers based on the teachings herein, as will be apparent to those skilled in the software art. Some embodiments may also be implemented by the preparation of application-specific integrated circuits or by interconnecting an appropriate network of conventional component circuits, as will be readily apparent to those skilled in the art.
Some embodiments include a computer program product comprising a computer readable medium (media) having instructions stored thereon/in and, when executed (e.g., by a processor), perform methods, techniques, or embodiments described herein, the computer readable medium comprising sets of instructions for performing various steps of the methods, techniques, or embodiments described herein. The computer readable medium may comprise a storage medium having instructions stored thereon/in which may be used to control, or cause, a computer to perform any of the processes of an embodiment. The storage medium may include, without limitation, any type of disk, flash memory devices, or any other type of media or device suitable for storing instructions and/or data thereon/in.
Stored on any one of the computer readable medium (media), some embodiments include software instructions for controlling both the hardware of the general purpose or specialized computer or microprocessor, and for enabling the computer or microprocessor to interact with a human user and/or other mechanism using the results of an embodiment. Such software may include without limitation device drivers, operating systems, and user applications. Ultimately, such computer readable media further includes software instructions for performing embodiments described herein. Included in the programming (software) of the general-purpose/specialized computer or microprocessor are software modules for implementing some embodiments.
Suitable operating systems, databases or servers may be integral to the cloud system on which, for example, secure data warehouse 116 is implemented. The operating systems, databases and servers can be any suitable systems, including commercially available solutions or customized solutions. In addition, these systems may be supported by any suitable persistent data memory, such as a hard disk drive, RAID systems, or any other suitable hardware options. The design and development of suitable operating systems, databases, and servers are known and understood by those of ordinary skill in the art.
Those of skill would further appreciate that the various illustrative logical blocks, modules, techniques, or method steps of embodiments described herein may be implemented as electronic hardware, computer software, or combinations of both. To illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described herein generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the embodiments described herein.
The various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein.
The techniques or steps of a method described in connection with the embodiments disclosed herein may be embodied directly in hardware, in software executed by a processor, or in a combination of the two.
Accordingly, it will be understood that the invention is not to be limited to the embodiments disclosed herein, but is to be understood from the following claims, which are to be interpreted as broadly as allowed under the law.
This application claims priority to U.S. Provisional Application No. 62/000,076, entitled SYSTEMS AND METHODS FOR IDENTIFYING CUSTOMERS USING PAYMENTS DATA, filed May 19, 2014 and naming Matthew Gillooly, Dan Hodge, Anthony Accardi, and Angus M. Davis as inventors, the contents of which are incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 62000076 | May 2014 | US |
