Announcement

Collapse
No announcement yet.

Miva Search; Small improvements I made, and features I wish we had!

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Miva Search; Small improvements I made, and features I wish we had!

    Hello!

    I have been spending a lot of time on improving navigation and helping customers find the products they want faster and easier. One thing that made a noticeable impact on sales was giving some attention to the built in miva search. Outlined below are a few things I did to improve our search accuracy so you might be able to use and increase your own sites accuracy. The other section is a few features I would love to see added as they solve other problems we had.

    First thing i did was tackle the problem of the search results displaying a lot of false results. For us the problem was that the search was setup to look inside to many vague fields. You can adjust these search fields inside "User Interface / Search Settings". The base "Searchable Fields" are product code, name, sku, description, attribute code, prompt, option code, prompt. The problem we were facing was that the "Product description" was being included in the search fields and it was giving to many false results. One example was in a description for product A it would say "This product will not work with product B". So when you search product b, product a would show up and confuse customers. After I removed the description from the search fields we stopped getting a lot of false positives but we in turn found a new problem and that was lack of results. (For anyone curious we are currently only using product code, product name, and product sku)

    To tackle the new problem i turned to the custom field section inside search settings. Most of the custom fields we use are for the miva facet system and thus are great for adding to the search fields as a kinda "Key word" system. By adding in custom fields like Category, Type, Subtype, Brand, Material, Color, Shape, and Model we saw a lot less searches return no results. This was great but there was still room for improvement.

    At this point things were better but we were still getting customers calling in saying they could not find products. When someone called in or wrote about having problems finding a product we would go into the name or a custom field to try and make it searchable. This ultimately just ended up feeling like a game of wack-a-mole where one fix might break another. The solution we ultimately landed on was to create a new custom field called "Search Tags". If someone has a problem finding a product instead of changing accurate data to better suit an outlier, we just add the outlier to the search tags field. One example of this is our product "O-Ring". The correct product name is O-Ring but some customers type "oring", while others "o ring" and would not see product despite it being the same. So we in turn add both variations to the search tags field, allowing it to be found. YAY!

    After adding the search tags I kinda got fixated on knowing the different ways people might try to search for the same product. I looked into the SRCH page and found the section of code that is for telling the customer no product was found and added some code to have it email me the query along with their ip address. This little trick was both amazing and terrifying as i got so much information but also learned just how many failed searches we get (Was over 1k a day). The thing that immediately stood out was that if someone searched for the plural of a product it would almost always return no result. To return to a previous example "O-Ring", if someone searched "O-Rings" it would return no results. This was a bit sad to learn because it was a really common thing for us to reference products in the singular and the customer to look for a variety of the same product in plural. The upside to this is if we did the plural and the customer searches the singular (and its simply "Product"+s) then it should still find the product. So we changed as many fields as possible to be the plural, and if we couldn't we added the plural to the search tags (great for non S plurals like Cactus -> Cacti).

    So these few things really helped improve our search accuracy, but there is still room for improvements but im not sure i can get there alone. One thing i keep seeing come across my failed search emails is misspellings. Google has a great way of dealing with this problem in that they offer a suggestion and run the suggested search instead. Luckily there is an article about how this task can be accomplished HERE. After building out the spelling corrector in C# I uploaded the same fields used in the search settings and got amazing predictive results. This kinda system could be added on its own but I almost feel like it should be built into the search system. Maybe setup to a scheduled task to build the "Big Text" file out of the fields selected inside the search settings.

    Another feature that might be great to have is having the search setting "Use Database Full-Text Searching" be a bit more flexible instead of an all or nothing system. The reason why i would like this feature is for the products that have a UPC code on them. We have a majority of our SKU's setup to number only and if we want the search to be able to search based on UPC it will need to be full-text otherwise it will return false results if someone searches by SKU. Example being "SKU:15-100123" if someone searches 100123 it might pull up UPC "743838100123".

    Lastly there is a downside to the "Search Tags" in that it seems to look inside the field and compare the search based on continuous text. An example of this might be a product called "Stacey Pace". Inside the Search Tags (Which are a custom field set to multi-text) we try to catch the common misspelling of "Stacy", and even have her nickname "The Raven" on the second line. So now if someone searches "Stacy Pace" despite it being spelled wrong, it still shows product. Also if they type "The Raven" it will show her product. However if the "Search Tags" values are not in the exact order of the query it will not return results despite having all the values. So if someone types "Stacy Pace Raven" no results will be shown because they did not include "The" and thus the match was broken and it exited the comparison. Really what i think might solve this would be the search looking into each text line in the multi-text field as its own separate comparison. haha this one is a bit hard to explain so i hope someone gets it.

    TLDR version below :D

    Quick points on improving your search
    • Limit search settings search fields to smaller values
    • Add custom fields like brand, category, type, subtype, material, and color (aka facets)
    • Try to make fields plural (aka 'productS' not 'product')
    • Consider adding "Search Tags" custom field to give a hidden method of searching alternative paths
    • Consider adding a system to see what people are failing to search
    Code inside SRCH page for sending email on fail search (Requires Toolbelt module)

    One important thing to add is the g.search EQ '*' as it keeps the bing / google bots from spamming you.
    Also might want to have it not send email if your ip does a search as its not exactly valuable because its not customers.
    Lastly its nice to add user ip to track the search process and help track the individual

    Code:
    <mvt:if expr="NOT ISNULL g.Search">
            <mvt:if expr="l.settings:search_product_count EQ 0">
                <div class="row">
                    <form method="get" action="&mvte:urls:SRCH:rr_noparams;" class="np nm">    
                        <mvt:item name="urls" param="hidden_params:SRCH:rr" />
                        <div class="column whole">
                            <h5>No results match those keywords. </h5>
    
                            <p>
                                <label for="l-Search" class="bold">Search For:</label>
                                <input type="search" name="Search" value="&mvte:global:Search;" id="l-Search" />
                            </p>
                            <p>
                                <input type="submit" class="button button-medium bg-blue white" value="Search" />
                                <a class="button button-medium bg-charcoal white" href="&mvte:urls:SRCH:secure;">Clear</a>
                            </p>
    
                        </div>
                    </form>
                </div>
                <div id="myFacetResults"></div>
    
                <mvt:if expr=" s.remote_addr CIN 'YOUR IP ADDRESS' OR g.search EQ '*' ">
                    <mvt:else>
    
                        <mvt:item name="ry_toolbelt" param="assign|g.mail:to|'Your@Email" />
                        <mvt:item name="ry_toolbelt" param="assign|g.mail:from|'Your@Email" />
                        <mvt:item name="ry_toolbelt" param="assign|g.mail:subject|'Failed Search'" />
                        <mvt:item name="ry_toolbelt" param="assign|g.mail:message|'Search: '$ g.search $'     IP: '$ s.remote_addr $ '     URL: ' $ s.request_uri " />
                        <mvt:item name="ry_toolbelt" param="sendemail|g.mail|text" />
                    </mvt:if>
    
    
            <mvt:else>
    Last edited by Beefy Nugget; 02-27-19, 03:09 PM.

    #2
    Thanks for sharing your detailed feedback. These are all things we're looking at supporting in future updates.
    Brennan Heyde
    VP Product
    Miva, Inc.
    [email protected]
    https://www.miva.com

    Comment


      #3
      Thanks for taking the time to include so much detail in this post. Very helpful!
      Diana Hall
      http://aGardenPlace.com

      Comment


        #4
        haha thanks :D

        I wanted to try to give something back to the community here.

        Comment

        Working...
        X