Making Your Customers Thirsty

Search Personalization for Retail Web Sites

Back in March of this year I did a webinar on this topic.  You can view the webinar via this link:

http://www.davalen.com/info.php?about=Search_Personalization

 Here’s a brief over view of what is discussed.  I’d be interested in your feedback. 

Extend the Reach of Your Website Beyond One or Two Target Audiences
 

Optimize Websites for Respond Multiple Audience Response

Make Product Lists More Interesting for Your Customers

One of the biggest challenges a retail website has is how to provide a meaningful online  experience to multiple audiences. 

To meet the challenge you need the ability to:

• Organize your catalog to make the most sense to your users
• Sequence products within your catalog for an appealing display for each customer.
• Dynamically change catalog organization product listing sequences based on customer type.

IBM OmniFind Discovery Edition provides a way to meet these needs. 

OmniFind can drive dynamic navigation on your website and target specific audiences using a persona-driven approach influencing product display order for different users.

 

 

Ten Mistakes to Avoid When Implementing Site Search for Internet Retail Sites

Setting up and using Site Search is a black box mystery for many people.    That makes it very difficult to know if you are falling into a huge pit or missing a golden opportunity.  To help judge where you might be I’ve put together a list of mistakes and missed opportunities.

10. Assuming that you will get the custom results that you want with an out-of-the-box solution.9. Not supporting search individualization/personalization.8. Not supporting marketing-based search tuning.7. Restricting the role of your search platform to return only search results.

6. Expecting the same results with your new search platform as you got with your old platform

5. Not tuning search based on site search analytics so the best products appear at the top of a result set. 

4. Not checking the contents of a result set against your product catalog.

3. Bad, messy or incomplete data.

2. Not identifying and designing the data you need to drive the search results you want

1. Not identifying and defining search scenarios at the start of your project.

 Remember!

    The bottom line is this…

                      “If they can’t find it, they won’t buy it!”

Beyond Search: Expanding WebSphere Commerce-Driven Websites with OmniFind

Recognizing the potential of OmniFind in a WebSphere Commerce site requires a different mindset.   Here are some thoughts to get you started:

Think of OmniFind as an integration tool between the front end User Interface and the WebSphere Commerce database.  

Any time you want to display a set of products – think OmniFind

Any time you want to let users dynamically navigate a product set – think OmniFind

Any time you want to generate navigation dynamically based on information within a set of products – think OmniFind

Any time you want to create associations between products based on common attributes – think OmniFind

Any time you want to display a subset of products based on user actions, user credentials, user choices or other conditions – think OmniFind

Any time you want to bring together information from different sources beyond the WC catalog database – think OmniFind

If you want to associate data from different sources around a specific product, topic, or category – think OmniFind

ODE Chronicles: Quick Tip – Too May SnapShots?

Ever run out of space on your servers because of too many snapshots? 

Try this feature to limit how many will be kept after builds.

ADMIN_MAX_DEPLOYMENT_DIRS

Link to IBM InfoCenter entry

At the Intersection of Technology, Metadata, and Goals

Discovery Architecture lives at the intersection of technology, metadata, user goals and business goals.   

 

In order to be successful, you have to take all four aspects into account when you build a search /discovery framework.

 

User goals and business goals blend together into sets of goals and form a business strategy. 

These sets of goals inform you about the direction you need to head.   What they don’t do is tell you necessarily is how to get there.    But have no fear!  One of the great things about search technology is that it increases the number options available to you. 

 

The obvious side of this part of the equation is that you have to understand how user and business goals fit (or don’t fit) together.  A situation that I’ve run into where this can sometimes turn into a “gotcha” takes place when business analysts map out solutions (some very elegant) – without taking into account what current technology can support.  In these cases, they are building a Discovery Architecture without considering other parts of the equation.

 

Look to your technology to shape your solution.  

Technology will both enable and constrain what you will be able to implement – even if you have an unlimited budget for customizations.  At the same time, your technology is also likely to open up opportunities that you may have not considered before. 

 

So, I suggest to my clients, especially ones who have built solutions without an eye towards the technology they are using, to keep an open mind to consider how a given technology might accomplish the same goal but take different steps within its own framework.  This will help keep down costs from requesting unnecessary customizations.  To help keep your options open, ask these questions:

 

-          What features does the technology offer that we haven’t requested that may be relevant to our goals?

-          Are there places where you can eliminate unnecessary customization by leveraging the technology’s supported feature set?

 

Metadata is the foundation for the framework you build.

Let’s be blunt.  To borrow an old saying, “You can make a silk purse out of a sow’s ear.”

 

 

No matter how sound the business strategy…

 

No matter how good your technology…

 

If you don’t have good metadata…

 

Your plan will fail!

Discovery Architecture – In A Nutshell

While on the plane tonight, I came up with a brief, elevator-speech description of Discovery Architecture.

Discovery Architecture
Using technology to interact with and manipulate metadata to enable users to meet their search/discovery goals in ways that also meet your business goals.

ODE Chronicles: In progress

I’ve been having a blast writing a couple of search apps lately.

If you’ve read my other entries you already know that I favor separating the User Interface, Search, and Data layers more distinctly than the ODE bean that puts ODE objects into a JSP’s request object.  Now I have a more pragmatic reason.  Have you ever tried to debug a JSP page????    It will drive you nuts!  And believe me, building a search app is complex enough that you don’t want to deal with not being able to debug your work.

“Okay,” you might think to yourself, “that’s fine but in the WebSphere Commerce model should I build a Commerce command or just create a JAVA package?”  Great question.   I’m going to be exploring that more myself.  If I learn anything of special note, I’ll let you know.  

What I do know is that if you go down the Commerce command route, you had better be very sure that you won’t want access to the ODE search capabilities outside of Commerce.   I mean, think about it.  Are there going to be times when you may want a search interface into your site’s resources other than your retail view?   BTW , be careful to follow your licensing constraints.   You can’t buy the ODE/ Commerce integeration module and then turn around and use it for just anything.

A Search & Discovery Skunk Works?

These are exciting times for people who love this whole Search & Discovery Space.  People are (finally) moving from using search/discovery technology to only facilitate end user searching and expanding into exciting territory. 

 

The interesting aspect of this trend is the ability to dynamically hook together different resources – but this time based on search technologies.  (Sidebar: I really ought to say search and discovery technologies.  For the moment, I’ll use the two interchangeably.)   

 

Let me give you an example so you can see what I mean…

 

A practice that I’m seeing more of uses search to drive non-search functions on eRetail websites.   On those websites search is transparently driving navigation.   This has HUGE implications for retail website designers – especially those who seek to personalize their website experience for individual customers.   

 

Now you wouldn’t necessarily want to muck up your site’s main navigation.  After all site-wide navigation needs to be consistent to keep from driving users crazy. 

 

Just imagine what you could do with a special area on a page that provides guided navigation based on user actions (i.e., clicks) on your website!  

 

If you want to see an example of this, read my blog on AutoZone and then visit their site.  On their site, once you select a vehicle, it “remembers” it and when you click on different products categories afterwards it only returns products that actually designed for your vehicle.   It’s a shade-tree mechanic’s nirvana!  If only Lowe’s or Home Depot would do something similar.

 

My point is this:  There is so much more that search can do.  The problem is that most people don’t realize its potential for both the end-user and for driving revenue and ROI. 

 

What we need is a group that explores and pushes the boundaries of how search and discovery technologies are applied to solve various business problems – a Search & Discovery Skunk Works.

ODE Chronicles: Quick Tip – Viewing Management Console Changes

You can see changes via the Management Console but there is also another way — if you don’t mind reading XML.  Go to

managementConsoleChanges.xml

Located in your project’s directory at deployment/[projectName]/[projectName]

ODE Chronicles: Quick Tip – Keeping a Feature from Being Searchable

Say you are indexing a database or XML file and you want a specific column or XML node element displayed on the search results page but you don’t want to that column to be searchable.

 

The first step is to make sure the column or XML element is included in your features.txt file.  This tells ODE to include that particular data element when it ingests the database row or XML item.  ODE calls that data element a feature. 

 

The next step is to tell ODE that you do not want that feature included in the index.  

 

Go to your features.txt file and locate the feature name.   

 

Add the following line to the feature definition block:

 

  build_ir: no

 

Because ODE is updated periodically be sure to check the ODE InfoCenter at IBM InfoCenter Link for the latest info.