The Ones & Zeros of E-Commerce, Part IV: Data Format & Delivery Methodology

Data is a foundational concept in commerce. It is arguably the most critical topic related to success. This blog series covers the different types of data that exist, the importance of data quality and ways data is prepared and transferred in e-commerce today — so you can make appropriate plans or changes to your relationship with data to build a greater chance of success. (Read Part I, Part II & Part III.)

—

Now that we’ve established solid ground regarding data in the context of e-commerce, and covered data quality and consistency, we now need to look to how that data is structured and delivered. At some point in your business life, you have likely interacted with an FTP to transfer data from one location to another. If you haven’t, then this should introduce you to some new ways to consider managing data transfers.

If your product data lives in a database on your server and you have processes to transform that data via your own CRM, or if employees spend time manually updating the data on your server, you should maintain a goal to deliver that same information over to Rithum (or any other partner who needs the data). If you do not do this through some level of automation today, you should consider the investment in automation to save time and effort, and ensure parity between your systems and partner systems.

Data Output Format & Methods of Transfer

Your business relationships often require you to communicate in a different way inside your organization versus outside. For example, the language spoken and jargon used within your office may differ from the language you need to use with a client or business partner. To properly convey ideas and plans externally, you need to speak a common language or follow some shared principles to convey information.

This is similar to the storage of data versus the output of the data. While it is stored in a particular language or format that may be specific to your business, it needs to be shared with business partner systems in a format and language both can understand and interpret.

Rithum supports a number of data formats for importing data — while more exist, we cover most of the popular data formats:

• Flat Files (.txt, .tsv, .csv)
• Excel (.xlsx)
• XML Files (.xml)
• XML

Jumping back to our human communication analogy… We have different methods to communicate at our fingertips — face-to-face, phone, text, email, chat programs and more. For our purposes, much of what we can communicate (transfer) allows us to choose any of these methods. 

Similarly, data has multiple mechanisms available to transfer data. Again, Rithum supports a number of very popular transfer methods, but there are more possible. In many cases, the format and method are directly linked based on what is supported by the organization. An organization may not support all formats with all methods, so it’s important to understand that while these are interconnected, the experience may be different from one organization to another.

• UI Upload — a user-interface to upload all supported formats except JSON.
• FTP (File Transfer Protocol) — typically a username and password protected location.
• FTPS (File Transfer Protocol Secure) — similar to FTP, with an additional layer of security. This is more secure than basic FTP.
• SFTP (SSH File Transfer Protocol) — similar to FTPS with a different type of security. This is also more secure than basic FTP.
• HTTP — optionally a username and password protected location.
• REST API — requires authorization, development and coding, but transfers data between locations directly.
• SOAP API – requires authorization, development and coding, but transfers data between locations directly.

The table below shows how different formats relate to the transfer methods in the context of Rithum’s system.

Encryption

Some businesses transfer data that is highly sensitive — financial institutions, insurance, or medical organizations may be top of mind — and they need to be very sure the data they transfer from one system to another is properly secured during connection, transport and after receipt. Encryption allows them to do this, and it ensures that the party receiving the data is authorized to access it. Sellers in e-commerce may benefit from encryption as well, and Rithum supports one of the two overarching methods of encryption when it comes to the transfer of flat file or XML data.

There are two levels on which encryption can happen:

1. Connection level — the transfer method used to send the file is secured to ensure the connection only happens between the sender and recipient of the data, and ensures the recipient is the intended connection. This is generally sufficient for most businesses outside those sharing the most critically sensitive data. Rithum supports this method via push of data to Rithum’s SFTP with SSH Public Key. 
2. File level — the file is encoded to ensure the right receiving party has a key to decode it. The file could be encrypted and sent over an insecure connection method, but still not readable to the receiver if they don’t have that key. Rithum does not support this type of encryption.

Communication Frequency

One of the more important concepts in data transfer is the frequency with which communication occurs. Do you need to communicate updates on all product data points every five minutes? Probably not — doing so might be costly from a time and processing perspective for your organization as well as your partners’. 

Consider how frequently data changes in your system. Limit the frequent deliveries to data that is changed regularly, and save the less important data points for a daily or weekly update schedule. Some data does need to be updated frequently — product quantity is the first thing that should come to mind. A separate upload with only product unique identifier and current quantity will process much more quickly than a large file with a lot of fields that are not changing. In addition, consider the time of year and adjust the upload schedule to keep up with your sales velocity during that time frame. For example, your quantity may need to be updated every five minutes to keep up with order volume if you are selling costumes in October.

This concept also applies to how Rithum and how often we are allowed to communicate with the channels we are connecting to on your behalf. Limits exist to ensure all sellers on that channel can benefit and prevent single sellers from hogging bandwidth. Consequently, those frequencies vary by update types — order retrievals, shipping updates, new product generation, product updates, and product quantity changes may all have different frequency allowances. Most of these frequencies are posted on our Community page on Communication Frequency. For example, imagine we are only allowed to update product data once an hour, then your communication of changes on a product to Rithum does not reflect in the marketplace at the moment we receive it. We queue it for the next update, which may be in five minutes or could be in an hour. Identifying how long it will take to update is often an imprecise exercise, so you shouldn’t expend too much energy or concern about delays unless they are widespread and significantly impacting your business. If you at least understand frequencies in this context, then you will have a better starting point to figure it out and adjust your expectations.

—

We hope you found this blog series helpful and enlightening to one of the biggest elements in many business relationships during our global technological revolution. We look forward to bringing you more data and information to help your business strategy and success. If you have questions about these topics, feel free to reach out to your Rithum contacts or open a Support case, and we’ll be happy to assist!

If you’re not a Rithum client and would like a quick demo of the Rithum platform, let us know and we’ll be in touch.