We’ll be working on understanding the retailer domain a bit better today. This knowledge is needed to get our information model in place and identify key challenges. It will also give a list of limitations and assumptions the app could be working under, which will be lifted in later releases as inputs mature.
So I am sitting at home, switch on my phone, download and install the app and start it. First thing the app should do is retrieve my current location using location services or the GPS sensor on my device. Typically, this delivers me a latitude and longitude for my current position. No rocket science …
Based on my location, the application should find x number of grocery shops nearest to my location. If x is variable based on a maximum distance between the shop and my location, or is actually a fixed number is not important at this time. More importantly, there should be a flexible shop finder embedded in the app, because the shops that are going to be visited might not be anyway near the place that I’m activating the app. But as an initial selector it would be nice.
Fun thing is, this is sort of a mini-app already that has value anyway. We’ve already see that working (poorly) in the Aanbieding app, and we might be able to find some great examples of apps doing exactly the same. I will write a future blog post on this separate mini-app.
Let’s assume I’ve just selected two shops that I would like to visit to do my groceries, and I’m starting to compile my grocery list, how should that look like? What I would like to see, is a search box with predictive results and suggestions, like Google search does. The ranking of the searched items should give priority to product brands that are sold in the selected shops, but it would also be interesting to see other cheaper brands and offerings lower in the stack. That way, I can still choose to defer my article selection outside of my shop selection scope.
Now this is where it gets very challenging. Searching for an product on description, the code should be the (invisible) key for the resulting product returned from the query. In each result, there should be a list of identifiers for the shops where the product is sold. Prominently, the resulting list of shop identifiers are within the scope of selected shops, but as stated above, the app could also return shops out of the selected scope with interesting deals. So we need to have uniquely identifiable product codes available in relation to the shops where they are sold.
How do we know which articles are sold in which shop? And potentially, how can we find out if the shop has the article still in stock? Well … For starters, I don’t think we can assume that every shop for a specific brand has the same inventory. It will depend on the size of the shop, location, and other circumstances. Brands will probably also handle their shops in that way, as individual entities. The central office will have a strategy in place to make sure country-wide offers are possible and available in all stores as much as possible, but not all stores can be handled exactly the same way.
So an individual store at a specific location belongs to a specific brand and has its own inventory. Is it possible to find out what it is? Maybe though something called the GS1 eCom system. This system is used in the Netherlands to standardize exchange of logistics information between retailers and suppliers. I’m not sure if it contains information about current stock, or individual shops at all. Maybe it only takes care of order and shipping between the central brand shipping facility and suppliers, but at least it is coupled to the GEPIR (Global Electronic Party Information Registry) that uses EAN numbers (also used for the product bar codes) to uniquely identify products. Product ID to retail brand mapping is already a big step in the good direction. This is a starting point for further investigation and something to discuss in a separate future post as well.
As discussed, the product will have an EAN ID and an description that can be searched for. Furthermore, there are details like weight, amount or volume that specify a quantity for a product unit. This should all be coming from the GEPIR. An image of the product is almost a prerequisite as well in order to be able to achieve a suitable user experience, and I’m not sure if that is a property in the GEPIR. What we can try-out is searching Google images for ‘EAN <product EAN ID>’ and see if we get a good hit.
The product’s price is a property of the relation between a retailer brand and a product. This may also vary over individual shops for a specific brand, as I know that for gas stations these differences are there because of location and depending on service of the individual shops and such. But I’m not sure if that is reality for groceries and how often that actually occurs.
In an oversimplified view, the information model discussed will look something like the figure below. And with that image I’ll leave you for today.
Can’t wait to start on the next post and do something techie for a change!