Standard Data Format
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. |
Allowlisting IP addresses
To access SFTP storage locations in Customer Data Platform (CDP), your IP must be on Acquia’s allowlist.
If you encounter errors such as Network timeouts while trying to establish a connection, try to connect from an allowlisted IP address. Ensure that you complete the following prerequisites before contacting Acquia Support.
Prerequisites¶
IP address is public:
Public IP addresses can be accessed from outside the network whereas private IP addresses cannot be accessed from outside the network. Ensure that your IP address is public. To locate your public IP, see What is my public IP?.
Acquia cannot allowlist a private IP address. The following is the range of private IP addresses:
192.168.0.0 - 192.168.255.255 172.16.0.0 - 172.31.255.255 10.0.0.0 - 10.255.255.255IP address is static:
Perform an Internet lookup for the IP address to ensure that the address is static. Acquia does not allowlist dynamic IP addresses because the IP can change and that voids the allowlisting.
To check the type of your IP address:
- Go to Look up IP Address Location.
- Enter your IP address and click Get IP Details.
- Check the value for the Assignment parameter.
Unblocking SFTP access:
Check your Firewall or VPN settings to ensure that they do not block SFTP access. Test connections by using other SFTP clients to verify if the issue is related to your SFTP client. For more information about the public SFTP servers, see Free Public SFTP Servers.
Informing Acquia about allowlisted but unused IP addresses:
If you were using a legacy IP address to access the SFTP storage and want to use a different IP address now, inform your customer value manager (CVM) about the old allowlisted IP address.
IP Allow-listing Range Limits:
CDP supports a subnet mask range of 22 to 32.
The notations are as follows:
- /24 denotes a subnet mask that enables the usage of 256 IP addresses.
- /23 denotes a subnet mask that enables the usage of 512 IP addresses.
- /22 denotes a subnet mask that enables the usage of 1024 IP addresses.
The /17 range results in the usage of a significantly large number of IP addresses, increasing the potential security concerns. Therefore, CDP does not support the subnet masks in the /17 range to avoid exposing the systems to a large number of IP addresses.