Personalization Implementation - Page 3
November 22, 2000
We're not going to get into actual code just yet, so let's talk about
designs and schemes first. Note that we'll first talk about the
implementation of the individual schemes, followed by the integration
of all three.
Rules Based
The simplest approach to implement this scheme is to do so during
explicit events in your application. For instance, as soon
as a user logs on, or once they add something to their shopping
cart would be two good examples. You could very easily add some ASP
code to each page where an event would occur that could fulfill your
rule based command - add an if statement to your shopping cart
page to check if this user is adding a printer, and then display
an ad for printer paper, for example.
However, this method is rather difficult to maintain, and if your
rules changes often, a nightmare to keep up-to-date. And you know
we're not going to suggest something so inelegant.
A better method would be to separate your event code and situations
from your actual ASP pages. You can place generic code to handle
events in a separate file, or a COM object, and place the conditions
and outcomes in a database. This makes things much easier to keep
track of as well as maintain. We'll take a look at this in more detail
when we get to some code.
Collaborative Filtering
This method is simple enough to implement in individual ASP pages.
In the appropriate places, you could simply add code to tell the
user what they need to know. For instance, if your site is dynamic,
and all products are stored in a database, you can add code on the
page that dynamically displays your products that would tell the
user what other people bought. This, of course, requires that
you have some previous knowledge of what people bought - if this user
is the first person who's bought anything, they won't see any data.
This method is easiest to implement alone, but what happens when
we take this to the next level? Suppose we don't just sit there and
let the user come to these pages, but rather, we group them into
categories depending on what they've done previously, for example,
Computer Book Buyers, or Window Shoppers. (Note that this requires some
backend processing prior to a user's visit.) In essence, we've
broken down the collaborative filtering to a more granular level,
to tailor the personalization even further. Now, wherever a user is,
you can drop them hints saying, "Other computer book buyers bought..."
or simply, "We think you'd like..." These suggestions could be
based on the "special purpose groups" they fall into.
The code that calls this "grouping" functionality can be placed
anywhere on your site, and can be made generic enough (by using
databases) that it won't ever have to be manually updated. You
would have to implement a backend monitoring application, however,
that periodically checks a user's history and lumps them in the
proper groups.
Inference
This may be the most difficult scheme to implement. To analyze
real time clickstream data, it is necessary to build functionality
that can watch and keep track of everything a user does on a page
(which typically is only clicking links, unless you use
DHTML, but
that's another story). There are two major ways to do this:
You could change all links on all pages to refer to an ASP that
processes the click before redirecting the user to the address they
clicked on. This is rather tedious, so you could instead build an Internet
Server Application Program Interface (ISAPI) filter that traps
clicks coming from the client and process them accordingly. This,
unfortunately, is a rather complicated procedure, however, so
it may not be appropriate for all situations. i
The other method is to analyze, in real time, the log files
of the server. After all, why try to catch and analyze all the clicks,
when they're already captured and stored for you? This method
requires more than a simple ASP to process though, and a COM
object would be very useful here. The object could watch open
sessions on the web server, and analyze the appropriate data placed in the
logs files. The drawback here is that it may be difficult to analyze
the log files while visits are occurring, because of locks placed
on the file.
No matter which way you monitor the clickstream, you have to
communicate the results back to your web application, and react
properly. Remember that your application may also refer to information
stored in your user databases to deliver information to the user.
Your ASPs would then have to process this information and display
it appropriately.
Integration
We won't spend too much time here, but let's take a look at the
top view of what needs to be done to integrate all of this.
|
