25
July
2014

mPOS as a Recommendation Agent

Abstract

This paper takes a plunge at explaining a new method that increases the possibility of receiving in-store recommendations automatically in a personalized manner through a mobile transaction agent, referred as mPOS. To establish the fact that mPOS can be used effectively as a recommendation agent, we have relied on a modified version of the well-known Apriori data-mining algorithm that takes into account transaction logs of an mPOS agent. Our analysis of the empirical data would show that mPOS can be used as an agent to deliver the tailored recommendation to customers, based on their preference and purchasing behavior.

INTRODUCTION

Receiving Recommendation through mPOS

With the advent of proximity marketing from the pages of theory to an increasingly popular practice, it has become important to understand how big transaction repositories like mPOS can be transformed effectively into user-adapted recommendations agent. In order to receive a transparent look at the transformation, we need to explore the rules of association between these two apparently diverse domains. Using the basics of Apriori Data mining becomes relevant for this very reason. The data mining process, within the context of this paper, has become the major tool to discover the association through the segmentation technique model, also described as Buying Behavior Segmentation. Furthermore, an efficient implementation has been performed to obtain results in real-time. As soon as a user closes his session in the transaction agent, all data are recalculated to take the recent interaction into account for the next recommendations.

Theory of Location Based association

Geographic Segmentation

The geographic segmentation process is done by updating the dataset with IP address from the location obtaining agent that mPOS already contains. Every merchant outlet has a unique IP address that is coupled with the merchant management system. The merchant management system keeps storing shopping basket data and the segmentation of the same is done in accordance with the geographical location with the help of IP address. Later, the shopping basket data can be used for creating recommendation alerts as the algorithm takes into account the geographically segmented data.

Buying Behavior Segmentation

Model Description

Behavior segmentation is an essential part of modern marketing that takes into account customers’ purchasing behavior, based on their lifestyle, pattern of usage and the modes in which they spend money. Buying behavior segmentation is one of the pillars without which the idea of proximity marketing cannot have a proper foundation. The proposed model of Buying Behavior Segmentation, at the first place, attempts to calculate most common items that customers have purchased most frequently. The calculation is done by taking into account products from cross categories. Results of the calculation are categorized accordingly from the highest to the lowest order. Once this is done, buying behavior segmentation model attempts to formulate a rule of association for predictive bundled items (category wise) that can be sold together. At this stage, by including user id with the results helps with the creation of customer profiles. Creation of customer profile database with the help of buying behavior segmentation model is used for recommending, 1. Merchants with bundle Items profiling, customer profiling, faster Checkout, and 2. Shoppers with suggested items as per their associated profiling, automatic payment upon authentication

Data Description:

1. Category

No. ABB Category
1 A FRUIT
2 B Bread
3 C Vegetables
4 D Magazines
5 E Yoghurt & Curd
6 F Milk
7 G Chocolate
8 H Soft Drinks
9 I Beer
10 J Cigarettes
11 K Cheese
12 L Juice
13 M Butter
14 N UHT Milk
15 O Fat & Oil 1055
16 P Soups & Sauces
17 Q Tinned Sour Food
18 R Water
19 S Spices & Mustard
20 T Sweets
21 U Snacks & Crisps
22 V TOYS
23 W GIFTS
24 X Category
25 Y Category
26 Z Category

 

Transactional Cart Data

No TID Transaction id(tid) Shopper id Category based Cart Sets(TABLE 1.0)
1 4 TKTPOS0001 1006 NLH
2 9 TKTPOS0002 1001 POO
3 4 TKTPOS0003 1002 DEF
4 3 TKTPOS0004 1008 FJZ
5 8 TKTPOS0005 1006 HWB
6 10 TKTPOS0006 1005 XRA
7 2 TKTPOS0007 1008 LGM
8 7 TKTPOS0008 1005 DHO
9 4 TKTPOS0009 1003 SCW
10 8 TKTPOS0010 1001 OMR
11 2 TKTPOS0011 1009 WHX
12 7 TKTPOS0012 1010 UHP
13 6 TKTPOS0013 1010 NZZ
14 4 TKTPOS0014 1007 XDQ
15 3 TKTPOS0015 1002 JTU
16 10 TKTPOS0016 1009 IPM
17 10 TKTPOS0017 1007 SOA
18 9 TKTPOS0018 1010 HUY
19 3 TKTPOS0019 1001 SFB
20 6 TKTPOS0020 1004 RCQ
21 6 TKTPOS0021 1010 MNU
22 6 TKTPOS0022 1008 LJV
23 3 TKTPOS0023 1006 SGV
24 5 TKTPOS0024 1002 DBE
25 6 TKTPOS0025 1010 UFY
26 5 TKTPOS0026 1009 COE
27 9 TKTPOS0027 1002 EIU
28 6 TKTPOS0028 1005 LOW
29 7 TKTPOS0029 1009 JVB
30 6 TKTPOS0030 1000 WZX
31 8 TKTPOS0031 1003 UJW
32 9 TKTPOS0032 1000 AZO
33 8 TKTPOS0033 1001 RXN
34 10 TKTPOS0034 1000 EOH
35 9 TKTPOS0035 1001 KAU
36 2 TKTPOS0036 1010 DQA
37 9 TKTPOS0037 1010 CLA
38 7 TKTPOS0038 1003 QUD
39 10 TKTPOS0039 1004 NNS
40 1 TKTPOS0040 1006 STY
41 4 TKTPOS0041 1000 DCH
42 3 TKTPOS0042 1008 YDW
43 10 TKTPOS0043 1002 AAJ
44 3 TKTPOS0044 1000 JWU
45 1 TKTPOS0045 1010 ONY
46 5 TKTPOS0046 1004 KHA
47 4 TKTPOS0047 1009 QQY
48 4 TKTPOS0048 1003 OGV
49 1 TKTPOS0049 1000 CKF
50 5 TKTPOS0050 1010 YIY
51 3 TKTPOS0051 1010 TZK
52 8 TKTPOS0052 1004 VDW
53 1 TKTPOS0053 1008 JOO
54 5 TKTPOS0054 1004 YPY
55 6 TKTPOS0055 1005 GFR
56 5 TKTPOS0056 1001 LCK
57 7 TKTPOS0057 1005 ZJN
58 7 TKTPOS0058 1007 MKY
59 8 TKTPOS0059 1007 QYK
60 3 TKTPOS0060 1000 GOJ
61 9 TKTPOS0061 1010 TYP
62 3 TKTPOS0062 1006 ILC
63 7 TKTPOS0063 1000 KYU
64 3 TKTPOS0064 1002 VJL
65 7 TKTPOS0065 1008 JHC
66 5 TKTPOS0066 1009 KKN
67 6 TKTPOS0067 1007 ESZ
68 2 TKTPOS0068 1001 SYN
69 8 TKTPOS0069 1004 ZLL
70 10 TKTPOS0070 1001 HQM
71 1 TKTPOS0071 1003 SNE
72 8 TKTPOS0072 1007 JNZ

 

Mining combination of most frequent Data Sets

The table 2 contains simulated transactional data sets with mPOS terminal id, transaction id, shopper id (beacon-id & email/phone & biometric) and shopping basket item sets with cross category levels only.

Representing Shopping Basket Data

We assume that Category based cart sets, mentioned in TABLE 2, are stored in a file, basket-by- basket. The cart sets can also be stored in a distributed file system where baskets become the objects in the file or can be treated as a conventional file along with a character code, representing basket and the item sets. Let us say the basket format in the conventional file be the following: { N,L,H} {P,O,O} { D,E,F}……….. Now, let us assume that the average size of the basket is small and it can contain data from maximum 3 categories. Please note that we will be considering 3 as the average value for N number of transactions on Y number of TIDS. We have consciously avoided from including item/product codes, as they will comprise into a large datasets, resulting in BIG O problem. However, you will see in the subsequent model that the problem with BIG O problem, even with large datasets, has been completely solved. It means memory usage will be less while storage and mining computer program is written. Our opting for average case complexity will let the model ignore any large size datasets, greater than 3. 

Model Definition

Function f(T)= { i € I | ?t € T , i € t } Returns all the item sets included in the set of transactions T h(I)= {t € T | ?I € I , i € t } which returns the set of transactions supporting a given item set I (its id- list )

Support

We have to calculate equivalent item sets, which contain elements of same transaction set. The support of an item set (I) is defined as the proportion of transactions in the data set that the item set contains. Support (I)= count f(T)/count ?t=h(I) Let us explain with an example in Table 2

Item Support
A 4
B 3
C 5
D 5
E 6
F 4
G 3
H 5
I 4

Each number corresponds to a product such as "category." The first step is to count up the frequencies, also referred as supports, of each member item separately. We can define the minimum support level to qualify as “frequent," based on the context. For this case, let the minimum support be 4. Therefore, all are frequent. In the next step, we should focus on generating list with all 2-pairs of frequent items. However, it is important to note that no item that hasn’t been frequent, would be included in the list of potential members of the 2-item pairs list. In this way, model prunes the tree of all possible sets. In next step we again select only these items (now 2-pairs are items) which are frequent (the pairs written in bold text):

Item Support
A,B 4
C,B 3
E,F 5
K,B 5
C,M 6
G,H 4
D,M 3
I,K 5
L,M 4

The algorithm ends here because none of the 3-triples has the desired support. Basics of A-priori algorithm has been used to develop the above framework. Customer Profiling Engine based on Shopping Basket Analytics The entire transaction log is modeled as a tree where the nodes represent different ids. The first step will be to create a transaction id similarity tree.

Receiving Mobile Recommendation In-store

Similarity Tree

The model tree is similar to a transaction directory, where edge connects one node to another, provided that the transaction id corresponding to the latter node is hierarchically located. Let’s say there are Ith and Jth transactions. Now, they can be in similar node chain only when they have the following parameters in common and in order of parent child relation. 1. Creation of master/parent transaction profiles using only frequent item sets (calculated from Apriori algorithm, over a period of time 2. Frequent item sets with maximum ids (as a set) will be considered as parent id set 3. Associating location id dataset to the transaction profile and creation of location based transaction profile 4. Transaction “I” matches 1 5. Transaction “J” matches 1 6. Transaction “J” will become child only when it’s done at a later time or doesn’t have location id (point 2) information 7. “J” will precede “I” if “J” has customer information matching the base transaction profile set 8. Transaction “I” and “J” are parts of the same chain.

similarity_tree

For better performance, transactions having common area greater than 50% will be considered.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>