7 potential problems when defining product data models for PIM

If you’ve read my previous posts about PIM, you’ll probably have gathered that I prefer a collaborative and iterative approach to defining a product data model. There’s a good reason for this. By including multiple voices and approaching the subject from different points of view, the chances of missing or misinterpreting a key detail are reduced - and the chances of success therefore increase.

But even with multiple knowledgeable people in the working group, problems can still arise. Some of these relate to the solution, others to the method by which it is devised, but all of them can add delay into the process or inefficiency into the output.

Of course, the problems that can occur vary widely but I’ve highlighted 7 common pitfalls to consider when modelling product data as part of your PIM implementation:

1. Levelling

Frequently we think of products as belonging to a specific node within a taxonomy or hierarchy of domains and categories.

As businesses evolve their product catalogue over time the levels within this can become disjointed and misaligned. For example, Men’s clothing within a previously female focused brand may be grouped together, where the womenswear is split into categories like dresses, skirts and trousers.

Equally dysfunctional, the organisational boundaries, teams and subdivisions can find their way into the taxonomy, reducing its purity as a consistent, mutually exclusive hierarchy of products - one that should remain uncompromised by the way the business is managed at a specific point in time.

2. Gender specific items

Depending on the sector, some products may be commonly considered as gender specific (e.g. skirts) whereas others are unisex (e.g. trousers). But in reality, it isn’t even as simple as this, as continuing with the trousers example - whilst products exist for both men and women they often aren’t the same cut, fit or style.

Considering how to handle these products is therefore a key consideration - it is feasible to have a completely gender neutral hierarchy, or does it require a gender split? And if it is split, should this be as a high level branch, or as a final separation to the final leaf nodes?

Moreover, however this is logically resolved, how will the model’s structure handle the necessity for different sizing protocols for male and female focused products, particularly regarding size localisations to different sizing regimens.

3. Dual-use naming

When is a category not a category? When its a category of course…

Confusing, yes… but I’ve found even within a single company there can be as many as five different interpretations and meanings behind the term “category”. The most common disjoint here is that what something is physically is not the same as where it sits on a website - so when talking categories with different business users, be really clear on what you both mean.

4. Precision vs. accuracy

Whilst having precise definitions for every single option within the product facets and attributes might seem like an admirable goal of product information management, be careful what you wish for.

Providing too many near duplicate options risks inconsistency in how they are used, leading to a poor filter experience for customers and a lack of statistical power in the data when used for analysis.

There will always be a trade-off between precision and accuracy, so where “spots” may not be 100% perfect for a polka dot dress, is it close enough that customers will still be able to filter from a reduced set of options and find what they’re looking for? And will your insights team find it easier to identify the key trends and see how spotty products are doing versus striped, floral or colour block?

5. Decision making

Who owns the product data model and taxonomy in your business? In many cases, the answer here is one of: “I don’t know”, “no-one” or “we all do” - none of which are ideal!

If you’re restructuring the product data model for an entire business, its right that the solution should be devised collaboratively. But it is also unlikely that you’ll reach a consensus on every aspect. At some point, someone needs to decide how the model will be set, draw a line under any debates and provide the direction to move on with putting it in place.

Even with a mandate in place its vital to not let perfection stand in the way of progress - as long as the structure is robust, scalable and extensible, consider where to draw the battle lines.

6. Migration

Migrating data is hard. This is especially the case when the data in question is changing formats, attributes are being redefined and options removed or amended.

To mitigate any problems at the migration stage, consider the from and to data mappings as early as possible. To help work out how much involvement this requires, think about how much manual assignment will be needed, or whether you can map many-to-one, or many-to-many based on attribute combinations.

AI can also show its benefits here. Visual tagging or information scraping and retrieval can help fill in the blanks, or replace inaccurate values as part of preparing the data.

7. Misuse of attributes

Finally, don’t be tempted to force attributes to apply where they don’t, e.g. “Skirt Length” should only be applied to clothing items with a skirt (e.g. Dresses / Skirts) - don’t add additional options just so it can be also applied to other things.

Even worse, don’t “borrow” an attribute and use it for an entirely different purpose altogether. No-one will be happy with spurious values cropping up in filters or their analysis.

The cost of an additional attribute is very little, but the cost of poor data reducing the quality within an existing one is potentially quite high. Construct a product data model that is flexible enough to cope with the subtleties of your business and it's product catalogue but that restricts attributes and options only to those products where they are valid.

Don’t trip up!

The data model within your PIM is a critical component in both the product experience you can deliver, and the insight you can gain from your product catalogue. If you've made the conscious decision to implement a PIM solution to improve your business performance, don't trip up when considering the data that will go into it.

With the advances in ease of use and configurability in today’s PIM solutions, the data modelling is likely to be the most involved task you undertake when implementing a PIM. But extra time and care taken at the outset will pay dividends in the future.