Atomic Data Modeling and SEO Speech in Miramar Florida

June 24, 2009 19:53 by NielsenData

I'm pleased to be speaking to the Miramar group of the Florida Dot Net group at www.FlaDotNet.com.  You can register for this event at the following website:  Click here to register.  I will be discussing how proper search engine capabilities start at the database level using atomic data modeling practices.  The samples of the atomic data model will include how to layer in object inheritance at the SQL Server level, utilizing some new features in SQL Server 2008 including the intrinsic Hierarcy data type and a nice overview of search engine techniques that can benefit from a highly optimized and atomic database.  I hope to see you there!

You can get a head start by reading my blog series on the topic at:

www.NielsenData.com - Atomic Data - Best Business Practices for Product Catalog Data

There are other resources that ascribe to the Atomic Data Modeling concept which you can find at:

Zimbio.com - The Atomic Data Warehouse

Wikipedia.org - Data Warehousing and the use of Atomic Data within the Data Mart

Other announcements of this event include:


Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Speaking at the Houston Tech Fest

January 9, 2009 01:35 by NielsenData

 

Houston Tech Fest with Jared Nielsen Speaking for www.NielsenData.comIt's about that time again so I'm going to be speaking once again.  Please join me at the Houston Tech Fest in Houston (naturally) Texas for my seminar on finding your Search Engine and Data "Superman" amid your "Clark Kent" business.  Being able to identify as a coder the business methods needed to get proper search engine (SEO) rankings while satisfying good design criteria an reusability is important.  This seminar will walk you through such advanced topics as:

 

  • Atomic Data Modeling
  • Fast Page Load with Highly Normalized Data
  • Content Distribution Networks and Edge Caching
  • SEO and SEM Techniques in Code
  • Funneling "Juice" with your Web Traffic
  • Comparison Shopping Syndication
  • Expanding Marketing Channels through Code

Join my Houston Tech Fest Group on Facebook!


Currently rated 5.0 by 1 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

That's No Moon... It's a Space Station! - JaxDUG seminar on SEO and SQL Database Design

October 29, 2008 11:20 by NielsenData

Jacksonville Developer Users Groups JaxDUG

In an obtuse blend of incisive marketing strategy combined with hard-core database design, I will be speaking at the Jacksonville Developers User Group on November 5th at the Seashell room in Building 500, Bank of America Building, 9000 Southside Boulevard, Jacksonville, Florida.

The first seminar in my series, "Jedi Mind Tricks for Business", I will be exploring the database work that can be done in anticipation of marketing's demands for high speed, infallible reliability, and no cost solutions for SEO integration of websites.... it's just the tip of the iceberg folks...

For directions, please see this link:

http://www.jaxdug.com/Events/MeetingLocations/tabid/63/Default.aspx

 


Currently rated 3.0 by 2 people

  • Currently 3/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Featured Story on CNN (TV and CNN.com)

October 29, 2008 11:14 by NielsenData

A nice thank-you to the guys at CNN for running the story of my cubicle on their evening news and on their homepage.  Wasn't expecting it but it was a nice kudo:

http://www.ireport.com/docs/DOC-33852


Currently rated 3.0 by 2 people

  • Currently 3/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Featured Story on Carpetology Blog

October 29, 2008 11:04 by NielsenData

Here's a fun article about the benefits of plush carpeting to complete my Extreme Cubicle Makeover:

 http://carpetology.blogspot.com/2008/08/carpet-for-your-tent-carpet-for-your.html

"Don't you agree that high design such as this in the workplace, particularly in a cubicle, can only elevate, enhance and improve?  I do have one suggestion. A larger rug. For that matter, what about wall-t0-wall carpet for this cubicle? It would add to the richness of the experience, help absorb unwanted noise from neighboring cubicle mates and generally enhance the work environment." - Christine Whittemore, Director of In-Store Innovation for Solutia's Wear-Dated carpet fiber.


Currently rated 3.0 by 2 people

  • Currently 3/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

e-Barnett.com implemented my earliest e-Commerce system

October 29, 2008 10:43 by NielsenData

Here's a blast from the past...

Barnett, Inc. Chooses 'AutoStock' Supply Chain And E-Commerce Management Software

http://findarticles.com/p/articles/mi_m0EIN/is_/ai_54534095

 


Currently rated 3.0 by 2 people

  • Currently 3/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

www.MrsStrong.com - Mrs. John L. Strong Stationers

October 29, 2008 10:27 by NielsenData

I was contacted by a gentleman in New York to do an evaluation of an e-business that caters to the luxury market in niche metropolitan areas.  Mrs. Strong Stationers provide high quality, high margin gifts and stationery through their website.

Below is my evaluation of their project:

MrsStrong.com

Search Optimization

META Information

Description

The Description tag needs to be adjusted to accommodate proper (but non-exploitive) repetition of critical keywords.  Reliance on mottos and standard phrases should defer to crucial keywords in order of precedence.  Instead of

Keywords

Keywords need to be analyzed in terms of conversion ratio per dollar spent.  When I search for “fine stationery” the site is not on the first page.  The initial strategy needs to rely on paid search initially to generate the required revenue boost and traffic load necessary to seed the natural search (see natural search below).

You are not capitalizing on misspellings, which are going to be more than common with the word “stationery”.  While the proper spelling is classy and elite, we want to be sure that we are diverting all traffic to us (regardless of grammatical correctness).  Consider registering domains and emphasizing keywords for “stationary” as well, even if they are demoted or concealed.

Keywords need to be analyzed for KEI compliance.  There are many combinations that should be leveraged throughout the home and landing pages.

Title

The title is key real estate to deliver your branding message and you are only delivering the name “Mrs. John L. Strong”.  Consider adding a keyword laced message next to it: “Mrs. John L. Strong – purveyor of fine stationery”.  This delivers powerful influence on the naturals.

Search Results

Prime Visibility

You are invisible on the search engines.  If you aren’t on the first page, you either don’t exist or you aren’t credible.  If PPC budgets are a concern, then we can take tertiary strength keywords and fund them (very inexpensive).  If budget is not an issue, then we launch a frontal assault on the higher ranked pages immediately with a well funded PPC campaign.  This will let them know that we’ve arrived and we’re not going anywhere.  Once the competition starts to figure that out, it will put pressure on them to up their budgets and start an arms race.  While we just increased the costs of our competitors, we will quietly be vacuuming up all the secondary and tertiary keywords that are inexpensive but have far higher conversion rates.  Our $ per conversion will increase while theirs will decline substantially.

We need to tune the natural search carefully to drift somewhat away from the “what we are selling” element to the “how your life will change by buying our products” tone.  This will give us ample opportunity to channel the search engines to that rich keyword-laced content, while the “shoppers” are not diverted from buying.  This is done with a carefully constructed pattern of NOFOLLOW and precedence placements in your layout.

Standout Imagery is not being utilized on the search results and skyscraper advertisements.  By layering in Google Checkout as part of your payment offering (very plebeian I know..) it provide outstanding visibility of your PPC placements on page 1 of the search results.

The Homepage is very focused on branding and is torpedoing the SEO power of the home as the primary landing page.  It does a decent job of segmentation, but fails to deliver proper search engine visibility due to keywords being embedded in graphics or FLASH, choosing look over function, and other factors.   We can re-engineer the page without losing the “style” but it must involve certain sacrifices.

Consider layering in <div> injection on the FLASH so you can stream useful text to the search engines while the customer sees the graphical immersion you want.

Page Mechanics

Load Speed

The page loads are interminably slow.  You are selling “lifestyle” to people that hardly have the time (or interest) to wait for anything.  If you want to preserve the “style” then move the primary DNS of the site to an edge caching network which sources from your original origin servers.  I will have to do an analysis that verifies that this won’t pollute your viewstate or postback integrity, but once that is done your page load will decrease from 21.54 seconds to 0.5 seconds. That is a whopping 4200% increase in speed and must have an impact on your conversion ratio.

I found as I was “browsing” the catalog that I didn’t want to wait for even the product thumbnails so I ended up cruising through the site without seeing the products at all… Until I ended up on the product detail page.

FLASH Considerations

Your use of FLASH has pros and cons, but the current implementation lacks the proper Javascript for modern browsers that “activates” the FLASH.  This adds an unnecessary click and an annoying popup on all modern browsers… see below:

 

Page Compression

Modern browsers support GZIP page compression which your website is not utilizing.  This leaves your modern browsers with an experience that is as slow as the older browsers for no reason.  This could cut your page load speed down significantly.  Speak to your hosting provider to enable this for your site.

Page Weight

The size of your page is an astronomical 3,121,587 bytes.  Compare this to the target size which should be 100,000 bytes.  The longer a page loads, you exponentially lose conversion power.  This also has various other disadvantages (chances for errors go up, bandwidth costs exponentially rise, local machines slog through your site, etc).

Consider a cleanup where images are streamlined and made web-ready, FLASH is demoted from integrally packaged images to asynchronously called from web services, dynamically cached constructed images, etc.

Rewritten URLs

You are not leveraging URL aliasing.  This eliminates an extremely powerful influencer on the natural search penetration of your site.  Nobody is going to search for “.php?ID=746” to find your site… so don’t show that to them (or the search engines).  Consider the URLs like www.mrsstrong.com/catalogue/page.php?cPath=23_32 and then compare that to www.mrsstrong.com/gifts/calendars/Pagoda_Calendar .  It’s clear to see which one would provide better conversion and natural search rankings.  Consider the use of a standardized URL Rewriter with database lookup so it’s automated and you don’t end up out of sync with manually maintained URL rewriting configuration files.

Traffic

Traffic Profile

 

The site came on the scene in 2007 and is fading in the face of steep competition from the other sites.  This is 100% due to lack of an effective PPC, affiliate, and natural search strategy.

You should analyze the crane.com and finestationery.com websites for competitive intelligence.

Analysis

Analytics

I note the use of Google Analytics, but no use of Website Optimizer or Conversion Analysis.  You need to expand your analytics penetration to flag landings and conversions.  I also highly recommend cart interim analysis tags that can help you determine cart abandonment rates and other factors (like conversion values, etc).

Pull Marketing

Email

Cart Abandonment

Your site doesn’t leverage cart abandonment which is a critical step that carries an additional 20% conversion “re-bonus” if it’s implemented properly.

Email Registration

The instant email confirmation email is timely but has several flaws (See the incomplete domain information):

 

The email is also lacking any analytics or tracking beacons that will enable you to measure email acceptance.  This is an important strategy in email conversion rates.

Branding is always important.  This confirmation email is a perfect time to layer in graphical or stylistic branding.  Consider a stylized signature and elegant HTML wrapping that is compatible with the majority of email clients.  This can also facilitate proper beaconing.

New Account Registration

The new account registration as placed can act as friction to the ordering process.  Because of the likelihood that a popup will distract the customer from completing their order, it makes sense to put a “continue your purchase” link in the email that direct the customer (if they click on the popup from their mail client) back to the ordering process they were distracted from.   This is effectively a “dead end” page that interrupts a very important process flow.

Branding in this confirmation email could be tastefully done and would facilitate more beaconing.

The suspension of disbelief is important to maintain.  Calling the storefront an e-boutique rather than boutique has the tendency to shock them out of the disbelief that they are actually “in a boutique.”  Consider treating the website as a normal boutique in the phrasing and tone of the site.

The additional “thank you for registering” page is an unnecessary click and interrupts the process flow of the site.  Cart abandonment is the most difficult challenge, so eliminating this in lieu of a thank you message on the cart is preferable.

Checkout

Security

The Gift Options tab exposes the internal database customer ID value that is otherwise concealed in the osCsid.  This could be exploited by a savvy hacker to reveal information about the customer.   It also makes it somewhat easier to decrement the value and try to “surf” other customers.  Having sequential customer IDs is rarely a good idea.

Shipping

The concealment of the shipping rates can cause a customer to click “back” once they are at the checkout_payment.php page because they may not be sure what the shipping rate is.

I like the implementation of the multi-ship feature.  It may make sense to have the chosen shipping address to persist for items added subsequent to the shipping address being chosen.  Drag and drop would be very elegant here.

Payment

There is no confirmation of the payment amount at the time the credit card is being asked for.  This can have a significant impact on conversion.

Customer Memory

The browser forgets the user if the session is lost.  This requires a customer to log back in, even though the session timeout wasn’t met.  Anonymous checkout will resolve this to some degree, but you need to have a longer term cookie for persistence so you can capitalize on personalization.

Account

Anonymous Purchase

Not everyone wants to deliver their full profile information just to shop on your site.  Certainly you will harvest certain data from their credit card information, but the anonymous checkout feature has the benefit of reducing friction in the order process.  This will increase your conversions.

Payment Methods

Gift Certificates

There is no method of redeeming a gift certificate online.  This can be a powerful conversion tool, particularly for past-deadline shopping (too close to Christmas)

There is no method of obtaining an electronic gift certificate.  I realize this may fly beneath the level of the type of class the site is attempting.  There may be a “classy” hybrid where the online gift cert is designed to work with an iPhone for example, so we are borrowing some corollary brand equity from someone else that reinforces and “floats” the brand without drifting into the “tech” branding.

 

Currently rated 3.0 by 2 people

  • Currently 3/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Atomic Data - Best Business Practices for Product Catalog Data Structures - Part 1

October 29, 2008 09:42 by NielsenData

This is the first installment in a series that blends website architecture, data structures, and SEO marketing into a collaborative design pattern.

Designing a product catalog is one of those "better get it right" projects that any e-commerce firm faces.  When you discuss lifespans of projects, this one has the longest lifespan of them all.  Since I've been through this a couple of times, I thought I would share my thoughts and designs as I delve into yet another one.

There are a lot of political and technical pressures put on a product catalog from many departments within an organization including IT, Marketing, Executive, Operations, and particularly the "Industry Expert" within any company.  It is important to not only recognize them, but to appreciate them.  At the end of the day, almost everyone is "right" in their desires to have the catalog data serve them in a certain way.  As you put yourself in their shoes by doing a proper discovery before you start designing you should try to not only understand what they want, but why they want it.

Atomic Data

Your marketing team will call this "flexibile product information", your IT team may call this "dynamic product data", but at the end of the day, it's product data that is smashed into all of its discrete component pieces.

This is one of the first pressures that will be placed on you and you need to be prepared to deal with it properly.  It is important to understand that there is a competing struggle in any database design... Flexible vs. Fast.  If you think of a product as a construction made from legos, then the properties of those products are the individual lego pieces.  The concept of "atomicity" means that you can assemble your lego construction with Red, Blue and Green legos to make a space ship... and then you can rearrange those same Red, Blue and Green legos and build a house.

Now you've all seen the non-atomic way of building a product.  It's a row in a product table and it tends to look like this:

 

You are limited however when you decide to stock a product that has a "Sub Sub Type", or a product that only has one color, or a product that has two vendor brands on it.

You also have a design flaw where you are "numbering instances" of properties.  In this case "Color1" and "Color2" are going to cause problems for you when you want to search by "Color".

There is also a failure to properly "atomize" the data with things like "SubDept" being equal to "Ladies Apparel".

Let's compare this model to one that is fully "fourth normal" or highly "atomic".

 

Lets analyze this model.  The product is statically registered in a much abbreviated product table.  It serves now primarily as a hook that you can hang things from.  We've decided to establish all of our atomic types as "Type", "Gender", "Vendor", "Brand", and "Color".  You can see how this can be reused.  For the "Live Strong Velocity Ladies Sport Top" it makes sense that Color (to this product) "means" White and Yellow... but to other products the same property of "Color" could "mean" other colors.

You can also see the intrinsic hierarchy here that establishes "Apparel" as a "top category" over "Top" and likewise, "Top" as a parent category over "Tank Top".  This enables you to still utilize hierarchies in your product data representations while granting you also the ability to search ad-hoc through your product data in a non hierarchical manner by using the raw properties.

 I have taken an apparel data model and created a good sample of how the property to product mappings for a decent catalog could be structured:

 

This model describes the relationship between products and properties but also illustrates some of the intrinsic relationships between the properties themselves.  For example, if you mapped a City to a product, you could "infer" what State and Country relationship existed by recursing through the Property-to-Property relationships.

So... which data model is right?  The answer could likely be ... Both!  It really depends on your requirements which we will discuss in Part 2 - Best Business Practices for Product Catalog Data Structures - Speed versus Flexibility.

  

Currently rated 4.0 by 2 people

  • Currently 4/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Edge Caching Versus Dynamic Data - Best Practices for Product Catalog Data Structures - Part 2

October 29, 2008 09:34 by NielsenData

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

We've discussed some ways you can create highly discrete or "atomic" data for a product in the first article.  This article will delve into how to evaluate the choices involved in speed versus flexibility.

Any database administrator that works on a high volume, high production website will simply start to quiver uncontrollably however, because there are severe implications for accessing this type of data scattered throughout several tables in a production environment.  Pass him a mug of decaf and let's walk together through how we can tackle the thorny issue of speed related to product catalog data.

We can start with our sample product that we have now mapped into its discrete elements.

 

This data is fairly granular (or atomic) and is highly reusable within its domain ("Color" categorically means a similar thing to every product that is bound to it).  There are many considerations when it comes to allowing Speed to dictate your design, but I'll list some of the top ones:

  • Static Edge Presentation vs. Dynamic Source Presentation
  • Precomputation or Data Summarization
  • Staged Caching or Static Publishing

Static Edge Presentation 

Static Edge Presentation refers to the concept that data that is requested through web pages goes through many stages.  One model that many people are familiar with is the following:

 

Generally when the first hit is generated for a distinct URL, such as http://www.domainname.com/?ID=5, the Data Server generates the data needed for the page, the Origin Web Server composes the data into a functional web page, and then the Edge Cache Server distributes that origin page into its "cache" where the unique page sits in "static" for all subsequent hits.  If the page is requested from hundreds of Client PCs after that, only the Edge Cache Server responds to the request (until its cache expires).  If a single Client PC hits refresh over and over again, depending on the Client PC settings, the page is instead served from the Client PC's Browser Cache, which is a local equivalent of server-based edge caching.  This is generally one of the more advanced methods of serving high volume pages in a fast manner (and in a way that the database is impacted the least).  This is the preferred shield which allows your data structures to be a bit more complex (read slow), because at the price of the initial render, the cost per page load is mitigated by the Edge Caching.

Take a page that requires 8 seconds to load.  This is generally considered "too heavy" of a page to be used in production environments.  However, this is only the Origin Page Render cost, meaning it only "costs" this much time for the very first load of that unique page.  If all subsequent page loads only take 0.5 seconds from the Edge Cache for all subsequent hits, then averaged over the numbers of hits, you can quickly see how the page load time continues to approximate the 0.5 seconds load time overall for the page.

Another model is the Dynamic Rendered Page which is far more common to most web developers and online businesses:

 

This model demonstrates the direct nature of the requests from the Client PC, straight to the Origin Web Server (which gets its data from the Data Server).  In this model, there is generally a one-to-one relationship between the "hit" and the "data request", so the load on the database server is relatively high.  There are tricks you can use to ameliorate this, including Origin Server Caching, SQL Dependency Caching, and other methods, but most implementations use this form of dynamic page delivery.  In this case, data structures that cause delays can severely impact the performance of the application.

 Take a page now, which due to its flatter data model, only costs a 3 second load time.  Because the Edge Cache has been removed from the architecture, your average page load time is going to remain 3 seconds (the page construction happens over and over again for each hit).  While you gain some flexibility by having constantly changing data available on the page, you pay in the overall load on your servers (up to six times more costly in time than an edge cached solution), and you also are forced into a far less flexible data model to compensate for the speed requirements of live rendered pages.

Precomputation

The concept of pre-computation is based on a similar concept as caching.  This means that pretty much anything your database is going to need to "think" about, can in many cases be "pre-thunk."  The art of pre-thinking things before they are needed involves storing what's been thought out and saving it somewhere.  You also have to factor in the speed of retrieving things... some methods of storage are faster than others.

The diagram below (Self Healing Data Retrieval) shows the "layers" that a data request goes through before a page can be rendered.  It's pretty clear that the fastest way to get data to the customer is when the customer asks for a webpage that has been "pre-thunk" already and is waiting in cache at the Edge Cache (Akamai for example).  Here's where the magic happens.  If the page is not available in cache, the Edge cache forwards the request to the Webserver.  The Webserver then can not only generate the page, but it "heals" the Edge Cache by delivering the new page so any subsequent hits to the same page are now "healed" and available on the Edge Cache again.

 

This type of failover I described above cascades all the way up to the top.  In the examples above, if the Edge Cache fails, the Webserver picks up the slack.  If the Webserver fails, then the Method Farm system checks to see if it has an XML representation of the data in memory (extremely fast).  If the Method Farm doesn't have it in memory, then the Edge Net Storage picks up the slack.  If the Edge Net Storage doesn't have the data, then the Method Farm checks to see if it has it saved in a file on the hard drive (pretty fast).  If the Method Farm doesn't have it written to disk, then the SQL Server attempts to pull a static, pre-generated copy from a static table.  If the static table doesn't have the data, then the SQL server regenerates the data.  In general the failover escalation follows this model:

  1. Edge Cache Static Copy
  2. Webserver XML
  3. Method Farm Memory XML
  4. Edge Net Storage XML
  5. Method Farm XML from file
  6. SQL Server Static Record
  7. SQL Server Dynamic Generation from data

In any of these cases, each step is design to "repair" the previous caller that failed.  This ensures that over time, the vast majority of requests are being serviced by the Edge Cache Server and approaches near 100% availability. 

Static Publishing

The last method of high volume, high speed retrieval of web pages that can help reduce load on database systems is the Static Publishing technique.  This means that without waiting for for a user to request a page, the system is designed to "spit out" every single possible page and page combination that could possibly be hit and this entire pile of page data is dumped onto an edge cache somewhere.  There is certainly some value to this, particularly for legacy media archives and other non-dynamic, and non-live page data, but it's use is extremely limited in the e-Commerce arena. 

This highlights to some degree the ways in which network and publishing architecture can drive decisions of data structures in general.  If you choose a more normalized method of data structure, then you need to compensate on the performance side with effective edge caching.  If you choose a more dynamic method of page delivery, then you need to look more toward a flatter, more static form of data model that can deliver the performance that you need.  Many database administrators will tell you that the atomic data model listed above (Sample Product to Property Association) may be too normalized for high volume use, but if the data being accessed is used to serve up pages for an edge cache architecture, the negative is eliminated.

It is important to factor in all of the requirements of your web project before making final data architecture decisions, but it is important to note that deficiencies in one decision (choosing a more normalized data structure) can easily be offset in other ways (choosing edge caching over dynamic page construction).  This may give you more freedom as you make your data structure and architecture choices.

Now that you have evaluated your choices of data models and a highly normalized method is a good architectural choice for your situation, it's prudent to examine the benefits of what the data model will enable you to do.  We will examine some of these benefits in Part 3 - Best Business Practices for Product Catalog Data Structures - Customer Paths.

  

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

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

October 29, 2008 09:31 by NielsenData

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


Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5