INTRODUCTION
We continue our series on the technical integration of a marketplace model in an e-Commerce ecosystem:
- The integration of the marketplace in my e-Commerce ecosystem: General technical impacts
- Technical integration of a marketplace UPSTREAM : from vendor onboarding to catalog distribution
- Technical integration of a marketplace ON SITE: adapting the back office of my e-Commerce
- Technical integration of a marketplace ON SITE : adapt the front-office of my e-Commerce (coming soon)
- The technical integration of a marketplace DOWNSTREAM : the after sale (coming soon)
Taking, as a central reference point, the moment when a customer visits your marketplace and places an order, the following diagram presents everything that happens before (UPSTREAM), during (ON SITE: during the visit) and after (DOWNSTREAM: the after sale).
In this article we will focus on what to expect ON SITE (and more precisely in the back-office of your e-Commerce solution: the orange part of the diagram above).
Indeed, on the e-Commerce site side, there are worksites to be implemented on 2 axes:
Adapt the e-Commerce back-office to make room for new data specific to the operation of a marketplace:
- Sellers
- Products
- Offers
- Orders (managing orders from third party sellers will have an impact)
Adapt the front-office to display the specificities of an e-Commerce on a marketplace model
- Product listings (categories, search results)
- Product files
- Shopping cart and order tunnel
- Customer account
The following article focuses on the back-office axis (the front office focus will be done in the article “Technical integration of an ON-SITE marketplace: adapting the front-office of my e-Commerce” (coming soon).
1. BACK-OFFICE E-COMMERCE
On the back-office side and the e-Commerce data model, unless you are already using an e-Commerce solution that includes marketplace functionalities, you need to be able to make changes to your tool to accommodate these new concepts (offers, sellers, split orders*) and handle them.
* distinction between your own orders and the orders of the sellers
1. PRODUCT DATA
In any e-Commerce solution you can model products. That is to say, you can define the structure of your products (attributes, lists of values) and their implementation (in categories).
In a marketplace integration project, there is a real topic around product modeling. But it’s mostly about: what modeling (what format) will you propose to your sellers so that they push their data to you (on their own modeling) and that it matches.
Product modeling in the broadest sense is :
- The categories in which I can implement products
- The attributes that describe a product (description, size, color, technical data, brands, reference,…)
- Lists of values for attributes of the choice list type
– Aside from the concept of the product format Operator/Vendor –
The diagram above shows the issue that needs to be addressed:
❶ – your vendors have their own product models
❷ – they need to map them to yours (operator).
(Between these 2, there are, in general, tools to do the mapping).
So the challenge is to build this product format (❷) based on your existing in the wide sense:
❸ – your different modelings already present for the sale of your products: potentially some products in a PIM modeled in a certain way, a potentially very different front structure, an even different way of managing your products on the purchase side,…. It is the analysis of all of this that should allow you to build a coherent model capable of leaving no ambiguity for the vendor when he/she has to implement a product in a category (1 product -> 1 single category).
– End of the aside –
If we go back to the objective of this article: to explain what there is to change on the e-Commerce side: in terms of product modeling on the e-Commerce side… Not much in reality….
Indeed, your products are already exposed on the front end by the e-Commerce. Of course, you will integrate many products from vendors, but this does not mean that the way you will expose them will change.
Or at the margin….
- Your sellers, by enriching the catalog, will also enrich your lists of values (new brands, new values of variants,…), so they must be reported in the e-Commerce.
- You want to flag the products provided by the sellers (you will have to add an attribute with the seller’s name and possibly a “marketplace” yes/no flag).
…And if… 😉
- You integrate product families that are completely different from what you used to sell… You will then have to add the appropriate attributes and value lists.
- You take advantage of the marketplace model to completely change your structure, and the presentation of your products…. This is a project within a project…
Note:
We are talking here about an adaptation of an existing e-Commerce to transform it into a marketplace model.
If you start a marketplace project from scratch you will have to build everything in terms of product modeling by projecting the offer that you will integrate via the catalogs of your sellers.
2. OFFER DATA
An offer is :
- A price (the price P1 at which a seller sells a product potentially sold by you at price P2, or other sellers at price Pn)
- A stock (the value of the seller’s own stock of this product)
- A state (the state of the product: new, reconditioned, used, etc…)
So on the same product there can be several offers.
In an e-Commerce solution, this concept of offer is not generally found.
It is therefore necessary to adapt the data model and back-office interfaces to manage the offers. So that the e-Commerce is able, on the same product sheet, to propose several offers.
– Apart –
The offer carries the price decided by the seller.
When we talk about price, we can ask ourselves the question… of promos.
In general, the seller can decide on a price and a reduced price (which allows displaying a promotion but only in crossed-out price, as on the image opposite for example).
For what concerns the rules of promos (an amount or a percentage according to the rules of catalogs or baskets with or without coupons) it is immediately more complex.
In a marketplace integration project, most of the time, complex questions about promotions management are managed in post MVP packages.
– End of the aside –
3. VENDOR DATA
As for the offers, the notion of seller does not necessarily exist natively in your e-Commerce solution.
It is therefore also necessary to enrich the data model to accommodate all the information that you want to persist … and to exploit them :
On the front of the lists or product sheets:
- “Sold by xxx”
- The seller’s note
On the seller pages :
- A complete page with all the information you want to present to the customer
- A logo
- His acceptance rate
- His reviews
- The description of its activity
- Its returns policy, its shipping methods
- …
In back-office :
On management listings for administrators. (If you need to quickly access a list of merchants, their offers, … without necessarily changing the tool by consulting this information on the back office of the marketplace engine).
4. ORDER DATA
A customer can place a “mixed order” on your marketplace.
A “mixed order” is an order composed of items from several sellers.
This translates into several sub-orders (one order per seller).
And it is this notion of multi-orders that you must be able to manage in your e-Commerce.
It is up to you to judge the best modeling strategy between the existing and the target.
Let’s take 3 examples:
- A parent order that carries some information from the order (the cart) to the global (for example the payment transaction ID) and has daughter orders for the contents of the 1P* order and 3P** suborders.
- The parent command which is in fact the 1P command and which has the 3P commands as sub-commands
- Sister commands that coexist without any particular link apart from a command ID strategy to be implemented (a suffix to each one for example).
* 1P order = order your own products
** 3P order = order products from third party vendors on your marketplace
Below is a diagram that can illustrate the structuring of orders between 1P orders and 3P orders for an order placed by a customer (composed of products sold by the operator and products from 2 other merchants in the marketplace).
(A 4th example of managing this order data could be: no persistence of marketplace orders in e-Commerce).
There is therefore a strategy of order numbers (reference/ID) to be put in place: the reference of the main order and the references of the related orders.
And therefore, potentially modify the way orders are modeled in your e-Commerce solution.
The choice of this architecture will be guided by your legacy technical constraints, or by the use you wish to have.
But it is, in general, not necessary :
- To persist all the data of a marketplace order in your e-Commerce brick
- Push marketplace orders into your ERP
The desire to keep vendor order data in your systems could be driven by :
- Reporting/BI: but it is better to build these reports by consuming the data flows exposed by the e-Commerce and the marketplace. And thus keep each brick for what it is intended for:
- The IS/ERP for the commercial management of your own sales and your commission is taken from marketplace sellers
- The marketplace engine for merchant orders
- The e-Commerce brick for the link between the two
- Customer service: indeed, an agent who has a request from a customer must be able to understand if it is an order only “own sale” or only “seller”, or “mixed”. We will talk about this later in the after-sales phase.
5. INTERFACES
Most marketplace solutions work with APIs.
All the data and functionalities specific to the management of a marketplace are therefore accessible through these half-interfaces which make things much easier. They are generally well documented by the editors.
Whether on the front or back side of the e-Commerce, there are many interfaces to implement with (non-exhaustive list):
- Asynchronous flows (for “cold” data, persisted in the e-Commerce database)
- The products
- The offers
- Sellers
- Synchronous flows (for hot or non-persisted data)
- Checking the stock of an offer before ordering
- Messaging between customer and seller
- Calculation of seller’s shipping costs at checkout
- Marketplace orders displayed in the customer account
So we’ll need to create these flows between applications, and also create user interfaces to manipulate them, view them, or add functionality to the people who will manage the marketplace’s daily operations.
For example:
- Manually trigger a synchronization of offers
- Manually trigger a replay of orders
- Set up a product validation interface
- List data: list of sellers, and associated offers
- …
In summary
In the table below we summarize on which perimeter it will be necessary to intervene to make your e-Commerce “marketplace ready” on the axis ON SITE – e-Commerce back-office.
