课时5:运营增长实战 | 学习笔记

开发者学堂课程【DevOps 日志分析实战：课时5:运营增长实战】学习笔记，与课程紧密联系，让用户快速学习知识。

课程地址：https://developer.aliyun.com/learning/course/302/detail/3522

课时5:运营增长实战

内容介绍：

一、 运营增长的介绍

二、 SLS 在埋点场景下的产品能力介绍

三、 模拟埋点数据的分析及可视化

一、 运营增长的介绍

1. 数字化运营

（1） 为了获取用户的增长，可以投放广告，内容营销、社交传播、地推销售，或者持续的专注于产品优化。无论哪一种方式，我们都面临这几个问题:

运营活动，覆盖了多少用户?

多少用户，开始使用产品?我们的获客成本是多少?

多少用户付费?

多少用户持续的活跃?

这张图就比较形象的展现出来，当我们没有在做数字化的时候，我们在任何一个阶段都有可能流失到我们的用户，通过很大的力气跟传播获得了第一笔用户，也许在注册的时候就有一半的用户流失掉了，剩下的一半用户在真正使用产品的过程中，可能会有各种各样的问题，如果这些问题不能被运营知道和反馈的话，可能也会有大部分用户流失掉，那么，还有一些我们朝夕相处的客户，突然之间，由于我们某一次的改版升级，导致这些用户使用习惯发生了较大的变化，那么这些用户也有可能流失掉，综上所述:

我们应该把精力放在哪些方面?是持续运营?还是开发新功能?

在这种有限的人力资源情况下，以及有限的活动运营经费情况下，我们应该把经费投放在哪里？才能让我们的产品更好的在市场中占有一席之地，那么早在像硅谷巨头 facebook 等等，在成立初期是很少具有大量的推广成本，他们很巧妙的借助了一些公开渠道，包括学校 和社会上一些年轻人主导的地方，他们在这些地方通过宣传、策略，可以获得第一批用户，他们获得了这批宝贵的用户之后，有这些改进的数据，通过指标和方法，去量化不同阶段、不同产品的环节对用户使用的影响，从而快速的迭代、逐步的改进，可以形成这样一个正向的循环。

（2） 目标：业务上的主要目标，例如: DAU、GMV 等现阶段最核

的商业诉求

目标可以理解为，在现阶段最核心的商业诉求比如说像一个社交媒体的 APP 或者像新闻频道的 dau 还有就是电商交易型的更加关注自己的 grb

策略：达成目标的主要策略，例如:为了提高 GMV，可以提高订单量。

这理论是针对上述的目标定制相关的一些一些手段，比如说我们为了提高整体gmv可以提高近一段时间，可以让更多人下单，提高我们的单量，还有就是提高我们的客单价，可以让用户买更多的产品，我们可以做一些活动，相对于dau这种指标，我们要怎么做策略，可以通过发新，让更多的新用户来尝试注册体验，从而可以找到我们系统中看到的沉睡客户、僵尸客户，我们要有一些功能能够匹配到这些用户，让这些客户回来使用我们的产品，从而提高 dau。

指标：对应上述不同策略，影响用户各行为阶段的关键指标

指标就是为了顺承上面这些策略，我们要在用户的使用我们产品行为的各个阶段，做一些量化我们产品的指标辅助我们分析我们在哪一个环节、在哪一个阶段能够比较准确的有的放矢，将有效的人力、物力、财力投入进去，达到一个最好的效果。

在核心业务流程中，对于新用户，我们更加关注的是注册以及登录指标，当一个用户激活的时候，那么会有一些关键流程转化率，比如说针对电商而言，他们是不是需要下第一单、是不是需要绑银行卡、是不是要绑定一些支付宝，那么对于一个成熟用户而言，我们更加关心他的一些核心页面，比如说付款下单的一些核心页面指标是否正常，是否由于我们某一次改版影响这个用户使用。

（3) 指标拆解

访问数(Visits)

访客数(Visitor)

停留时长(Time On Site)

页面浏览数(PageViews)

跳出率(Bounce Rate)

页面统计(trackthis virtual page view)

统计操作行为(trackthis button by an event)

做指标的拆解可以举一个具体的例子，比如像一个系统类的 APP，它的核心指标更加倾向于产品的规模，市场的运营和商业效果，那么产品规模的领域更加关注活跃的用户总数以及每天新增或者下载的用户数，对于市场运营而言，更加关注活跃用户比例以及这批活跃用户，他们最早注册时对于哪一个渠道是自然流量，还是我们买的a渠道到b渠道，还是通过其他的一些 APP 帮我们下载推广，还是说其他的。还有一个指标就是留存率，用户使用一次就走了，或者用户使用了之后就一直在使用我们产品黏性而言，这个指标是很重要的，还有就是商业效果，商业效果就是日均流水以及客单价和订单转化率有多少，客户下单了，但是并没有走到付款这一步我们要考虑到是涉及的问题，还是支付方式的问题。

针对于核心指标，我们还有一些延伸指标，这些延伸指标大部分会分不在跳转环节或者交互环节，更多的是在注册点上，我们要知道，注册模型即漏斗模型在注册方面的转化情况。以及我们的流程，比如说用户在使用哪个功能，之后不用了或者说使用了哪个功能之后就一直在用，那么我们要通过分析，日留存周留存月留存，以及每一个页面，甚至是每一类操作，她最后的留存情况，还有就是浏览的指标浏览指标里面最核心的就是浏览，浏览数量，以及浏览的平均时长，对于新闻类的app，对于用户的评论收藏分享，等等，基于这些指标，我们可以和好的，去量化用户为平台上使用的的一些状况，从而被我们的产品设计或者用户研发，产品体验等提供一些比较好的指导。

二、 SLS 在埋点场景下的产品能力介绍

1. 让用户专注在“分析”上，远离琐碎的工作

(1) 数据实时采集 LogHub

40+渠道

公网加速

断点续传

数据加工

免维护、低成本

(2) 数据加工 Transformation

开箱即用，免运维

开放灵活，无需写代码

稳定可靠

(3) 智能查询分析 Search/Analytics

SQL92语法

秒级分析亿级

所见即所得

AI、预测与告警

(4) 数据分发 LogShipper/LogHub

免维护/免费

生态丰富

使用简单

可靠：双十一、金融级考验

稳定：百万机器运行保证

无运维负担：0负担，0预留成本

迭代快：与阿里使用同一套产品

日志的四大部分，在埋点层面上而言，更多的是数据怎么来的，我们的客户端怎么来的，我们的客户端怎么来到我们的服务端。那么，有没有简单便捷的方法让我们使得数据可以快速的传回来？

这边提供了四种数据接入渠道，所有这些端、埋点的数据，可能都是非结构化的对于这种非结构化的数据，我们怎么样才能更好的转换成结构化数据？便于我们市场人员进行一些分析，那么这个时候，我们提供了开箱即用免运维的数据方案，这种方案有一个最大的好处就是用户只需要关注自己的业务逻辑，将你的拆分规则，分发规则以及复化规则写好就行，其他的我们会帮你们做一些托管式的运维。数据加工好之后，最后就要进行智能分析，包括留存率的分析，漏斗模型的相关分析，那么，我们这边提供了标准的 SQL92的方法，可以大大的简化用户分析的门槛，同时，我们也针对亿级别的数据提供秒级返回分析结果，同时，还有大约7、80种图表可以让用户展示自己的分析结果，同时把这些分析结果放在大盘里面，可以在各个维度展示分析结果，最后的时候会给大家做一次介绍。

2. 日志服务(SLS)-产品功能

（1） 数据实时采集

阿里日志平台，稳定可靠

40+数据接入手段

全球20+Region/全球加速网络

多协议+开源软件支持

在采集阶段的话，大致分为这么几类，比较相关的是服务器应用数据，在这一类里面，可能大多用户会去接一些访问日志，包括一些程序比较大的日志，比如说什么时间点某一个用户走了某一个接口，以及他的状态是什么。还有就是互联网设备，比如说教学机，游戏机，还有一些早教的伴读机，这个里面可能会有很多影响用户体验的点，比如说软件崩溃或者某一个界面卡顿，甚至是联网的网络性能不好，那么这些点其实在用户的里测，很难让服务端知道，这个时候就需要将 SDK 集成到互联网设备端然后把数据返回到服务端，能够让研发工具和运营做一些更好的改进。

（2）查询分析

大规模，免运维，低成本

极致速度，十亿数据秒级返回

SQL92完整语法支持

多种可视化平台兼容

在这个里面，我们提供了上百种 SQL 的算子，可以比较好的帮助用户分析一些指标，还有一些高风险的，或者有欺诈行为的 IP 以及手机号码的相关查询，以及是否是黑厂之类的查询，多数对于很多数据而言，大多数是一个 UIl，我们有非常丰富的 uil 解析转换编码的一些函数接口，通常对于业务指标可以提供一些预测的方法，让用户可以在现在就去关注到，比如说未来一周或者一个月的发展趋势，同时可以把相关的结果存到 dashboard 的里面做一些订阅，以及一些可视化的工作。

3. 不同埋点之间的差异

（1） 代码埋点

在某个空间操作发生时通过预先写好的代码来发数据

（2） 可视化埋点

通过可视化界面配置控件操作与事件发生关系的埋点方案

（3）全埋点

也叫无埋点，用户展现界面元素时，通过控件绑定触发事件，事件被触发时系统会有相应的接口让开发者处理这些行为

埋点大概分为三到四类，比较常见的是代码埋点，代码埋点就是在某个空间操作发生时，通过预先写好的代码将数据采集上来，同时发送到服务端。可视化埋点就是通过一些可视化的界面配置，将组件跟事件做一些关联，然后将结果记录到某一个文件里面。全埋点也叫做无埋点，用户在展示界面时，通过绑定事件，事件发生的时候会把数据推发出去，相关的研发同学就会有一些接口，让这些推发的数据可以接过来做一些后续的处理，丢掉的话也是可以的。

下面这个表格就是比较各个端埋点的优点和缺点，比较关注的就是部署的周期以及部署的复杂程度，像代码埋点及服务端埋点都会涉及到版本，比如说某一个代码会想多两个字端，那么一定是要把这个东西写到代码里面去，然后重新发布升级之后才能支持这两个字端对数据的采集，其实服务端也是一样，也会经过一些配置的更新，然后把相关的字端采集上来。可视化埋点稍微简单一点，比如说你托托拽拽就可以把这个相关的东西推到服务上去。是否需要技术人员参与，这个里面大多数情况下都是需要研发同学去对接各个埋点的数据，然后将数据集成到现有的产品中去，然后把数据采集回来。对于数据量而言一般的话，像代码埋点以及服务端埋点数据都是可控的，需要多少都是可以根据自己的需求来定制。

三、 模拟埋点数据的分析及可视化

我们这边是一个实际的场景为例来进行展开这个场景，就是通过各个渠道，包括搜索引擎，广告跳转，然后以及用户主动搜索，还有 uil 之间的请求，还有爬虫之间的相关点他们会定期的来访问我们，阿里云服务的一些相关请求那么，这些请求大致包含以下几类信息:1.设备信息，设备信息主要描述当前设备的状态，甚至包含你的设备的唯一 ID，当前访问的一些网络状态。2.事件信息，事件信息就是访问网站页面的时候，你可能是通过哪个地方来的，又去了哪个地方，然后你当前的时间节点怎么样。

1. 设备指示列表    

页面事件埋点    

我们可以看一下具体的埋点日志长什么样子。这个数据就是我们通过 mock 出来的一条请求，这条请求我们就可以看到，是一个安卓的设备然后通过扫码的形式访问到了我们的某一个网站，访问了配置-2, uid 是985912，对于这样一个场景，我们要先确认一下它对应的每一个北极星指标是什么，以及后续我们要针对哪些指标要进行留存分析、漏斗分析、事件分析。

模拟埋点日志

device.first time: 1597393921

deviceheight: 1098

device.id:ffffffffffffff ffffffffff0b38

device.language:CN

device.width:720

event.type: ScanQrCode

ip: 100.68.107.134

os.platform: Android

os.user agent: Mozilla/5.0(iPhone 4CPUiPhone OS 7 0 like Mac OS X) AppleWebKit/537.51.1(KHTMLlikeGecko)Version/7.0MQQBrowser/7.5

1 Mobile/11A465 Safari/8536.25MttCustomUA/2QBWebViewType/1

referer:http://www.host8.com/def

referer.type:

session.id:ffffffffffffffffffffffffffffob383

session.starttime: 1597393921

site.host:www.aliyun.com

site.title:日志服务文档中心

site.url:ttp://www.aliyun.com/page2

uid: 985912

2. 分析指标

北极星指标确立

留存分析

漏斗分析

事件分析

“North Star Metric"北极星指标，又叫做“OMTM"One metric that matters,唯一重要的指标。之所以叫北极星指标，是因为这个指标一旦确立，就像北极星一样，高高闪耀在天空中，指引着全公司上上下下，向着同一个方向迈进。

北极星指标简单意义上讲，就是说让我们这个网站 DAU 到年底的时候能达到一个亿，目前可以看到我们的天 AU 在100000GB，周 AU 在500000GB，这就是当前的状态。现在所有的分析其实都是围绕现状展开的，看看在哪一个层面上能够更好的帮助产品在各个环节上可以优化，进而能够帮助我们达到或者提高 DAU。

3. 北极星指标构建

核心指标和环比指标

上面这张图配置的是报表的图，背后就是这样一条 SQL，通过一个子查询的形式，对这一周 ub 的情况进行分析。下面这张图是天级别的，这一天跟前一天 uv 的比较情况，这个里面涉及到 compare 函数，这个函数是说我当前的某一个观测指标在间隔这么多秒之前的状态是多少。数组可以拆分至如下结构。

*

select

uv，

1000000.0 as total

from

（

select

approx_distinct(uid)as uv

from

log

）

|

select

diff[1],

diff[2],

round(diff[3]*100-100,2)

from

(

select

compare(uv,86400) as diff

from

(

select

approxdistinct(uid)as uv

from

log

)

)

4. 整体趋势分析

近两个月 UV 趋势变化

把某一天的指标经过时间维度去做一个聚合。然后做一次可视化

|

select

date format(t,'%Y-%m-%d') as t

uv

from

（

select

date_trunc(day，time_)as t,

approx_distinct(uid) as uv

from

log

group by

t

order by

t

）

limit 10000

两周 DAU 增长情况

select

from_unixtime(diff[4]).

coalesce(diff[1],0)as"本周" coalesce(diff[2],2)as"上周"， round

coalesce(diff[3],0)* 100- 100,2

)as"增长比例" from

(

select

ts_compare(uv,604800) as diff from

select

date_trunc('day._time__)as t approx_distinct(uid)as uv from log

group by

t

)

group by

蓝色的线表达的是本周每天的 uv 情况，它的值具体对应的是左半轴上。黄色这条线对应的是上一周相同的时间点，就是往前推七天，它的 uv 情况增长比例是说当前这一周减去上一周除以上一周的比例的情况。

5. 留存分析

留存分析里面比较重要的指标就是七日留存分析和留存率曲线，可能还会涉及到不同维度的留存率的曲线。比如说省份，终端，访问配置，以及不同的功能等等。

七日留存率

这个 SQL 主要的点是在我们要拿到每一天的数据来找到对应的 UID， a 表和 b 表要做关联，这个关联就是 uid 维度，同时我们要去做一些拆分，这个拆分其实就是 a 表的 day 减去 b 表的 day，然后按照天来算。我们把这些维度聚合出来，就相当于拿到了一个很长的表，我们当前的某一个用户在某一天他的留存情况。紧接着在外围的 SQL 上可以拉到外围的情况去比较并做聚合。我们拿到在不同时间点以及前两天，前四天，前六天的统计值，在这个里面我们会再搞一层子查询，这个子查询的主要目的是我们拿到天级别的uv数量，按照天级别来做一个聚合之后做排序，做一个表。大体上就可以拿到这样一个表。

select

date_format(x.day,%-%m-%d)as日期"，

x.regist num as"新用户数，

round(y.day2*100.0/x.registnum1)as"次日留存" round(y.day3*100.0/x.registnum1)as"3日留存" round(y.day5*100.0/x.registnum1)as5日留存" round(yday7*100.0/x.registnum1)as7日留存

from

（

select date_truncdaytime)as daycount(DISTINCTuid)as regist_num

from log group by day order by day desc

)x

join(

select

a.day as day,

count if(date _diff('daya.daybday)=1)as day2

count if(date_diff('daya.dayb.day)=2)as day3

count if(date diffdaya.dayb.dav)=4)as day5

count if(date_diff'daya.dayb.day)=6)asday7

from (select uiddate trunc(daytime)as dayfrom log group by dayuid)a

join select uiddate truncdaytime)as dayfrom log group bydayuid)b

on a.uid=b.uidand(

date diff(dayaday,b.day)=1

or date_diffdaya.daybday)=2

or date_diff(daya.daybday)=4

or date_diffdaya.daybday)=6

)

group by day order by day

)yon x.day=y.day

order by y.day

留存率曲线

*|

select

days,

counts,

round(counts*100.0/(min by(countsdays)over0)2)as"留存率% from

（

select

date diff(dayadayb.day)as dayscount(1)as counts

from

（

select uid,date_trunc(day.time_)as day from log group by day, uid

)b

join(

select * from

(

select*min(day)over()as m

from (select uid,date_trunc(day,_timeas day from log group by day,uid)

)

where day=m

)a on a.uid=b.uid and(

date diff(dayadayb.day)>=0

and date diff(daya.daybday)<=7)

group by days order by days

)

不同省份留存率曲线

通过 ip 字段，可以分析不同的ip来自不同的省份，对不同的省份做聚合，就可以知道不同的省份在时间维度上的留存率的曲线。

select

province, days, counts,

round(counts*100.0/(min by(counts,days)over())2)as"留存率% from

(

select province,date diff(day,a.day,bday)as dayscount(1)as counts

from

(

select uid,date truncday，time)as day

from log group by day, uid

)b

join (

select *

from

(

select*,min(day)over()as m

from

(

select

ip_to_province(ip)as provinceuiddate_truncdaytime)as day from log group by province,day,uid

)

)

where day=m

)a on a.uid=b.uid and(

date diff('dayadayb.day)>=0

and date_diff(dayadayb.day)<=7)

group by days, province order by days

)limit 10000

几个高频的算子

ip_to_province

compare date_trunc

date_dif

min_by

max_by

ts compare

6. 漏斗分析

那种分析是一个比较关键的指标，就是从用户最开始接触到我们的产品，到最后用户流失掉，他在每一层的流失率怎么样。我们可以看到最开始的时候可能是百分之百通过几层的转换之后从50%可能降到50%或者0%。

移动端各按钮的漏斗计算

(

os.platform:ioS

or osplatform:Android

)

and event.type:click

and(

event.target:register

or event.target:button_19 or event.target :button 18

or event.target:button_17 or event.target:button_16

or event.target:button_15 or event.target:button_14

or event.targetbutton 13 or event.target:button_12

or event.target:button_11

）|

select

"event.target" as target,

count(1)as click count

group by

target

order by

strpos(

'register,button 19,button 18,button 17button_16button_15button_14,button_13,b utton_12,button_11',

"event.target"

)

我们把数据的链路可以抽象成一系列数据的操作，这个操作是有前后顺序的，比如说从注册从19~18~11结构化的一个顺序，通过相应字段对应的标记在序列中的位置做一次排序和聚合，然后我们就可以拿到所有在不同阶段的数量，因此我们就可以拿到这样一张漏斗图。

7. 事件分析

事件分析里面更多的是浏览事件，不同平台浏览事件。以及不同来源包括社交媒体，搜索引擎以及搜索引擎里面的关键词。

以及我们通过哪些渠道来的是最多的，这是我重点关注的渠道，还有一些注册事件，扫码事件，这些指标都同理。

接下来我们要看一下实际对应的场景。这份数据其实就是上述介绍的数据。

这样就可以把刚刚所有分析的图标放到里面，定义出一个最核心的北极星指标，所有数据服务都要奔着提高我们的指标去，我们会去看每周 uv 情况，同时我们还能知道整体访问数据来源大多是呈现在某一个区域里的，我们也可以通过地图来看。

我们还可以通过分析不同的移动端，包括 PC 端等不同渠道来的这些点击事件对应的漏斗模型，我们可以分析出来在哪个环节是我们用户流失比较大的地方，哪个是比较好的地方，以及我们对应的七日留存率以及留存率的曲线的计算，包含一些浏览事件，注册事件码，事件的分析结果，这样就是一个简单的报表。

现在已经把数据整合到模拟器中，相关的数据可以实时的产生，用户也不用太复杂就可以玩转这个场景。