Agree with you on pages upon pages!


To tackle the concept of being found for individual SKUS. Relationship tables (raw HTML) were added to the product page that containe SKUs, OEM SKUs, Competitor SKUs, sizes, measurements, etc. additionally, if space allowed, meta information was populated with skus.

Have you tried to use kitting? That might give you the ability to "group" three separate products onto a single page but still have a product page for each SKU.

If that doesn't work you will need to resort to custom development. It should be very doable, though.

Ok, I took a good look through the system at how the SKU is used.



There is a "FindBySku" method that exists throughout the system, but upon analysis of the stored procedure it automatically excludes any product variations. There is one exception to this - when the second parameter is set to "true" it selects all the product varations, but this function is only tied to the web services, and it is apparently not in use by BVC.



The rest of the logic doesn't seem to rely on the SKU being unique and updates to the product records are based on the bvin.



So, I removed the unique constraint and commented out the two unique SKU validators in the product variation editor. The only thing is now it is a manual process to ensure I don't use the same exact SKU as the parent - I have to ensure there is a space after the SKU on all of the variations. This fixes the display issues as well as ensuring the SKU is the same regardless of which launch page the customer orders from.



I thought about trying to merge the variation records together as shared under the different products, but this cannot be done because each variation can have one and only one parent id - that is a much closer representation of what I would like to do and would make the inventory tracking easier.



However, I was able to find a hack for the inventory tracking that was acceptable. Although, technically we won't be keeping inventory, we just wanted a status indicator on the web site that we could change to In Stock, Out of Stock, or Low Quantity, but unfortunately there is no way to do this without also tracking the inventory because the product variations don't have individual type properties. A custom status indicator can be used on products without variations with no issues though, so I also put in an "Override Inventory Tracking" type property and a "Overridden Inventory Status" field.



As for the products with variations, I can just set up a low inventory email and manually update the inventories when they get low on a one off basis. I set up only the matching SKU (between product variation and the parent) to track inventory, so although there are 9 variations, there are only 3 inventory records in the database. Sure, depending on how the customer buys the product they will not decrement correctly, but in a perfect world I wouldn't want those values to decrement automatically anyway (after all, it is just a status).



Once the SKU problem was fixed, the inventory information could easily be found by looking up the bvin of the parent record for that SKU and then searching for the SKU in the children for that parent record. That's a mouth full, but it is how it works :).



Take a look - on all 3 of these products, the inventory is only tracked once and they lookup the status where it is needed. The result is the status is the same regardless of which actual page you view the product variation under. http://www.foldingchairdepot.com:8080/c/Test-Main-Category.aspx



Oh, the things we must do for SEO...

Matt,

I am curious if i should take your helmet approach with some of my products that have 4+ options to chose from. The only concern i would have with SEO is the same product description showing up for 10+ products.

Here would be one product i could divide up: http://www.medsupplier.c...dick-atria-6100-ekg.aspx

Just out of curiousity, why was the color added to the SKU? Was it because the model number was not different for each color, or to make the product more easy for humans to identify by SKU?

Google officially stated that they do not penalize a site for having duplicate content (sorry, I don't have the URL handy where I read this). The only places where you can run into trouble is if the pages are exactly the same, the page titles are exactly the same, or the meta descriptions are exactly the same. Adding a paragraph to each product description to highlight everything about the product that makes it different (on the SKU level) and making the title and meta description different for every product will solve these issues - for best results, put the individual SKU in the product title and meta description.


That said, the more unique content you can add to each page the better.

Parent SKU was simply a reference for the product, for quick visual recognition by customer or staff, etc.

The warehouse skus were added at time of customer choice, that's what appears on the ticket.