Not at least on the European scene with the upcoming General Data Protection Regulation (GDPR) there are limits to how long you can go in profiling your (prospective) costumers. And I am sure those people will value more you are telling them the complete story about your products, rather than guessing what products (from your range) they might need.
As a consumer, we want the facts about the products to make a self-service purchase. We want to be able to search for and navigate precisely to a product suitable for a specific use. We want the facts in a way, so we can compare, perhaps using a comparison service, between different brands and lines. We want to know what accessories goes with what product. We want to know what spare parts goes with what product.
By the way: Business buyers want all that too. And a person being a business buyer is a person (data subject) in the eyes of GDPR too.
For providing complete and consistent product data you as a (re)seller need to maintain high quality product data and if your product portfolio is just above very very simple, you need a Product Information Management (PIM) solution and, if you have trading partners, you need a PIM-2-PIM solution to exchange product information with your trading partners.
Oftentimes it still takes a human eye to establish if a number, year, term or other piece of information is wrong.
I had that experience today at Harvard Square in Cambridge (Boston) when looking at the sign in front of our lunch restaurant. Established 1271 it says. Hmmmm. North American natives were not known for establishing restaurants. Also, the Vikings did not stay that long or went that south in North America.
The restaurant website actually admits the sign is wrong and this is a printing flaw (should have been 1971) that they have chosen to keep – maybe also in order to test the clever people hanging around Harvard.
Anyway, without attempting to turn this into a foodie blog, the food is OK but the waiting time for being served does resemble spans of centuries.
This week I attended an event called Retail Summer School at Columbia Business School in New York.
Much of the talking was about how to get insights on your (prospective) customers by collecting data in all kinds of ways – while observing the thin line between cool and creepy.
My thinking, of course biased by my current Product Data Lake venture, is that you should also pay attention to product data. For at least two reasons:
Algorithm effectiveness: Your algorithms on what products to present based on your rich insight into your customers need will only work if you are able to automatically match the needs against very specific product attributes. And most retailers don not have that today if you look at product descriptions on their ecommerce sites.
Also, I am not impressed by the suggestions I get today. They generally fall into two buckets:
Things I absolutely do not need
Things I just bought
Self-service craving: As a customer, we strike back. We do not need to be told what to buy. But we do want to know what we are buying. This means we want to be able to see rich product information. Therefore retailers must maintain a lot of product data and related digital assets that they should fetch at a trusted source: From the manufactures. And if the manufacturer wants their products to be the ones selected by the end customers, they must be able to deliver these data seamlessly to all their distributors, retailers and marketplaces.
This blog is in English. However, as a citizen in a country where English is not the first language, I have a problem with English. Which flavour or flavor of English should I use? US English? British English? Or any of the many other kinds of English?
It is, in that context, more a theoretical question than a practical one. Despite what Grammar Nazis might think, I guess everyone understands the meaning in my blend of English variants and occasional other spelling mistakes.
The variants of English, spiced up with other cultural and administrative differences, does however create real data quality issues as told in the post Cultured Freshwater Pearls of Wisdom.
When working with Product Data Lake, a service for sharing product information between trading partners, we also need to embrace languages. In doing that we cannot just pick English. We must make it possible to pick any combination of English and country where English is (one of) the official language(s). The same goes for Spanish, German, French, Portuguese, Russian and many other languages in the extend that products can be named and described with different spelling (in a given alphabet or script type).
You always must choose between standardization or standardisation.
Product Information Management (PIM) is a fast-growing discipline enabled by PIM platforms. While the current market for PIM platforms is much about supporting a consistent in-house management of the information related to product models we make, buy and sell, there are new opportunities arising. Three of them on my radar are:
The recent buzzword in the chain starting with “supply chain” and going over “value chain” is “value web”. Learn about the arrival of continuously evolving business ecosystems and value webs in this article from Deloitte University Press. Product information management encompassing business ecosystems will be imperative in value webs.
Product Data Lake
This is in all humbleness my venture by having launched a PIM-2-PIM platform that deals with the current main pain in product information management, being exchanging product information between trading partners. We do that in an agile and automated way by supporting partnerships in value webs and are soon adding things to Product Data Lake.
The difference between solving data quality issues for party (customer, supplier and other business partner) master data and product master data was discussed 7 years ago on this blog in the post Same Same But Different.
Since then I have worked intensively with both party master data and product master data and the data quality challenges organizations have within these domains.
Building on the findings from 7 years ago and recent experiences, I think there are two areas it is worth emphasizing on:
Data Quality Dimensions: All dimensions are important and they support each other in solving the issues. But there are some differences as explained in the post Multi-Domain MDM and Data Quality Dimensions. In my mind, uniqueness is the worst pain for party master data and completeness is the worst pain for product master data.
External Data Sources: The use of data sources was examined in the post 1st Party, 2nd Party and 3rd Party Master Data. In my mind, extensive utilization of third party data is paramount for party master data quality and effective exchange of second party data is paramount for product master data quality.
A Sharing Concept
For solving both party master data and product master data quality issues you need Multi-Domain MDM for business ecosystems as proposed in the Master Data Share concept.
Facebook is set to fight fake news by using artificial intelligence. A good way to practice may be by playing a bit more around with their geolocation intelligence.
Today I, as far as I know, are on the Canary Islands. This is a part of Spain, though a little bit away from the motherland down the Atlantic Ocean off the North African coast. A main town on the islands is called Las Palmas.
However, according to Facebook I seem to be in a place called Las Palmas Subdivision on Hawaii in the Pacific Ocean on the other side of the globe with Hawaii being a bit away from where it were last time I looked on a map.