6 Use Cases for Compatibility Databases on E-Commerce Sites

During our e-commerce usability research studies, we have time and again observed how a lack of compatibility database in relevant product verticals can have hugely negative usability and business implications, resulting in lost sales, anxious customers, and returned orders.

Some products are compatibility dependent – that is, the product’s relevance is determined entirely by its compatibility with another product the user already owns or plans on buying. Typical compatibility dependent products include accessories (e.g., a case for a laptop that has to fit), products used in conjunction with other products (an audio system that needs to plug into the TV and media players), spare parts (a laptop adapter that needs to have a charger tip and power rating that matches the user’s laptop), consumables (ink that has to fit an exact printer model), and so on.

Inter-product compatibility is essential to the user for these types of categories. For instance, if the user needs an adapter for their laptop, they need to be absolutely sure that the two are compatible or the adapter will be useless to them. In these types of product verticals it will therefore often only be a small sliver of the vast sea of products available on a site that are of any relevance to the user because all the other products are incompatible with the item the user already owns (or plans on buying). Thus, unless the site provides a way to browse products based on their compatibility with the items the user already owns, the user is forced to plow through an endless stream of noise just to find a few products that are potentially relevant to them. Compatibility databases provide the bedrock of such navigational features.

But what exactly is a compatibility database? It’s essentially a mapping of product inter-compatibilities throughout a site’s product catalog (and sometimes beyond) that enable the site to recognize which products are compatible and which aren’t. The applications of such databases are wide-ranging, although the perhaps most obvious feature is allowing users to filter out products based on their compatibility with one or more inputted items (which the user already owns or plans on buying).

In this article we’ll explore the concept of compatibility database, what they are, why they are important, how they can be built, and the wide range of applications that they have – improving everything from the user’s filtering and on-site search experience, to enabling better product suggestions, powerful personalization features, and opening up attractive new SEO opportunities.

Why Compatibility Databases are Important

Product compatibility has been a recurring theme throughout all of our usability studies, from Homepage & Category, to Mobile E-Commerce and E-Commerce Search, and even our Checkout studies. When inter-product compatibility isn’t understood and supported by a site, it quickly shows throughout the entire e-commerce user experience, leading to:

• Lost sales – Some users will (quite understandably) decide to not purchase when they can’t tell or feel uncertain about a product’s compatibility with the item(s) they own. These users will find other places to shop where they can get the reassurance they need. This obviously leads to lost sales.
• Anxious customers – While some users will simply leave the store, others will decide to take a chance. During usability testing, the test subjects that felt somewhat certain in a product’s compatibility would sometimes “take the chance” and simply order the product. Yet they would not do this until after exhausting the site’s product range and their product descriptions, and the subjects certainly didn’t have a great shopping experience. Placing an order for a product you’re only fairly confident will be compatible with the item(s) you own obviously makes for a stressful shopping experience, both during the online shopping and during the stretch between placing the order online and receiving it and testing its compatibility – the “moment of truth” where you get to know whether you made the right choice or not.
• Returned orders – Sometimes those anxious customers were right to be anxious, as some will inevitably end up ordering incompatible items. This happened a number of times, even for test subjects that felt very confident in the product compatibility. Once received, tested, and found incompatible, the customer will naturally want to return the order. (Yes, some users may find returning their order too much of a hassle, which is potentially even worse since the experience will be doubly-frustrating for them – not only did they not end up with the product they were looking for, they also wasted money and time, waiting for the order to be delivered. Don’t expect many of these customers to return.)

Clearly, not supporting product inter-compatibility in relevant verticals is highly problematic. Yet despite all of these seriously negative consequences, the support for product compatibility is lackluster at most sites in today’s e-commerce landscape. This is true even when the scope is limited to industries where inter-product compatibility is absolutely fundamental to the product verticals, such as electronics products. Yes, it does take some effort and resources to tackle product compatibility, but the rewards of a compatibility database far outsize the investment.

Related Products vs Compatible Products

“Compatible products” and “related products” are two fundamentally different things. When discussing compatibility we’re referring to products that have an interdependency – for instance, a replacement battery designed specifically for a particular laptop, the two must function together to be considered “compatible”.

Meanwhile “related products” don’t necessitate such inter-product relationships. For instance, a helmet is a related product to a bike, but the two don’t have an inter-product compatibility requirement as the products function independently of each other. So while all “compatible products” can logically be considered “related products”, not all “related products” will necessitate inter-product compatibility. “Compatible products” are in other words a sub-set of the broader “related products” spectrum, with much stricter requirements for accuracy.

Product compatibility therefore covers a much narrower set of product domains. It’s likely less relevant to apparel sites, health and beauty products, etc. Meanwhile a site selling cameras will almost certainly need a compatibility database to map the vast range of cameras, lenses, batteries, bags, and more, to one another so the user can easily weed out all incompatible items and focus just on the products relevant to their unique context.

6 Use Cases for Compatibility Databases

Compatibility databases essentially let the site act as a highly knowledge sales clerk, guiding the user towards the products that are uniquely relevant to them and the items they own (or are about to purchase). This can be especially helpful for users who have little or zero domain knowledge and need assistance in picking products that will be compatible.

1) Filtering

No matter how good the price is, how great the specs are, how perfect the customer reviews pronounce the product to be, or how appealing the product’s design is, the end-user will not be interested if the product is incompatible. Compatibility basically represents a go / no-go factor that can completely invalidate any product, regardless of its other product attributes.

And thus, one of the most obvious ways to put a compatibility database to use is by using it to support product list filters, allowing the user to filter the listed products by their compatibility with the item they already own (or are about to buy). This could be anything from entering the name of a camera to get a list of matching lenses (a fairly complex data model) to selecting between laptop sizes for a list of laptop sleeves (a somewhat simplistic and potentially flawed approach). It’s an elegant solution that in a single action allows the user to customize the site’s product lists to show only the items relevant to their unique situation.

That said, not all compatibility filters are created equal. One of the poorest stand-ins for compatibility filters are ‘Brand’ filters. Let’s be very clear: ‘Brand’ filters are nearly always inferior and won’t be able to provide the necessary user assistance. First off, brands tend to have multiple series or products with different compatibility aspects. For instance all Lenovo adapters will not fit all Lenovo laptops, so simply applying a filter for “Lenovo” will not give the user a list of all the products compatible with their specific Lenovo laptop. Second, for several compatibility dependencies, 3rd-party products are a major aspect, thus a brand filter for laptop sleeves will be useless in providing the user with a full list of laptop sleeves for their Macbook laptop.

Instead compatibility filters typically need to be based on the product attribute(s) that determine the product’s compatibility. For a sleeve, bag, or case, it would typically be size, or at least a size interval. For a laptop adapter, the relationship is a little more complex and a filter would ideally allow the user to enter their laptop model and get back compatible adapters.

2) Search

As described in our exposition on e-commerce search, compatibility searches are when the user queries for the name or brand of a product they own along with the type of accessory or spare part they are looking for, such as “sony cybershot camera case”. These types of searches are surprisingly common because users often don’t know the name of the accessory or spare part they need but only know the details of the product they already own. This can indeed be an incredibly powerful way for users to find accessories and spare parts.

Of course, in order for the search engine to return meaningful products to compatibility-based search queries it has to understand the inter-product compatibility relationships in the searched domain. Compatibility databases can be used to feed your search engine with this type of information so it can return highly relevant results to a user’s compatibility search.

A simpler but also very powerful implementation is to use your compatibility databases to filter the matches returned from the search engine. This doesn’t require as tight integration between search engine and compatibility databases, and the search engine doesn’t need features to handle inter-product compatibility relationships. Instead, all that’s needed is a system to detect compatibility-based search queries, and then when detected, the system can re-use any compatibility filters already implemented by automatically applying the relevant filter value(s) as extracted from the user’s search query (this of course requires the ‘applied filters’ design to be implemented flawlessly.

The filter-approach provides the user with a great deal of transparency because they can see that the site indeed understood their compatibility query and applied it as a filter on the search results, but the lower degree of integration also means the search engine can’t use the information to adjust result relevance. A combination of the two would of course be ideal, with both deep-integration between compatibility databases and search engine as well as high interface transparency through auto-applied filters.

3) Product Suggestions

Suggesting relevant supplementary products when the user is on a product page or have just added an item to their cart can be a very effective way of up-selling, as explored in our article on alternative and supplementary product suggestions – if they are relevant product suggestions, that is.

During our usability tests we’ve found that poor product suggestions are perceived as noise and only served to distract and annoy the test subjects, whereas highly relevant product suggestions were seen as a service – something desirable that the subjects actually liked. The relevance of product suggestions is therefore essential. Now, there are many factors that go into making highly relevant product suggestions but compatibility is naturally a major factor in verticals where inter-product compatibility is of concern.

As discussed in our article on product suggestions, many users will actually assume that any recommended products are compatible with the product they were suggested from. So if the user is on the product page of a camera and a set of camera bags are linked to, the user will likely expect those bags to be compatible with the camera. And this only seemed to be even truer of any products suggested for an item the user has just added to their cart. The labelling of product suggestions is therefore crucial unless compatibility can be ensured.

In fact, during our usability tests the only label that didn’t naturally lead the subjects to expect compatibility was “Other customers also bought” and similar phrasings that underscored the suggestions were based on the behavior of other customers and not recommendations coming from the site or vendor. It’s worth noting that such product suggestions were often perceived by the subjects as “less trustworthy” because they weren’t “mindful recommendations” but rather a set of behavior-based links.

Any site wanting to make product suggestions (such as up-sell promotions of related accessories) in compatibility-dependent product verticals therefore either need to always base them on the behavior of other customers (which isn’t always a good strategy for low-volume items, and altogether unviable for any sites that don’t receive hundreds of thousands of visitors on a monthly basis) or they need compatibility databases to ensure the recommendations are indeed compatible.

4) Personalization Features

When the test subjects during our usability studies are looking for compatibility-dependent products it often involves a great deal of anxiety. Even subjects that are fairly certain they’ve found a compatible product tend to verify a couple of extra times on the product page before adding the item to their cart. Sometimes this verification involves going off-site to research the two products’ inter-compatibility, which can naturally lead to site abandonments if the user gets distracted or picked up by a competitor during that research process.

With compatibility databases in place, site can implement some intelligent personalization features that help reassure users of product inter-compatibilities to reduce anxiety and prevent them from venturing off-site to verify compatibility assumptions. For instance, if the user has performed a compatibility filter on previous pages, have added an item in their cart, or have purchased items in the past, and that user is now looking at a category of products with inter-compatibility dependencies with that item, each list item could display a notice indicating its compatibility with the prior item – as seen above at eBags. Or a suggestion to add a filter based on the item could be displayed.

Product pages could similarly be updated to reassure users. For instance, if the user have added a ‘Lenovo Yoga 3 Pro’ laptop to their shopping cart and are now looking at a spare battery, the product page could display a notice saying “This battery is compatible with the ‘Lenovo Yoga 3 Pro’ laptop in your shopping cart”. That way the user is reassured that the two items are indeed compatible and will feel confident in adding the product to their cart without feeling the need to venture off site to verify their inter-compatibility.

It’s all about taking advantage of the user’s prior site behavior (e.g. previously applied filters and visited products), their current context (e.g. items in the user’s cart), and any historic data available (e.g. past order history), and then intelligent making small modifications to product lists and product pages to eliminate customer anxiety about purchasing compatibility-dependent products.

5) Wizards

Simply finding compatible products isn’t always enough – sometimes the user also needs assistance in finding “just the right item” in that collection of compatible products. With compatibility databases in place, sites can develop product finding wizards that help the user find compatible and appropriate product integrations (e.g. stereo for a TV) and accessories by asking the user a series of questions and then returning a highly relevant set of products based on the user’s inputs.

The promise of wizards is grand indeed, and when they work well, wizards can be incredibly powerful – effectively acting as a highly knowledgeable and helpful sales clerk, finding just the right product for each customer that walks in the door. Wizards are basically a highly assisted type of product browsing, where instead of having the user weeding out products until they hopefully see something to their fancy, the site seeks to find them just the right item based on a profile of their needs (which is created through the user’s answers to the series of questions the wizards puts up).

Of course, in order for product finding wizards to deliver on their promise of finding a handful of highly relevant items (or “just the right one”), the underlying dataset must be rock solid. In product verticals where inter-product compatibility is a concern, compatibility databases are an absolute must for wizards. In fact, because wizards yield a set of product recommendations, users will naturally expect them to be compatible.

During our usability tests, even fairly simplistic product recommendations in the form of up-sells on product pages and in the shopping cart, have been perceived by some test subjects as recommendations by the site, which is critical because those subjects consequently expected the recommendations to naturally be compatible (the user’s logic probably goes something like “of course the site would only recommend items that are compatible with the other items I’m buying”). And of course the only way for a site to ensure that is to have the compatibility relationships mapped out in a database.

Therefore, in product verticals where inter-product compatibility is of importance, a site should only offer a product finding wizard if it is backed by an underlying compatibility database.

6) SEO

Compatibility databases map out highly important relationships between products and these connections can be used to auto-generate thousands of custom category pages. For example, a custom “Lenses for Nikon D7100” page could be auto-generated. It’s easy to see how this opens up for long-tail search engine optimizations.

Due to the mathematics of networks, even simple compatibility databases quickly run into the thousands of possible combinations. So while each of these custom pages may individually be low in traffic volume they can collectively make up significant volume over time. Especially since the high specificity of these custom pages will make it much more likely to catch top positions for these equally highly specific search queries.

The quality of this traffic will furthermore tend to be high, since highly specific search queries acts as a pre-screener because they only bring traffic that’s already provided a lot information about their interests. A user searching for “wide-angle lenses for Nikon D7100” is obviously very likely to be very interested in those types of camera lenses, whereas traffic from generic queries like “Nikon lenses” have vastly lower chances of being a good match between user and landing page.

Building a Compatibility Database

Ok, so we’ve looked at some of the many ways compatibility databases can be put to use, but how do you go about building one? Unfortunately, this can vary a lot from site to site, and product vertical to product vertical, and so there isn’t a single “right” answer. There are however a few implementation details to consider.

A poorly sourced or incomplete compatibility database will naturally lead to poor and incomplete product lists and suggestions. This often occurs if suppliers’ or manufacturers’ spec sheets are used directly. For compatibility databases to work well, it’s important to source information from the right places and even then the data will most likely still need to be harmonized to make it comparable across product vendors as it is not uncommon for different suppliers and manufacturers to name the same specs using different labels, use different units of measure, or even use different scales. For some product features, manufactures will even purposely create naming inconsistencies as part of their branding efforts.

To deal with all of these matters, consider the following these implementation details.

Sourcing Compatibility Data

The resources required for implementing compatibility databases will vary greatly depending on industry and the specific product type for which the compatibility database has to work. In some industries, it’s common for manufacturers to list all compatible products. In those instances, having a filter for product name is relatively straightforward as it is simply a matter of sourcing this publicly available information.

Unfortunately, reliable and uniformly structured compatibility data is often difficult to source from a large collection of suppliers. As a result, compatibility filters are rarely a plug-and-play implementation. Implementing and maintaining compatibility filters will therefore often require reformatting of certain product attributes so that, for example, all dimensions are in the same unit or sequence so they can be parsed computationally and turned into a filter.

For product types and industries where it’s rare to supply compatible products or product series as part of the product information, you’ll often have to reprocess the actual product specs to compile a list of compatible products and sometimes also source additional data (e.g., eBags had to source laptop names and dimensions to create the name-based laptop sleeve filter / finder).

If only compatible product series are delivered, you’ll have to cross reference them with a list of all product models within each series to compile filters based on product models. During testing, the subjects often became in doubt when presented with just the product series, for example, not being completely sure if their “Lenovo X61s” was part of the “Lenovo X60-series”.

Data Harmonization

In some industries where there’s fierce competition on a few key specifications or features, there’s a tendency for manufacturers to use brand-specific names for those features. For example, for TVs, Sony has named their refresh rate system “Motionflow”, while Samsung calls it “Clear Motion Rate”, LG “TruMotion”, etc. Or for camera lenses, the manufacturer Sigma calls their image stabilization system “Optical Stabilization (OS)”, Nikon call theirs “Vibration Reduction (VR)”, Canon “Image Stabilizer (IS)”, Sony “Optical SteadyShot”, Tamron “Vibration Compensation (VC)” and so on.

Regardless of what the manufacturers may get out of this, these branded feature names cause usability issues on the e-commerce sites that simply reuse this manufacturer data for filtering. Simply listing all the different branded feature names will require extensive domain knowledge for users to recognize and select between (e.g., they’ll have to know or research that “TruMotion” is much the same as “Motionflow” in order to filter by any of the values).

What the user is more likely to know and be able to filter by is the “common name” of the feature (e.g. for the two prior examples of TVs and camera lenses, it would be “Refresh rate” and “Image stabilization” respectively). Besides being more recognizable, the user will get the option to infer advanced domain knowledge (yes, these features are in fact similar), and the filtering interface can often be simplified greatly (e.g. reduced to a single checkbox for a yes/no feature).

To offer harmonized filtering values, the site will often need to post-process the branded feature names into a “common name” product spec that can then be used to filter by. Data processing-wise, this will often be a relatively simple task once the system is in place, but it needs to be supervised or initiated by someone with sufficient domain knowledge to identify the branded features’ counterparts. (Note that the suggestion here is not to alter the product page description or spec sheet itself, but to create a “harmonized extra dataset” to base the universal filtering option on.)

“Translating” Filters

Users’ lives seldomly revolve around technical specifications of products they own – therefore, most will often have a difficult time understanding, remembering, or even locating technical compatibility specifications for products they already own (and even more so for products they plan to buy). This can be, for example, the lens mount type of their camera, the voltage rating for charging their laptop, or the cartridge number of their printer ink.

Our e-commerce research studies show that usability issues arise when users are asked to select between compatibility filter options based on specifications that they don’t recall or fully understand. Therefore, instead of asking users to apply filters based on compatibility specifications, consider reprocessing the compatibility specs into something that is more relatable or accessible to the user, such as the model name or number for the product they already own.

In the above example, allowing users to look up compatible lenses by simply entering their current camera model saves the user from identifying and specifying lens mount type, frame size, and built-in autofocus features. Such filters will of course require reprocessing of those lens attributes to compile a complete list of cameras that each lens is compatible with.

Getting Started

We’ve purposely referred to compatibility databases in plural form throughout this article, since a site will often need multiple different compatibility mappings for each of their compatibility-dependent product verticals. However, nobody said you have to develop and launch all of these at once. Begin with your most popular product vertical where inter-product compatibility is a concern.

After reading this article you probably (hopefully!) have a pretty good idea of what that compatibility database might look like, how you might source and post-process the information for it, and of course some of the many different ways you could put it to use. Improving everything from your users’ filtering and search experience, to enabling guided product finding through wizards, improved product suggestions and powerful personalization features, and possibly even taking advantage of new SEO opportunities.

An added benefit of compatibility databases is that they – much like e-commerce search engine investments – benefit both desktop and mobile sites / apps. Indeed, some of the product finding use cases of compatibility databases are even more relevant in a mobile context because product browsing tends to be tricker on mobile devices due to the lower page context and similar mobile design limitations.

Compatibility databases might not be the simplest of e-commerce features, neither from a content management nor a technical perspective, but their potential benefits are palpable indeed, and may just be one of the best ways to create and maintain a competitive advantage in a crowded e-commerce landscape.