NielsenData

Mind Tricks for Business - Atomic Data Model makes Search Engine Dominance Possible...

March 30, 2010 at 7:01 PMJared Nielsen

Atomic Data makes search engine dominance possible

Online retail is not the same as brick and mortar retail.  When a brick and mortar store launches online they fall into this biggest trap.  Take an apparel shop… when you first walk in you find a men’s department and a ladies department.  The store is physically trying to demographically segment you.

If you create a data model that matches this, you will end up with the first <xml> node being <gender> which is a highly limiting path to follow for a search engine even though it may make the most sense for a human being.  You would then add data for teams, sports, colors, sizes, variants, materials of manufacture, and many other “parameters” for this data.  To avoid 3rd normal database limitation, you would start to peel this data out into separate tables… one for colors… one for teams…one for sports.  Then you would need to create many-to-many crosslink tables.  Over time, your table count just gets larger and larger as new needs arise.

The Root Object Classification

There is certain data that “hangs” off each sub-classification.  In this example the Item class stores who the manufacturer is (because most items have manufacturers).  The Apparel class contains the style information (because style is global to all apparel objects), whereas the Shirt class contains collar styles, sleeve variants, etc.

By localizing this information to class levels, once I define a “field” for the Apparel class, all future objects that inherit from that class will inherit that field.  Any objects that do not inherit from the Apparel class will not have the field at all.

Note how different this is from a traditional 3rd normal representation of data where we would have fields like “color1” and “color2” and “color3” simply to leave enough fields available just in case we might need them for a particular product application.

Maximum Flexibility for Customer Paths

Now that our data is structured with infinite flexibility while still retaining a core hierarchy (for default navigation purposes), when a customer walks into our store, we can simply ask Google “how they sent them” to us… and what keywords they used.  Now when the customer enters our “store” we can toss all of the inventory up into the air and literally rebuild our store to match the words they used in the order they used them.  Now they can enter as “ladies yellow tank top” and we structure our product data in terms of gender first, color next and product class third… but we also can welcome customers that ask for “white womens Nike shirt” which we do by scanning for aliases of class nodes, parent classes, and other permutations of the item for maximum comfort to the customer and higher conversion rates on sales.

Know a business that would benefit from our whitepaper on how Atomic Data Modeling can make search engine optimization possible?  Download it now:

02-Atomic-Data-Enables-Search-Engine-Dominance-by-FUZION.pdf (369.99 kb)

Customer Paths - Best Business Practices for Product Catalog Data Structures - Part 3

October 29, 2008 at 9:31 AMJared Nielsen

This is the third installment in a series that blends website architecture, data structures, and SEO marketing into a collaborative design pattern continuing from Part 2 - Best Business Practices for Product Catalog Data Structures - Speed vs Flexibility 

Many e-Commerce projects begin with an existing brick and mortar store that has decided to go online.  This means that certain data models and business processes can be inherited from the legacy business processes of a non-online environment. 

If you were going to open a physical, brick and mortar store, you would generally design the store based on "Customer Paths", meaning you would examine the vector that a customer would take upon entering your store so you could direct them along the shortest path (in certain cases) to where they were trying to go to find the product that they wanted.  Many websites are designed along a similar path but the application of brick and mortar strategies to websites may not be the most effective.

Take for example the concept that an apparel store is designed along the Customer Path strategy of Departments, Aisles and Shelves.  An apparel store would generally have a Ladies department, with a Shirts Aisle and a Tank Top Shelf.  It would make sense from a Customer Path perspective to have (female) customers enter, segment them by Gender as they walk to the Ladies department, further segment them by Type as they walk to the Shirts Aisle, and further segment them by Type as they scan the Tank Tops Shelf.

This seems to work in practice, but only as long as you can only have a single store.  Take a customer now that is female but instead wants the Nike Shirts section.  Your demographic segmentation Customer Path does not cater to them properly and so the Customer is forced to scan through all shelves that have Shirts in order to find the Shirts that match the Nike Brand.  You can see how relying on a fixed hierarchy limits your store planogram and structure in a very singular manner.  To experiment with alternate Customer Paths, you would be forced to do a hard store reset, or you could experiment with alternate locations... perhaps a Nike Store which would provide a Brand-based alternative for the Brand-conscious customer.

Imagine now a website where instead of a fixed store with a rigid, hierarchical structure of Departments, Aisles and Shelves, you had a completely dynamic store that could be rebuilt in an instant and individually for each customer that entered for their own, private shopping experience.  Imagine also, those fixed Aisles and Shelves full of product, which instead of sitting in fixed placements, when a Customer entered the store the entire inventory was tossed into the air, only to fall back in the precise order that the Customer wanted to see them in upon entering.  This is no fantasy in an online e-Commerce website where this type of flexibility is possible.

Let's take a look a the Customer Path options open to an e-Commerce Apparel customer:

 

If you recall the Product to Property Mapping diagram shown in Part 2 - Best Business Practices for Product Catalog Data Structures - Speed vs Flexibility, you will see some of the same Property mappings in the above diagram.  These help to illustrate the product being mapped within the data model along the Customer Preference Paths instead of a fixed hierarchical model that a traditional brick and mortar store operator might follow.

For example, a customer that may be more interested in Tour de France could be immediately segmented in a store with inventory sorted by the Event Property first.  Then, if the customer was interested in the Brand Property next, the inventory would be tailored to suit by showing Nike merchandise.  Finally as the customer settled on a Tour Property related Product with UCI Pro Tour branding, the final product match is easily found because the inventory re-sorted itself to match the preconceived desires of the newly arrived customer.

Similarly, a customer that was more interested, at the time, in Lance Armstrong and then Tank Tops and then a color selection of White, could follow the Customer Path of Player / Type / Color.

You can see how the model continues.  Take some time to evaluate your own design process when you created your categorization model for your e-Commerce storefront.  Think about the process you went through as you decided on the model and see if you were trying to adapt a brick and mortar model to one that could have been conceived with an online presence in mind from the start.  If so, this may help guide you along a fresh look at the construction of a new categorization schema for your online e-Commerce catalog.

The series continues in Part 4 - Best Business Practices for Product Catalog Data Structures - SEO Path Aliasing

Posted in: e-Commerce | Research Laboratory

Tags: , , , , , , , , ,

SEO Path Aliasing - Best Business Practices for Product Catalog Data Structures - Part 4

October 29, 2008 at 9:28 AMJared Nielsen

This is the fourth installment in a series that blends website architecture, data structures, and SEO marketing into a collaborative design pattern continuing from Part 3 - Best Business Practices for Product Catalog Data Structures - Customer Paths.

It may seem counterintuitive to discuss search engine optimization (SEO) techniques in the midst of a conversation about data structures, architecture diagrams and in-store plan-o-grams, but it can directly relate to your choice of data models.  As we discussed in the previous article, it is important to structure your website to conform with the needs of entering customers in a way that segments them properly so they find the things that they were searching for.  Part of this is anticipating what a customer is going to want before they enter your store. 

When dealing with search engines, there are two customers to contend with... the "Natural" search engine... and the "Paid" search engine.  These two customers are very important to understand and to distinguish and need to be treated with a deference and distinction from the "real" customers that frequent your online store.  The complexity arises to some degree because these two "customers" happen to be "ghost shoppers".  You never know when they are going to arrive and they generally float through your store much like a customer would, but they are searching for every product on every shelf in every aisle and in every department... all at the same time.  The complications continue because you want to manage what the ghost shoppers can and cannot see so they don't memorize portions of the store that you don't want reported on the search engines.  This may come across as elemental theory to an SEO expert, but in the context of blending SEO concepts, architecture and data structure modeling, it illustrates one aspect of the equation.

Imagine now that you are a search engine, whose job is to find, identify and classify billions of e-commerce pages throughout the Internet with the primary objective of finding pages that are considered "relevant."  I quote the term "relevant" because what that precisely means changes with the breeze and the whim of arcane departments of voodoo at the various search engine optimization firms.  With that said, you want to look at a natural search engine as a stream of water pouring into your website.  This stream is going to remember whatever it touches, so you want to ensure that it finds the things that you want it to see.  You also need to consider the diffusion of the stream of water as well.  Don't let the natural search engine stumble across pages like "Privacy Policy" or "Terms & Conditions" as that won't deliver any tangible benefit for you.  In similar fashion, on your landing pages you should try to structure your site so the links that are the most compelling draws for the majority of natural searching customers should be setup to receive the largest stream of natural search "attention." 

You also need to anticipate every possible combination of keywords that would be used to "land" on any given destination.  Lets take a look at the SEO Path Aliasing diagram to illustrate that:

 

We have already covered Customer Paths but sometimes the proper "path name" doesn't match an actual English phrase.  This means that the combinations of words that make sense for categorizing a mix of products may not make linear sense for a keyword search.  Our diagram above illustrates this with the green path of "Ladies / Nike".  There may not be many customers that would enter that phrase in a search, but it may be a logical progression as they navigate through a website.  This is where Aliased Paths come in.  In our example, the Aliased Path for "Ladies / Nike" could be "Ladies Nike Apparel"... sure this one is a bit of a stretch...  I'm not sure how many actually type in the word "apparel" but you'll need to work with me on this one.

You will note that this path is identified as "overridden".  In smaller e-Commerce websites, it may be a simple matter to manually go through each Customer Path and identify the possible Aliases but in far larger catalogs this quickly becomes a daunting task.  It doesn't mean that overridden Path Aliases aren't an important part of configuring your catalog categorization scheme, but you can, for the most part, rely on the auto-generated Path Aliases for many of the Customer Paths in your catalog.  Take the path "UCI Pro Tour / Tank Tops" which easily converts to an English text keyword search of "UCI Pro Tour Tank Tops". 

Note also our attempt to focus the "stream" of the natural search flow throughout the various Customer Paths.  Many search engines respond to a setting within the hyperlinks of a "NOFOLLOW".  This mechanism gives you some measure of control over which links you allow the natural search "probing" to find.  You will note how the various Customer Paths are identified as NOFOLLOW for those paths that we want the search engines to pass on as they traipse through our pages.  This poses another logistical issue in a large-scale e-Commerce website which we will address in the next segment, Part 5 - Best Business Practices for Product Catalog Data Structures - SEO Weighted Auto Mapping

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

October 29, 2008 at 9:15 AMJared Nielsen

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.

Posted in: e-Commerce | Research Laboratory

Tags: , , , , , , , , , ,

I'm Human... You can talk to me personally...

I am available for speaking engagements and book signings. If you are interested in having me attend your tradeshow, corporate training event, or media event please contact me directly using the below form.