efficient ways to anonymous personalization using ASP.NET + Cookie

Question

Hi all:

I am trying to achieve anonymous personalization in a ASP.net environment. I know that ASP.NET 2.0 provide Profile. However, I want to avoid traffic to the database as much as possible since the site I am working on is a relatively high traffic site.

The other obvious solution is cookie, but given the limitation of cookie, I was wondering if anyone have any efficient method to store information into cookie. Does anyone know how amazon or yahoo deals anon. personalization?

Ultimately, We are trying to serve up different dynamic content to our user base on a set of business rules outline in a pre-defined campaign. The reason is to measure conversion rate in our site. The same campaign can be use on all different pages of the site. The reason I need to set this to a cookie is that the user is able to see the same content served up previously if we want it to be. So this is what I have in cookie right now.

 campaign code:page id:result display

And you can see that this will build up if there is a lot of campaign and each campaign is used on many pages.

Thanks in advance!

Answer 1

I'd create a database record for the visitor and only store the ID in the cookie, this way you can look up all the personalised details from the database, and keep the cookie size to a minimum.

If database speed is an issue, perhaps use a differrent database and server to store the personalisations.

Alternativly you could store personal data in the file system, and load into the session when the visitor returns matching the cookie ID.

If identifying the user and cookie clearing is an issue, you cold use and ActiveX control, but this requires installation on the client computer, which people could object to.

Answer 2

If database load is an issue, you can retrieve the personalization when the user starts his session on the website, and then store it on the session state. This way, only the first page load will make a call to the database.

You can store the user ID in the cookie.

Just remember to persist the session in the db when the user updates his preferences, and deleting old db records after a while might be a good idea too if that many anonymous users will visit your website.

Answer 3

If you want to persist the changes, such as each campaign view, there really isn't any way around accessing to write those changes. ASP.NET Membership is not bad on a high-volume site (>1 mil a day), when used correctly. For instance, you should be wrapping calls to the membership provider in a cached object, and refresh often (short expiration). Also, make sure to set the cacheRefreshInterval on the RoleProvider. This will force asp.net to cache the Roles in a cookie, to cut down on DB activity.

Another way to look at this is to take Ady's advice and to seperate the Membership into a separate DB. Yet again, another great feature of the ASP.NET Membership provider - you can set a different SQL connection string, and load it up on a different DB and/or server.

There are several other techniques around the membership provider that can really increase performance. Some quick google searches comes up a number of them.