· E-commerce

Marketplace #3 – UPSTREAM impacts

INTRODUCTION

In our Marketplace serie, after talking about the main principles in the first article, we have indeed started to deal with the technical impacts of integrating a marketplace in the previous article. Given the scope of the task, we have divided the subjects to offer 5 different articles :

  • The integration of the marketplace into my e-Commerce ecosystem : General technical impacts
  • The technical integration of a marketplace UPSTREAM : from seller onboarding to the distribution of catalogs
  • The technical integration of an ON SITE marketplace : adapting the back-office of my e-Commerce. (coming)
  • The technical integration of an ON SITE marketplace : adapting the front office of my e-Commerce” (coming soon)
  • Technical integration of a DOWNSTREAM marketplace : after-sales (coming soon)

Taking, as a central benchmark, the moment when a customer visits your marketplace and places an order, the following diagram shows everything that happens before (UPSTREAM) during (ON SITE : during the visit) and after (DOWNSTREAM : after sales)

In this article we will detail : The technical integration of a marketplace UPSTREAM, from seller onboarding to the distribution of catalogs.

0. INITIALIZATION, SETTINGS AND MODELING

This first step is quite obvious : it begins after choosing a marketplace solution publisher and contractualization its use.
And continues with a phase of initialization of the platform by having :

  • Make the minimum settings to start using it
  • Planned a model (a format, a structure) to accommodate the products and offers of your sellers

This modeling consists in having configured… :

  • your categories,
  • your product attributes,
  • your lists of values.

… so that your sellers will be able to match their product information with this format.

To do this modeling there may be technical impacts if you decide to synchronize this with your product repository (a PIM, or your e-commerce, or even the ERP if it is your repository).

/ !\ do not mix up

  • Synchronization of sellers’ product sheets : This synchronization will have to be done between the marketplace and e-commerce anyway to publish sellers’ catalogs
  • Modeling synchronization : attributes, categories, lists of values.

We will come back in more detail, in a future article, to the construction of this product modeling for the marketplace. This is an essential, structuring step, which must be successful from the start because it will be difficult to go back when you have tens or hundreds of sellers on your marketplace.

1. PRE-BOARDING

It is a phase of recruitment, application, negotiation, … the commercial phase to reach an agreement between operator and seller. We will talk about pre-boarding or administrative/commercial onboarding/… a phase during which it is necessary to :

  • Validate the consistency of the operator/vendor offer,
  • Negotiate commissions,
  • Contractualize.

This phase does not really have any technical impact for your e-commerce ecosystem, unless you choose to put a registration form on your site. It will then be :

  • Create this form, and make it visible (a link in the footer “sell on the marketplace”)
  • Link this form to your CRM or directly to the marketplace solution to automatically create a seller.

Once the pre-boarding phase has been completed (it is assumed that the contractual, administrative and commercial aspects have been finalized or are dealt with in parallel with the technical onboarding), the operator can create a user account(s) to the salesman.

2. TECHNICAL ONBOARDING OF VENDORS

The operator who has created a seller account can invite the latter to connect to the seller back office on the marketplace.
The seller then begins his onboarding work and must provide :

SELLERS INFORMATION

It is necessary for the seller to provide a certain amount of information :

  • Identification information (email, address, legal status, etc.) and payment information (RIB).
  • Various information (return policy, description of its activity, CSR policy, etc.)

These first 2 points mainly involve the entry of information, by the seller, in his space on the marketplace.
This data will be returned to the front office for the customer who wishes to know more about a seller. A “seller page” will then be displayed containing all this information as well as customer reviews.

KYC DOCUMENTS

KYC documents and the KYC (Know Your Customer) procedure make it possible to ensure the identity of the merchant (in order to prevent identity theft, tax evasion, money laundering or terrorist financing). By “Customer”, we mean here the merchants who market their products on the marketplace and not the end buyers.

A PSP is generally responsible for validating KYCs and should be delegated this task.
The seller must provide you with these documents and you must send them to the PSP.

For this, 2 solutions :

  • Manually
    • Example : you collect the documents from the sellers, you send them to the PSP (all by email). The PSP checks the documents and sends you a status by email. ;
  • Automatically
    • The seller uploads the documents from his account on the marketplace, via a form provided for this purpose (which you will have previously configured).
    • The technical integration with the PSP allows automatic sending.
    • The PSP checks the documents and returns a status (valid y/n) which allows the seller to be activated.

The 2 cases described here are very simplified. It takes a well-established procedure to ensure that nothing is forgotten, and a substantial test phase to ensure proper operation.

In these 2 cases, there are no real technical impacts insofar as the integration between the marketplace engine and the PSP (on the scope of the KYC process) will not involve your technical resources as operator.
Indeed, unless you choose a PSP and an overly exotic marketplace solution, a connector surely exists (make sure before choosing the solution).
Be careful, even if you are told that a connector exists, check carefully :

  • its perimeter,
  • feedback from integrations on other marketplaces,
  • if not obsolete.

Non-validation of KYCs for a seller can :

  • either prevent him from accessing his account on the marketplace engine,
  • either prevent it from publishing its catalogs,
  • either, and this also happens, he can sell on the marketplace but will not be able to recover the funds

SELLERS’ CATALOGS

You have to be able to retrieve sellers’ catalogs (products and offers) and display them on the e-commerce site.

This part, upstream of the marketplace engine, is above all a subject for your seller.
He must send you his products and his offers, and for that you must offer him a maximum of possibilities. In general it can :

  • Manually create its products and offers on the interface of its seller account (rarely used for large sellers with several hundred or thousands of products),
  • Upload flat files, then map with the format set by the operator,
  • Integrate by API,
  • Go through a feed aggregator (Lengow, Shopping feed, iziflux, etc.). On this point, you must bear in mind that the technical integration of an aggregator on your marketplace will not be your responsibility, but the responsibility (and goodwill) of the aggregator itself. This will potentially have a cost (not always) but in general quite painless compared to the overall cost of a marketplace project.

PUBLICATION AND MODERATION OF VENDOR CATALOGS

Once the products and offers have been validated (it is understood here that the products, provided by your sellers, have passed the technical and commercial checks put in place by the operator) on the marketplace engine, the operator must publish them on the e-commerce site : either directly to the e-commerce solution, or via a PIM.

Logic would like :

  • Products * : from the marketplace to the PIM then from the PIM to e-commerce.
  • Offers * : from the marketplace to e-commerce (more frequently than products for price and stock updates).

* Recall :

  • A product = all the “cold” information that describes a product (descriptions, characteristics)
  • An offer = “hot” data in the context of the sale of a product (stock, price. Information on the condition of the product – new, refurbished, used, etc. – is also carried by the offer ). 2 merchants can sell the same product : it will be 2 different offers.

– Aside –
At this stage the question always arises : PIM ? no PIM ?
That is to say : do I put the products of my sellers in my product repository ?
This subject could be the subject of many discussions, but what must feed the reflection to answer it can be held in 4 main points (excluding financial considerations, and time to market) :

  • Do I want to publish product sheets (including marketplace products) on channels other than e-commerce
  • Do I already have a PIM – > e-commerce technical flow ? and I want e-commerce to consume only one product feed ?
  • Do I have business rules in my PIM that cannot be reported elsewhere, and that marketplace products must satisfy to guarantee the quality of my product data globally ?
  • Do I, as an operator, want to enrich sellers’ products with additional content ?
    – End of the aside –

So… Merchants’ products are in the marketplace tool, they have passed technical checks, moderation, duplication,… and they must be published on the site.

In general, marketplace solutions already expose all the APIs to consume all the data. It is therefore necessary to set up the half interface on the e-commerce side to integrate the Marketplace <> e-commerce flows.

Hold on, didn’t we go a little fast by stopping there ?
Indeed, we have just mentioned : “technical controls”, “moderation”, “deduplication”.
Behind these words hide quite structuring things and not all marketplace solutions offer the same level of functionality to properly address these 3 topics.
But you will be obliged to check at least the validity of the format of the product data provided by the seller, not to create as many product sheets as offers on the same item, and to validate the overall consistency of the product offer on your site.
So either it’s the marketplace solution that can answer this, or it will have to be developed somewhere (in the PIM, in e-commerce, in a specific brick).

SUMMARY OF THE TECHNICAL IMPACTS OF THE INTEGRATION OF A MARKETPLACE INTO THE E-COMMERCE ECOSYSTEM (FROM SELLER ONBOARDING TO DISTRIBUTION OF CATALOGS)

In summary, this UPSTREAM part does not involve a lot of technical upheavals for your CIO.
We know that we need a solution for :

  • Interface with vendors
  • Check product data
  • Disseminate product/offer/vendor data

All these UPSTREAM processes are ideally addressed in large part by the marketplace solution which will then expose the half interfaces to connect to them.

We will see in the next article, the technical impacts on the e-commerce side to accommodate this data.

Summary in 1 table :