周转率计算
库存周转率是反映企业库存周转的快慢程度。周转率越高表明存货的周转速度越快,从成本→商品销售→资金回流的周期越短,销售情况越好。
1、库存周转率=销货成本/平均存货余额
把公式指标拆开来看,
①销货成本=单件销货成本*销售件数
②平均存货余额=(期初存货金额+期末存货金额)/2
其中,期初存货金额:上期账户结转至本期账户的余额,在数额上等于上期期末存货金额
期末存货金额=期初存货金额+本期增加发生额-本期减少发生额
2、库存周转天数=360/库存周转率=(360*平均存货余额)/销货成本
库存周转天数是企业从取得存货开始,至消耗、销售为止所经历的天数。
通俗来说,就是库存周转率越高,周转天数就越小,说明存货变现速度越快,销售状况越良好。
例如你看这张库存周转分析,就可知道
库存周转天数→柱形图,库存周转率→折线图
1)全年中 11月周转天数最小,为0.04,周转率最高,为9231.42 ,销售状况最为良好。
2)下半年销售情况明显好于上半年,因为库存周转天数小,库存周转率高。
- 第一步:计算平均存货余额,平均存货余额=(期初存货金额+期末存货金额)/2
- 第二步:计算销货成本,销货成本=单件销货成本*销售件数
- 第三步:计算库存周转率,销货成本额/平均存货余额
- 第四步:计算库存周转天数,库存周转天数=360/库存周转率
拉新分析
在下个季度用50w预算,实现50w新用户注册。在同等预算下,上个季度的目标是30w,这意味着,再延续上个季度的宣传方式就无法完成目标。
搭建多维度的数据指标体系:
- 上个季度用的是怎样的宣传方式?
- 是广告投放还是新媒体推广?
- 哪个渠道的宣传效果更好?
- 这个季度要不要优化投放方式?
- 是不是还可以增加口碑营销?
- 如果用口碑营销,我们的基础用户又在哪里?
- 另外我们的竞争对手在同期做了哪些商业动作?
客户流失率逐年提升
分析思路
- 首先,判断指标下降是否合理;
- 其次,是否是数据传输故障等原因引起的;
- 最后,可以考虑对用户进行拆分,考虑从新老、渠道、地区等维度进行拆分,确定留存率下降的用户群体;
- 通过PEST(政治、经济、社会、技术),SWOT,4P理论(产品、价格、推广、渠道),竞品分析等方法分析数据波动的外界影响。
- 用合理的分析方法探究原因以及评价效果(各类活动效果分析,版本变化分析,用户分析,流失分析)
- 综合运用统计学知识对活动效果进行预估(异常值发现,年龄分布,同比、环比,用户画像)
或者
- 从大盘及流失用户画像:大盘中18到35岁的男性用户约占60%。
- 渠道分析:渠道B的用户流失率最低,渠道D的用户流失率最高
- 流失前最后行为特征分析:用户流失前在APP的最后行为有一定的共性 结论
- 结论1:建议业务方尝试追加渠道B的资源投放,减少渠道D的资源投放
- 结论2:用户最后访问的页面可能是用户直接流失的原因之一,建议好好排查
数据思维
数据分析思维七个模块
-
目标导向
如何走出取数的怪圈;什么是目标思维;如何找出目标(5why分析法);如何将目标思维融入工作的各个方面
- 想看一下某功能新用户的人数规模,业务方为什么要取这个数、这个取数需求背后的目标是什么、业务方想要知道这个人数规模有什么用、;领导想要看,为什么领导要看这个数、领导要看这个数的目的是什么
- 在一次会议上,领导发现新用户可能是业务增长的一个突破口,于是想要先看一下新用户的目前规模如何,值不值得投入资源做运营?
- 表面需求:想看一下新用户的人数情况
- 实际需求:是确定新用户到底有没有精细化运营的价值。队了人数外,还要衡量新用户有没有精细化运营的价值,那么新用户的活跃率、留存率、分享率等等数据
- 写一份完整的分析报告
- 新用户目前的整体状况
- 是否有运营价值
- 如果要运营,那么有哪些切入点
- 要了解写分析报告真正的目的是什么?不是为了让你说出来,而是让业务方能听进去。业务方不懂具体方法,他要的是结果,以及自己能做什么。
-
客观严谨
为什么客观严谨那么难;什么是客观严谨的分析:客观严谨的分析=事实+认证过程+观点;如何陈述事实;如何陈述谁过程
- 如何陈述事实:避免模糊的名词,专业名词不要搞错,用具体数据代替形容词副词;
- 如何陈述认证过程:
- 数据分析方法(对比思维:对比分析,线上试验;分群思维:结构化分析,同期群分析,RFM模型,K-Means模型;相关思维:相关性和因果性,因果推断)
- 不要预设立场
- 逻辑正确、思路清晰
-
指标思维
- 数据&指标&指标系统
- 如何构建指标体系
- 确定主指标:主指标就是用来评价负责的业务到底怎么样的最重要指标。如:销售部的责任是尽量多卖出产品,所以主指标是销售额;渠道运营的责任是拉来更多的有效新用户,所以主指标是有效新用户数。
- 一款APP常见主指标如下:初期做留存,发展期做用户数、活跃率等,成熟期做销售额、利润率等,衰退期主要指标是用户流失率等。
- 主指标确定的OSM模型:obejective(业务目标):用户使用产品的目标是什么?产品满足了用户的什么需求?Strategy(业务策略):为了达成上述目标我采取的策略是什么?Measurement(业务度量):这些策略随之带来的数据指标变化有哪些?
- 以滴滴网约车为例,按照OSM模型。O:用户的需求是便捷、能快速打到车、并且安全到达目的地;S:策略如下;便捷方面(滴滴提供了多个产品入口,有独立APP版本、小程序版本、以及高德、微信、支付宝等打车入口);快速方面(针对不同的需求提供了不同的产品选择,比如快车、优享、拼车、出租车等业务。并且根据早晚高峰的出行需求调节运力,减少用户排队时间);安全方面(实行司机准入机制和司机合规机制);M:指标;;便捷(渠道转化人数);快速(乘客取消率、供需比);安全方面(司机服务分)
- 拆分子指标
- 构建主指标的子指标(利润=营业额-成本;营业额=用户数 * 付费率 * 客单价;成本=渠道成本+营销成本+商品成本+其他成本;渠道转化人数=渠道人数*渠道转化率;;供需比=司机人数/乘客人数)
- 拆分过程指标
- 主指标和子指标都结果指标,结果指标可以明确地告诉我们业务做得好不好,但是有个缺点,就是反应慢(销售额,已经发生了)。过程指标:一个更灵敏的指标,提前发现问题。我们可以监督销售流程的各个环节。
- 过程指标最觉的形式就是漏斗模型。
- 落地页【页面点击率、停留时长、跳失率、分享量】--(购买率)-->购买页【浏览量、页面点击率、停留时长、收藏量】--(订单转化率)-->支付页【订单金额、订单用户数、订单量】--(支付转化率)-->购买成功【销售额、成交用户数、客单价】
- 提升销售额:提升落地页的转化率
- 添加分类维度
- 常见的分类维度有时间、地域、渠道、用户群体、商品类型等
- 确定主指标:主指标就是用来评价负责的业务到底怎么样的最重要指标。如:销售部的责任是尽量多卖出产品,所以主指标是销售额;渠道运营的责任是拉来更多的有效新用户,所以主指标是有效新用户数。
-
逻辑推理
- 到底什么是逻辑推理能力:逻辑推理能力是一个找到信息内存的逻辑关系,并推理出符合逻辑关系的结论的能力
- 逻辑推理的方法
- 指标归纳法
- 一月底销量下降,二月底销量下降,三月底销量下降;归纳法:每个月月底销量会大幅下降
- 指标演绎法
- 需求了解原因。找到销量下降的原因,是因为库存不足,但下个月底的库存充足,演绎法:下个月底的销量不会下降。
- 三要素:大前提:销量下降,是因为库存不足。小前提:下个月的库存充足;结论:下个月的销量不会下降。
- 指标类比法
- 指标归纳法
- 如何在工作中应用逻辑推理
-
系统思维
-
结构化思维
简单来说就是思考问题的时候,分析的思路要有一个结构,不能想到哪分析到哪。
提升日活用户数
- 结构化思维工具:逻辑树分为有三种
- 议题树:把大问题拆解成一个个小问题
- 1、收集各方案
- 2、分类。把这种想法进行归类。【分类新用户(外部渠道拉新,拉新落地页优化);老用户(老用户留存率);流失用户(流失召回)】
- 3、补齐缺失内容。【分类新用户(外部渠道拉新,拉新落地页优化,应用商店 自然流量,新获客方式);老用户(忠实用户留存率,普通用户留存率,潜在流失用户留存率);流失用户(流失召回,流失超过180天召回,流失超过90天召回,流失超过30天召回)】
- 假设树:假设一种方案,然后去验证假设
- 提出假设方案:加强渠道投放获取新用户,支撑这个假设的条件有两个。【条件1:加强渠道投放可以带来新用户提升。条件2:渠道投放 的投入产出比是正数。】
- 是否树:提出一个判断题,根据问题的答案进行下一个问题或得出结论
-
系统性思维
-
-
业务思维
-
为什么落地很重要:有分析结论和方案,方案要落地。
-
业务人员是怎么思考问题的
- 做分析最终的目标是提升某个业务指标,如日活人数,销售额,本质都是反映了用户有没有做某些特定的行为,比如:日活人数就是有多少用户访问了APP;所以要想提升业务指标,本质上就是要让用户做出某些特定的行为。
- fogg模型,这个模型将人的行为分为动机、能力、触发三个要素。
-
用业务思维分析问题
- 业务视角读懂数据
- 提出靠谱的建议
限时折扣活动的用户群体中90后用户的转化率偏低,如何给出问题解决建议?
通过fogg模型:【动力:分析90后用户会被什么样的广告方案吸引,找出区别于其他群体的需求。能力:分析90后用户的使用时段,看是否需要调整限时折扣的活动时间。触发:什么渠道的转化效果最好,用户在什么情况下转化率更高。】
-
信息不足:可以收集其他信息,比如内部调研、竞品分析等
-
汇报时候说:我调研了10位同事,共收集到以下23条建议,合并归类后我整理出13条,其中提升动机的建议5条,降低门槛的建议4条,优化触发的建议4条,分别如下:。。。
-
-
用户思维
- 什么是用户思维(用户需要什么,如何影响用户)
- 用户决策的过程(产生兴趣、收集信息、评估价值、做出决策)
- 如何应用用户思维
- 更高效的数据驱动
- 更精准的漏斗分析(传统漏斗:广告解达,落地页,购买页,支付页;用户决策过程漏斗:产生兴趣,收集信息,评估价值,做出决策;传统的漏斗分析不考虑转化流程本身是否有问题,而且是站在业务的视角看待问题,未必能得出有效的建议。)
-
数据源
- 数据埋点
-
构建体系和标准
- 数据指标体系
- 业务评价标准
-
商业智能分析
- 探究原因
- 评价效果
- 活动预估
数据埋点
数据埋点是一种常用的数据采集方法,是数据产品经理、数据运营以及数据分析师,基于业务需求或产品需求对用户在应用内产生行为的每一个事件对应的页面和位置植入相关代码,并通过采集工具上报统计数据,以便相关人员追踪用户行为和应用使用情况,推动产品优化或指导运营的一项工程。
数据埋点收集的数据包括但不限于 :访问数,访客数,停留时长,页面浏览数和跳出率。这样的信息收集可以大致分为两种:页面统计,统计操作行为。
数据埋点需要关注的三个问题
一、 用户的哪些行为会被采集到,是在客户端还是在服务器被采集到
- 设备的硬件能力,例如设备品牌,型号,主板,CPU,屏幕分辨率等等信息;
- 是软件能力,就算没有点击网页或者APP,像横竖屏,截屏,摇一摇等操作也会以被记录下来
- 是数据权限,新注册某款软件时,对于相册、通讯录、GPS等比较私密的信息一般会跳出是否授权的操作选项,如果用户同意授权,那么网页或者APP就能够采集到的这些信息
- 用户行为,用户只要对网页或者APP进行操作,行为都会被记录下来
二、 实现用户数据采集的技术有哪些以及它们之间的异同
数据埋点的方法根据其位置分类,可分为 前端埋点和后端埋点。前端埋点通过SDK进行数据采集,为了减少移动端的数据流量,通常对采集的数据进行压缩、暂存、打包上报。对于那些不需要实时上报的事件,通常只在wifi环境下上报,因此会出现上报的延迟与漏报的现象。
而后端采集数据则是通过调用API接口采集信息,使用内网传输信息,基本不会因为网络原因丢失数据,所以后端传输的数据可以非常真实地反映用户行为。
前端埋点【代码埋点/手动埋点,全埋点,无埋点,全自动埋点,可视化埋点】
代码埋点是最经典埋点方式,能采集到非常复杂的行为,尤其是一些非点击的、不可视的行为,按照位置的不同,可以分为前端埋点、后端埋点。前端埋点用来记录用户在客户端的操作行为,后端埋点用来记录客户端进行服务器请求的日志。
后端埋点【后端埋点】
-
前端埋点
前端埋点能够收集更全面、精细的用户数据,尤其是不需要请求服务器的行为数据,如:页 面停留时长、页面浏览深度、视频播放时长、用户鼠标轨迹、表单项停留及终止等等,只能通过前端 埋点实现。但缺点在于,前端埋点的上报一般存在15%左右的延迟上报和漏报(客户端未联网、数据 打包上报、用户删除行为数据等原因)。另外,如果客户端是APP,每次上线新的埋点或者更新埋点 时,需要发布新的版本才行,但是会存在部分用户不更新版本情况,影响数据质量。
-
后端埋点
理论上,只要客户端向服务器发送过请求,服务端埋点能够收集到。相比于前端埋点,能实 时采集数据,不存在延时上报,数据很准确;并且,服务端埋点支持与用户身份信息和行为附带属性 信息整合;另外,每次上线新的埋点或者更新埋点时,发布后马上生效。
代码埋点的适用场景
代码埋点适合精细化分析的场景,我们可以将各种细粒度的数据采集下来,后续做深度分析。当 然这种埋点方式很低效,需要经历完整的埋点流程,包括业务梳理(产品运营)、埋点设计(产 品运营/研发)、实施/测试/上线埋点(研发/测试)。整个过程需要多方协作,且要求产品运营 也具备一定的专业水平,如果发生错漏无法快速补救。
全埋点/无埋点
无埋点、无痕埋点、自动埋点,指的都是全埋点。这种埋点方式想要实现的效果是全自动化埋点, 将客户端的用户行为尽可能地全面采集,然后通过界面配置的方式对关键行为进行定义。使用这 种方案,每次有用户行为分析的需求,不用再走一次完整的埋点流程,只用在产品中嵌入SDK, 等于做了一个统一的埋点。
该种方案的弊端:
无埋点有很明显的弊端。主要体现在以下四个方面:
- 无埋点只能覆盖基本的点击、展示等用户行为;
- 全埋点采集的数据量非常大,随着数据量上升,可能会导致客户端崩溃的概率也会上升。尤其是移动端,更多的数据量意味着更多的电量、流量和内存消耗;
- 即使全部行为数据都被收集回来了,具体分析时也不能避免二次梳理和加工,因为机器无法在采集时按照我们想要的方式对全部事件进行有意义的命名,甚至无法保证采集上来的事件都正好是正确的;
- 现阶段全埋点对于用户身份信息和行为附带的属性信息也几乎无能为力。
可视化埋点
可视化埋点也被称为「无码埋点」,它的理念是降低实施埋点的门槛,以此来提升原工作流程的效 率。实施埋点时,无需研发人员介入,产品运营可以直接在网站或移动应用的真实界面上操作埋点, 而且埋点之后立即可以验证埋点是否正确,并且,埋点部署到所有客户端也是几乎实时生效的。
同样的,可视化埋点也有很多局限。 首先,可视化埋点也只是针对点击可见元素的,一些动态页面、 不可见的行为是采集不到的;其次,对于点击操作附带的业务属性,比较难实现;第三,为了确保 埋点准确性,可视化埋点也逐步整合了更为复杂的高级设置,操作起来也很低效。
各类埋点的定义、异同、优点、缺点以及适用场景
准确性:代码埋点>可视化埋点>全埋点
并不存在某种普遍完美的可以适应一切场景的数据接入方案,而是应该根据不同的产品,不同的分析需求,不
- 同的系统架构,不同的使用场景,选择最合适的一种接入方案。下面是一些典型的例子:
- 仅仅是分析UV、PV、点击量等基本指标,可以选择代码埋点或者可视化埋点等前端埋点方案;
- 精细化分析核心转化流程,则可能需要利用后端SDK或者LogAgent接入后端日志;
- 活动/新功能快速上线迭代时的效果评估,则可以利用可视化埋点快速完成;
- 对客户服务质量的考核,或者不同快递在不同省份运送不同品类产品的速度的比较,则需要使用后端SDK来对接第三方系统以便导入数据。
三、 采集到的用户数据是如何实现上报的
埋点能够获取用户设备、行为等方面的信息,获取信息后需要进行上报,然后入库储存,最后数据 分析师才能拿到这些数据进行分析。有两种主流的数据上报技术。客户端主动上报和服务端获取。
- 客户端主动上报:用户对客户端进行操作后,客户端通过网络发送HTTP请求给服务端,同时将数据上报给服务端
- 服务端获取:在网页中,用户首次看到的一切,都是从服务器返回的(APP不同,因为部分界面和逻辑已经安装在了用户的设备上,展示这部分界面不需要网络请求)。那么服务器在应答你的客户端请求的时候,也能拿到一些基本信息,比如你的浏览器类型、版本号、屏幕分辨率、IP地址等等。
四、 数据埋点的流程
日常工作中数据埋点的完整工作流程,它既有流程图,也有数据埋点的需求,涉及项目需求(含产品经理自提需求)的承接、评审、跟进、上线 以及项目复盘的各个业务环节。
数据埋点的流程
数据埋点工作是以数据产品为核心来推动的。数据产品经理负责数据埋点的整体工作,包括验证数据埋点的质量、判断数据埋点的准确性(包括日常工作中上线的数据埋点的准确性)等。一般的数据埋点需求关联的工作人员如下(另外还有部分需求会涉及数据采集、数据仓库):
- 业务方:页面运营人员、产品运营人员。
- 数据产品线:数据产品经理、数据产品测试人员。
- 广告产品线:广告产品线产品经理。
- 页面产品线:页面产品经理、页面测试人员、页面前端开发人员。
互联网公司点击埋点、曝光埋点的协作流程图
数据埋点的日常流程
-
提出埋点需求
-
运营人员提出埋点需求:不仅涉及埋点的位置,比如App的开屏页、App首页联版、App首页banner位,还涉及需要埋点的终端,比如有的埋点需求只 需要进行App端的埋点,而有的埋点需求需要进行App端、微信小程序、WAP端等多端的埋点。
-
产品经理自提埋点需求:数据产品经理在进行竞品分析及日常使用产品时,也会根据业务情况提出埋点需求。
-
-
梳理埋点需求,整理埋点方案
不同终端(App、内嵌H5、PC、WAP、微信小程序等)的埋点方案各不相同,通常至少需要包括以下几点:
- 埋点的位置:需要添加埋点的位置,比如登录页上的按钮、页面底部导航、搜索结果页等。
- 埋点的参数:用户浏览、点击的页面位置需要通过前端页面开发埋入的参数,比如页面编码、模块编码、区位编码、商品编码、店铺编码、页面特殊参数等。每个位置的埋点必须是全站唯一的,不能重复。
- 终端类型:对各终端进行约定,表示终端的标识。比如,约定App终端 为数字1:WAP终端是数字2:等等。
- 模板名称:需要埋点的页面的模块位置、页面的模板名称。例如,模块位置一App首页轮播banner,模块名称-轮播 banner位第二个资源位。
- 数据产品经理需要将自己整理的数据埋点方案与业务方、前端开发人员核对,以确保埋点方案可行。
-
需求评审,埋点文档评审
数据产品经理写出数据埋点需求文档,列出埋点位置、埋点所需的参数、涉及的埋点终端、埋点需要调用的接口、埋点是否需要异步触发、本次埋点需求期望的上线日期和联调日期等。
埋点需求评审的参与人员有业务线产品经理、数据产品经理、页面产品经理、前端开发人员、测试人员、业务线开发人员、数据开发人员。在必要时,比如新增埋点的产品类型时,还需要与数据采集人员、数据仓库管理人员沟通数据埋点需求。
-
埋点开发阶段
前端开发人员需要根据埋点需求进行埋点开发,实现相应的曝光埋点、点击埋点、埋入页面参数、异步触发请求(对于广告等埋点需求,在点击埋点关联到广告扣费结算时,需要再触发一次请求)。
-
埋点联调测试阶段
埋点开发结束后,进入埋点联调测试阶段。在联调测试阶段,需要在测试 环境下验证曝光埋点和点击埋点是否正确、埋点的参数是否有遗漏或错误。
-
埋点上线
埋点测试验证通过后,将埋点按照约定的日期上线。上线时同样需要测试。在生产环境下,可以下订单来验证订单归因(简单来说,订单归因就是通过订单能否验证订单的来源、来源对应的埋点位置)。
-
埋点需求复盘
埋点上线后,及时更新埋点验证情况,列出每期上线的埋点及需求内容。总结在每期埋点项目中遇到的问题,这样后面在推进新的埋点需求的过程中可以少踩一些坑。
-
埋点数据统计与用户行为分析 部分公司会开发数据埋点平台,这些平台会按天、按周、按月对每个数据 埋点进行数据统计;可以对同一个位置进行曝光埋点、点击埋点和页面事件的同比、环比趋势对比,比如淘宝App首页在618、双11等大促活动的趋势对比;可以根 据埋点数据做用户增长,提升用户留存率,比如根据淘宝App商品四级页的点击到达率来分析用户在之前哪个环节跳出。
数据埋点“七字决”
- 位:埋点的位置。
- 埋:埋点规范对接,前端开发埋点。
- 时:开发进行埋点后的联调时间、上线时间。
- 测:埋点在联调、上线时测试。
- 传:埋点测试通过后传的参数,埋点传参经过数据采集、数据仓库(对部分字段进行解析)。
- 表:埋点经过数据采集、数据仓库 传参后落表,为实 时或离线 的Hive表。
- 统:埋点验证成功后的统计。
两份报表统计出来的日活跃用户(DAU)数量不一致
先确定两份报表的统计口径是一致的吗?最小的统计维度是一致的吗,DAU以account_id为最小维度进行统计或者以device_id或者open_id为最小维度进行统计结果都会有一定的差距。而且,即使统计口径一致,埋点和上报方法也有区别。
埋点方案相关概念
1、事件
记录用户在使用网站、APP或小程序的过程中触发的行为。用户的行为有一部分会在他们使用的过程中自动被采集上来,常见的如:跟访问有关的“页面浏览”,“停留时长”;另外一部分包含具体业务含义的,则需要通过埋点才能得到,例如:“注册”、“登录”、“支付”等等。
2、事件属性
可以通过属性为事件补充相关的信息,例如:位置,方式和内容。用户产生行为时就会上报具体的属性值,比如对“购买事件”定义了“支付方式”的属性值,则根据不同的行为可能上报的是微信支付,支付宝支付。事件属性有点像字段,发生这件事件的一些相关字段都可以理解为属性,例如“购买事件”中的支付平台、金额、银行卡等相关字段,都可以被定义为事件属性。
3、用户属性
在分析过程中,需要引入注册用户的更多维度,比如注册用户ID、姓名、用户等级等等,也需要进行梳理,方法 同事件属性。
六个步骤实现数据埋点设计
-
确认事件与变量
这里的事件指产品中的功能或者用户的操作,而变量是指描述事件的属性或者关键指标。确认事件与变量可以通过AARRR模型或者UJM模型进行逐步拆解,理清用户生命周期和行为路径,抽象出每一个步骤的关键指标。
-
明确事件的触发时机
不同的触发时机代表不同的计算口径,因此触发时机是影响数据准确的重要因素。以用户付款为例,是以用户点击付款界面作为触发条件,还是以付款成功作为触发条件进行埋点呢?二者口径不同,数据肯定会有一定差异,因此明确事件触发条件非常重要。
如在用户付款中,我们建议使用两个字段记录用户付款行为,一个字段记录点击付款界面这个行为,另一个字段记录是否付款成功。
-
明确事件的上报机制
不同的上报机制也是数据准确性的重要影响因素之一,客户端上报数据可能会由于网络原因出现丢包的情况,作为数据分析师,在完成埋点工作的时候也需要确定数据是实时上报还是异步上报,以确定埋点是否合理,并及时调整数据埋点方案。
-
设计数据表结构
统一的数据表结构,方便团队内部进行数据的管理和复用,建议团队内部形成一套统一的数据结构规范。例如,将表分为不同的层级,第一层记录用户的基础信息,包括id,地区,昵称等;第二层记录玩家行为信息。
-
统一字段命名规范
有了统一的数据表结构档案还是不够的,统一数据命名规范数据埋点工作的重要一环。确保同一变量在所有的数据表当中都用统一的字段,比如消费金额这个字段,我们希望所有的表只要出现消费金额都用Amount字段,不要出现money,pay等其他字段。建立公司内部或者团队内部的命名规范是非常必要的,可以采用「动词+名词」或者「名词+动词」的规则来命名,比如「加入购物车」事件,就可以命名为:addToCart。
-
明确优先级
数据埋点都是为数据应用做铺排,埋点之后分析师可能面临着搭建指标体系和数据报表体系的工作,可以根据报表的优先级、埋点的技术实现成本以及资源有限性为数据埋点确定优先级。
数据埋点设计师数据分析师是埋点的重中之重,埋点设计得好能够极大地方便后续的数据应用。对于数据埋点设计,我们也总结了六个关键步骤。
埋点方案,以京东排行榜为例
-
分析分析当前APP所处的阶段,设置合理的目标。
京东排行榜是为了让用户跟着排行榜购买好物,即为了让用户更多地消费,同时由于推荐的是经得起考验的好物,也希望能在客户心目中留下好的口碑,提高用户对APP购物体验的满意度。因此,本次埋点的目的是为了收集用户的行为信息,提升用户体验、以及收集用户信息,进行精准推送,提高转化率。
-
分析实现目标需要采集哪些数据?
用户的行为是由用户一系列的事件组成,包含5个基本要素:何人,何时,何地,通过何种方式,发生了何种行为。
埋点方案包含两个部分:
- 事件方案 -- 确定上报哪些用户行为
- 用户方案 -- 确定上报哪些用户属性
-
事件方案––梳理需要埋点的事件、事件属性
| 平台 | 事件ID | 事件显示名称 | 事件说明 | 属性ID | 属性显示名称 | 属性说明 | 属性值数据类型 |
|---|---|---|---|---|---|---|---|
| Android,iOS | $ViewDetailtab | 切换菜单 | 切换菜单时触发 | tabid | 菜单ID | 用户点击的菜单 | 字符串 |
| classification | 菜单所属分类 | 用户点击的菜单所属的分类 | 字符串 | ||||
| Android,iOS | $ViewDetailtab | 浏览推荐 | 点击推荐商品时触发 | PageID | 页面ID | 用户点击推荐的商品 | 字符串 |
| Android,iOS | $Viewgoods | 浏览商品 | 点击排行榜商品时触发 | goodID | 商品ID | 用户点击的商品 | 字符串 |
| Rank | 排名 | 用户点击的商品的排名 | 字符串 |
- 用户方案 -- 确定要分析的用户的维度
| 用户属性ID | 属性显示名称 | 属性说明 | 属性值数据类型 |
|---|---|---|---|
| username | 用户名 | 用户名 | 字符串 |
| age | 年龄 | 用户年龄 | 字符串 |
| sex | 性别 | 用户性别 | 布尔 |
| region | 地域 | 用户地域 | 字符串 |
通过以上用户属性及事件属性,可收集到不同地域、性别、年龄的用户更倾向于购买排行榜中哪些分类中的哪些商品,进而可以在推荐位置中多推荐这种商品,以提高用户的付费程度。
以电商购物成交转化为例实现数据埋点设计
-
确认事件与变量 -- 通过UJM模型拆分用户购买商品的路径
将用户购买路径拆解为【注册-登录-商品曝光-商品点击-浏览页面详情-加入购物车-生成订单-订单支付】步骤,根据产品或策划提的数据需求,确定每一个步骤需要看哪些字段才能实现数据需求。
-
确认触发机制
明确是在点击按钮时记录行为还是在用户完成该步骤时记录行为。
-
确认上报机制 明确数据上报机制,是实时上报还是异步上报,不同的上报机采集到的字段可能不一样,或者说需要将字段拆分到不同表进行记录。
- 注册时【异步上报】
- 登录时【实时上报】
- 商品曝光时【异步上报】
- 商品点击时【实时上报】
- 浏览页面详情时【异步上报】
- 加入购物车时【实时上报】
- 生成订单时【异步上报】
- 订单支付时【实时上报】
-
统一字段名
业务内同一变量在所有的数据表当中都用统一的字段,例如:
- 用户编号:account_id
- 用户所属国家:region
- 用户所属地区:ip_region
-
统一表层级结构
我们这里采用两层数据表结构,第一层存放用户基信息,第二层存放用户行为信息。这个根据团队内部的数据接入规范进行调整,只要是统一的结构,对于数据分析师的分析都是有利的。
-
明确数据优先级
根据埋点需求的紧急程度,给每一个埋点任务标上优先级。例如:P0,P1(数字越高,代表优先级越高)
根据上面的六个步骤,将每一个步骤需要记录的字段按照标准格式汇总到文档,即可完成初步的埋点设计。当然完成初版埋点设计之后,还需要与产品、策划、程序一遍一遍过文档内容,不断修改完善,直至三方会谈达成统一意见。
优惠券数据埋点
常见的埋点采集方式
数据埋点常见问题
- 这个数据跟后台差异很大,数据不准导致这种情况的原因会相对复杂-些,以下是常见原因,主要与数据的采集和统计定义较为相关:
- 统计口径定义不一样
- 埋点定义不一样
- 采集方式带来的误差
- 想用的时候,发现没有我想要的数据:
- 没有提数据采集需求
- 埋点不正确、不完整
- 事件太多,不知道什么意思,用起来很麻烦
- 埋点设计的方式
- 埋点更新迭代的规则和维护
- 想分析一个问题,但是不知道应该看哪个数据、哪些指标
- 数据定义不清楚
- 缺乏分析思路
事件埋点
- who:id识别
- when:时间戳
- what:是什么
- where:位置环境场景
- how:维度特征
案例-1:如何描述APP首页浏览这个行为呢?
WHO:即参与这个事件的用户是谁。用户进入一个功能页面,我们要知道进来的用户是谁,并且同一个用户以不同身 份状态在不同的端操作时,都能是识别出来就是同一个人,一套合适且完备的ID-mapping解决方案,对于提高用户行为 分析的准确性、完整性有非常大的影响,对用户数量的统计、以及漏斗、留存、路径等期望用户行为流相关的分析尤其明显。同一用户的识别出现断层,会导致以上分析数据不准确或不可用。因此,我们在进行任何数据接入之前,都应当先确定如 何来标识用户。
WHEN:即这个事件发生的时间,神策分析通过自动采集的时间戳属性来记录。
WHAT:描述了一个事件具体是什么,这里就是神策事件设计模型的一个独特的地方。在这里场景下,按照神策的事件设计规范,事件是“APP页面浏览”,而不是“首页的浏览”,通过增加『页面名称』这个属性来区分究竟浏览的是哪个具体的页面。
HOW:即用户从事这个事件的方式,HOW关联的是与事件强相关的属性内容。这是企业在事 件梳理过程中非常容易出 纰漏的地方。比如在APP页面浏览或者APP的点击事件上,经常会出 现找不到按钮,或者无法定位页面的情况,原因就是研发的规范性较差,比如对页面标题的定 义不规范等。
WHERE:IP、国家、省、市区等用户的操作属性,神策分析都是会在基础信息采集上做加工衍生,可以做到自动采集。端口、应用版本、操作系统、操作系统版本、设备制造商、设备型号、屏幕高度、屏幕宽度这些前端维度与属性,神策分析的采集也是默认获取的。
案例-2:描述客户支付订单
首先,订单的流水会有一个唯一标识,类似前面APP页面浏览中的『页面名称』,是订单的唯一标识,这是必须要进行采集的,否则无法与后台数据进行匹配,因为后台的数据通常唯一标识是按照订单的流水号。
针对支付订单事件,强关联的属性也会在HOW中,比如支付金额、支付方式(信用卡or储蓄卡or微信等)、所属银行、是否成功。“是否成功”是一个非常典型的属性,我们判断用户“是否支付成功”,其触发机制必须等到前端拿到后端服务 器处理结果后,再进行上报。如果我们希望了解的是,“用户是否有意愿支付”,那么当用户点击“支付订单”这个按钮时,进行前端采集即可,这部分在接下来的内容还会做重点介绍。
这个例子中的“是否成功”属性也再次提醒我们:事件采集显然是要与用户的分析诉求强相关的。在同一个事件中,对其业务属性的价值定义和分析应用的场景,与技术端去做采集的触发时机是强相关的。这需要对接人有特别清晰的定义,才能保证埋点的正确性。
指标体系
数据指标体系是把数据指标系统地组织起来,可以按照功能模块、业务模块,以及其他一些划分的方法组织起来。
电商数据分析基本指标体系:总体运营指标,网站流量指标,销售转化指标,客户价值指标,商品类指标,市场营销活动指标,风控类指标,市场竞争指标。
电商平台的用户运营指标体系(海盗模型AARRR)
- A-拉新
- 渠道UV
- 渠道曝光
- 渠道点击
- 渠道落地页浏览次数/浏览人数/跳出率
- 单位获客成本
- A-激活
- UV
- app整体停留时长
- app启动次数
- 注册人数/转化率
- 曝光/点击
- 商品/运营位曝光次数/用户数
- 商品/运营位点击次数/用户数
- 商品/运营位渗透率(CTR)
- 浏览
- 浏览深度(用户进入app后浏览的页面数,体现用户对app的兴趣程度)
- 浏览某页面(例如商详页)次数/用户数
- 浏览某页面(例如商详页)次均/人均时长
- 互动
- 收藏商品次数/用户数/渗透率=收藏商品人数/商详页浏览人数
- 搜索次数/用户数/成功率
- R-留存
- app留存率:某一天启动app的用户在n天后仍然启动app的比例(次日留/3日留/7日留/30日留)
- 复购率:某一天支付订单的用户在n天后仍然支付订单的比例(次日留/3日留/7日留/30日留)
- R-转化
- 支付订单次数/人数
- 支付订单转化率
- 客单价
- R-分享/传播
- 分享商品详情页/其他页面次数/用户数/渗透率=分享人数/浏览页面的人数
- 裂变k系数:平均一个活跃用户会分享给多少个潜在用户
指标体系的五大作用:监控现状,预测趋势,评估分析,决策支持,反映问题。
读懂指标
- 理解指标的含义
指标口径:针对某一指标达成一致的统计逻辑,可减少无效讨论带来的分歧。
- 知晓指标的分级:一级指标和二级指标
- 看懂指标的波动:正常波动和异常波动
- 正常波动:任何指标都会受到一些客观因素影响出现一些波动,会对应合理波动范围,称为阈值。
- 异常波动:超过了阈值的波动都称为异常波动。
- 如何解读指标的异常波动
- 通过同环比来确认波动值(比昨天高?比上周、上月、去年同期高?高多少?)
- 通过拆解寻找原因(订单量=下单人数*人均订单量;下单人数=老客+新客)
常见指标体系
-
OSM模型
OSM是object(目标),strategy(策略),measure(度量),理解业务目标是OSM模型的核心;制定行动策略是实现业务目标的手段,度量是策略的支撑和监控
O:业务目标:业务目标需要和负责的业务方达成一致,了解业务方的核心目标是什么,比如,是为了提升用户数、用户时长、用户付费数、用户金额等。保证业务目标符合DUMB原则。(D:切实可行,U:易于理解,M:可干预、可管理,B:正向的,有益的)
S:业务策略:在清楚业务目标以后,为了达到上述目标,需要采取相应的业务策略,比如,为了提升新用户数,采取的对应策略就是加大 外部渠道的投放,包括在抖音等投放广告。
M:业务度量:用于衡量评估策略是否有效果,反映目标的完成情况。OSM模型的数据指标框架可以把目标和最终 评估的数据体系连接起来,做到第一个指标的设定都知道是为了评估哪一个具体业务的策略效果,每一个业务的策略效果是怎么为总体目标服务的。
电商线上活动:电商企业经常举行线上活动,最终目的是希望通过活动产生最终销售。
| 目标 | 策略 | 度量 |
|---|---|---|
| 提升活动GMV | 提升活动流量、 提升活动页流量分发效率、 活动商品运营 | 活动浏览人数/时长/ 退出率\活动入口流量不同坑位商品 点击率/加购买/订单量、活动带来的GMV, 活动商品的点击率/加购/订单量 |
OSM模型的适用场景:有明确目标的场景,复盘场景
- UJM模型
UJM(User Journey Map用户旅程地图)模型指的是用户在APP中的操作路径。简单来说,就是通过拆分用户使用产品的阶段性行为,从中挖掘用户的需求,从而在每个阶段确定能够提升的指标。
UJM模型是为了梳理用户的行为旅程地图,因为数据指标体系是与用户行为直接相关的,完整科学地梳理好用户的整个行为旅程,才可以在每一个环节设计相对应的指标。
以电商平台为例,用户购买一个商品的完整的UMJ如下:打开APP-->搜索/浏览商品-->查看详情-->加入购物车-->支付
利用UJM搭建体系。
OSM和UJM是可以相互验证的模型,可以结合使用,
-
AARRR模型 AARRR模型(海盗模型)主要从5个方面完整刻画一个app,包括用户获取、用户活跃、用户留存、用户变现、用户推荐。可以保证指标体系的完整性和科学性。
- 用户获取:用户从不同渠道来到你的产品
- 用户活跃:用户在你的产品上完成了一个核心任务
- 用户留存:用户回来继续不断的使用你的产品
- 获取收益:用户在你的产品上发生了可使你收益的行为
- 推荐传播:用户通过你的产品,推荐引导他人来使用你的产品
-
MECE分析方法
MECE分析法是逻辑分析领域应用得最为重要的方法。中文意思是相互独立,完全穷尽。对于一个议题,能够做到分类不重叠、不遗漏。
MECE方法展开:1、确认问题是什么。2、寻找切入点就是分析问题和目的,想得到哪方面的结论,就从哪里作为切入点。
如何提高未来一年内的利润
利润=收入-成本; 收入:【如何提高销量,如何改变定价】,成本:【如何降低固定成本(厂房租金、设备折旧),如何降低变动成本(原材料费、人工成本、水电燃气)】
-
北极星指标 北极星指标也叫唯一关键指标(OMTM),产品现阶段最关键的指标。
6个标准筛选是否是合适的北极星指标:
-
能够反映用户从产品获得核心价值
-
能否为产品达到长期商业目标奠定基础
-
能否反应用户活跃程度
-
指标变好,能否预示公司在往好的方向发展
-
是否简单,直观,容易获得,可拆解
-
是否是先导指标,而非滞后指标 假设 分解 验证 指标
-
企业内部搭建数据指标体系流程
流程:需求提出--指标规划--数据采集--指标计算--搭建报表
具体事项:归纳需求--制定OSM+梳理UJM--埋点梳理+埋点开+埋点测试--口径确认+指标计算--可视化
电商常见指标体系
从人货场三个维度
- 有关人的指标
- 客服(询单量、询单转化率、平均接待时长、DSR评分)
- 用户
- 流量(免费流量/付费流量、UV、PV、流量深度=PV/UV、停留时长、ROI、来源转化率、跳失率)
- 成效用户(新用户数/老用户数、活跃用户数/沉睡用户数、复购率、客单价、连带率、RFM)
- 有关货的指标
- 进货(品类采销比/价格带采销比/尺码采销比、深度:平均每款备货数量、宽度:平均每款SKU数、广度:备货品类数、备货SKU数)
- 库存(周转率/天数、库存金额、库存数量、库存结构【年份/品类/价格带】、有效库存比、可销天数)
- 销售(销售结构【品类/价格带/折扣带】、畅滞销、动销率、售罄率)
- 售后(退货率【整体/单款】)
- 有关场的指标
- 页面(流量路径、热力图、停留时长、跳失率;页面陈列:屏效)
- 促销(促销宣传度、品牌参活率、促销力度、可控因素:优惠券、流量、加购商品监控、老客户激活、促销爆发度、促销衰减度)
- 销售(销售预测:增长率、权重指数;销售分析:销售额、销售量、订单量、客单价、连带率、成交转化率、业绩达标率、业绩增长率、毛利率)
电商八类基本指标
- 总体运营指标:从流量、订单、总体销售业绩、整体指标进行把控,起码对运营的电商平台有个大致了解,到底运营的怎么样,是亏是赚。
- 流量类指标【独立访客数UV,页面访客数PV,人均页面访问数】
- 订单产生效率指标【总订单数量,访问到下单转化率】
- 总体销售业绩指标【成交金额GMV,销售金额,客单价】
- 整体指标【销售毛利,毛利率】
- 网站流量指标:即对访问你网站的访客进行分析,基于这些数据可以对页面进行改进,以及对访客的行为进行分析等待。
- 流量规模类指标【独立访客数UV,页面访客数PV】
- 流量成本类指标【访客获取成本】
- 流量质量类指标【跳出率,页面访问时长,人均页面访问数】
- 会员类指标【注册会员数,活跃会员数,活跃会员率,会员复购率,会员平均购买次数,会员回购率,会员留存率】
- 销售转化指标:分析从下单到支付整个过程的数据,帮助你提升商品转化率。也可以对一些频繁异常的数据展开分析。
- 购物车类指标【加入购物车次数,加入购物车买家次数,加入购物车商品数,购物车支付转化率】
- 下单类指标【下单笔数,下单金额,下单买家数,浏览下单转化率】
- 交易类指标【交易成功订单数,交易成功金额,交易成功买家数,交易成功商品数,交易失败订单数,交易失败订单金额,交易失败订单买家数,交易失败商品数,退款总订单量,退款金额,退款率】
- 支付类指标【支付金额,支付买家数,支付商品数,浏览-支付买家转换率,下单-支付金额转化率,下单-支付买家数转换率,下单-支付时长】
- 客户价值指标:这里主要就是分析客户的价值,可以建立RFM价值模型,找出那些有价值的客户,精准营销等待。
- 客户指标【累积购买客户数,客单价】
- 新客户指标【新客户数量,新客户获取成本,新客户单价】
- 老客户指标【消费频率,最近一次购买时间,消费金额,重复购买次数】
- 商品类指标:主要分析商品的种类,哪些商品卖得好,库存情况,以及可以建立关联模型,分析哪些商品同时销售的几率比较高,而进行捆绑销售。
- 产品总数指标【SKU数,SPU数,在线SPU数】
- 产品优势性指标【独家产品收入比重】
- 品牌存量【品牌数,在线品牌数】
- 上架【上架商品SKU数,上架商品SPU数,上架在线SPU数,上架商品数,上架在线商品数】
- 首发【首次上架商品数,首次上架在线商品数】
- 市场营销活动指标:主要监控某次活动给电商网站带来的效果,以及监控广告的投放指标。
- 市场营销活动指标【新增访问人数,新增注册人数,总访问次数,订单数量,下单抓换率,ROI投资回报率】
- 广告投放指标【新增访客数,新增注册人数,总访问次数,订单数量,UV订单转化率,广告投资回报率】
- 风控类指标:分析专家评论,以及投诉情况,发现问题,改正问题。
- 买家评价指标【买家评价数,买家评价卖家数,买家评价上传图片数,买家评价率,买家好评率,买家差评率】
- 投诉类指标【发起投诉(申诉)数,投诉率,撤销投诉(申诉)数】
- 市场竞争指标:主要分析市场份额以及网站排名,进一步进行调整。
- 市场份额相关【市场占有率,市场扩大率,用户份额】
- 网站排名【交易额排名,流量排名】