我正在考虑编写自己的工具来跟踪访客/销售，因为 Google Analytics 和其他工具在数据部门还不够全面。 他们有很好的 GUI，但如果您有 SQL 技能，那么这些 GUI 是不必要的。
我想知道执行此操作的最佳方法是什么。
我可以简单地将 IP 等记录到文本文件中，然后在后台运行异步服务以将其转储到数据库中。 或者，也许这太过分了，我可以直接将其放入数据库中。 但就可扩展性而言，每个 Web 请求写入一个数据库似乎是一个糟糕的选择。 想法？
顺便说一句，捕获引用 URL 或任何传入流量是可能的，对吗？ 因此，如果它们来自论坛帖子或其他内容，您可以跟踪该实际 URL，对吗？
看来这是一个非常标准的要求，我不想重新发明轮子。
一如既往，感谢 SOF 的见解。
I'm considering writing my own tool for tracking visitors/sales as Google Analytics and others are just not comprehensive enough in the data dept. They have nice GUIs but if you have SQL skills those GUIs are unnecessary.
I'm wondering what the best approach is to do this.
I could simply just log the IP, etc to a text file and then have an async service run in the background to dump it into the DB. Or, maybe that's overkill and I can just put it straight in the DB. But one DB WRITE per web request seems like a poor choice where scalability is concerned. Thoughts?
As a sidenote, it is possible to capture the referring URL or any incoming traffic, right? So if they came from a forum post or something, you can track that actual URL, is that right?
It just seems that this is a very standard requirement and I don't want to go reinventing the wheel.
As always, thanks for the insight SOF.
发布评论
评论（3）
这个问题的答案提到了开源 GAnalytics 替代方案Piwik - 它不是 C#，但您可能会在实现过程中得到一些想法。
对于 .NET 解决方案，我建议阅读 Matt Berseth 的 访问/PageView Analysis Services Cube博客文章（以及早期 和 示例 和另一个 示例，因为在他的网站上很难找到它们）。
我不确定他是否发布过服务器端代码（尽管您会找到他的
openurchin .js链接在他的 html 中），但您会发现大多数概念都有解释。 按照他的指示，你可能可以很快地让某些东西发挥作用。我认为您不想写入文本文件 - 可能会出现锁定问题； 我会选择 INSERT 到数据库表中。 如果表变得太大，您可以随时定期“汇总”结果并清除旧记录。
至于 REFERER Url，您绝对可以从 HTTP 标头中获取该信息（假设它是由客户端发送的，并且没有被代理或严格的 AV 软件设置剥离）。
顺便说一句，请记住，Google Analytics 为统计数据增加了很多价值 - 它对 IP 地址进行地理编码，以按位置（国家/城市）以及 ISP/IP 所有者显示结果。 他们的 JavaScript 进行 Flash 检测并将用户代理分段为有用的“浏览器类别”，并且还检测其他用户设置，例如操作系统和屏幕分辨率。 如果您想达到相同水平的报告，那么您必须执行一些重要的编码 - 更不用说获取条目和信息的数据和计算了。 退出页面信息、回访、唯一访问者、回访者、网站停留时间等。
有一个 Google Analytics API，您可能也想查看一下。
The answer to this question mentions the open-source GAnalytics alternative Piwik - it's not C# but you might get some ideas looking at the implementation.
For a .NET solution I would recommend reading Matt Berseth's Visit/PageView Analysis Services Cube blog posts (and earlier and example and another example, since they aren't easy to find on his site).
I'm not sure if he ever posted the server-side code (although you will find his
openurchin.jslinked in his html), but you will find most of the concepts explained. You could probably get something working pretty quickly by following his instructions.I don't think you'd want to write to a text file - locking issues might arise; I'd go for INSERTs into a database table. If the table grows too big you can always 'roll up' the results periodically and purge old records.
As for the REFERER Url, you can definitely grab that info from the HTTP HEADERS (assuming it has been sent by the client and not stripped off by proxies or strict AV s/w settings).
BTW, keep in mind that Google Analytics adds a lot of value to stats - it geocodes IP addresses to show results by location (country/city) and also by ISP/IP owner. Their javascript does Flash detection and segments the User-Agent into useful 'browser catagories', and also detects other user-settings like operating system and screen resolution. That's some non-trivial coding that you will have to do if you want to achieve the same level of reporting - not to mention the data and calculations to get entry & exit page info, returning visits, unique visitors, returning visitors, time spent on site, etc.
There is a Google Analytics API that you might want to check out, too.
您是否看过日志解析器 解析 IIS 日志？
Have you looked at Log Parser to parse the IIS logs?
我不认为写入文本文件比写入数据库更有效 - 事实上恰恰相反。 您必须在写入时锁定文本文件，以避免并发问题，这可能比写入数据库（专为这种情况而设计）产生更大的影响。
我也对重新发明轮子持谨慎态度。 我完全不清楚您认为定制的点击记录器可以比 Google Analytics 做得更好，因为 Google Analytics 非常全面。 相信我，我一直在努力编写自己的代码，而 Analytics 让它变得非常多余。
I wouldn't have though writing to a text file would be more efficient than writing to a database - quite the opposite, in fact. You would have to lock the text file while writing, to avoid concurrency problems, and this would probably have more of an impact than writing to a database (which is designed for exactly that kind of scenario).
I'd also be wary of re-inventing the wheel. I'm not at all clear what you think a bespoke hits logger could do better than Google Analytics, which is extremely comprehensive. Believe me, I've been down the road and written my own, and Analytics made it quite redundant.