使用 ASP.NET 进行匿名个性化的有效方法 + 曲奇饼
我正在尝试在 ASP.net 环境中实现匿名个性化。 我知道 ASP.NET 2.0 提供了 Profile。 但是，我希望尽可能避免数据库的流量，因为我正在工作的网站是一个流量相对较高的网站。
另一个明显的解决方案是 cookie，但考虑到 cookie 的限制，我想知道是否任何人都有任何有效的方法将信息存储到 cookie 中。 有谁知道亚马逊或雅虎如何处理匿名。 个性化？
最终，我们试图根据预定义活动中的一组业务规则大纲向用户提供不同的动态内容。 原因是为了衡量我们网站的转化率。 同一活动可以在网站的所有不同页面上使用。 我需要将其设置为 cookie 的原因是，如果我们愿意，用户可以看到之前提供的相同内容。 这就是我现在 cookie 中的内容。
campaign code:page id:result display
您可以看到，如果有很多营销活动并且每个营销活动都在许多页面上使用，这种情况就会增加。
提前致谢！
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!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果数据库负载是一个问题，您可以在用户在网站上启动会话时检索个性化信息，然后将其存储在会话状态中。 这样，只有第一个页面加载才会调用数据库。
您可以将用户 ID 存储在 cookie 中。
只需记住，当用户更新其首选项时，将会话保留在数据库中，如果有很多匿名用户访问您的网站，一段时间后删除旧的数据库记录也可能是一个好主意。
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.
如果您想保留更改（例如每个营销活动视图），则确实没有任何方法可以访问并写入这些更改。 如果使用得当，ASP.NET 会员资格在高访问量网站（每天超过 100 万）上表现还不错。 例如，您应该将对成员资格提供程序的调用包装在缓存对象中，并经常刷新（短期到期）。 另外，请确保在 RoleProvider 上设置 cacheRefreshInterval。 这将强制 asp.net 将角色缓存在 cookie 中，以减少数据库活动。
另一种看待这个问题的方法是采纳 Ady 的建议，将会员资格分离到一个单独的数据库中。 ASP.NET 会员资格提供程序的另一个重要功能是 - 您可以设置不同的 SQL 连接字符串，并将其加载到不同的数据库和/或服务器上。
会员资格提供者还有其他一些技术可以真正提高性能。 一些快速的谷歌搜索会出现其中的一些。
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.
我会为访问者创建一个数据库记录，并且只将 ID 存储在 cookie 中，这样您就可以从数据库中查找所有个性化详细信息，并将 cookie 大小保持在最小。
如果数据库速度是一个问题，也许可以使用不同的数据库和服务器来存储个性化设置。
或者，您可以将个人数据存储在文件系统中，并在访问者返回与 cookie ID 匹配时加载到会话中。
如果识别用户和清除 cookie 是一个问题，您可以冷用 ActiveX 控件，但这需要在客户端计算机上安装，人们可能会反对。
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.