设计 网站访问次数 第1篇
日志记录的完整性决定了后续统计的数据来源。日志记录一般需要记录用户的操作、业务线、访问模块、操作说明、操作时间、响应时间、数据来源、异常说明等信息。
其中，访问UA又可进一步解析，从中提取出使用的操作系统、浏览器和设备型号，便于后续更好地维护。
日志记录不仅仅从用户的操作层面去记录，更要从业务线的角度进行记录，在涉及到业务的统计时仅靠操作日志是难以出结果的，具体的业务线需要产品经理进行定义。
比如用户提交一个事件，以事件为单位，记录该事件的提交时间，审核时间、处理时间、办结时间、反馈时间等。记录全流程的过程，可统计办结率、平均办理时间等，这就是从业务的角度去记录。
日志的数据量大，通常以TB为单位，那么如何存储这么大的数据量，如何在大数据中读取数据并解析是需要提前考虑的问题。
目前市面上主流的处理方式是使用Hadoop进行处理。
日志一般获取到的形式为一长串的字符。需要从中提取出有效信息，才能方便后续的统计。所以要将UA解析为结构化的日志模板和参数。
比如UA为Mozilla/ (Windows NT ; Win64; x64) AppleWebKit/ (KHTML, like Gecko) Chrome/ Safari/ Edg/ ，可以解析出浏览器、渲染引擎、操作系统、设备型号和CPU信息。
同样的，访问失败日志也需要从报错信息中解析出相关的信息。
数据清洗是将数据中一些脏数据、缺失数据进行处理。具体包括去除重复数据、填补缺失值、处理异常值和转换数据格式等操作，是为了提高后续统计的准确性和可靠性。也是数据预处理中重要的一环。
日志的记录目的在于运维和系统分析。
一方面是对运维来说，能够快速定位到用户操作，通过对用户操作的日志分析，可以得出操作失败的原因。或模拟用户的访问环境进行模拟登录，还原用户访问失败的场景。
另一方面，可用于系统分析，统计不同时间段的访问量、访问人数、不同应用的访问量和人数、较同期、上期的对比数据等。从统计的数据中得出某些结论从而反哺于系统是我们的终极目的。比如根据用户的使用系统时间段高峰期可以预测用户的集中使用系统时间，在该时间段内加强系统监控，提高其稳定性高，减少系统更新，都有助于优化用户的使用感受，提高口碑。
还可以根据系统的访问情况得出最好用的某业务以及最难用的业务，取长补短，进行分析改进。根据用户的访问习惯对用户进行画像分析，得出用户感兴趣的某些领域，并推荐相关联的信息。
从日志信息中能挖掘的的信息很多，具体要看产品经理如何去分析，最好是有大数据相关背景的人士进行指导和讨论，结合具体的业务，才能最大程度地发挥日志的作用。下面会展开讲具体的统计维度和分析角度。
设计 网站访问次数 第2篇
常见的统计包括浏览量、独立访客、IP、访客次数、新独立访客数、平均访问时长、人均浏览页数、平均访问深度，跳出率，以下是上述统计项的具体定义和算法，用户可根据自己的系统和统计项进行取舍。同时要确定统计的时间维度，一般来说，会有四个统计维度，按日，按周，按月，按年，且统计时间一般截止到昨天的24:00,今日的数据要明日才能统计出来。以下是一些常见的统计项的定义和算法。
1）浏览量/浏览次数（PV）
即通常说的PV（PageView）值，选定时间段内访客访问应用的页面总次数。访客每打开一个页面被记录一次，同一页面打开多次浏览量值累计计算。
2）独立访客（UV）
即通常说的UV（Unique visitor）值，一天之内访问应用的独立访客数（以Cookie或设备ID为依据），一天内同一访客多次访问应用只计算为一个访客。选定时间段内的访客数为时间段内的每一天访问应用的独立访客数的累计值。
3）IP
一天之内访问应用的独立IP数，一天内同一IP多次访问应用只计算为一个IP。选定时间段内的IP数为时间段内的每一天访问应用的独立IP数的累计值。
4）访问次数
选定时间段内访客访问应用的总次数。访客首次访问或距离上次访问超过30分钟再次访问会被记录为一个新的访问。
5）新独立访客
当日的独立访客中，历史上首次访问网站的访客为新独立访客。
6）平均访问时长
选定时间段内访客访问应用的平均时长。
访客的单次访问中，访问的总时长为打开第一个页面到退出或关闭最后一个页面的时间差。
平均访问时长=访问总时长 / 访问次数
7）人均浏览页数
平均每个独立访客产生的PV。体现网站对访客的吸引程度。
人均浏览页数=浏览次数/独立访客
8）平均访问深度
平均每次访问(会话)产生的PV。体现网站对访客的吸引程度。
平均访问深度=浏览次数/访问次数
9）跳出率
只浏览一个页面就离开或关闭应用的访问次数占总访问次数的百分比。
跳出率=跳出次数 / 总访问次数 * 100%
除了统计上述的数据项之外，还可以进行同期数据的对比，使得数据项的变化更直观。如果要显示今日的数据，则刷新功能必不可少，因为日志的统计是实时的，在页面加载完成后还会有数据的更新。
日常的统计按应用角度来。范围广到细可根据：按应用，按模块、按内容三级来统计。应用统计是比较笼统的统计，看的是整体的数据，这个应用的整体趋势和使用情况。统计项可以包括PV、UV、IP、访问时长以及一些同比环比数据等。并且可以统计一些常见的业务数据。
某一应用再按功能可细分为二级模块、三级模块…按需再往下统计具体二三级模块的访问数据。
模块下某些上新的新功能也可做埋点，统计使用情况。比如上新了智能查重功能，就可以统计上线以来的使用次数，最后用该功能提交的文章，从而统计使用率。
设计 网站访问次数 第3篇
数据的挖掘与分析是日志的最后归口和产出。如何在海量的数据中挖掘出有用的信息，提高产能和效率是最考验产品经理的一件事。
我们都听过啤酒和尿布的故事，20世纪90年代，在美国有婴儿的家庭中，购买尿布的任务往往由年轻的父亲负责，他们会在买尿布时顺带为自己购买啤酒。沃尔玛超市尝试将啤酒与尿布摆放在相同的区域，并通过一次销售两件商品而获得更好的销售收入。对购买信息进行数据分析，得出尿布和啤酒的线性关系，就是一种典型的数据挖掘与分析。
本文只讨论一些简单的分析方法，具体内容还需具体分析。
在文章的第二章节，提到了许多的统计维度，展示的方式不仅仅局限于表格，适合的方式展示会事倍功半。趋势图可以查看系统的使用趋势，根据时间来观察用户使用频率高的时间。
活跃度情况可以用棋盘格来显示，在GitHub中非常常见。
也可用图表结合的方式对统计数据进行展示，统计图是展示分类和趋势，表格展示具体信息，结合起来会效果更好，能反映的数据信息也更多。
系统的分析反馈是渗透在统计中的，这需要产品经理有一双智慧的眼睛。
比如系统的访问日志中，有可能出现访问的周期性，那么根据用户习惯在访问频率高的时候推送一些爆点新闻，可提高用户的留存率和用户粘性。系统的报错日志统计出报错最多的前三的应用，每月进行整改。新上线应用使用率高，则应大规模推广，使用率低考虑功能是否便利，解决了用户的问题。
这些都是可以通过系统的统计分析出来的，设置分析的规则需要根据具体的业务来。
用户画像则是对用户的一些使用习惯进行分析，常见的方式有贴标签，特长。
比如很多应用注册时会要求用户选择感兴趣的领域。系统也可根据用户的访问内容的标签进行相关联，用户查看过某一新领域后尝试推送该领域的热门内容，如果继续点开，或者点开率达到50%及以上，那么可为该用户推荐该领域的相关内容并打标签。标签的分类可包括手动选择，自动选择。