Product data and relationships

Don't worry, we didn't go to therapists. But today we want to look at the topic of relationships — more specifically, the question of what product data has to do with relationship knowledge and how the two topics intertwine in marketing.

First of all: A “product” in marketing is easy for most people to imagine — whether as a product detail page on the web or as a page in a print catalog. There, this product then has a name, an order number and many features that describe it. How well this information is structured and presented consistently is a decisive factor in how efficiently the data can be worked with and how successfully the products sell. Are the right keywords in the product text? Does the name of a technical attribute correspond to industry jargon? Is my product portfolio described in such a way that the user can easily compare? And is my data model so flexible that I can react quickly to market changes or system requirements? At the same time, the question is: Can I standardize all of this so that I can efficiently operate as many output systems as possible? How do I deal with image variants?

We have been asking all of these questions for years. Today, however, we'd like to address two recent trends that we're observing.

Trend 1: More and more information per product data set

In recent years, we have seen a significant increase in the amount of content per product data set. More media assets are being produced, there are more texts, and there is a growing desire to store and link as much additional information as possible about each product. Archived products continue to be published, images are provided in higher resolutions, and under the pressure of digitization, the need to consolidate as much data as possible in one system and streamline its output is increasing.

An example: The new product image of article A is also used as a “similar image” for article B. Accessories X and product Y go together — but this information is only really useful for the user if he also knows after how many operating hours a wear part must be replaced or in which assembly the part appears and how often.

Trend 2: Data must become more intelligent

Another trend is the increasing importance of service-oriented business models, which need to be more digitalized. A good example is the rapid knowledge of suitable spare parts for local service technicians — this saves time and money. The information about compatible accessories, including change intervals and downtimes, not only potentially increases sales in the shop, but also helps users calculate quantities in their company. This in turn can be a decisive argument in sales.

database, relationships between objects and flexibility

These trends are prime examples of “relationship knowledge” — the ability to model relationships between objects. Is it an accessory or a spare part? What is the context? Does it mean the same in all countries? And what information is “on the relationship” between two objects and not directly on the individual objects themselves? Such relationship information could even help automate processes that previously had to be maintained manually.

As always, the most important thing is: You have to understand the reality that you want to depict.

What may sound abstract here has been known in the automotive sector for decades. No manufacturer or car repair shop can do without the appropriate information today. As a result, the requirements for data quality and structure are also increasing in other industries. The resulting opportunities are far-reaching.

Data quality and data completeness as a competitive advantage

Data quality and data completeness are decisive competition criteria — especially when industry standards such as Tecdoc, ETIM, ARGE and Datanorm provide a verifiable definition of these criteria. But even outside of such defined standards, the following applies: “Complete” is not a static state in an age of rapidly changing requirements. That is why “flexibility” is at least as important.

Most new business models and projects are based on this requirement: a solid database on the one hand and the necessary mobility on the other. This once again confirms the old quote from Lothar Schmidt: “Relationships only hurt those who don't have them.” Even though he probably didn't think of product data.

‍