NielsenData Blog by Jared Nielsen

Internal Site Search Optimization - Best Practices for Product Catalog Data Structures - Part 6

This is the sixth installment in a series that blends website architecture, data structures, and SEO marketing into a collaborative design pattern continuing from Part 5 - Best Business Practices for Product Catalog Data Structures - SEO Weighted Auto Mapping

It turns out that Property mappings for Products can also lend a hand for search term optimization.  While this is helpful with external search engines through Customer Path definitions, it also becomes helpful with internal search tools built into the site itself.

As you are defining your internal search strategy, you have many considerations that need to be planned out.  Some aspects of internal search could include:

  • Related Keywords
  • Misspellings
  • Alternate Names
  • Competitor Keywords
  • Plurals
  • Multilingual
  • Synonyms
  • Legacy Phrases
  • Synonym Phrases

The diagram below demonstrates some uses of Property mappings dovetailed with internal search terms:

You can see in this model how we can implement various internal search strategies that are directly mapped to Properties.  This helps us because the mapping of internal search terms can be done atomically to each Property value which when mapped to Products can create an aggregate library of internal search terms for each product that is mapped.

Take the Customer Path of "Ladies / Nike".  We have decided to map Synonym terms for "Ladies" that incldues "Womens", "Hers", and "Female".  While the actual value of each synonym should be independently tested (through A/B testing or multivariate), each one of these could be used interchangeably with the term it replaces.  This helps us on the natural search engines that traverse the Customer Path and also contributes to a more effective internal search algorithm as well.  Now the Customer Path can be addressed through "Ladies Nike" and "Hers Nike" at the same time. 

In similar fashion, if a customer was looking for products that were mapped to the White Color Property, even multi-lingual terms could be interchanged such as "Blanco" and "Blanc" which opens up our search results to even more ranges of public and private search engines.

Related keywords enable us to establish corrolary alternatives to common terms, in this case one of the Nike related keywords could be "Velocity" to which the Property of Nike could be mapped.

Misspellings offer a rich range of additional keywords that can be layered onto a particular Property value, such as customers that type in "Lantz" instead of "Lance" when they are searching for Lance Armstrong apparel.  It's useful to mine the "missed" search logs as you let your internal search tool collect them so you can decide which misspellings to incorporate into your Property value mappings.

Alternate names allow you to link various other phrases that can be used interchangeably, in this example the UCI Pro Tour is also referred to as the UCI Tour.

Competitor Keywords layer in the functionality of "borrowing" a bit from the brand equity of the phrases that may be used by your competitors.  If there was a competitor that used a brand name of "Tankz" and you were selling "Tanks" as one of your products, you could affiliate their brand key phrase with your product Property mappings.

Plurals are such an easy keyword combination to miss but they are ever so common.  Because it's highly intuitive that customers will use plurals (or singulars) in everyday use, this should prioritized as one of the best targets for low hanging fruit.

There are other uses of this Property to Product mapping with alternate keyword value definitions that I haven't even thought of, but I hope that the message is clear that utilizing the Property to Product data mapping architecture can provide a high degree of flexibility and utility.  In general the use of highly atomic information that is reconstructed at will based on the needs of the customer without preventing you from implementing edge caching as your front end solution to the client.

We continue to explore how to leverage the atomic data model in Part 7 - Best Business Practices for Product Catalog Data Structures - Comparison Shopping Site Syndication.

Comments are closed