Step 1 - Making Customers Happy - Page 8
January 15, 2001
Let's provide the visitors a way to make the site work better for
them. Assuming design and layout of the site is perfectly fine,
we need to allow the visitors to find what they want easily, when
they want it. And though they may not know they want or need it,
it also means providing easy access to the checkout page. (Think
about it — nearly everyone knows where brick and mortar stores
put their registers, so it's easy for customers. That should be
the same for Web sites.)
We can combat this in two ways: statically, or dynamically. The
static method involves allowing the visitors to choose their own
favorites, and place them in a section that provides easy access
for them. Dynamically handling this would involve monitoring a
user's clicks, determining what they click on the most and what
they skip over. (Note that this could take place over multiple
user sessions.) This method should also provide some form of
management — so the visitor can fix it if we guess wrong.
There is a case for both methods. With static personalization, we
don't have to worry about guessing wrong — the user knows
what they want to see. This method also takes up less computing
power. With dynamic personalization, the user won't have to worry
about figuring out how to work the personalization mechanism, and
if it works correctly, will be much more happy with the results.
Perhaps a combination of both?
Building a static personalization scheme is simple — the only
decision you have to make (aside from the UI design aspect) is
where to store the personalization info: on the client via
cookies, or on the server in a database. ACME has decided to go
with the latter, so that visitors can log on anywhere and see the
same customizations. Implementing this is simple — build a page
that allows users to specify what they want to see, and possibly
where they want to see it. All this is done through simple ASP
procedures, so we won't cover it here.
Now for the dynamic handler. There are three ways to handle this.
Detecting clicks on the fly is unfortunately not a simple
process. You can either build a click detector using ASP pages,
using an ISAPI filter, or by purchasing a third party product.
Because this article is supposed to be ASP related, let's choose
the ASP method, which nicely enough is the easiest technically.
Build a simple ASP page that determines what the user clicked on
(this can be done with the HTTP_Referer request
header). Log this click somewhere — preferably in a
database — and redirect the user to the place they wanted
to go in the first place. If done correctly, the user will never
know what happened. The problem, however, is getting every page
to go to this intermediate page instead of to the
href of the link.
Continuing with our theme, there are again two ways to accomplish
this. You can manually change every link in your application to
go to this new page, with a querystring parameter
that specifies where it should actually go to, but that can be a
real pain. An easier way to do this would be to include this file
into every page. Granted, it still requires modification of many
pages, but it doesn't alter your pages at all, and, if you have
designed a clever architecture, you may already be using include
files on every page, in which case your include file can simply
include this new page.
This was an example of inference-based personalization.
A Situation - Page 7
Everything you Need to Know About Personalization: Part 2 - Page 6
Step 2 - Informed Customers - Page 9
|
