如何规划电商平台产品线（完整版）
观主互联网生涯的前六年都在电商这大坑里滚爬，从无到有的搭建了三个产品团队，规模基本在10-20人之间。
电商平台都需要做哪些埋点 电商平台必要
电商平台都需要做哪些埋点 电商平台必要
今日兴致不错，就和各位道友聊聊，观主所理解的三种电商平台产品线规划策略（ps：根据不同行业、类型会有细微异，以下仅供参考；尤其要注意，不要拿某宝来比对，人家是终形态下的产物，早期和中期的电商玩不起，还是先把业务做扎实吧）：
一、按使用流程分：
▍1、核心数据：
以用户使用的流程为依据做切割和划分。
买家线：从找到平台到找到商品到完成交易到售后环节再到二次购买的一整条交易主线。
卖家线：从入驻平台到成为商家到开店上传到接单卖货再到售后跟进的一整条服务主线。
平台线：从服务买卖双方到活跃激励整个平台用户到拉新推广到服务保障到财务结算等。
▍2、举例说明：
不分先后：
a.搜索线（分类管理＋标签管理＋逻辑＋搜索算法＋排序、展示逻辑等）
b.展示线（内容、广告位管理＋首页＋落地页＋聚合页＋seo/sem支持＋专题、活动页、帮助中心等）
c.子频道线（按需设立：一般于平台主交易流程之外多子频道或者常态活动频道，都会设置一条单独的线来管理，如某宝聚x算、抢购功能、如某家居商城的装修资讯频道、如一些电商的等，这条线相对较为灵活机动，类型多样）
d.主交易线（商品详情页＋售前服务＋购物车流程＋下订单流程＋支付流程）
e.买家后台线（会员中心＋信息管理＋虚拟钱包＋售中、售后服务＋订单管理＋收藏、历史浏览等增值功能＋用户成长和激励体系等相关延伸，不赘述）
f.卖家后台线（信息管理＋商品管理＋订单管理＋财务管理＋物流管理＋库存管理＋推广管理＋店铺管理等＋用户成长和激励体系等相关延伸，不赘述）
g.平台总后台线（平台总后台，功能在早期考虑到代运营和强管制需求，一般会包含并大于卖家后台功能，同时需要注意以下几点务必早做打算：权限切割、财务结算、系统对接、数据和埋点、用户成长和激励体系、客诉和以及商家管理等）
h.移动线（包含移动端app和微信和wap，如果是平台性质的，前期不过早的介入移动端，当然看具体行业，移动线前期主要是将平台的功能精简并迁移，存在功能重叠，推广和开发成本高等问题，所以判断是否需要移动线应看公司战略，以及移动线的优势是否对业务有帮助，再做定论，观主经历过不少移动做个花架子或孤注一掷结果半途而废的例子）
i.金融线（主要两块，对买家的消费金融＋对卖家的供应链金融，大多数早期平台没有，因为授信和风控难以控制，但是b2b供应链想对容易，因为证照齐全，交易真实性保障度高）
▍3、人员要求：
按照分线策略，在招人时需注意，应聘人员是否有符合该线要求的相关项目经验，过往工作内容是否与该产品线的要求相近，在工作经验上可适当放宽，主要看对某条线，比如对商品展示的了解程度，因为该线是模块化切分后做前后衔接，所以每条线上的人能力不用太全面。
▍4、优劣对比：
优势：各线更为专注，各线间的关联性强，对各线的产品的能力要求相对较低，不需要过于全面，设某条线的产品较弱，前后关联线可以通过协作，做很大程度的弥补，发挥整体优势。
劣势：一旦某条线出问题，衔接上会很混乱，同时产品对其余每条相关产品线需要花很大精力去了解和熟悉，一旦消息不透明或闭塞，就容易产生盲区，造成设计上的前后不一致。
二、按业务板块分：
▍1、核心数据：
以平台业务板块来切割和划分：
按品类：一般适用于全平类平台，不同品类之间异化太大，会按品类来做区分。
按模式：一般适用于多种交易模式的平台，如b2b供应链大多会分三块：撮合、现货和金融。
▍2、举例说明：
用某化工b2b平台举例，分以下几条线（该线特点是出了移动线其余每条线对应到一个业务部门负责）：
a.撮合交易线（询盘相关业务：从采供信息展示、搜索、下询盘到撮合交易到线下等）
b.现货商城线（类似一个小天猫，不展开赘述）
c.供应链金融线（类似p2p，不展开赘述）
d.用户体系线（用户管理与激励，招商和认证等等）
e.用户后台线（买家和卖家的管理后台，不赘述）
f.总后台线（整个平台的管理后台，对以上几条线形成管理和支撑，包含BI系统）
g.移动线（包含app和微信，将部分核心业务流程迁移到移动端）
▍3、人员要求：
相比上一种分法，这种方法人员数量和线对数量都会减少，但几乎每条线都会涵盖比较完整的一段流程，所以对每个产品的能力、经验要求会提高，需要每个产品都有较为全面的能力，同时对完整流程有足够的作经验，招人的侧重除了不变的“项目经历契合”，改变的是“需要从专提升为全面”。
▍4、优劣对比：
优势：每个业务板块延伸的产品线，相当于一个的项目，各线之间更为，不容易因为某线出问题或者延缓导致联动性问题发生，同时每条线因为对一个业务板块负责，需求会更有针对性，支撑会更有效，更可量化。
劣势：任何一条线的人员要求都较高，否则就容易自坑，如上例，无论询盘线还是现货线，都需要完成用户的整个使用流程的产品设计，相比方法一，由于整个平台的在产品设计过程中被相对了，可能带来的问题就是容易过于沉浸，导致业务板块之间的协作和支撑缺失。在项目管理上，因为大家负责的实际设计会有很多类型上的重叠，比如询盘线和现货线，都要关注seo或者app或者微信，这种情况下，在需求到开发的过程中容易产生冲突和掐架。
三、按人力资源分：
▍1、核心数据：
这种分法，对于小团队（三无创业公司）特别好用，说白了，早期业务不清晰、人员预算不充足时，这种类似游击战的打法未必漂亮，但是至少高效和高能！
▍2、举例说明：
实际作就是一拖多，大家读书时都知道先进带后进，帮困小组吧？
这个分法很简单，就是把现有人员按能力和经验高低分层，然后按金字塔形一层层排布：执行类往下推，决策类往上推；难度往上推，简单的往下推。
比如观主目前在的创业公司，就一个app，一个web，一个后台，三个产品，有2个产品助理＋观主，就能解决了，产品助理主要做些非重要的设计工作和文档整理，观主主要做需求分析和产品功能制定等稍微需要烧脑的部分。
▍3、人员要求：
至少一名全栈产品或20%的中高级产品（二选一）＋80%初级产品，不展开赘述。
▍4、优劣对比：
优势：省钱，省人，设计出来的东西，中规中矩，高度统一，不容易出大乱子。
劣势：但是一旦出大乱子，就是天大的乱子，因为决策层较少，点的错误容易瞬间扩散到面。
以上就是观主的一些拙见，与各位分享，举例中或有不详尽之处，敬请谅解，无论大公司、小公司，都可以按以上的方法来分，无非终划分到的颗粒度有多细致而已，希望对大家有帮助，该篇不单适合产品团队管理者，同样的，产品想要有提升，必须对管理和规划有足够的理解！
望与诸位道友在产品的路上，一同共勉共励，一起披荆斩棘，谢谢！
ps：以上就是本观主的点滴心得体会，仅分享给需要的人来互通有无、相互印证！
神策数据618系列篇丨电商平台大促之目标用户精准营销
在上篇《电商平台大促期间精准营销“五步”走法则》中，我们整体概述了6促的精准营销流程，并详细阐述活动目标拆解和完善埋点设计。本期我们将进一步讲述如何将用户群体进行精细化分层，并对精细化分层的用户制定异化营销策略。
注：文中数据均为模拟。
一、精细化营销策略的原理
当你对某个细分用户群做策略触达，并收获比此前更好的反馈时，整体的运营效果也会大幅提升，这就是精细化营销策略的价值。因此，需要有效地对用户进行精细化分层，才能获得大盘上的运营效果。
二、用户分层的方法
当你比较看重整体用户的运营效果时，可以选择「用户生命周期」的分层方法。因为不管你的业务和产品形态如何，用户必然会属于生命周期分层中的某个阶段。使用这种分层方法，可以确保每个用户都能获得针对用户所处阶段合适的运营策略。
1、用户生命周期
（1）用户生命周期的定义
用户生命周期就是用户从开始接触产品到离开产品的整个过程，通常分为五个阶段：导入期、长大期、成熟期、沉默期和流失期。不同的产品形态定义各个时期的方法也是不同的，要深度结合自身的业务情况进行判断。通过对用户生命周期的划分，不仅可以宏观管理全量用户，而且可以明确用户的价值，通过运营手段让用户趋于停留在价值的阶段。
（2）用户生命周期的维度
以电商为例。一般来讲，用户生命周期的划分维度如下：
导入期：没有发生过购买行为，但存在购买意向的顾客长大期：已经完成首次购买流程成熟期：发生多次购买行为沉默期：曾经有过付费的用户，但在一段时间内未登录访问流失期：超过一段时间未再访问过产品
（3）用户生命周期的标准
在定义用户生命周期标准的时候，我们可以通过用户启动产品的时间间隔的趋势来判断。某电商客户时间范围为10-300天，其用户启动产品的时间间隔在时间范围大于天往后趋于27小时。也就是说，只要超过天后，无论时间范围如何扩大，用户使用产品的情况基本不会有太大变化。
在确定时间范围后，我们首先看下沉默期和流失期用户的标准。
通常情况下，「启动产品」这个关键行为动作能够帮助我们衡量用户是否沉默和流失。因为用户只有发生「启动产品」这个动作后，才能发生「浏览商品」「购买」等后续一系列行为。当用户在一段时间内未发生「启动产品」行为时，这就表明用户可能对平台失去兴趣，发展到一定时间后用户或许已经删除我们的产品。所以「启动产品」这个行为能够帮助我们很好地判断用户是否沉默以及流失。当然，我们也可以根据公司所处的阶段或者业务形态的不同选择用户的其他行为，比如「登录」「浏览」「加购」等来定义用户的沉默和流失。
那在付费后多长时间未「启动产品」的用户会进入沉默期，以及间隔多长时间未「启动产品」的用户会进入流失期呢？我们可以用“二八法则”来确定用户沉默和流失的时间。如下图：
从「支付订单」到「再次启动产品」的时间间隔趋势图来看，80%的用户在「支付订单」后会在18天内重新「启动产品」。因此我们可以将沉默期定义为在支付订单18天后「未启动产品」的用户。
从两次打开App间隔时间趋势图中可以看到，80%的用户会在27天内重新启动产品，因此我们可以将流失用户定义为超过27天没有「启动产品」的用户。那么，我们对用户生命周期的五个分层的明确定义可以如下：
2、用户价值区分
用户生命周期可以有效覆盖全盘用户，但是当用户体量较大且业务发展已步入成熟阶段时，我们的用户群体已不仅仅是行为相对简单的导入期或新用户群体了。长大期、成熟期的用户行为更加复杂，也值得我们根据创造价值的不同投入异化的精力去做维持和转化；针对沉默流失期的用户，往往也需要面向不同价值的用户实施异化的召回策略。此时用户价值分层恰好能够解决这个问题，它能够对需要认真投入精力运营的核心用户群体进行价值细分，实施异化的营销策略，保证运营手段的有效性和针对性。
3、价值分层：RFM
用户价值的RFM分层是指对于已经在产品内转化的用户，根据用户在产品中近一次消费、消费频率、消费金额来做好用户群体价值界定。
（1）RFM的定义
RFM模型通过用户近一次消费（Recency）、消费频率（Frequency）、消费金额（Monetary）三个维度划分出来8个用户价值群体，将群体用户进行价值细分，如下图所示： （2）RFM标准制定
RFM中三个维度的阈值并不是一成不变的，它需要随着终划分的人群以及相关的运营效果、活动规律，调整阈值的设定，终达到一个合理的划分。因此我们会通过“二八法则”对RFM值进行划分，这也会方便我们在后续迭代优化中根据业务反馈调整相应的阈值比例。
按近一次消费（Recency）对用户进行排序，的购买者排在首位，再根据用户数的累计占比发现80%的用户近购买时间距今为18天，从而选择18天作为划分近一次消费高低的阈值。同理，消费频率（Frequency）取3次作为划分购买频次高低的标准。消费金额（Monetary）普遍会出现20%的用户创造大部分营收的情况，所以我们取购买金额0元作为划分消费金额高低阈值。
通过对用户的消费数据进行分析确定RFM的相应的阈值之后，我们可以建立RFM用户分层如下： 三、不同人群精准营销策略
用户分层后，一定会有一个“理想”的分层是我们“梦寐以求”的用户。比如，电商企业都希望能有大量的成熟期用户，持续在产品上产生交易。然而，初级分层的用户想要跃迁到下一层，会存在一些用户视角的阻塞点，让他们存在疑问不想转化。运营策略就是要解决这些用户当前存在的阻塞点，帮助初级分层的用户更容易跃迁到下一个理想的阶段。而对于成熟用户，需要增加他迈向流失的阻塞点，以留存理想中的用户。以下为我们列出的电商行业中用户视角常见的阻塞点，以及配套的一些运营策略：
将「用户生命周期」和「价值分层」结合起来后，不仅对不同阶段用户的策略更有针对性，也可以根据用户的价值分层有优先级地投入有限的资源。在活动预算有限时，对于重要分层的用户，可以做一定的倾斜，对于一般分层的用户，则可以不做太多额外的动作，节省资源。以下为我们列举的用户分层和策略，以供参考：
点击放大查看高清图
6促作为电商行业全年重量级活动，更需要将用户群体精准化，配合个性化的营销策略，才能实现效果化，为全年目标的完成打下良好基础。
关于埋点文档的一点总结
埋点就是在用户使用产品时记录下用户行为数据，以便后面对用户行为进行数据分析。比如说需要页面的浏览量，就需要对用户浏览页面这一行为进行记录，然后一个页面的所有用户浏览量相加，便可以得到这个页面的浏览量了。
1）埋点是为了进行数据分析，因此先明确数据指标或者是分析目的，这样能够保证自己想要的数据都能找到。
2）埋点可以为单位进行的，每一条埋点数据或者说是用户行为数据，记录了一个的发生。每一条数据需要讲清楚“ 什么人在什么时间、地点以什么方式完成了什么事情 ”，也就是who/when/where/what/how。
举个例子，以视频播放这个为例，视频播放其实就是用户播放视频这个行为，那么这个里就包含是哪个用户在什么时间、什么模块看了什么样的视频，如果需要投递视频播放这个，那么包含的字段就有：用户ID/时间/在APP的位置/视频ID/视频属性。
比如像点击、浏览、曝光这些行为便可以用前端埋点，主要是发生在用户与界面的交互；如果是电商中要统计下单成功这个，客户端是没有办法知道订单是否成功的。如果统计的里有需要用到后端的数据，也是要进行后端埋点的。
埋点数据是需要存储起来的，数据就会有它对应的字段。一般一条埋点数据需要记录：
ID、名（英文名、中文解释）、属性（属性英文名、中文解释、属性类型）、埋点形式（前端/后端）、触发时机（什么时候投递这个）
一个发生时，像用户ID、设备信息这些都是每个可以共用的，因此可以定义一些每个都可以使用的公共属性，比如可以定义：
像用户信息（用户ID、设备信息、网络信息、地理位置信息）、时间信息等字段是所有都会用到的，因此可以把他们当做所有的公共属性。
类型分为点击、曝光、页面停留等，在设计时，可以按产品的功能模块、点击、曝光等维度进行划分。比如说现在对西瓜视频进行埋点，从功能上可以划分为视频相关的、视频互动（评论、点赞、分享等）相关的，一些较为简单页面可以直接统计点击和曝光。
视频相关的包括有视频播放、视频曝光这两大类。
西瓜视频首页视频播放过程可能会有：
因为视频播放中可能会出现各种情况，此时列出所有情况，尽量考虑到每种情况下播放时长应该怎样进行计算。关于视频曝光这块，后面如果在数据计算时，会计算曝光总和作为曝光量，如果是小视频出视频就算曝光了，而且这块可能出现快速滑走的情况，为了防止曝光时间过短，可以设置有效曝光时间，这样计算曝光量时我们可以控制什么样的曝光用来计算曝光量。
对于简单的页面曝光，可以进行简单的罗列；如果页面点击比较简单的话，可以用一个点击按钮属性来区分不同的点击按钮，但是如果点击比较复杂，本身可能就带有比较多得属性，或者这个点击很重要时，还是建议单独写一个点击，便于后面的分析。
一个APP里面有很多的埋点，而且都是不断迭代的（其实我就想说写完太累了，哈哈哈哈），所以就大概写一点了，大概形式就不多了，总而言之，埋点还是得根据数据的需求来，比如数据需求想分析用户关注行为，就可以把关注单拎出来做一个。
支付宝小程序： 如何做好小程序埋点？Part IV 埋点实施实战
埋点实施应该注意些什么呢？
埋点实施
下图为一个资讯行业的埋点模版，可以参照这个模板去进行梳理并提交给技术。友盟+ 开发者数据银行产品中的智能采集平台就可以按照这个模板，直接帮我们生成对应的埋点方案，并协助我们进行后续的管理。
市场上主流支持的四种埋点方式，分别是 代码埋点、服务端埋点、可视化埋点和全埋点。
代码埋点： 支持与参数这种结构化的使用方式，弊端是想增加或修改，都需要重新发版，用户更新后才能采集。 服务端埋点 ：通常用于业务数据的采集，例如：付费成功、用户注册等，这个场景会选择用服务埋点进行采集。 可视化埋点和全埋点 ：都是解决整个App前端作的一些点击行为，例如说某些按钮、页面，每一个点击都能监测。但异点在于可视化埋点只能看到圈定后的数据，那么全埋点则是在圈定时，历史数据也能去追溯。但这两个埋点的弊端是散点采集，每一个点击行为都是一个，在数据分析时，的量级会较大，不易于分析，而且它只能是取这种点击行为的，并不能把参数带过来，你可以理解为它就是一个纯扁平化的一个采集。
针对需求的不同，数据采集方式应该是结合使用的，以友盟+为例，友盟+现在支持两种埋点方式，代码埋点和可视化埋点，开发者可以结合使用，去满足方案的采集需求。
埋点验证
埋点后可通过三种方式验证：
打印日志，开启debug去打印Log，去验证触发log是否有上报，这种方式需要技术来配合验证 集成测试，以友盟+为例，只需要让技术注册一个测试设备，就可在你这个测试设备上去启用你的App，在去触发，产品、运营的同学就可直接测试埋点情况。 也可以使用市场上智能验证的工具，以友盟+为例，可先注册设备，自动去识别整个埋点的情况，且日志是实时的，可产出的验证报告。
智能验证，可以帮您智能验证这些的点是否采集了，是否有遗漏，会定期给出体检报告，详细的明细都会有。在友盟+的智能采集页面就可以智能验证埋点，只需要注册一个测试设备，这个测试设备填加完之后会实时把客户这些埋点的数据进行验证，到底是成功还是异常，以及测试的时间是什么都会有详细的数据。
综上所述：一个公司的埋点要可见、可控、可管，如果一家公司不清楚自己的埋点结构，便是在错误的数据上长期持续经营业务，越走越错。合理的埋点方案，可以使埋点能够智能调试和验证，大幅降低埋点采集的成本，从而终达成数据质量的根本性提升。
手机端建站如何处理数据埋点
手机端建站如何处理数据埋点?首先明确埋点的目的，埋点主要是为了(1)产品的核心指标。通过核心数据反映产品的宏观情况。(2)获取真实的用户行为，通过数据产品流程设计上是否有不合理的地方。(3)获取阶段内的数据变化，检验运营活动的效果。
在埋点时，就可以从这三个角度展开设计。
一、产品的核心指标
首先要想清楚，产品的核心数据指标是什么?如对于电商产品来说，就是有效订单数，客单价，平台流水等等。这些指标的优先级是怎么样的?这个就要根据公司的战略定位和现阶段目标来确定，如同样是电商产品，大宗商品可能会比较关注客单价核心客户数等，toC的电商产品可能会比较注重订单数。如处于不同融资阶段、拥有不同阶段战略规划的公司核心指标优先级也许又是不一样的。
产品核心指标一般包含：
1.产品规模
1.1用户数据。如新增用户、用户类型分布、活跃用户、沉默用户、启动次数、版本分析等。
1.2业务数据。这个与具体业务有关，如问答社区的问题数，回答数，全网热度，浏览量;如对含交易平台的交易量，交易额，客单价，转化率，利润等。
2.产品运营
2.1流量数据。pv，uv，dau，mau，留存分析(次日留存，7日留存，用户新鲜度),流失分析(日周月、自然流失、回归流失)，
2.2渠道数据。渠道流量，渠道转换率，渠道评价，渠道时段详情，渠道质量(渠道活跃用户/渠道流量)等。
二、获取真实的用户行为
获取真实的用户行为，调整产品侧重，通过数据产品流程设计上是否有不合理的地方。比如用户普遍在某个模块中停留时间较长，说明该功能对于用户来说是被真实需要的，对该模块的优化优先级可以提高，比如某流程在A环节的终止率跳出率非常高，那我们就知道A上存在问题。
1.作行为数据
1.1功能使用。如用户访问路径，用户点击分布，用户参与度(使用时长，使用频率，使用间隔)功能打开率，功能内具体组件使用率，功能使用时段，功能使用用户群等等。
1.2功能转化。通过记录相关页面的访问量，得出漏斗模型，转化率。登陆转化，注册转化，购物车转化，收藏转化，粉丝转化，用户跳出页面等。
2.传播数据
如化分享(分享平台、分享页、分享人数、接收分享人数)
三、获取阶段内的数据变化，检验运营活动的效果。
埋点数据参考以上，只是范围上更针对运营活动的相关内容，时间维度上集中在活动开展期间。
四、其他
根据需要，还可以埋点监测其他数据，如终端数据，bug数据等。
移动端和PC端的区别主要在于载体和表现形式不同所带来的影响，注意区别这些异在数据上带来的影响，如PC打开页面占用多个Tab，采用多会话和时间戳统计出来的TimeonPage就会有本质的异。
，埋点得到数据不过是把已客观存在的数据抽出来集中展示，想要从数据中获取能够对产品决策有用的信息，还是需要通过对数据进行综合分析。
建站手机端建站
关于数据埋点，你需要知道的技术方案和规范流程
埋点是数据采集的专用术语，在数据驱动型业务中，如营销策略、产品迭代、业务分析、用户画像等，都依赖于数据提供决策支持，希望通过数据来捕捉特定的用户行为，如按钮点击量、阅读时长等统计信息。因此，数据埋点可以简单理解为：针对特定业务场景进行数据采集和上报的技术方案。
数据埋点非常看重两件事，一个是数据记录的准确性，另一个则是数据记录的完备性。
先讲数据的准确性。数据埋点非常强调规范和流程，因为参数的规范与合法，将直接影响到数据分析的准确性，如果准确性得不到保障，那么所有基于埋点得出的结论，都是不可信的。辛辛苦苦做了很久的方案，一旦因为一个疏忽的小问题，导致下游集中投诉，其实非常划不来。
道理每个人都懂，但现实情况中，数据埋点所面对的客观环境，其实非常复杂，例如：
因此本文有非常长的篇幅来写流程问题，其实是非常有必要的。
再讲数据的完备性。因为埋点主要是面向分析使用，对用户而言是个额外的功能，因此埋点的业务侵入性很强，很容易对用户体验造成影响。别的不说，仅仅是流量的消耗，就很容被用户喷。因此，要提前想清楚，我们要采集哪些东西，因为修改方案的成本，是伤不起的。
通常情况下，我们需要记录用户在使用产品过程中的作行为，通过4W1H模型可以比较好的保障信息是完备的。4W1H包括：
规定好记录信息的基本方法之后，按照固定的频率，如每小时、每天，或者是固定的数量，比如多少条日志，或者是网络环境，比如在Wifi下上传，我们就可以开心的把埋点数据用起来了。
当然，数据记录的时效性也比较重要，但因为埋点数据通常量级会比较大，且各个端数据回传的时间不同，因此想做到实时统计，还是需要分场景来展开。在Flink技术日渐成熟的今天，全链路的实时采集与统计，已经不是什么难题。
在埋点的技术方案中，首先要重视的，是用户标识的建设。如果做不到对用户的识别，那么基础的UV统计，都将是错误的。
因此，在数据埋点方案中，有两个信息是一定要记录的，即设备ID+用户ID。设备ID代表用户使用哪个设备，如安卓的ANDROID_ID/IMEI，IOS中的IDFA/UDID，浏览器的Cookie，小程序的OpenID等。用户ID，代表用户在产品中所注册的账号，通常是手机号，也可以是邮箱等其他格式。
当这两个信息能够获得时，不论是用户更换设备，或者是同一台设备不同账号登录，我们都能够根据这两个ID，来识别出谁在对设备做作。
其次，我们来看一下Web的数据采集技术。Web端数据采集主要通过三种方式实现：日志、URL解析及JS回传。
浏览器的日志采集种类又可以分为两大类：页面浏览日志和页面交互日志。
除此之外，还有一些针对特定场合统计的日志，例如页面曝光时长日志、用户在线作等，但原理都基于上述两类日志，只是在统计上有所区分。
再次，我们来看下客户端的数据采集。与网页日志对应的，是手机应用为基础的客户端日志，由于早期手机网络通讯能力较，因而SDK往往采用延迟发送日志的方式，也就是先将日志统计在本地，然后选择在Wifi环境下上传，因而往往会出现统计数据延迟的情况。现如今网络环境好了很多，4G、5G流量充足，尤其是视频类APP基本上都是一直联网，因而很多统计能够做到实时统计。
客户端的日志统计主要通过SDK来完成，根据不同的用户行为分成不同的，“”是客户端日志行为的小单位，根据类型的不同，可以分为页面（类比页面浏览）和控件点击（类比页面交互）。对于页面，不同的SDK有不同的方式，主要区别为是在页面创建时发送日志，还是在页面浏览结束后发送日志，区别在于业务统计是否需要采集用户的页面停留时长。
页面的统计主要统计如下三类信息：
埋点其实还需要考虑数据上传的方案，批量的数据可以通过Flume直接上报，流式的可以写到Kafka，或者直接使用Flink来处理。这些框架相关的内容不是本文考虑的重点，有兴趣的可以自行查阅资料。
有了指导思路和技术方案后，我们就可以着手制定相应的数据埋点流程规范了。
笼统上，流程规范会分成五个步骤，即需求评审、埋点申请、技术开发、埋点验证、发布上线。
步，需求评审。
前文提到过，数据埋点的方案一旦确定，返工和排查问题的成本都很高，但数据埋点之后的分析工作，又涉及到了PD、BI、算法、数据等多个角色。因此非常有必要，将需求内容和数据口径统一收口，所有人在一套口径下，将需求定义出来，随后业务侧再介入，进行埋点方案的设计和开发。
以前文提到的4W1H模型为例，常见的记录内容如下：
我们统计时，按照上述约定，统计用户在某个时间和地点中，看到了哪些信息，并完成了怎样的动作。上下游的相关人员，在使用这份数据时，产生的歧义或者是分歧，会小很多。
第二步，埋点申请
当下的热门应用，大多是以超级APP的形式出现，比如微信、淘宝、支付宝、，超级APP会承载非常多的业务，因此技术方案上会十分统一。
因此，当我们的技术方案确定后，通常要在相应的埋点平台上，进行埋点申请。申请的内容包括分配的SPM、SCM码是什么，涉及到的平台是哪些，等等。SPM、SCM是什么，有什么用，同样可以自行查阅。
第三步，技术开发
当需求确定、申请通过后，我们就可以开始开发动作了，这里基本上是对研发同学进行约束。埋点的开发，简单讲，是分成行为埋点和埋点两个大类，每一类根据端的不同进行相应的开发。具体的技术方案详见前文01章节。
详细的设计规范，是需要留文档的，因为代码不能反应业务的真实意图，而不论是事后复盘与业务交接，都需要完整的文档来阐述设计思路。
第四步，埋点验证
埋点的验证很关键，如果上线后才发现问题，那么 历史 数据是无法追溯的。
验证有两种方式，一种是实时的功能验证，一种是离线的日志验证。
实时功能验证，指功能开发好后，在灰度环境上测试相应的埋点功能是否正常，比如点击相应的业务模块，日志是否会正确的打印出来。通常而言，我们需要验证如下三个类型的问题：
除去实时验证，我们也需要把日志写到测试环境中，查看数据上报的过程是否正确，以及对上报后的数据进行统计，侧面验证记录的准确性，如统计基本的PV、UV，行为、的发生数量。
很多时候，数据是需要多方验证的，存在一定的上下游信息不同步问题，比如对某个默认值的定义有歧义，日志统计会有效的发现这类问题。
第五步，发布上线。
应用的发布上线通常会有不同的周期，例如移动端会有统一的发版时间，而网页版只需要根据自己的节奏走，因此数据开始统计的时间是不同的。，应用应当对所有已发布的埋点数据，有统一的管理方法。
大多数时候，数据埋点的技术方案，只需要设计一次，但数据准确性的验证，却需要随着产品的生命周期持续下去，因此仅仅依靠人肉来准确性验证是不够的，我们需要平台来支持自动化的工作。埋点的准确性，大体有两种方法保障：一种是灰度环境下验证真实用户数据的准确性；另一种则是在线上环境中，验证全量数据的准确性。因此，发布上线之后，后续的管理动作，应该是对现有流程的自动化管理，因为团队大了，需要埋点的东西多种多样，让平台自己测试、自动化测试，就是很多测试团队必须走的路
支付宝小程序： 如何做好小程序埋点？
一. 埋点还是埋雷？数据埋点的“坑”
在接触过上百家头部客户中，诊断和参与了数百次的数据体系搭建工作。几乎80%的开发者都没有科学的埋点规划，只采集显性数据，而更深层的与、参数相关的隐性数据，都没有采集到。埋点规划并不难！但为什么大部分企业都做的不太好？埋点规划需要整合产品、运营、技术和业务等跨部门的需求，运营同学不太懂技术、技术同学不太懂业务、产品同学不太懂埋点。
埋点的常见的问题有那些呢？
遗漏 ：指的是埋点采集不全面，有可能重要的数据并没有采集到，会对数据分析造成比较直接的影响，出现这个问题的原因是前期数据分析需求不清晰。
杂乱 ：前期并没有进行结构化的设计，想一出是一出。通常是想到一个需求，就把这个需求提供给技术进行埋点。例如：某一个位置或者某一个功能的点击行为，就当做一个进行采集，看上去采集和查看很容易，但随着时间跟需求的增加，当采集了大量零散的之后，需要在统计工具中通过分组分析时，就会比较麻烦。
低效： 在设计的时候，会去做结构化处理。但设计的参数逻辑会有问题，通常都是以大的页面这种框架的思维去进行设计。举个例子：部分客户在设计时，会按照页面的思路去进行采集，当产品结构产生变化时，原有调整概率会比较大，因为之前都是按页面结构去设计，页面的调整直接影响采集。
无用 ：指的是数据虽然采集了，但分析时根本用不上，这个问题主要有2个原因导致，一是前期需求不太清晰，另一个是之前的采集需求都是由不同人提出的，由于中间人员变动，很多采集需求就不清楚了，并且也不敢下掉，因为并不清楚这个是否还有人使用。
复用： 指的是重复采集，或者是需求重复，这个同样是与多个人提需求有关，并没有一个人去做整合管理，或者是说，没有一个工具去帮忙我们做管理。
如果想要避免这些坑，就需要坚守五个原则：
需求清晰 合理设计 实施规范 结果可验 规范管理