作为产品经理，进行需求分析的方法论，是通用的，哪怕是进行业务埋点需求分析，所使用的方法论，在我看来也是大同小异的。因此，我会在传统产品经理的需求分析方法论的基础上，进行埋点需求分析的总结。
成都创新互联公司专业提供成都主机托管四川主机托管成都服务器托管四川服务器托管，支持按月付款！我们的承诺：贵族品质、平民价格，机房位于中国电信/网通/移动机房，服务器机柜租用服务有保障！
作为传统产品经理，需求分析的步骤为：明确调研对象、明确调研方式 、需求调研、筛选需求、挖掘需求、需求归类及需求排序。对于埋点需求分析的步骤，只有需求调研和筛选需求这两步，需要一些特殊的办法。
在进行埋点需求调研的时候，和以往不同的是，我们应该要先做梳理产品的脉络和架构这件事情，梳理产品的脉络和架构，是为了整理用户使用产品的路径与流程，以便后续根据需求研究解决方案。
梳理完产品的脉络和架构之后，我们就有了需求调研以及后续提出需求解决方案的基础。
接着便是收集运营方的需求，明确运营方要达到的目的。例如说，运营方的需求，是为了让用户更多的购买、还是要让活动有更加多的曝光？
根据运营方提出需求的目标，我们就开始要根据产品的功能流程或者页面结构，定义好分析的目的，剥离关键流程，提炼关键指标。在这里，前面梳理的产品脉络和架构就用上了，必须了解了用户使用产品的路径与流程之后，才能根据产品流程确定关键指标的统计形式。
确定指标之后，则需要设计埋点事件对指标数据进行收集。
摘自
首先先理解什么是“事件”，可以理解为触发一个动作、行为或者到达某个条件，都是一个事件（Event）。
例如：在登录中，填写完信息后，点击一下“登录”按钮，或者点视频的“播放”按钮，页面流程的“下一步”按钮，获取到“登录成功”，访问某个页面，这些触发的行为都可以理解为一个事件。
因此，沿着流程和产品结构，会得到这么一个表格：
除了统计事件的触发次数外，还可以收集触发这个动作时，其他的附带信息。利用这类信息，有助于对事件有更加精准的统计，又称为参数（Key）和参数值（Value）。
事件、参数、参数值的关系如下：
埋点实施应该注意些什么呢？
埋点实施
下图为一个资讯行业的事件埋点模版，可以参照这个模板去进行梳理并提交给技术。友盟+ 开发者数据银行产品中的智能采集平台就可以按照这个模板，直接帮我们生成对应的埋点方案，并协助我们进行后续的事件管理。
市场上主流支持的四种埋点方式，分别是 代码埋点、服务端埋点、可视化埋点和全埋点。
代码埋点： 支持事件与参数这种结构化的使用方式，弊端是想增加或修改事件，都需要重新发版，用户更新后才能采集。 服务端埋点 ：通常用于业务数据的采集，例如：付费成功、用户注册等，这个场景会选择用服务埋点进行采集。 可视化埋点和全埋点 ：都是解决整个App前端操作的一些点击行为，例如说某些按钮、页面，每一个点击都能监测。但差异点在于可视化埋点只能看到圈定后的数据，那么全埋点则是在圈定时，历史数据也能去追溯。但这两个埋点的弊端是散点采集，每一个点击行为都是一个事件，在数据分析时，事件的量级会较大，不易于分析，而且它只能是取这种点击行为的事件，并不能把参数带过来，你可以理解为它就是一个纯扁平化的一个事件采集。
针对需求的不同，数据采集方式应该是结合使用的，以友盟+为例，友盟+现在支持两种埋点方式，代码埋点和可视化埋点，开发者可以结合使用，去满足事件方案的采集需求。
埋点验证
埋点后可通过三种方式验证：
打印日志，开启debug去打印Log，去验证触发事件log是否有上报，这种方式需要技术来配合验证 集成测试，以友盟+为例，只需要让技术注册一个测试设备，就可在你这个测试设备上去启用你的App，在去触发事件，产品、运营的同学就可直接测试埋点情况。 也可以使用市场上智能验证的工具，以友盟+为例，可先注册设备，自动去识别整个埋点的情况，且日志是实时的，可产出事件的验证报告。
智能验证，可以帮您智能验证这些事件的点是否采集了，是否有遗漏，最后会定期给出体检报告，详细的明细都会有。在友盟+的智能采集页面就可以智能验证埋点，只需要注册一个测试设备，这个测试设备填加完之后会实时把客户这些埋点的数据进行验证，到底是成功还是异常，以及测试的时间是什么都会有详细的数据。
综上所述：一个公司的埋点要可见、可控、可管，如果一家公司不清楚自己的埋点结构，便是在错误的数据上长期持续经营业务，越走越错。合理的埋点方案，可以使埋点能够智能调试和验证，大幅降低埋点采集的成本，从而最终达成数据质量的根本性提升。
开始这个题目之前，我想有必要简单明确一下以下2个问题：
1.为什么要做埋点？
2.如果确实要做埋点，为什么要做好需求分析？
我想明确了以上两个问题后，才能正式进入本文。
关于1.为什么要做埋点，可以换个思维来回答这个：埋点能为我带来什么？毋庸置疑，埋点能带来你想要的数据；当你需要进行决策或者评价某个活动效果时，常常会有数据诉求，而有的数据可能已经具备并且质量达标，但有的数据可能质量不达标，或者是空白，当你存在数据空白或已有数据不能满足需求时，埋点将是拯救你的一大利器；
关于2.如果确实要做埋点，为什么要做好需求分析？我能不能全埋点，跟随产品发版一次性全量采集所有数据（虽然有的数据现在不一定能用到，但谁敢保证将来一定不能用到呢，干脆一次性把能埋的地方能采集的地方全部埋点、采集了，省得将来再被人提需求）？全埋点确实也是埋点的一个形式，如果数据量不大，可以考虑全埋点，但就算全埋点也需要把所有内容梳理清楚；与全埋点不同，很多公司还是在针对性根据需求进行埋点，以降低计算、存储成本以及提升系统响应速度。总之，不管是全埋点还是针对性地进行埋点，需求分析都非常重要，如同一类型的埋点需求，为什么有的同学能一下找到问题本质，埋点上线后即皆大欢喜了；而有个埋点上线后，却是炼狱的开始，紧随着的是打不完的补丁，改不完的需求...
关于如何最好需求分析，不知道大家是否也和曾经的我一样犯过嘀咕：有没有一种需求分析的方法或者套路，我按部就班一步一步操作就能达到理想预期的效果？还是这件事情就是需要天赋异禀，必须天生拥有某项技能的人才能完成？关于这个问题，我的理解是套路肯定是有的，通过学习以及练习套路的使用，我想应该都能比较容易拿到80分，但如果想要拿到满分100分，确实需要一些天赋加持，如你天生就比别人思考的深度更深、同理心更强，那你需求分析时，你确实会占很大的优势，如果运用得当，那么也很容易和相同工作经验的人拉开差距；当然，如果你也和我一样，自始至终也没发现，自身有啥天赋异禀，那么也不用灰心，书上说通过后天的刻意训练，也可以拉近差距。
针对需求分析，个人常用的方法是5w2h和kano模型：
1.5w2h
5w2h即：why（为什么要做，理由？），what（目的是什么），who（谁来做），when（什么时候开始、完成），where（从哪儿入手？），how（如何去做），how mach（花多少钱）
2.kano模型
KANO模型是东京理工大学教授狩野纪昭（Noriaki Kano）发明的对用户需求分类和排序的有用工具通过分析用户对产品功能的满意程度，对产品功能进行分级，从而确定产品实现过程中的优先级。
KANO模型是一个典型的定性分析模型，一般不直接用来测量用户的满意度，常用于识别用户对新功能的接受度。
在KANO模型中，根据不同类型的需求与用户满意度之间的关系，可将影响用户满意度的因素分为五类：基本型需求、期望型需求、兴奋型需求、无差异需求、反向型需求。
针对本次埋点需求分析，相比较而言，5w2h相较kano模型更适合，所以下文将以京东首页排行榜为例、结合5w2h说明如何做好京东首页排行榜埋点需求分析。
对京东首页排行榜进行埋点要达到的目的：通过数据论证本模块是否真正达到了“跟榜购好物”的目标，同时为后续排行榜相关优化（如位置调整、算法优化等）提供数据支撑。
京东首页排行榜入口为首页，见下图
京东首页排行榜页面，见下图：
（1）产品功能架构
本排行榜涉及的功能包括返回上一页、排行榜分享、活动推荐、分类标签、上榜商品列表、分类标签、进入商品详情页等内容，完整功能架构详见下图：
（2）产品信息架构
本排行榜涉及活动、分类、商品等信息，完整信息架构如下图：
（3）核心业务流程
核心业务流程为：1.通过首页或者别人的分享进入排行榜页面—2.浏览榜单及商品信息—3.找到感兴趣的商品进入详情页—4.加购或者下单，从而完成交易。
京东排行榜要达到的目标是“跟榜购好物”，为了监控该目标的实现情况，我们需要关注以及埋点的指标如下（因用户及设备相关信息属于通用埋点需求，本模块不赘述）：
1.从首页或者其他分享渠道进入排行榜页面
A.从首页进入：从首页切换到排行榜花费的时间；（用该指标衡量排行榜的位置是否合适）；
B.从分享进入：各个渠道进入数量；（哪个渠道的分享更有效）
2.进入排行榜页面
本排行榜页面相关指标：uv、停留时间、榜单商品进入商品详情转化率、榜单商品加购转化率、榜单商品下单转化率、榜单商品距离上次购买时间间距、榜单页面分享次数、详情页面uv、详情页面分享次数、推荐的主题榜单进入次数（评价推荐的主题榜单的质量）、进入详情商品对应的分类（衡量分类顺序是否合理等）
3.从排行榜进入商品详情页
uv、停留时长、详情页面分享次数
4.加购以及下单
加购次数、订单数、笔单价、GMV
本模块改版后者相关内容改版时，需要重新检查、审视需要埋点的内容是否合理
京东首页排行榜及商品详情页
本埋点需求涉及PD、RD、运营、BI、boss等人员。
具体成本以及排期需要需求进一步细化提供给RD后，有RD进行工期评估。
移动互联网时代，无论是Android、iOS还是小程序，都有很多成熟的解决方案，无需花费很多的时间去处理埋点的事情，而且基于第三方提供的SDK进行埋点，在数据处理和分析上也有很大的优势。
但是在之前的PC互联网时代，除了网页端有百度统计、谷歌分析等，客户端的埋点似乎没有一套能拿出来可供大家讨论的解决方案，我就基于我的工作经验和理解，给大家分享一下PC客户端的埋点。
PC客户端的埋点
首先，在PC上，我们得知道我们需要统计些什么内容。
一个PC客户端，无论是工具类的还是内容类的，我们都希望知道我们提供的服务的效果。那么，我们从一个客户端安装、运行到最终被卸载来看看。
就拿产品使用较多的工具“Axure RP”来举例吧。如果“Axure RP”是我们自己的软件，首先我们需要知道被安装了，之后，我们关注激活情况，也就是使用，到最后，被卸载了，这一整个环节，构成了一个生命周期。 重点来了，对于这个生命周期，所有你想知道的关于“Axure RP”的情况你都可以统计到。
1.软件的安装
在PC客户端安装的过程中，流程一般是这样的：①运行安装包②弹出安装界面提供给用户操作③执行安装过程-写注册表、启动项、计划任务等④执行安装过程-创建安装的文件夹（③和④可以交换）。
在这个环节，我们一般需要知道：
安装包被运行了
在安装界面用户做了哪些操作
我们的安装过程是否正常执行
我们最终是否安装成功
在PC上，只要我们的安装包运行起来了，无论是弹出安装界面、写注册表还是创建文件，这些都是安装包可以控制的，所以我们能通过安装包进程，将整个安装环节的所有数据记录下来发送到我们的后台并记录下来 （这里要重点记住，由于安装是一次性的动作，所以统计一定要发实时的） 。
2.软件的使用
软件的使用，包括启动软件、使用功能和退出软件。
在PC上，软件的启动有很多种方式，例如开机自启动、计划任务、手动点击快捷方式，我们继续以“Axure RP”举例，当我们装上了“Axure RP”后，会在桌面、开始菜单中，创建快捷方式（有些程序会在任务栏上也创建），同时，会将后缀名为“rp”的文件默认打开方式调整为“Axure RP”。
对于启动， 我们就有了三种方式：桌面快捷方式、开始菜单快捷方式和默认软件打开，所以我们需要统计软件是否被启动了，是如何启动的。
对于使用功能， 当软件运行起来后，其进程就会启动，这个时候就跟移动端的应用类似，我们需要统计一系列事件，每个功能的使用情况、功能状态、付费、登录等一系列信息（区别于移动端的是，在PC上一般这些统计都是做单点统计，例如统计弹窗的弹出、功能的点击、某个状态，对于相互关联的一组事件统计是比较复杂的，需要定义结构体，在一条统计中包含很多组字段信息，因为没有成熟的SDK集成，所以基本都要自己定义埋点，复用性较差）。
这部分统计分为公共统计和专用统计。公共统计就是基本信息，常用的是用户标识、用户基本信息、计算机硬件信息和其他的可复用的；专用统计就是针对你的功能，你想了解哪些情况，针对性进行埋点统计。
对于软件退出， 这就比较简单了，是正常退出还是异常退出？软件使用了多久退出？
3.软件的卸载
软件卸载的流程包括启动卸载程序、用户操作、删除注册表及文件等操作、完成卸载。
在这个过程中，我们主要关注两方面的信息，一方面是用户怎么卸载的？是主动使用卸载程序，还是通过一些管理软件进行卸载；另一方面是用户为什么要卸载，这个时候我们可以在卸载的界面中给用户提供选择，以获取用户的反馈。
该怎么埋点
1.埋点的分类
（1）时效性
PC客户端一般情况下都比较复杂，子功能很多，可统计的内容很多，为了节省带宽，我们不可能每次都实时将数据传输回来，而且很多时效性不是很强的功能没有必要实时上报。
实时统计
当功能触发时或达到一定条件，立即将统计回传，一般情况下用于时效性比较强的功能，例如活跃统计、营收类统计，我们需要实时分析并调整策略。
延时统计
统计不立即回传，将统计积累，达到一定的条件或者一定的时间，统一将这部分统计回传，一般情况用于时效性不强的功能，例如采集设备信息、获取某些功能的状态、常规功能的统计，这部分统计使用范围比较广，一般都是隔日发送，有一天的延迟，统计的信息晚一天不会对分析产生较大的影响。
（2）埋点的作用
常规的基础统计
每次统计都需要发送，可以理解为公用统计，这部分统计是将几乎所有的统计都需要的部分包括进来，封装成一个统一的部分，每次发送统计都会带上这些内容，方便管理，节省后续埋点时间。
功能统计
针对特定功能，当功能被使用或者生效的时候，我们需要统计效果或者状态，可以理解为专用统计，不同于移动端，PC一般没有第三方提供的SDK，需要每个专用统计自己埋点，维护大量的统计内容，不过在一个公司内部，可以统一设计规范，方便维护。
（3）数据类型
结构体
统计连贯的事件，各项信息之间的关联很重要。
计数
统计某个行为发生的次数。
字符串
统计内容。
整形
统计数值，也可用来统计状态。
布尔型
统计需要判断的类型，一般使用场景较少，为了方便计算，大部分被整形和字符串替代。
2.数据埋点实例
（1）软件安装
场景：统计安装过程中的信息
（2）软件的使用
场景：软件启动后，用户使用了分享功能，将自己做的原型分享到了云端，最后用户关闭了软件。
要注意的是，软件启动和关闭，看需要是可以调整的，如果你只是想知道是不是启动了，来判断活跃，那么仅仅需要启动的时候发送个整型的值标识即可；如果想知道更详细的信息，比如启动方式、启动时间等等，可以定义结构体，将这一刻更多的信息发送回来，可灵活定义。
（3）软件卸载
卸载跟软件安装类似，这里就不赘述了。
在这里，如果希望收集用户的卸载原因，可以定义一个字符串，将用户填写的内容上报，这种形式的数据如果太多，不太利于分析，所以看产品情况可灵活设置。
作者 | 秦路
来源 | tracykanc
谈到数据驱动业务，离不开数据是怎么来的，数据收集是整个数据生命周期的初始环节。
数据生命周期的大体介绍，在过去的一篇文章中有提到。虽然文章的部分内容我准备重新构造，但是对于这部分的基础环节，并没有太多的变换。
文章会涉及到不少技术相关的知识，我会尽量减少这部分的细节。相信经过一系列的讲解，你会明白埋点数据怎么成为驱动业务的指标，文章也会提供网上的公开数据，帮助你实际上手操作。
需要收集的数据主要能划分成四个主要类型：行为数据、网站日志数据、业务数据、外部数据。
Web日志数据
网日志数据是Web时代的概念。
用户浏览的每一个网页，都会向服务器发送请求，具体的技术细节不用关注。只要知道，当服务器和用户产生数据交互，服务器就会把这次交互记录下来，我们称之为日志。
127.0.0.1 - - [20/Jul/2017:22:04:08 +0800] "GET /news/index HTTP/1.1" 200 22262 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.66 Safari/537.36"
上图就是一条服务器日志，它告诉了我们，什么样的用户who在什么时间段when进行了什么操作what。
127.0.0.1是用户IP，即什么样的用户。不同用户的IP并不一致，通过它能基本的区分并定位到人。 [20/Jul/2017:22:04:08 +0800] 是产生这条记录的时间，可以理解为用户访问的时间戳。
"GET /news/index HTTP/1.1"是服务器处理请求的动作，在这里，姑且认为是用户请求访问了某个网站路径，/news/index。这里省略了域名，如果域名是，那么用户访问的完整地址就是，从字面意思理解，是用户浏览了新闻页。也就是what。
who、when、what构成了用户行为分析的基础。Mozilla/5.0这个字段是用户浏览时用的浏览器，它的分析意义不如前三者。
如果我们基于who分析，可以得知网站每天的PVUV；基于when分析，可以得知平均浏览时长，每日访问高峰；what则能得知什么内容更吸引人、用户访问的页面深度、转化率等属性。
上面的示例中，我们用IP数据指代用户，但用户的IP并不固定，这对数据口径的统一和准确率不利。实际应用中还需要研发们通过cookie或token获取到用户ID，并且将用户ID传递到日志中。它的形式就会变成：
127.0.0.1 - 123456 [20/Jul/2017:22:04:08 +0800]…
123456就是用户ID，通过它就能和后台的用户标签数据关联，进行更丰富维度的分析。
案例的服务器日志，记录了用户的浏览数据，是标准的流量分析要素。但是网站上还会有其他功，即更丰富的what，譬如评论、收藏、点赞、下单等，要统计这些行为靠日志就力有未逮了。所以业内除了服务器日志，还会配合使用JS嵌入或者后台采集的方式，针对各类业务场景收集数据。
在这里我提供一份网上公开的数据集，年代比较古老，是学生在校园网站的浏览行为数据集。数据原始格式是log，可以txt打开。需要的同学可以在后台发送「日志下载」。
它是标准的服务器日志文件，对分析师来说，IP，时间、浏览了哪些网页，这三个字段足够做出一份完整的分析报告。后续的章节我将围绕它进行演练，为了照顾新手，会同时用Excel和Python演示。
首先进行简单的清洗。如果是Excel，直接将内容复制，文件开头的内容只需要保留第四。
按空格进行分列，初步的数据格式就出来了。
我们仔细观察cs-uri-stem，会发现有很多无用数据。比如/images/index_r2_c1.jpg，它是向服务器请求了图片数据，对我们分析其实没有多大帮助。用户访问的具体网页，是/index.asp这类以.asp为结尾的。
利用过滤功能，将含有.asp字符串的内容提取出来，并且只保留date、time、c-ip、cs-uri-stem、cs-uri-stem。按c-ip和time按从小到大排序，这样用户在什么时间做了什么的行为序列就很清晰了。
像172.16.100.11这位游客，在凌晨30分的时候访问了网站首页，然后浏览了校园新闻和一周安排相关的内容，整个会话持续了半小时左右的时间
Python相关的清洗留待下一篇文章，这里就不多花时间讲解了。感兴趣，大家可以先自行练习一下。
APP行为数据
数据埋点，抽象理解便是记录用户在客户端的关键操作行为，一行数据便等于一条行为操作记录。点击「立即抢购」是，在文章页面停留5min是，发表文章评论是，进行退出登录操作是，视频网站首页看到了10条新视频的内容曝光也是...反必要的，我们都采集。
APP行为数据是在日志数据的基础上发展和完善的。虽然数据的载体是在APP端，但它同样可以抽象出几个要素：who、when、where、what、how。
who即唯一标识用户，在移动端，我们可以很方便地采集到user_id，一旦用户注册，就会生成新的user_id。
这里有一个问题，如果用户处于未登录状态呢？如果用户有多个账号呢？为了更好地统一和识别唯一用户，移动端还会采集device_id，通过手机设备自带的唯一标识码进行区分。
实际的生成逻辑要复杂的多，安卓和iOS不一样，device_id只能趋近于唯一、用户更换设备后怎么让数据继承，未登录状态的匿名账户怎么继承到注册账户，这些都会影响到分析的口径，不同公司的判断逻辑不一致，此处注意踩坑。
回到用户行为：
when依旧是行为发生的时间。
where即行为发生的地点，手机上，通过GPS定位权限，获取用户比IP更详细的经纬度数据并不难。
what是具体的行为，浏览、点赞、评论、分享、关注、下单、举报、打赏，均是行为，如何统计取决于分析的维度。
如果我们想知道用户的点赞行为，那么在用户点赞的时候要求客户端上报一条like信息即可。
如果只是到这里，还称不上埋点，因为点赞本身也会写入到数据库中，并不需要客户端额外采集和上报，这里就引入了全新的维度：how。
如何点赞，拿微信朋友圈举例。绝大部分的点赞都是在朋友圈timeline中发送，但是小部分场景，是允许用户进入到好友的个人页面，对发布内容单独点赞的。服务端/后台并不知道这个点赞在哪里发生，得iOS或安卓的客户端告诉它，这便是how这个维度的用处。
换一种思考角度，如果很多点赞或留言的发生场景不在朋友圈，而是在好友个人页。这是不是能讨论一下某些产品需求？毕竟朋友圈信息流内的内容越来越多，很容易错过好友的生活百态，所以就会有那么一批用户，有需要去好友页看内容的需求。这里无意深入展开产品问题，只是想说明，哪怕同样是点赞，场景发生的不同，数据描述的角度就不同了：朋友圈的点赞之交/好友页的点赞至交。
除了场景，交互行为方式也是需要客户端完成的。例如点击内容放大图片、双击点赞、视频自动播放、触屏右滑回退页面...产品量级小，这些细节无足轻重，产品变大了以后，产品们多少会有这些细节型需求。
行为埋点，通常用json格式描述和存储，按点赞举例：
params是嵌套的json，是描述行为的how，业内通常称为行为参数，event则是事件。action_type指的是怎么触发点赞，page是点赞发生的页面，page_type是页面的类型，现在产品设计，在推荐为主的信息流中，除了首页，还会在顶栏划分子频道，所以page=feed，page_type=game，可以理解成是首页的游戏子频道。item_id指对哪篇具体的内容点赞，item_type是内容类型为视频。
上述几个字段，就构成了APP端行为采集的how和what了。如果我们再考虑的齐全一些，who、when及其他辅助字段都能加上。
埋点怎么设计，不是本篇文章的重点（实际上也复杂的多，它需要很多讨论和文档and so on，有机会再讲），因为各家公司都有自己的设计思路和方法，有些更是按控件统计的无痕埋点。如果大家感兴趣，可以网络上搜索文章，不少卖用户分析平台的SaaS公司都有文章详细介绍。
除了行为「点」，埋点统计中还包含「段」的逻辑，即用户在页面上停留了多久，这块也是客户端处理的优势所在，就不多做介绍了。
这里提供一份来源于网上的我也不知道是啥内容产品的行为数据源，虽然它的本意是用作推荐模型的算法竞赛，不过用作用户行为分析也是可以的。
这几个字段便是用户行为的基础字段，像deep_view，虽然没有明确说明是什么含义，但也猜测是描述了用户浏览的深度，比如看了50%+的文章内容，它只能以客户端的形式统计，实际业务场景往往都需要这种有更深刻含义的数据。
具体的分析实操留待下一篇文章讲解，感兴趣的同学可以自行下载，和网页日志放一起了。
行为数据不是百分百准确的，采集用户行为，也会有丢失和缺漏的情况发生。这里不建议重要的统计口径走埋点逻辑，比如支付，口径缺失问题会让人很抓狂的，相关统计还是依赖支付接口计算。支付相关的埋点仅做分析就行。
APP行为数据往往涉及到大数据架构，哪怕10万DAU的一款产品，用户在产品上的操作，也会包含数十个乃至上百的操作行为，这些行为都需要准确上报并落到报表，对技术架构是一个较大的挑战。而行为数据的加工处理，也并不是mysql就能应付，往往需要分布式计算。
对数据源的使用方，产品运营及分析师，会带来一个取舍问题。如果我只想知道点赞和分享数，那么通过api或者生产库也能知道，是否需要细致到行为层面？这便是一个收益的考量。
当然啦，我个人还是挺建议对分析有兴趣的同学，去能接触到用户行为数据的公司去学习。
业务数据
业务数据是生产环境提供的，我们在APP端获得了用户user_id，文章或商品的item_id，乃至支付order_id，但它们只和用户的行为有关。换句话说，我并不知道user_id是什么样的用户。
是男是女，芳龄几何？出生籍贯，从哪里来？这些人口统计学的信息必然不会在行为埋点中包含。商品内容订单也是同理。
单依靠埋点的行为数据，我们并不能准确描述什么样的用户做了事情，也不知道对什么样的内容做了行为。描述性质的数据/维度是分析的价值所在。男女的行为差异，不同城市的用户群体购买习惯，这才构成了分析和精细化的基础。
业务数据和行为数据的结合，在数据层面上可以简单理解为join。比如把用户行为数据的user_id和存放用户信息的user_id进行关联起来。形成如下：
上图是简化后的字段。user_name和sex就是取自业务数据的用户信息，item_tag也是取自内容信息表中的字段，而event则来源于行为埋点。三者共同构成了，什么样的用户who在什么时候when对什么样的内容做了什么事what。
简单说，很多用户行为的建模，就是拿各种数据组合在一起计算。用user_id的粒度聚合，你算得是这些用户喜欢哪些文章，用item_id的粒度聚合，你算得是这篇文章被哪类用户喜欢。它们都是你看待/分析事物的角度。
从更深的层面上说，行为数据也是可以再加工和利用的，它是构成用户标签的基础。拿浏览行为数据说，我们设计了埋点，知道王二狗看了哪些类型的文章，
item_tag是文章类型，游戏、娱乐、科技这类。有些用户可能各种各样的类型都喜欢，有些用户的口味偏好则比较集中，产品上可以拿用户偏好来代称，这里专指兴趣的集中度。
现在取所有用户的浏览数据，算它们在不同类型tag下的浏览分布（上文提供的行为数据就可以计算，cate_id便是内容类型）。比如王二狗可能90%的浏览都是游戏，10%是其他，那么就可以认为王二狗的兴趣集中度高。
这里有一个很简易的公式，1-sum(p^2)，将所有内容类别的浏览占比平方后相加，最终拿1减去，就算出了用户兴趣的集中程度了。我们拿案例简单看下。
上图的李二狗，他的兴趣90%集中在游戏，所以兴趣集中度= 1 - (0.9*0.9+0.1*0.1)=0.18,李三妞的兴趣稍微平均点，所以1-(0.5*0.5+0.5*0.5)=0.5，兴趣集中度比王二狗高。赵四有三个兴趣点，所以比李三妞稍微高一些，王五是均衡的，所以是四人中最高的。可能有同学疑问，兴趣程度为什么不用标准差算呢？它也是算波动偏离的呀，这是一个思考题，大家可以新加一个tag类别再算一下。
1-sum(p^2)是趋近于1的，有四个类别，一位均衡的用户（四个都是0.25）是0.75的集中度，当有十个类型，一位均衡的用户（四个都是0.1）是0.9的集中度。这种公式的好处就是兴趣类别越多，集中度的上限越接近1，这是标准差比不了的。
这里并没有涉及太高深的数学模型，只是用了加减乘除，就能快速的计算出兴趣的集中程度了。通过行为数据算出用户兴趣集中度，便能在分析场景中发挥自己的用武之地了，它是用户画像的基础，以后有机会再深入讲解。
外部数据可以分为两个部分，一个是行业市场调研类的，一个是爬虫抓取的，它们也能作为数据源分析，比如站外热点内容和站内热点内容、竞品对手商家表现和自己产品的商家，大家有机会应用的不多，就不多讲了，我也不怎么熟。
到这里为止，文章主要讲了用户行为层面的数据是怎么来的，更多是基础概念的讲解，下一篇文章会通过具体的数据教大家用户行为分析的技巧。不过，因为数据来源于网上，数据的丰富程度还是欠缺了不少，说白了，业务场景比较弱，希望大家自己在工作中多思考。
一、简述埋点
数据埋点是站在产品需求的基础上进行的数据采集，用来记录并分析用户的行为，对产品后期的迭代及运营提供的数据支撑方式。
二、前期思考
首先我们要分析我们目前针对产品数据方面的需求都有什么，想要通过什么方式进行数据埋点，得出哪些数据，通过这个数据分析得出什么样的结论。以京东的排行榜的模块为例，比如想知道哪个产品标签的PV最高，加购率最高，下单转化率最高，产品页面的核心跳转路径是什么，哪个页面的跳出率最高等指标。我们想要通过这些指标得到的结论是什么，可能进行的产品优化是哪些等。
在做需求分析时要站在产品目标和现有产品的框架和实际功能去思考，得出的最终结论一定要站在产品和用户的角度，能够产生实际的指导意义和得出有效的结论。
三、需求收集
根据不同的产品模块找出重点的需求收集方式，是采用访谈式，还是问卷式，还是通过之前得出的数据分析得出本次确定的需求，具体问题具体分析。
四、需求方案
针对前期我们思考的内容我们可以着手去制定我们的初步的埋点方案了。针对我们要进行埋点的产品模块，整理出具体的需求列表，进行优先级的排序，重点埋点数据都有哪些，并对我们梳理的需求进行再次的讨论和修改，确定最终的需求方案。
来自于一个数据小白的思考，欢迎指正。