If you provide your data in the Standard Data Format, your feeds need to comply with both the Customer Data Platform (CDP) standard schemas and logic. Do your feeds pass all the questions below? If so, your data follows the CDP standard! If not, please refer to the detailed sections to see how to map your data or ask your Implementation team.
STN = SourceTransactionNumber, the unique ID of the Transaction entity
STIN = SourceTransactionItemNumber, the unique ID of the Transactionitem entity
SPN = SourceProductNumber, the unique ID of the Product entity
SON = SourceOrganizationNumber, the unique ID of the Organization entity
SCN = SourceCustomerNumber, the unique ID of the Customer entity
MCID = MasterCustomerID, the unique ID of the customersummary entity. This is the new customer number once we have de-duplicated customer records.
| Standard | Generic Items |
You are only providing these feeds and they follow the standard format: |
|
| The standard feeds are in the expected file format: OpenCSV, special characters are escaped, tab or comma separated, text qualifiers, UTF-8 Without BOM encoding, naming convention, no encryption or PGP or GPG, available via sFTP | |
| The standard feeds are incremental (each file contains only new or modified records. Each ID in a file should show the last status) | |
| The transaction data comes from a single source system. | |
| There is only one marketing brand | |
| There is only one country | |
| There is only one website | |
| There is only one currency | |
| There is only one language | |
| Standard | Transactions |
| All transactions are Purchasese.g. no rentals, no samples/swatches, no options, no pickup, etc. | |
Only one customer is assigned to each transaction. e.g. no gifter/giftee, no buyer/traveler, no buyer/person picking up distinction |
|
| The SourceTransactionNumber field (STN) is the unique ID of your transaction feed | |
| The SourceTransactionItemNumber field (STIN) is the unique ID for you transactionitem feed | |
All items are either Shipped or Returned No Demand line, no Discount line, no Shipment line, no Deposit line, no Voided line, no Installment line, no accounting magic |
|
| If a customer exchanges a product, you use the same transaction number as in the original order ; otherwise you understand that the customer will be considered a repeat buyer because he now has 2 different transaction numbers associated to him. | |
If an item goes through different phases before it reaches the customer, all these will be updates of the same line item (i.e. same STN and same STIN). Not different STINs. e.g. If an item goes from Pending to Approved to Fulfilled to In transit to Delivered the latest status details can be stored in a custom status field but it should always be updates to a same line ID with the SubType = Shipped. |
|
| The STN is the same between the Shipped line and the Returned line ; otherwise you understand that the customer will be considered a repeat buyer because he now has 2 different transaction numbers associated to him. | |
| The STIN is different between the Shipped line and the Returned line | |
| The +/- symbol for Shipped lines is always + for SaleRevenue, Quantity, Cost, Discount, Tax | |
| The +/- symbol for Returned lines is always - for SaleRevenue, Quantity, Cost, Discount, Tax | |
| Gift card purchases are passed with revenue = 0 | |
| Item-level discounts are taken into account in the SaleRevenue field for Shipped/Demand/Returned/Canceled lines | |
| Order-level discounts are pro-rated and are taken into account in the SaleRevenue field for Shipped/Demand/Returned/Canceled lines | |
| Standard | Specific format issues |
All the dates are provided in a common format e.g. birth date, order date, line date, email signup date, loyalty signup date, store close date |
|
All the dates are provided in a common timezone e.g. birth date, order date, line date, email signup date, loyalty signup date, store open date |
|
No free-form field e.g. no “reason to unsubscribe” or “comment” field |
|
| The Country & CountryCode fields in the address and organization feeds are provided in ISO format | |
| The SourceOrganizationNumber field is populated both in the transaction and transactionitem entities. | |
| There is only one product category hierarchy being sent. | |
| The customer Email field does not contain dummy values (e.g. none@none. com) nor any value that you want to exclude from deduping (e.g. reseller or store values) | |
| The customer PrimaryPhone, SecondaryPhone, MobilePhone fields do not contain dummy values (e.g. 1111111111) nor any value that you want to exclude from deduping (e.g. reseller or store phone numbers) | |
| The customer Address fields do not contain dummy values (e.g. n/a or refuse or 00000) nor any value that you want to exclude from deduping (e. g. store address) | |
| Standard | Customers |
We will only dedupe on
|
|
| There is only one email address to keep per contact | |
The Loyalty information is pass-through and the logic to merge Loyalty information into the master record is to use the latest values. e.g.: there are no loyalty points or loyalty levels to combine |
|
| Standard | Email data |
| There is only one email execution system provider | |
| You reviewed the ESP standard connector documentation and we can use both the input and output standard connector for your ESP. | |
| The email system provider is the unique source of truth for the email subscription status | |
| There is a unique subscription status |
53 State Street, 10th Floor
Boston, MA 02109
United States
Phone: 888-922-7842