Jump to content

Product Options and Search


JackP
 Share

Recommended Posts

I've noticed that customers (and myself) find that the search function does not work very well within the product options.  I have about 2500 products (if you include product options) and use the product options extensively in an attempt to try to simply the interface and administrative work.  What I am finding in addition to the search function not working as well is that customers get confused by it.  Also, the price displayed is only the first option which poses questions as different options can have different prices.  Has any else experienced this? Does anyone use the product  options extensively?  I've thought about just giving each option their own product page, which also makes SEO and product images a bit easier.  Opinions or comments?

Link to comment
Share on other sites

"the search function does not work very well within the product options"

Actually, does not work at all. CubeCart does not search option names/values due to the way options are composed, then assigned to the product.

Unless some text about the options available is included in the product's Description content, it is not searchable. (That is, in a stock CubeCart. Code could be developed to provide this functionality.)

That said, a database exists, if not simply to store data, to provide the means to look for interesting things in it. Thus, the SQL language is robust enough to allow the creation of some incredibly complex SELECT statements.

The disconnect is that CubeCart does not provide to the customer the elaborate control interface necessary to pick and choose from a large number of search parameters. A case in point (if options were actually searched), "Show me all products that are green."

"customers get confused by it"

There is a science to constructing search queries, but, I think, apparently no standard. I suppose there is the de facto method - Google's.

Then, there is what are the expected results - again, Google has spoiled us, also with its auto-correct for bad grammar and spelling.

As for the search algorithm itself, CubeCart uses SQL's "Relevance" mode (near inscrutable to understand) to start, then "contains" mode if necessary.

"the price displayed is only the first option"

You may be seeing the product's base price (recalculated for a signed-in customer, if appropriate). I think CubeCart does not show the adjusted price of a default selected option (unless there is a mod doing that).

My opinions: CubeCart is a solution for a somewhat narrow scope of applicability. Other solutions are more complex and more difficult to use. Then there is the custom solution (Amazon, etc).

Link to comment
Share on other sites

Thanks.  I think just separating the products out is the best solution for the customer. It allows for easier search and better images (images matched with the option) under CubeCart.  I could customize it myself but I don't think the return I would get for the work involved is worth it. 

Link to comment
Share on other sites

21 hours ago, JackP said:

Does anyone use the product  options extensively?  I've thought about just giving each option their own product page, which also makes SEO and product images a bit easier.

There are plenty of stores that use product options extensively and if setup correctly, then they should always be used where relevant.  A product option should be a size variation, colour variation or something that doesn't materially change the nature of the product.  Splitting product options out to separate products is almost always very bad for SEO and also bad for your customer experience. We have a plugin that allows for the allocation of a different image for each product option which is great for certain stores such as clothing where you can show a different colour image when that colour option is chosen.  Splitting options out to separate products is bad for SEO in many ways not least trying to come up with unique descriptions and meta data for a different size / colour.

Ian

Link to comment
Share on other sites

Thanks Ian.  However, I don't see how the customer experience could be any worse by separating them out.  Customers are telling me they are having problems finding stuff.  I end up sending them a link when they tell me this.  My products have different skus and UPCs.  If the customer searches for either the SKU or UPC of the option, it is not found, which is a flaw in the search of the site.  That also means search engines are not finding these options except through the feeds.  Using the options in Cube Cart also means that even if the product is crawled, unless you put the sku and/or UPC in the option itself (where it ends up getting displayed), it will be referenced except from the database at the "add to cart" functionality.  So there is nothing for the search engines to reference in terms of SKU, UPC, color, meta data, etc, for each option.  I don't think your SEO comment makes any sense in light of how Cube Cart handles options. I am happy to listen to counter arguments though, I just don't see any at the moment.

Link to comment
Share on other sites

"the SKU or UPC of the option, it is not found, which is a flaw in the search of the site"

I am in no position to defend CubeCart, but if it wasn't programmed to do something, then I reject the premise the lack of that something is a flaw.

Let's start a project that will offer the customer the ability to enter a SKU or UPC (really? the customer would know that?), and have CubeCart return that product.

To begin with, I think there would be a restriction in that the search will be on either the SKU/UPC, or the regular search (across the product id, name, and description).

I don't want to make arguments, counter or otherwise. I want to solve things!

So what say you? We hope you are willing to give constructive guidance based on your knowledge of your customer's experiences.

Link to comment
Share on other sites

Thanks for your input bsmither.  Back and forth dialog, which is what a forum is for, is necessary to define what exactly needs to be solved.  Havensmith-hosting brought up point regarding SEO that I wasn't in considering at the time but I have since realized was actually very relevant to the product options question.  What I wanted was justification from havensmith-hosting for saying the customer experience was worse and that it hurts SEO.  In the current context of how Cube Cart operates, neither one of those comments is true.  I wanted the reasons for those comments otherwise they are just promoting their product, which only addresses one of my concerns with how product options currently works. 

Regarding your rejection of the premise that it is a flaw, if a search function doesn't search all products, then it is a "missing feature".  I would call it a flaw as search would imply that it would search all products, not just the top level.  If an option has a separate UPC and SKU, it is really a separate product even if it is a child of the main product.  If Google only indexed home pages of websites, would you call that a flaw of the search engine or would searching the sub pages just be a missing feature?

Link to comment
Share on other sites

"If Google only indexed home pages of websites, would you call that a flaw of the search engine or would searching the sub pages just be a missing feature?"

Depended on what they decided to do. If all they planned was the home page, then the flaw lay in their short-sightedness. But their indexing did exactly what it was programmed to do. Contrary-wise, if the search always meant to scrape for links and index all those pages, but failed to do so for whatever reason, then that is a flaw (aka 'bug').

I have made my initial edits to the "Advanced Search" page that has added another dedicated <form> to submit only known UPC or SKU numbers. So this is now a custom skin.

I am now working through the process of the search code identifying where (using hooks if possible) to add the special database queries to find UPC and SKU values.

Later, we can then expand to include JAN, ISBN, and whatever other individual product identifiers.

 

Link to comment
Share on other sites

LOL.  You think like a developer, which is generally a good thing.  I'm curious b-smither, do you run an e-commerce store or just develop? 

Yes, the flaw is the short-sightedness.  That was the flaw with the search feature on Cube Cart too. 

I see what you are doing with changing the search.  I hope you are not doing this for me as I can make the changes and will do it differently assuming I continue to use Cube Cart.  I have an ongoing list of things I want to change and will make a decision whether to make all the changes and donate to the community or just move to another solution. Time becomes an issue for me and e-commerce is how I make my living.  

The whole idea of "advanced search" is poor from a user stand point.  The average users experience is being able to type something and click search and finding something.  It is not choosing different types of search or options.  In e-commerce, you only have a few seconds to capture their attention.  One search is it.  With mobile, which is about 70% of traffic, you will never get an advanced search.  They will either type or scan the information and click search.  Consumers do not bother to spend time filling out other forms.

Link to comment
Share on other sites

"The average users experience is being able to type something and click search and finding something."

Something relevant, I hope. I would not want to list items that have barely any or no relationship to the term(s) entered. I would agree, however, that it is the merchant's prerogative to do this very thing. A search term of "green" should return a list of inventory items that are colored green, or is recyclable, or has a low carbon footprint - if that's what the merchant wants.

 

Link to comment
Share on other sites

Concerning the terms UPC and SKU, I find this:

Quote

While some may haphazardly interchange the terms UPC and SKU, they are actually two quite different entities. They are ... codes assigned to products, but UPCs, or Universal Product Codes are standardized for business use and provide a product description that, once scanned, anyone could read. In contrast, a SKU, or Stock Keeping Unit, is a code assigned to a product by the company for stock-keeping purposes and internal operations.

 

So, what is the pertinent reason for providing a means for the customer to search on SKU, if the code is intended for internal use?

I ask you, do you expect your customers to know your SKU codes? Or, in your earlier post where you first mentioned UPC and SKU, is it the case you were perhaps conflating the two concepts?

The CubeCart databse does not have a column for SKU (although it is a good idea for internal operations to know where in the warehouse the items are located).

Link to comment
Share on other sites

Thanks.  I'm well aware of the difference.  SKU maybe internal use but customers are aware of the SKU of many of our products because certain manufacturers publish them and many of our products have the sku prominently displayed.  Some of the products are not easily identifiable by sight.    I sell some 600 skus of guitar picks.  You know the SKU but trying to narrow it down when they all look similar (same sizes and colors, just slightly different shapes or different quantities) gets really tedious when if you can type the sku it is done.  As far as the database not having sku, product code is interchangeable with SKU.  Many systems use product code. Some systems call it SKU. Ebay calls it Custom Label for some reason.  Amazon calls it seller sku.  UPCs are very relevant for google feeds and most PPC campaigns.  Also, people will scan UPC codes for comparison shop. The way CC is setup now, this is totally missed in search,.

bsmither, you are smart guy and I will assume you are a way better coder than I am since I haven't coded for a living since 2002 and only do it now for my business needs.  But, you assuming I do not know what I am talking about when it comes to my products and customers is a bit of stretch.  I said earlier, this is my only job.  I make my living selling these products.  I'm not some old retired dude - the picture in my profile is not me, that's a guy who was named Don Vito.  In any case, you may want to change the tone and not assume people are morons. That will be a real turn off for people just trying to learn cube cart. There are enough people using Shopify, which, in some ways, is an inferior product.

 

 

Link to comment
Share on other sites

As I noted, it is already there.  SKU and product code are used interchangeably depending on whose system you are using.  Volusion uses product code too.  I can't remember what x-cart or Zen Cart or OsCommerce uses.  I've used all those as well as CandyPress and a bunch of others over the last 10 years. 

Link to comment
Share on other sites

I think we have a specific goal to code for: to have the general catalogue_search mechanism also search the Cubecart_options_matrix table for 'product_code'.

This is on our way to a more general solution of getting included in the search process for the properties of inventory items located in the Options area.

I'm currently working on solving a specialized search process where the UPC is queried directly from CubeCart_options_matrix and CubeCart_inventory, to find the base product.

 

Link to comment
Share on other sites

I've got something that will search in the Options Matrix table for the exact code of UPC or SKU (product_code), easily able to also include searching for the exact code of the other product code numbers (JAN, ISBN, EAN), as well as similar columns in the Inventory table.

Link to comment
Share on other sites

I'd just like to chime in to second that depending on the industry, customers may only search by product code. In my industry, for example, it is more common to search for  'E214B10' than 'class 2 rubber glove.'

I have used options extensively on my store - rather than having 100+ product listings for class 2 rubber gloves, there is only one with options. As a result, my store suffers the same search issue. For many products I have simply added a table containing each product code with some data to the HTML description; this has the benefit of allowing customers to easily compare as well as having the product show up in search results, but it is impractical for a case such as the gloves.

For those cases, having the search include the options matrix table (specifically the product code field) would be a suitable solution.

The only caveat I can think of is that CubeCart does not support displaying a link to a product that includes preselected options, so if you searched 'E214B10' it would only show you the base product, not the exact version of that product you are looking for. Perhaps including the matrix ID in the search results would allow for a more exact link?

Link to comment
Share on other sites

Thank you for chiming in.

I have given some thought that auto-selecting the options that correspond to the exact SKU would be a logical next step.

But one thing that needs to happen, so that the options "in play" aren't lost is that, since the SKU identifies exactly one single inventory item, CubeCart should bounce the customer to that product's page - avoiding the trip through the listing of the found search results.

Link to comment
Share on other sites

I agree that extending the search mechanism to option matrix product codes, if used, would be an excellent idea for core code and also if there is a unique match then taking the customer to that product directly is also good and would improve the customer experience especially if the relevant options matching that product code could be pre-selected !

However, I don't believe that many stores would have customers searching by the bar code and the addition of that functionality would be much more suited to a plugin where it could be configurable which code is used (UPC is mostly North America, JAN only in Japan, ISBN for book stores worldwide and EAN code is used exclusively in Europe).

Any solution would need to ensure that suitable indexes were added to database columns.

 

Link to comment
Share on other sites

There is still an SEO issue using product options.  Unless you put the SKU and UPC as part of the option attributes, they are never seen by crawlers for the product so all the search engines know is what is available on the main product page.  It would be a good idea to have something like "data-upc="1234567890" and "data-sku"="413P1.14" within the generated option tag. Cube Cart already does this for price.  I'm assuming this is valid for SEO to do this but I'm not an expert in that area. 

Current: 

 <option value="4"class="absolute" data-price="5.45">.50mm (Red) $5.45</option>

Proposed:

 <option value="4"class="absolute" data-price="5.45"  data-upc="1234567890" data-sku="424P.50">.50mm (Red) $5.45</option>

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...