A Few Fun Facts About Item Data

A Few Fun Facts About Item Data

So your company has embarked on a data quality journey, and you have decided to start with item data. Congratulations! Item data is what sells items, and without it you have nothing to display to your customers. As the new Item Data Manager you are tasked with improving your item company's item data quality....  TODAY!

Everyone always wants results today when it comes to investing in data. The Return-On-Investment story preached by data evangelists requires returns sooner than later, so you have to start producing results as soon as possible.  But what is a result for an item data improvement? How do you measure it? What are the confounding and contributing factors? Can you even isolate your item data influence? Is item data big data or just data? Where do you start?

Here are a few fun facts about item data quality that I hope will answer some of those questions.

#1 Item Data is NOT Big Data.

Contrary to popular belief not all data needs to be treated like Big Data. Big Data has several important characteristics that define how it fits into that moniker: It is transaction, it is not structured, it is (probably) not relational, and it is event-driven.  Item data is not transaction, as it is developed to influence transactions. It is highly structured and relational, and it is in no way event-driven. Item data is not Big Data: It is just data.

Treating item data as Big Data can be extremely problematic. Big Data treatment of item data removes the relationships that are important for downstream systems to consume. For example, an upsell or cross-sell relationship is necessary to compete in today's online marketplaces. Have you ever gone into a store looking for a digital camera and not seen it surrounded by other digital cameras? Those relationships are important because they create marketing opportunities, both in brick and mortar and in e-commerce platforms. Big Data is a giant flat file, and maintaining relationships in a flat file is much more difficult than with traditional relational structured databases.

To be honest I doubt there is an item data manager out there that does not understand this. Unfortunately the choice of systems you put in place can have an affect on your item data, as many CMS and E-Comm platforms "dumb down" your item data into flat files. I will not recommend any single platform over another, as every platform has its own advantages and disadvantages in its own space. However, make sure that the question of how your item data is stored is included in any RFP (Request For Proposals) documents that are created when migrating platforms even when those platforms are downstream of your item data systems. Treating your item data as unstructured and non-relational may have unintended consequences to your experiences.

#2 Fixing Data Always Costs More Than Fixing Problems

Many of you have heard me rail on the evils of item data remediation before. I promise not to revisit it with my normal vigor. However, I will talk to the damage that can be contained with a plan to fixing User Experience and Taxonomy issues rather than remediation programs. They are summed up with the old computer acronym GIGO: Garbage In Garbage Out.

People want results today so the first option is remediate the data. You can clean it up and possibly increase conversion with a methodology that builds a small ROI story. Depending on your product vertical this can be an efficient way to quickly show results.

 The average lifespan of a single product on a website is incredibly small. In fashion it can be as low as two weeks. In electronics it may last 6 months. In electrical supply it may last for a couple years, but most data remediation on electrical supply or building services-type products doesn't have a large immediate impact on sales.

By the time a data remediation plan is spun up it becomes a race against time that, in most cases, is not winnable. By the time you identify the items you want to remediate, educate your team on the process, re-capture the data, input the cleansed data into the system and have that data flow down to the platform selling that item there is a good chance that item is close to its end-of-life. The amount of time you have to influence the sales on that item through item data starts the second that item appears on a web site, but quickly decays as time passes. The longer it takes you to remediate the lower your ROI results will be.

On the other hand, spending the resources to fix the problem that caused the data issue in the first place has a much longer ROI story. This resource spend influences every item that has data collection applied to it from that moment forward. The ROI continues as long as the core data collection system exists or a compounding change is made to the system. This is an investment in item data quality instead of a cost associated with data collection.

#3 There are 3 Major Causes of Item Data Problems

So you realize that remediation does not work, so what do you do now? Understanding the three major causes of item data collection issues can assist you in knowing where to start. Those issues are:

  • Bad Taxonomy Design
  • Bad Item Data Collection UI
  • Bad Training

Taxonomy design is crucial to item data collection.  Having a poor taxonomy design makes it more difficult for users to properly classify their items, leading to misclassifications. As an example, a previous company I worked for at one time pointed to nearly 20% of their items existing in an incorrect taxonomy classification. That is 1-in-5 items that have the wrong attributes applied. Catching these exceptions and fixing the issues is expensive, and it is an unnecessary expense.

Retailers have gone to extreme measures to stop this from happening. They make complex machine learning systems to make sure items are placed correctly, but those rules are only as good as the programmer that creates them and the taxonomy they are applied to. Machine learning might help you classify items faster, but it will make almost as many errors classifying items against a bad taxonomy as a human will.  Taxonomy design is paramount.

The second issue that plagues item data collection is bad UI design. The UI design by itself is not necessarily always the obvious villain, as most of us chalk this up to human apathy. Item data collection is tedious, and humans by their nature make more mistakes as the task becomes more tedious. Give someone responsible for item data collection a shortcut through the system and they will follow that shortcut every time, no matter how it affects their data.

Item data collection UI's should be build for two purposes: To enable the user to enter the right data and to disable the user from shortcutting the system. Because UI design on data collection is regarded as an internal system not seen by customers it is never given the same treatment as an external UI. Most UI's for item data collection show significant leanings towards being envisioned by developers and not UI specialists.

The last factor that leads to item data issues is bad training.  If you combine a poorly designed taxonomy with a poorly designed UI the results from the training will be predictable. No amount of training can make up for a bad system design. However, the best taxonomy design and application development can be wasted if the trainers do not understand item data collection, specifically the impact that collection has on downstream systems.

The trainers must be able to show their trainees the most efficient process for collecting data that also results in the highest data quality. Choose efficiency alone and the users will shortcut and reduce data quality. Choose quality alone and the users will get bogged down in the process, and eventually cost will mandate they shortcut the system. Only the balance of efficiency and quality can lead to a higher level of data quality.

#4 Without Good Item Data You Are Wasting Time and Money

There is no denying it: Most people make their decisions to purchase items based off the pretty pictures on a web site. We are a visually-driven species, and we often quickly attach to items we want to purchase based off looks alone. We may look at the specifications of an item, but we fall in love with the pictures.

People also don't navigate through hierarchies of items nearly as often as they used to. I am a staunch advocate of findability through navigation, but the industry is dependent on search. Envision an item you want to purchase, and then go to a web site you know sells that item. Can you get to that item faster through hierarchy or search? We live in a search-dominated world.

However, there is a limit to how well these services can lead to conversion, and it is based on item data. For example, when you envisioned that item you probably searched for a broad category and then filtered using the facets on the page to find that specific item. Those facets are driven by item data. If you facet by color and someone enters the wrong color on that product you would not be able to filter to find it. If they spell a Brand Name incorrectly or have the wrong dimensions that item evaporates from your search. That is all item data, and getting that data collected correctly is paramount to your filters.

Now go look for that item on Google, but search by a color and another trait of the item. Google is indexing those values and using them to determine which items to show. If you enter an search term that should be applied to that item but is not due to a data collection issue your Google search rankings may bury that item compared to a competitor with the same item but better data. You can spend thousands of dollars on clicks to own the color blue on Google, but if your item has the wrong color it will not appear on Google. That is item data.

Now imagine someone else sells your products on their web site. They have a representation of your product data, either through your own collection that is syndicated to them or through their own data collection. In previous blogs I have shown how inconsistencies in this type of data collection leads to vastly different experiences on competing web sites. (See "Why Does Product Data Matter?") Having inconsistent data experiences between web sites leads to customer confusion, and confused customers do not buy confusing products. If you have bad item data and they re-display that data it is a horrible experience. If you have bad item data and they have better item data, your credibility suffers.

The Key to Being a Good Data Jedi: Balance

In my years as a product taxonomist I have seen both sides of the item data quality equation. I have seen companies that treat data collection as a cost and suffer through low conversion rates and cart abandonment issues when educated shoppers find data issues. I have seen companies that invest in their data as an asset, but cannot recover the cost of that investment due to user apathy and bad UI design.

Item data requires taxonomy development, UI investment, and training. Any one of these alone will barely make a scratch in your item data (and conversion) issues. All three must be tackled to build a truly remarkable experience. And yes, images will still sell items...  but only if customers can find those items and, when found, trust they are making the right decision based off the data you provide them. In 2016 customers are 100% portable; They can start visiting a competitor's web site without you knowing it, and therefore are more likely to betray your Brand for a better experience. Don't let item data quality be the reason they start looking elsewhere.





Henrik Gabs Liliendahl

Data Management Veteran, Founder @ The Disruptive MDM / PIM / DQM List, Co-founder @ Product Data Lake

8 年

Hi Daniel. Good stuff. May I challenge you a bit on whether or not item data is big data? If you look at it from within the corporate walls, I can agree that item data should not be handled as big data. The quest is to get what might not be well structured now to be well structured, commonly understood and fit for all purposes. However, if you look at it within the cross company business ecosystems, the aim will be the same, but the chance of success is quite utopic. Trading partners will always be on different maturity levels, use different standards and have their own bespoke structures. So for handling sharing of item data between trading partners there are advantages in applying big data approaches. We have taken that track in the Product Data Lake service I am working with right now. Some more information here https://liliendahl.com/data-quality-3-0/product-data-lake/

回复

要查看或添加评论,请登录

Daniel O'Connor的更多文章

社区洞察

其他会员也浏览了