If you provide your data in the Standard Data Format, your feeds must comply with the standard schemas and logic of Customer Data Platform (CDP). You must also ensure that the feeds adhere to the CDP standard. If not, see the detailed sections to know how to map your data or contact your implementation consultant.
Notations
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 after de-duplication of customer records.
Checklist
| Standard | Generic items |
You are only providing the following 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 must 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 purchases. For example, no rentals, no samples or swatches, no options, and no pickup. | |
| Only one customer is assigned to each transaction. For example, no gifter or giftee, no buyer or traveler, no buyer or person picking up distinctions. | |
| 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, the customer is considered a repeat buyer because two different transaction numbers are associated with the customer. | |
If an item goes through different phases before it reaches the customer, all updates are of the same line item, that is, same STN and same STIN. For example, if an item goes from Pending > Approved > Fulfilled > In transit > Delivered, you can store the latest status details in a custom status field. It must always be updated to the same line ID with SubType = Shipped. | |
| The STN is the same between the Shipped line and the Returned line. Otherwise, the customer is considered a repeat buyer because two different transaction numbers are associated with the customer. | |
| The STIN is different between the Shipped line and the Returned line. | |
| The +/- symbol for Shipped lines is always + for SaleRevenue, Quantity, Cost, Discount, and Tax. | |
| The +/- symbol for Returned lines is always - for SaleRevenue, Quantity, Cost, Discount, and 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. For example, birth date, order date, line date, email signup date, loyalty signup date, and store close date. | |
| All the dates are provided in a common timezone. For example, birth date, order date, line date, email signup date, loyalty signup date, and store close date. | |
| No free-form field. For example, no “reason to unsubscribe” or “comment” field. | |
| The Country and 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 and any value that you want to exclude from de-duping. For example, reseller or store values. | |
| The customer PrimaryPhone, SecondaryPhone, MobilePhone fields do not contain dummy values and any value that you want to exclude from de-duping. For example, reseller or store phone numbers. | |
| The customer Address fields do not contain dummy values and any value that you want to exclude from de-duping. For example, store address. | |
| Standard | Customers |
CDP only de-dupes:
| |
| 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, For example, there are no loyalty points or loyalty levels to combine. | |
| Standard | Email data |
| There is only one email execution system provider. | |
| You can use the input and output standard connectors for your Email Service Provider (ESP). For more information, see Email. | |
| The email system provider is the unique source of truth for the email subscription status. | |
| There is a unique subscription status. |