Jared Nielsen will be Speaking at SQL Saturday #49 in Orlando

This event is hosted by the great folks at SQL Saturday including Brian Knight of Pragmatic Works and many of the top industry leaders.  Jared Nielsen will be giving a presentation on SQL and SEO - the financial benefits of proper database design blended with effective website search engine marketing techniques (SEO).  Jared Nielsen is an Expert SEO consultant in Jacksonville and has used these skills in some of the largest websites in the world (Yahoo! Sports, ATP Tour, AOL).  Also included are personal evaluations of websites that are brought by attendees of the event including reviewing such topics as the Atomic Data Model™ and Exclusionary Dominance™ techniques.

Make sure you attend or send your marketing VP, your corporate CEO or your technical SQL Server DBA to be there and enjoy the event.  The SEO and SQL speech is at 100 Weldon Boulevard, Sanford, FL 32773 at 11:30am on Saturday, October 16th, 2010.  You can find out more information on my session at the SQL Saturday Website

Jared Nielsen will be Speaking at SQL Saturday

This event is hosted by the great folks at SQL Saturday including Brian Knight of Pragmatic Works and many of the top industry leaders.  I will be giving a presentation on SQL and SEO - Data Modeling and Web Marketing with an emphasis on how proper SQL database design can make search engine optimization even more powerful and flexible.  I will be reviewing such topics as the Atomic Data Model™ and Exclusionary Dominance™ techniques.

Make sure you attend or send your webmaster or DBA to be there and enjoy the event.  My speech is at the UNF Computer Conference Center at 10:15am on Saturday, April 17, 2010.  You can find out more information on my session at the SQL Saturday Website

To consult with Jared Nielsen you can reach him at the FUZION Agency at www.FUZION.org or you can call him at 904-638-2455

Seminar Materials for the SQL Saturday Event

01-Exclusionary-Dominance-on-Google-by-FUZION.pdf (673.09 kb)

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

03-Advanced-Search-Engine-Optimization-SEO-by-FUZION.pdf (215.98 kb)

Atomic-Data-Model-Presentation-Jared-Nielsen-FUZION.pdf (2.85 mb)

CustomerObjectives.pdf (398.88 kb)

I took a bit of a detour as I was working toward developing the Atomic Data Model in practice (rather than in theory).  I stumbled across many exciting technologies in the process.  From recursive common table expressions to CLR stored procedures (for you SQL User Group wonks) to the higher level business applications of pregenerating data and "atomicizing" the information that lies buried in these enormous databases we all struggle with, I have developed what I believe to be the first practical implementation of the Atomic Data Model in a real commerce environment.  I will be slowly launching this project on the website http://www.teamsportsfan.com/ as I move along so please feel free to join me as I move ahead.

In general terms you need to think of two key concepts... the "object" and the "relation".  At its core these two theoretical constructs form all of the data that we use in our applications, in our businesses and in our lives in general.  Not to wax too metaphysical here, but life (and data) is all about the "things" and how those things "relate" to each other.  In a practical data modeling sense, these objects come in various forms... theoretical "objects" are the classification and types upon which the "instances" of these objects are photocopied from.   As we flesh out our data model, we will first define the theoretical "genealogy" of object classes, who themselves have parents, relationships, children, and they inherit from higher order "classes".  Once this "skeleton" is formed, we can then snip a branch from this theoretical genealogy, take a copy, form the mud of actual instance information around it and then breathe life into it as an instance.  Enough theory?  Let's take a look at a realistic example:

Here is a definition of the root hierarchy for our theoretical object skeleton.  The most abstract construct that we have is the "object".  This is the theoretical construct from which everything else is derived (aside from relationships).  Items inherit from Objects, Apparel inherits from Items, Tops inherit from Apparel, Shirts inherit from Tops, and Polos inherit from Shirts.

In general when you are defining your core object hierarchy, you want to ask yourself "what does it 'act' like?".  Let's talk through that for a bit. 

What does an Item "act like?" 

• It can be owned
• It has an Item number
• It can be counted
• It is made of a material
• It can be associated with a sports team
• Apparel, Vehicles, Parts, and Devices can inherit its properties

What does Apparel "act like?" that is wholly distinct and separate from Items?

• It can be worn as clothing
• It comes in a "style"
• It can be designed with a "pattern"
• Tops, Bottoms, Dresses can inherit its properties

What does a Top "act like?" that is unique to this subclass?

• It covers the top of the body
• It has a neckline
• It can come in various size classes (S, M, L, XL, XXL)
• Jackets, Shirts and Vests can inherit its properties

What does a Shirt "act like?" that is unique from its ascendant?

• It has a collar (or lack of)
• It has sleeves (or lack of)
• Jerseys, Polos and Oxfords can inherit its properties

You can see that the cumulative "sum" of all of these properties give us a list of things we need to know about an instance if it inherits from the Object|Item|Apparel|Top|Shirt|Jersey class object.  By rolling up all of the behaviors of its inherited classes we now end up with a list of "fill in the blank" questions that we need to know about this object.

In similar fashion, where an "Apparel|Top" class may utilize the size classes of S, M, L, XL... the "Apparel|Footwear" class in contrast would use the size classes of "8, 8W, 9, 9W, 10, 10.5, 10.5 W" and so forth.

This allows our applications to very easily grab this "hierarchy" and then use it to automatically construct the data entry forms, application interfaces, and subitems for any given product without having to manually create this information on the fly.  How does this look in XML code?

I'm please to be speaking at the .Net user group in West Palm, my old stomping ground!  Many thanks to Scott Klein, noted .Net author and coder for having me down to the beach to spend some time with the great folks down there.  I will be giving a lecture on the Atomic Data Model, the X-Y-Z method of site expansion, and an in-depth analysis of one of their website projects live while we discuss it.

The event will be held at the following address at 6:30 for pizza and 7:30 for the lecture:

1750 North Florida Mango
Suites 302 & 303
West Palm Beach, Fl 33409
561-840-8080

Get Directions

For more information on the Atomic Data Model, please see my blog entries about that at:  Atomic Data Modeling - Part 1

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.

This is the fifth installment in a series that blends website architecture, data structures, and Search Engine Optimization (SEO) marketing into a collaborative design pattern continuing from Part 4 - Best Business Practices for Product Catalog Data Structures - SEO Path Aliasing.

We have discussed custom-tailoring a website's NOFOLLOW and Path Aliases to tightly tune the "stream" of natural search flow throughout your website.  By tuning what the search engines "see" you will be able to help your search engine rankings climb for the pages that you most care about.  In large scale e-Commerce platforms, it becomes an onerous task to keep up with all of these customizations.  Here is another case where your choice of an atomic data model will serve to automate some of these functions.

Let's examine the following model of SEO Weighted Auto-Mapping:

Here is a scenario where we assign "weights" to the various Property nodes that can be mapped to Products.  Once the weights are assigned, we can develop custom business rules that will help us "scale up" or "scale down" our Weighted Path's sensitivities to the search engines (through the use of NOFOLLOW tags).

We can roll back to the original case of a standard brick and mortar store that was the basis of our e-Business (for example).  In a traditional brick and mortar business, let's say that we determined that in general, segmenting our customers by Gender tended to be the most common and most popular means of diverting our customer traffic.  This could give us a clue on our e-Commerce website on what weight to assign to the Gender Property.  Since this Property holds primacy over the rest of the Properties in our categorization scheme, we could assign it with a high "weight" value.

Take our example above where we have decided that the Player Property is the highest ranking "Path" starting point in our categorization schema.  This is essentially because, in the cycling apparel business, Lance Armstrong (the keyword phrase) drives a significant portion of our prime traffic.  It also tends to be a highly competitive term that we would like a high search ranking for.  Additionally, it is a phrase that we would like to channel a lot of natural search traffic through, even to the exclusion of other lower performing phrases that have a significantly lower revenue opportunity.  For this, we assign the Player Property (regardless of the specific Player identified) a weight of 10.  This means that a customer that "lands" on the Lance Armstrong Player landing page who directly orders a product is defining the primary Customer Path that we are interested in promoting and that path gains a score of 10 / 1 (hop) which averages out to a 10 (no surprise).  Any links to this particular URL do NOT receive the NOFOLLOW parameter and the natural search engines will stream most of their energy through links like this.

We also have the option of defining our business logic for what rules we want to apply.  One example is how we set the threshold for NOFOLLOW parameter placements.  We have decided in the above example to set NOFOLLOW parameters on any Customer Paths that rank less than an average of 10.  Effectively we are deciding that we want the full "stream" of the natural search engines to flow through these highly weighted paths, which will tend to be very direct links through Products mapped to the Player Property.

We can layer in other business rules as well.  One business rule that we are using in the above model is the method of computing a multi-step Customer Path "weight".  In the example above, we simply decided to add the cumulative weights of all "hops" in each Customer Path and divide by the number of hops.  Take the Customer Path of "Tank Tops / Ladies / Cycling / Lance Armstrong".  Each "hop" as the customer steps through that path adds to our total and because there are four hops along the path, we divide the total (34) by the hops (4) and come up with an overall weight of 8.5.  This business rule may be subject to some review.  It seems that an alternative formula might be to reduce each hop's weight by the "distance" from the initial starting point.  This would then be 8 + (7-1) + (9-2) + (10-3) = 28 / 4 = 7.  However you decide to "compute" the average weight of any given Customer Path, it should make sense for your business while delivering some automation where possible for the NOFOLLOW mappings within your categorization scheme.

This demonstrates yet another possible use of blending the choice of data structure with your requirements for SEO initiatives.  We can explore more methods of integrating data models with Search Engine Optimization techniques in Part 6 - Best Business Practices for Product Catalog Data Structures - Search Optimization.

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.