使用 .NET 跟踪用户进行唯一访客报告的最佳方法？
我通常会使用谷歌分析，因为它是免费的并且易于实施，但在这种情况下我们需要一个内部构建的报告系统。 该系统需要使用 .NET，只是因为 JavaScript 不是一个选项。
我的问题是，当您无法确定唯一访问者是否打开了 Cookie 时，如何跟踪他们？
我打算通过设置带有 GUID 的 cookie 来跟踪它们，然后针对每个页面点击将该 ID 存储在数据库中。 问题是，如果他们没有启用 cookie，则不可能知道每次他们访问页面时您是否正在创建新的 cookie，因为最后一个 cookie 由于被禁用而实际上并未被接受。 显然，您不能使用会话来跟踪它，因为它们处于完全相同的状态。
我想你们中的一些人会说创建几个页面，在用户进入网站之前检查 cookie，但这不会有帮助，因为用户并不总是从网站上的某个位置进入。
谷歌必须设法做到这一点，尽管他们使用 JavaScript。
创建新的跟踪 ID 之所以成为一个问题，是因为它会使我的报告与应有的情况相比变得不正常。 假设我有 4 个用户访问，每个用户访问 10 个页面。 如果一位用户没有启用 cookie，则会显示该网站有 13 位唯一访问者。
I would normally use Google analytics because it is free and simple to implement but on this occasion we need an internally built reporting system. This system needs to be in .NET only because JavaScript is not an option.
My question is how do you track unique visitors when you can never be sure that they have cookies turned on?
I was going to track them by setting a cookie with a GUID, then store this ID in the database against every page hit. The problem is that if they don't have cookie's enabled it is impossible to know if you are creating new cookie's every time they hit a page because the last cookie wasn't actually accepted due to them being disabled. You obviously can't use sessions to track it because they are in exactly the same boat.
I imagine some of you are going to say to create a couple pages that check for cookies before the user enters the website, but that won't help because the users won't always come in from one point on the website.
Google must manage to do it, albeit they use JavaScript.
The reason why creating a new tracking ID is a problem is because it will throw my reporting out of whack compared to what it should be. Let's say I have 4 user's visit and each of them visits 10 pages. If one user doesn't have cookie's enabled it will say the website has had 13 unique visitors.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
首先，唯一用户数始终是一个近似值。 没有强制 cookie 的保证方法，无论如何，它们的持久性并不完全由您控制，而且 IP 通常代表用户块（有时是大量）。 这方面的数据质量不好，你必须接受这一点。
这是一个很好的入门指南cookie 分析。
根据我的经验，跟踪 IP 至少提供了一个安全的下限，但您仍在谈论模糊的数据。
我所知道的所有其他 cookie 替代品都只是暂时的。
其次，“JavaScript 不是一个选项”是什么意思？ 关闭 JS 会严重限制 ASP.NET 功能（恕我直言），并且您的选择将更加有限。 这是你所期待的状态吗？
Firstly, unique users is always an approximation. There is no guaranteed way to force cookies, their persistance is not completely in your control anyway, and IPs often represent blocks (sometimes vast) of users. Data quality is not good in this area, you just have to accept that.
This is a good primer on cookie analytics.
In my experience tracking IPs does at least offer a safe lower bound, but you're still talking about vague data.
All other cookie alternatives I'm aware of are transient only.
Secondly, what do you mean by "JavaScript is not an option"? ASP.NET functionality is (imho) severely curtailed by turning JS off, and your options will be more limited. Is that the state you're expecting?
我会建议您在用户使用您的第一页（例如登录页面时）时通过服务器端代码跟踪数据库中的用户：
借助以下命令：HttpBrowserCapativity browser = Request.Browser;
您将获得诸如正在使用哪个浏览器、是否设置 cookie 等信息...然后根据 cookie 是否设置，您可以操纵您需要的事物/跟踪所需信息。
I'll advice you to track users in your db thru server side code when they/users use your first page say when they login page:
with the help of this :HttpBrowserCapabilities browser = Request.Browser;
you will get the information like which browser is being used, cookies are set or not etc... then depending on cookies are set or not you can manipulate the things / track required info you need.
首先，你永远不可能获得 100% 的准确性。 时期。 话虽如此，您可以做一些事情。
我开始输入如何构建一个无 cookie 的跟踪机制，当我写到一半时，我心想“ASP.NET 肯定会支持这样的开箱即用的东西吗？”。 事实上：无 Cookie 会话 ID。 这至少可以让您确定哪些请求来自单个会话中的特定（尽管仍然是匿名）用户。
不确定是否可以将其与使用 cookie（如果可用）混合使用（这会产生更好的 URL，并可能让您有机会跨会话跟踪用户），但这可能是一个开始。
First off, you'll never get 100% accuracy. Period. Having said that, there's a few things you can do.
I started typing up how you could build a cookie-less tracking mechanism, and when I was half way, I thought to myself "self, surely ASP.NET would support something like this out of the box?". And indeed: Cookieless Session IDs. This would at least allow you to determine which requests were coming from a particular (though still anonymous) user within a single session.
Not sure if you can mix this with using cookies if they're available (which would result in nicer URLs, and possibly give you the opportunity to track users across sessions), but it might be a start.