Import your Reallm
We know how hard it is to build a marketplace. So we decided: heck, why not help everyone on this journey.
It’s always hard to see what the main factors are that influence supply and demand matching and figure out the growth strategy while making sure that everybody including the BD and marketing teams are on the same page when it comes to knowledge of the supply base.
Using Reallm one can do just that: map both your supply and demand data, see the factors influencing missed demand and allow this to formulate your data-driven and continually updated strategy!
In this blog post we give an overview of what is required to superpower your marketplace analysis using the Reallm platform.
We model your marketplace by reading and analysing past transactions on your platform (matched orders or bookings) coupled with associated parameters. These include time of the transaction, category / type of the booking (e.g. manual vs automatic transmission for car rental), booking location and price. Typically, these can be supplied to us either as .csv files dump or though read-only database access.
Example 1: .csv describing transactions
created_at,Postcode,Lng,Lat,category,price_usd,supplier_id
2015–06–22,B147NR,51.494762 -0.230727,Black Cab,30,197
2015–06–23,CR82JY,51.462347 -0.153927,XL,25,105
2015–06–23,CM165AG,51.462347 -0.153927,Pool,10,105
To analyse provided data we rely on the customer-supplied mapping between fields found in .csv files (or db tables) and our generalised notion of a two-sided marketplace.
Below we will walk you through the typical list of fields that you can map with Reallm.
Demand Metrics
Demand metrics constitute the parameters that relate to the customer’s usage. What type of service was requested / booked, when and for how much.
Booking Location
Indicated place where service is supposed to be provided. A preferable way would be to have lng/lat column indicating the precise place of every booking:
51.583293 -0.001135
51.57369 -0.001224
…
51.513253 -0.001812
51.56489 -0.001957
An alternative would be to specify the postcode of a booking:
AL69EN ← that’s a postcode
B14 7NR ← it’s fine to have space there and then
…
CR8 3BN
DA83JZ
Date of booking
Indicates the date of the order fulfilment. The time format is Unix timestamp or YYYY-MM-dd (optionally HH:mm:ss). Example:
2017–01–25 11:02:13
2017–05–26 09:35:03
…
2017–11–19 14:04:25
2017–12–17 22:14:22
Price of booking
Indicates the price of the order ($ or any other unit).
Filters (Categories / Type of service)
Filters indicate any number of parameters associated with the order. For example the type of a rental car, type of a haircut made or any important circumstances of the order. Currently Reallm has the capacity to include two different filters (primary and secondary) from 2 individual columns.
Bartender
Commi
…
Waitress(er)
Waitress(er)
Example above would mean that the resulting analysis could be performed on a subset of bookings defined by user-specified value (e.g. ‘Bartender’) in the respective column.
Supply Metrics
Number of suppliers alerted
Primarily this parameter indicates a number of suppliers that were alerted about particular order. This is common in marketplaces that have a bidding mechanism to match suppliers with the orders. It can also be applicable if the matching is automatic but the match is broadcasted to the nearest suppliers (e.g. taxi drivers).
Number of suppliers responded
Applications / quotes from suppliers to take on a particular order (after being alerted about it or otherwise). This is relevant in most marketplaces that don’t have instant match.
Booking supplier ID
The unique identifier of the chosen supplier. This parameter is used to figure out the partitioning of the bookings between different suppliers and estimate metrics like spread or revenue imbalance amongst suppliers. Important: we count the booking as unfulfilled if it has empty value in this column which in turn forms our missed demand metrics.
Supplier rating
This field indicates the reported or estimated quality of the order that was fulfilled (or the rating of a supplier that was matched to the order).
Locations covered by each supplier
Each supplier can serve different locations. This can be defined either by the radius in km (e.g. 50km or just 50) or by list of the postcodes where supplier is typically inclined to go. This can be also setup as a travel time duration (e.g. 10h).
AL69EN/B147NR
…
10
50
Search Metrics
The following metrics in turn are not always available but are still great to have nevertheless to better understand missed demand that would now include zero-result searches or other lost opportunities. This is typically decoupled from the past transaction history and can be supplied as an additional .csv file with each row specifying a single search session.
Location of interest (enquired for)
The location where a service is desired to be fulfilled at. Can be a slash-delimited vector of search locations if a search session included multiple subsequent locations of interest.
AL69EN/B147NR ← search of user #1
…
51.583293 -0.001135/51.5736 -0.001224 ← searches of user #11
51.57369 -0.001224
NW1 0DA ← search of user #13
Browser location (place of enquirer, GPS)
The location of a device that is being used to perform the search.
Search Date / Time
The time and date of the search. The time format is the “date of booking”: Unix timestamp or YYYY-MM-dd (with optional HH:mm:ss).
Filters / categories / type of service searched for
Other parameters that are associated with the particular search. Should contain the same keywords as do the Filters in Demand metrics.
Aaaand that’s it! Thank you for making it this far. Now hopefully it will be easy to create your own Reallm. Please don’t hesitate to give us a shout in case something goes south! :P
