作为一个产品经理，我们经常在焦虑， 无法发现问题和科学的了解现状，不知道后续做什么事情才是正确的。
在这样的焦虑中，我们唯一可以依靠的武器就是数据， 通过数据发现正确的问题。定下一个可量化的目标和拆分出可以支撑这个目标的指征。时刻的核对自己的目标，保持对目标的动力以及知道自己如何达到这个目标。
下面我们来看看如何写一个小爬虫，来研究人人都是产品经理的文章发布和阅读情况。利用获得的数据来辅助业务推进。
这次所有分析的动态图表可以在这里查看，并自己进行进一步的下钻进行分析。
me.bdp.cn/api/su/DSLB…
寻找线索，获得规律
我们选定http://www.woshipm.com/ 作为我们的数据收集对象， 第一部首先需要通过一个结构化的数据知道整个网站文章地址的规律是什么， 否则没有结构化的数据，无法通过脚本来替代人工工作。
首先我们点开一篇文章，尝试用文章的链接地址中发现线索， 比如这篇文章
链接地址的格式是 www.woshipm.com/ai/1873778.… ， 多点开几个文章就会发现，这里的ai 代表着这篇文章所在的大类目。 网站将文章按照领域划分了多个一级类目。
基本可以断定页面链接的组成格式 是 网站域名+类目+文章编号。 但是这里有个问题，我们并不知道是每个类目都会有自己独立的文章编号，还是共同的文章编号，只是域名中做了一个虚拟的类目映射关系。 这个问题需要进一步的探索。
接着我们尝试是否可以通过更改文章编号来发现另一篇文章。如果可以用个这个方式访问目标页面， 那么事情就简单了， 直接无脑+1 循环就可以获得文章内容了。
提示404 了。 此路不通， 可能的原因是每个文章编号会在投稿的时候生成，但是有大量投稿并未通过，所以无法用该编号找到文章。 另一个可能是该编号文章映射的分类并不是AI，所以无法通过链接改id来找到对应文章。
通过链接无法形成规律，那么只能再看看其他路线。
回到首页，祭出前端开发神器， 浏览器调试器，切换到Network一栏，试试看每次页面刷新的时候，前端页面会向后端请求什么数据。 试着在这些数据里找到规律。
排查Network记录，我们在页面下拉时， 可以发现页面向服务器的http://www.woshipm.com/__api/v1/stream-list/page/2 接口发了一个请求，获取了一些数据
通过Preview该接口返回的内容，我们发现了前往数据宝库的入口 。
该接口默认会通过json格式返回11篇文章的信息， 包含作者信息，评论数，题图，点赞数，链接，说明文字，文章标题，阅读数量。
我们试试这个接口是否可以多次请求获得翻页后的数据。 接着往下翻，发现自动加载了http://www.woshipm.com/__api/v1/stream-list/page/3 。 这里的3肯定就是代表页面的参数了，于是我们可以模拟页面翻页，来获得源源不断的纯净数据了。
试试用这个接口单独打开一个tab， 并将最后的3改为一个很大的数字，比如400 。
正常返回了信息，说明起码在400页，还是有不少信息的。 不过浏览器直接打开页面会发现看不懂信息， 没关系，里面的中文被更改过编码而已。 后续获得信息后，可以自动将这些改回正常的中文编码。
内容规律的探索到此结束， 下面就是如何批量的使用这些规则获得需要的信息了。
自动化获取样本数据
前面找到可以获得结构化数据的信息后， 我们需要开始写代码来爬这个接口了。
开写之前，我们需要看看数据存在什么位置，这里我使用了Leancloud的在线数据库， 免得本地搭建数据库环境了。
爬这个接口相对比较容易， 代码逻辑只需要做这么几个事情。
- 步进构建请求的api。 一个while 或者for循环搞定。
- 将api的中获得的json 信息载入。
- 获取每次返回的信息中有多少行
- 循环将json中每一行中需要的字段赋值到指定的变量名称上。
- 将变量存入数据库。
为了不引起服务器的压力，我们这里对每次请求加一个3秒的延时
以下是python 代码 。
# -*- coding: UTF-8 -*-
import leancloud
import json
import urllib2
import time
leancloud.init("XXX", "XXX")
page=1808
while page<4167:
#当page小于我们希望获取的最大值时，执行以下逻辑
url="http://www.woshipm.com/__api/v1/stream-list/page/"
req = urllib2.Request(url+str(page))
#将api加上page页数,进行请求，获得数据
opener = urllib2.build_opener()
f = opener.open(req)
date = json.loads(f.read())
print page
i=0
while i'payload']):
#当i小于我们当前页获取的文章条数时执行以下逻辑
TestObject = leancloud.Object.extend('pm')
test_object = TestObject()
test_object.set('author', date ['payload'][i]['author']['name'])
test_object.set('category', date ['payload'][i]['category'])
test_object.set('catslug', date ['payload'][i]['catslug'])
test_object.set('comment', float(date ['payload'][i]['comment']))
test_object.set('date', date ['payload'][i]['date'])
test_object.set('id', float(date ['payload'][i]['id']))
test_object.set('like', float(date ['payload'][i]['like']))
test_object.set('permalink', date ['payload'][i]['permalink'])
test_object.set('snipper', date ['payload'][i]['snipper'])
test_object.set('title', date ['payload'][i]['title'])
test_object.set('view', date ['payload'][i]['view'])
test_object.save()
#以上是将json中制定行数的特定字段赋值，并储存在leancloud上
i=i+1
#做完一行的储存后，行数加一继续执行下
page=page+1
#做完一页的数据储存后，页数加一继续执行
time.sleep(1)
#休息3秒
print (page/4167),'%'
复制代码 好了，数据已经存好。
数据清理
拿到数据后， 先不要忙着动手分析，首先验证一下数据， 看看数据本身是否正确，有没有因为格式导致一些问题或者被网站故意投毒而数据无法使用。
验证数据正确后， 再看看数据格式是否统一。 很多网站在经过多次的改版后，前后的格式会有很大的差别， 无法统一进行分析。
抽样看了一些数据， 这里有一个坑。
人人都是产品经理对于阅读数量格式是放在后端处理的， 会将阅读数高于1万的数字改成 “1.3万”的格式。 于是字段从纯数字变成了文本格式，分析时会无法进行数字的数学处理 。
将原始数据保留备份，命名为raw， 复制一份导入excel。祭出熟悉的excel 公式对带有万字的数据重新盘一次，
=LEFT(J2,LEN(J2)-1)*10000
取单元格数值长度后，去掉最后一位乘以10000
清理好数据，保存完毕，开始进行数据分析。
数据分析
可以使用的数据分析工具有很多， 常用的Excel透视图已经可以满足大部分需求了， 高级点的tableau。 这里使用一个新的数据分析工具BDP， 可在线使用，功能特点与tableau类似。
这次一共收集到从2012年5月到2019年2月的 47441篇文章。
其中12年5月的时候，出现了异常数值新增了2924篇文章。 这里一般会是两种原因，平台刚刚启动，导入了外部的数据， 这是业务导致的异常。 另一种原因就是数据记录的异常，因为系统更新或者其他原因，在12年5月做了数据更新，导致12年5月之前的数据的创建时间全部丢失，所以使用了这一天作为文章的创建日期。
明确问题后，为了避免干扰，可以将这部分数据排除在外。这下可以随便怎么分析就怎么分析了。
每年大家关注的主题都有所不同
我们先从宏观来看
阅读量从13年后一直稳步上升， 在16、17年达到一定的峰值后开始下降。 18年的下降趋势比较明显。特别是在18年8月有一个不错的增长后，整体下滑严重。 除了可以反映人人都是产品经理网站本身发展之外。 对整个互联网环境的发展热度也能产生一定的映射。
然后加入总体的点赞和评论数据，一起看变化。
我们会发现在15年下半年的时候，虽然阅读数比现在要低，但是点赞的数据有一个明显的波峰， 但是评论却成了一个波谷。 这里应该存在一些产品或者运营机制上的变化， 让读者更多的选择的点赞互动，而不是留下评论。
看完总体数据，再根据类目纬度对数据做进一步的拆分， 发现特点。
看看最近一年不同主题的文章平均每篇的阅读数量，
很明显， 最近18年里，招聘主题的文章都能获得超过其他主题的阅读量。 也许招聘主题的文章更少， 而其他主题的文章因为低阅读的文章较多，很容易就会拉低平均值。
很多时候拆分只能体现当前的状态， 但是我们并不知道这些状态究竟反映了什么，是不是正常的。 于是需要对历史数据进行对比，来评估当前的状态。
对比一下17年不同主题文章的平均阅读数
与18年对比，17年有两个很明显的区别， 17年数据分析和产品需求文档类型的文章有更多的平均阅读数。 也许是17年新人更多，更关注基础的实操能力。
高质量的作者是网站的核心
数据分析的一个重点工作，就是发现核心问题， 便于集中资源来对核心问题进行挖掘，达到最高的产出比。
对于人人都是产品经理来说， 什么样的作者才是最核心的部分呢？
如果我们看文章的贡献量，最近一年，机构作者产量是最高的。
但是从文章数量并不能评估其价值，对于网站贡献价值最高的评估标准应该是获得赞赏的能力。 个人作者往往是获得点赞最多的。
米可 和 纸盒小火车这一年有超过三千个赞， 我得好好拜读一下这些文章。 基于这样的数据，很明显，网站的运营方需要给这前面几个伙伴好好的打好关系，不要被别人挖走了。 否则读者对网站的质量观感会下降的很快。
如果我们即需要从质量，又需要从带流量的能力来评估作者的话， 我们可以做一个散点图。将不同作者的能力进行划分 。将作者每篇文章的阅读量做Y轴， 每篇文章的点赞数做X轴。 可以得到下面这个图。
越靠上的作者获得阅读的能力越强， 越靠右的作者文章获得用户认同的能力越强。
这里有一位作者特别的出众， 晋童。 我们通过BDP的联动功能看看他到底做了什么。
发现他只写了一篇文章就收获了这么多的赞和阅读。 大牛，收下我的膝盖。
了解完一个网站最重要的作者资源后，我们再来看看什么样的文章更能吸引读者。
入门的干货知识永远是获得点赞最多的
从文章角度最近一年点赞最多的文章如下
关于具体某个App的竞品调研、功能分析和产品文档 ， 产品经理与技术的关系，获取流量的产品运营方法。这些干货一直是最受欢迎的文章，
同时对比17年的文章，
17年的最受欢迎文章，很明显有更多的小白入门系列的文章。 如何埋点、如何做数据分析、如何做需求调研、如何画流程图 。一个产品经理的入门知识，基本在17年的文章中都能得到回答。
总结：
基于以上通过数据对业务的不同维度拆分， 进行历史对比， 找到核心因素， 分析重点文章。 我们基本已经知道在一个业务推进中近期的变化，以及需要攻克的难题。
重复一下产品经理如何用数据指导和激励自己的工作：
通过数据发现正确的问题，定下一个可量化的目标和拆分出可以支撑这个目标的指征。时刻的核对自己的目标，保持对目标的动力以及知道自己如何达到这个目标。
好的，更多问题，欢迎关注微信公众号“冷小胖和李小胖的日常” 一起交流。
=======
冷帅：
前京东到家-达达 、拼多多增值服务产品经理 。