In Item Data, the Little Things Count

When I was a kid I loved to take things apart. Growing up in Canada in the 70's and 80's we actually had to rent our phones from the phone company rather than buying them outright. At one point I disassembled the new pulse phone my parents rented from the phone company and attempted to reassemble it. I had a few extra parts left over afterwards, but the phone mostly worked. Okay, "mostly" may be an exaggeration. With my inability to resolve the issue about to become extremely apparent to everyone in the household, I did the only thing I could think of: I hid the phone and played dumb.

So you are a paragraph into an item data blog and I am discussing destroying electronic equipment. It seems a pretty big stretch to connect the two, does it not? Believe it or not, it is not. Prepare to be amazed at how little details, tiny parts, and a lack of planning can affect your data. As I am in item data I will use this analogy against my preferred topic, but this can be applied to any data domain with a vernacular adaptation and a little understanding.

#1 Have a Plan

My first mistake in disassembling that phone was that I had no idea what I was doing. I was intrigued by the sophistication and wanted to dig deeper, but I had no plan to achieve that goal. The goal was disassembly without any understanding of what would happen next. I could meet my short-sighted goal fairly easily, but the consequences of reaching that goal were not understood.

The same is true in item data. Many companies install software and assume that item data will flow. The tool is the plan, and therefore the implementation is the goal. However, it takes much more to be able to build a successful item data program. For example, is your metadata for units of measure going to be collected in feet or inches? When you collect it in feet will you collect "Feet", "Ft" or "ft" as the unit of measure? Here are the consequences of not having a plan for these kinds of issues:

This is not a very egregious example. In fact, some may not even see the issue. Or, if you look closely, issues. Look closely and you might catch them both.

The first issue is pretty obvious. 35.0 says "IN" after it while none of the other filters in this facet have a unit of measure. First off, this looks horrible. 35.0 IN looks out of place. Secondly, if 35.0 IN wasn't there what unit of measure would you apply? Inches? Feet? Centimeters? Meters? Parsecs?

Secondly, someone during data collection obviously didn't understand fully what was being asked and entered a value of "0.0". Seeing a zero is odd. Seeing a zero with a decimal place and a trailing zero is even more odd.

This occurred because a style guide was never universally applied. Everyone in taxonomy or who took English Composition 123 in college knows what a style guide is. Remember having to write papers in APA or MLA format? Remember all those citations you had to create in exactly the right format? Above is the output when you don't follow your style guide.

Item data needs a style guide for both collection and presentation. You can have different style guides for each function, as you obviously may need a different format for a catalog presentation than collection. Similarly, your catalog and website may need to display data differently. The point isn't that you need one style guide across your entire enterprise (although you should have one style guide governing desktop and mobile commerce) and may necessarily not want to have a single style guide. However, each function needs to be working against a guide of some sort.

Your style guide is part of your plan. A functional taxonomy is another part. I've talked extensively about taxonomy issues in the past and I will let you peruse my previous blogs at your leisure, but suffice it to say that taxonomies do not fall out of thin air.

It is nearly impossible to show you a data collection taxonomy example of how they can go wrong, because most data collection taxonomies are invisible to the outside world. They collect data but they only display it internally. So I am going to present an example, but it is somewhat made up. I'm using web presentation to simulate data collection, which use two different sets of rules for item categorization. Therefore, be aware that this is for illustration purposes only.

There are 5 types of hook categories presented here. A garment hook and a ceiling hook are pretty easy to define, and everyone had a conceptual understanding of what an adhesive hook is. However, what if you had an adhesive garment hook? If you had to place that item in this taxonomy where would you categorize it? Is it an adhesive hook for garments or a garment hook with an adhesive attachment point?

Mutual exclusivity is paramount for item data collection. If an item can be classified in two different locations it may end up displayed in two completely different non-related categories when it is displayed. That item when classified in one of the two categories may also end up with a completely different set of attributes applied than an item that is classified in the second category. Your item data is no longer standardized, as two similar items have different data. This affects accuracy, normalization, and consistency, all of which are necessary for data quality to be developed.

#2 Document Your Activities

I had a goal when I disassembled that phone. I wanted to see how it worked. I achieved that goal, as I saw how a printed circuit board with some switches attached to keys on the keypad interacted with other components to make a working phone. I marveled at the lack of potentiometers I had seen in rotary dial phones and how the tone/pulse system functioned. Unfortunately, I cannot explain this in visual details because I do not recall a single internal component from memory except for the outside shell and the color of the number buttons.

The same occurs often in item data modelling. A model is easy to build, and most models follow some sort of business logic. However, in every model there decisions made that drive future development activities. Many times these decisions lie within the grey matter between the ears of several individuals that may or may not still be with that company. I know many things about past taxonomies I helped develop that are pertinent to how to standardize the development going forward. However, I no longer engage with this companies and they would not understand the questions to ask.

Imagine this: A 10 year old buy has reassembled a new telephone costing several hundred dollars in 1980. However, he has 3 parts left over: A screw, a plastic clip, and a wire. His choices were:

• Disassemble the phone again and attempt to locate where those parts came from, possibly leading to more mystery parts and a no positive movement in his request to have a Lamborghini when he grows up.
• Build a time machine, go back to an hour prior, and tell his younger self to put the screw driver down.
• Run away to join the circus.
• Hide the phone.

Yeah, it sounds funny. But it relates well to building an item data program. At the point in time that you want to evolve your item data you could disassemble your entire data program from scratch and hope to put it back together in a more functional manner. You could attempt to understand what happened during the original development by seeking out those that were involved. You could practice juggling flaming chainsaws. Or you could try to sweep the problem under the rug and hope nobody notices.

I would prefer to document the decisions in an item data governance log or integrate the log into the style guide I now know I require for taxonomy development because I did not skim point #1. Plus I really really suck at juggling.

Here is an example of why this is important. Imagine you have a metadata attribute of Color Family. In that attribute you have decided that "Teal" is not a recognized color family, and prefer to reference it as "Blue-Green". Three weeks later someone calls up your taxonomy department with their hair on fire screaming that they need the value of "Teal" in your color family attribute. If you had a decision log/style guide you could easily reference that anyone wanting the value of Teal should use Blue-Green. If you don't have a decision log/style guide the response from your team with vary member to member. Suddenly instead of having "Blue-Green", you also have "Teal" and "Green-Blue" in your color family attribute. When someone is looking for Teal wallpaper and filters on that value they will not see the Blue-Green or the Green-Blue items.

So document your item data development, and not just the initial development. Every change should be logged in a manner that follows your style guide AND documents any exceptions. Yes, it is added work. However, if you want to keep your data consistent and standardized it is necessary work.

#3 Use the Right Tools

Remember the first piece of furniture you bought from IKEA, with those little torx screw drivers they include that hurt your hands and slip out of the screw head way too easily? Remember your frustration and how many times you wished there was a simpler way? Well, there was and still is. Every screw driver bit set on the market includes at least one and often multiple torx bits. Here is a reminder of what the worst torture device since your mom's tuna casserole looks like:

Why did you not go running for your tool box before starting assembling your new Hemnes coffee table? Because they included the tool they wanted you to use, so why should you take the time and effort of going to the garage and finding the right tool for the job? The instructions are pretty clear: Destroy your knuckles with the included tools.

Item data collection is a foundational program. Most of the work from that team is never directly viewed by the end display systems in the enterprise. It is twisted and transformed to meet the needs of that particular channel. By the time item data has moved from collection to display it is hard to recognize the work that goes into collecting it. Therefore, item data collection programs are generally the last teams to get any budget love from the enterprise.

Until something goes wrong. Several years ago when I was senior member of a fairly large taxonomy team we decided to start standardizing our metadata values across all attributes. This is a huge task, as the web of impacts was significantly large for even the smallest change. We decided to test how these impacts would flow downstream in a controlled fashion by changing a single value: I changed the value "White" to "white".

The following Monday my manager came to my desk asking if we had done anything to break the links for the new iPad Mini deal that launched in the newspaper that weekend. As it turns out the link we used was case-specific and included the word "White". However, we no longer had White iPads: We had white iPads. We quickly undid the change.

Has our tools been more advanced the change from "White" to "white" would have been seamless. However, we did not have the right tools. In fact, I have never seen a comprehensibly-built taxonomy tool that can handle that simple of a change without causing some form of chaos downstream. I have however seen many many systems that cannot.

So despair and gloom on all us product taxonomists, right? Well, no. The above example is very specific to a particular problem. The bigger problem is that most businesses do not have the correct tools in place to even have the "White" versus "white" issue. They have White, white, Wht, wite, wte, WHITE, and every other variation and miss-spelling of that value possible. (Why didn't I say white is a color value? Ugh. The OCD in me has to show you this now..... )

Too many systems still rely on excel spreadsheet input. Whatever is inputted is stored, and that is that. Many more systems are built on string values with no validations, allowing different versions of white to exist. Lastly, many systems are not abstract enough to be able to reuse the same value list in multiple places, or stop you from adding bad values in the first place. This causes issues with consistency, accuracy, and normalization in your item data that shows itself during presentation.

Is there one perfect tool? No. There are plenty of imperfect tools for item data, both in the data collection space and the taxonomy space. You will never get 100% of the desired functionality you want for your item data program, just as most projects in business today never achieve their full initial scope. But understanding the abilities and limitations of the software on the market is the only way to start a scope discussion that is realistic to move your foundational need to a funded project. Too many item data projects are doomed before they start because of a lack of internal and external education on your business needs and the tools to meet those needs,  as well as unrealistic scoping. Don't let your project fall into that project black hole.

Had I used the right tools (apparently using the fork end of a hammer to pry the shell off the guts of the phone is a bad idea) I may not have had the extra bit of wire left over, and may have been able to understand where all the screws went when I reassembled. That extra clip probably came off during the prying, so being more careful with my tool choice might have averted that mistake as well. Looking back, I guess I am fortunate I did not use the other end of the hammer in a fit of what I like to call BFI. (Brute Force and Ignorance.)

Using the right tools is important. Excel is not a superior data collection tool, and storing decision logs in a database is a poor choice. There are plenty of solid taxonomy development tools, mind-mapping software, and other logging tools like SharePoint and Confluence. (These are not tool endorsements. They are all the first link in google based off a simple word search....  Please search responsibly.) Understand the tools you use and it becomes easier to manage the entire item data realm you manage.

In Summary...

Plan. Document. Educate. Build a Foundation. It does not get any simpler than that.

And....

I'M SORRY MOMMY! LOVE YOUUUUUUUU!