Spotler's Customer Prediction Platform uses 3 types of Data:
- Customer Data
- Transaction Data
- Activity Data (Optional)
Customer Data
The Customer Table contains details of your Customers. This table has two mandatory fields: customer_id (string) and customer_since (date). You can also add additional data present in your Customer records, which can help improve accuracy of your Models.
The customer_id field is the primary key of this table. Each data record must have a Unique value for this field.
| Field Name | Data Type | Example | Description |
*customer_id | String | e131498 | This is the key field, used for Identification of Customers. All values in this field must be Unique. |
*customer_since | Date | 2010-12-21 | Date of first contact with the Customer. This field is vital for future predictions, and every customer should have a value for this field. |
customer_gender | String | female Ms. LLC | Gender or Title of the Customer; Used as Categories for Pattern Recognition. |
| customer_age | Date | 1997-06-22 | Date of birth of Customer / Date of foundation of Customer company. Missing values are acceptable. |
zipcode | String | 50676 | ZIP code of the Customer. |
| customer_country | String | France DE | Country where the Customer is based; Used as Categories for Pattern Recognition. |
email_ending | String | gmail.com live.com | Customer's email address provider. If email is mapped to this field, the part before @ is automatically removed; Used as Categories for Pattern Recognition. |
| phone | String |
0153 | The starting digits of the Customer's phone number; Used as Categories for Pattern Recognition. |
Transaction Data
The Transaction Table contains details of Transactions made by Customers, such as Purchases and Returns. The Transaction table has 7 Mandatory fields, as this data is required for understanding the long-term Value of every Customer for better predictions.
The primary key for this table is the combination of 4 fields: customer_id, invoice_id, transaction_timestamp and item_number. In other words, for every transaction made by a customer at a given time, each record should contain a Unique item.
| Field Name | Data Type | Example | Description |
*customer_id | string | e131498 | The Customer ID; Unique identifier used for merging all tables. |
| *transaction_ timestamp | date | 2013-01-17 | Date and (optionally) Time of the Transaction. |
*invoice_id | string | i_1021 | Unique ID of every Order; Used to track different items in the same Order, or to match Orders with Returns. |
*item_number | string | 3 | Item number of each item in an Order. Must not be repeated within a single Order/Invoice. |
| *price | decimal | 29.99 179 | Unit Price per item. Can be Net / Gross / Discounted Price etc. |
| *order_type | string | sale return neutral | The Order Type ( Sale / Return / Neutral ) of each Order. By default, Sale is Positive, Return is Negative while Neutral is ignored. |
| *quantity | decimal | 3.5 -1 | Can be number of items ordered, or weight/volume. This is multiplied by price to get total value of Ordered Item. |
| gross_margin | decimal | 17.04 29 | Gross profit margin per unit. Can be used to select a Margin-based view instead of a price-based view. |
| order_channel | string | internet telephone fax in_person | Information about how the order was placed. The 6 values on the left are accepted by default. For passing more values, please reach out to customer support. |
| productgroup_id | string | clothing furniture | Category to which product belongs to. Ideally, this should not have more than 20 Unique entries. |
| productgroup_id2 | string | shirts shoes | A finer product group can be passed in this field to create finer NBO models in expert mode. |
| productgroup_id3 | string | t-shirts sneakers | In this field an even finer product group can be passed to create finer NBO models in expert mode. |
| product_id | string | p063 | This field is only used if referenced in expert mode. May then be used to compute product specific models. |
| return_reason | string | NULL wrong size | The reason for return or cancellation. |
| voucher | string | 8WBA2TV | The presence or type of a voucher can be stored here; Used as Categories for Pattern Recognition. |
| size | string | XL 12L | This field can be used for Prediction Models; It also serves as a feature to analyze frequency distribution of different sizes. |
| product_supplier | string | IKEA S123 | This field can be used for Prediction Models; It also serves as a feature to analyze frequency distribution of different Suppliers. |
Activity Data
To improve model and forecasting quality, you can upload additional tables that contain specific activities and interactions with your customers. These tables must each contain at least a unique customer ID, a timestamp, and an activity type. Additionally, an activity_id can be passed that links the activity to a specific action. However, this data is not required for an initial well working model and is therefore optional.
You can upload one or more of these tables:
- Online activities (customer in login area on your website / click in email)
- Inbound activities (customer calls call center, letters and emails from customer)
- Outbound activities (print mailings, catalogs, calls from a call center)
- Payment activities (customer pays an invoice, receives a dunning level, is referred to collections)
In order to make use of these activities in the modelling process, it is important that they are stored in the so-called event format (just like transactions). This means that each row in an activity table describes exactly one 'event' at a time with a customer.
| Field Name | Data Type | Example | Description |
| *customer_id | string | e131498 | The Customer ID; Unique identifier used for merging all tables. |
*activity_timestamp | date | 2015-01-13 | Date and (optionally) Time of the Transaction |
| *activity_type | string | CartAdd CartCancel | Used to generate patterns for the most common types. |
| activity_subtype | string | Trousers Black 4RTR3022DS | Can be used to generate additional patterns. |