基于SLS中台的数据分析实战：带你玩转埋点数据-阿里云开发者社区

增长关乎产品的存亡

增长！增长！增长！业务增长是每一个创业者每天面临的最大问题。无论你的产品是APP，还是web，或者是小程序，只能不断的维持用户的增长，才能向资本市场讲出一个好故事，融资活下去。活到最后的产品，才有机会盈利。

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

1. 运营活动，覆盖了多少用户？
1. 多少用户，开始使用产品？
1. 多少用户付费？
1. 多少用户持续的活跃？
1. 下一步，我们应该把精力放在哪些方面？是持续运营？还是开发新功能？

如果不能回答这些问题，无疑我们的运营活动或者开发就是盲人摸象，完全靠运气。为了解答这些问题，我们不妨关注一下growth hacking这种数据驱动的手段。

（快速增长只是冰山一角，冰山之下是各个需要优化的细节。）

改变思维行为、拥抱GrowthHack

“增长黑客”是一个跨越营销漏斗、产品开发、销售部门和业务其他领域的快速试验过程，以确定最有效的方式来发展业务。增长黑客团队由市场营销人员、开发人员、工程师和产品经理组成，他们专门致力于建立和吸引企业的用户群。

一种通过创造性的方法、科学的数据分析工具，可以用极低的费用在短时间内吸引数以百万计的用户的增长方法。

1. 转化率思维

转化率思维指的是将一件事情看作触达量与转化率之乘积。一个广告触达到100w人，最终1w人做出了购买决定，这个过程转化率就是1%，100w×1%=1w。这种思维方式告诉大家

1. 很多事情都要敢于尝试，说不定有人愿意买账
1. 永远不要去用自己的想法推测大众，因为你的想法不能代表全部
1. 不要希望让所有人满意，而要考虑让尽量多的人满意

2. 定量化思维

GH离不开定量化思维。GH的基本任务是回答以下几个问题：

1. 我的这项做法，能够让目标量增长百分之多少？
1. 我执行过的做法，已经让目标量增长了百分之多少？

在GH中采取的不同的措施该如何评价，则是完全取决于这些措施所带来的目标量改变的比较。在GH中，只有定量化思考的对象，才能获得提高。

3. 迭代化操作方式

迭代化的方式就是上面提到过的“小步快跑，知错就改”。

1. 小步快跑指每次尝试的改变都是很小的改变，小到措辞，排版，颜色等等细节。如果一次计划中需要做出大规模的改变，则最好把这种大改变划分成诸多小步骤来做
1. 知错就该，指的是获取反馈的思想。每次尝试小改变之后，都要敏锐的捕捉这次改变带来的定量效果，如果目标量得到提高，则保留这种改变，甚至加强这种改变；否则就要抛弃这种改变。其实这种做法很像自然界生物进化的过程，每次突变都是极小的改变，改变之后受到优胜劣汰的筛选，将优秀的改变保留。

采集哪些数据？

所谓埋点就是在应用中特定的流程收集一些信息，用来跟踪应用使用的状况，后续用来进一步优化产品或是提供运营的数据支撑，包括

• 访问数（Visits）
• 访客数（Visitor）
• 停留时长（Time On Site）
• 页面浏览数（Page Views）
• 跳出率（Bounce Rate）
• 渠道导流质量（网页/网站跳转、搜索跳转、扫码进入等）

这样的信息收集可以大致分为两种：

• 页面统计（track this virtual page view）
• 统计操作行为（track this button by an event）

device.first_time:  1597393921
device.height:  1098
device.id:  ffffffffffffffffffffffffffff0b38
device.language:  CN
device.width:  720
event.type:  ScanQrCode
ip:  100.68.107.134
os.platform:  Android
os.user_agent:  Mozilla/5.0 (iPhone 4; CPU iPhone OS 7_0 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 MQQBrowser/7.5.1 Mobile/11A465 Safari/8536.25 MttCustomUA/2 QBWebViewType/1
referer:  http://www.host8.com/def
referer.type:  
session.id:  ffffffffffffffffffffffffffff0b383
session.start_time:  1597393921
site.host:  www.aliyun.com
site.title:  日志服务文档中心
site.url:  http://www.aliyun.com/page_2
uid:  985912

GrowthHacking运营大盘

1. 数字化北极星指标

• 先明确我们的北极星指标

“North Star Metric” 北极星指标，又叫做“OMTM” One metric that matters, 唯一重要的指标。

之所以叫北极星指标，是因为这个指标一旦确立，就像北极星一样，高高闪耀在天空中，指引着全公司上上下下，向着同一个方向迈进。
明确我们当前的现状是什么？每周的AU是多少？每天的UV是多少？同前一天的比较？同前一周的比较？

在上面的描述数据中，我们可以较为方便的使用SLS计算出对应的指标
• 通过下面的SQL和刻度盘的配合使用我们可以得到WAU的计算结果

* | 
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 
          approx_distinct(uid) as uv 
        from 
          log
      )
  )

同理，本周AU和上周AU之间的对比图可以通过调整数据观测的时间范围就可以实现了
• 我们也要关注下最近两个月，每天的DAU的变化

* | 
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这个维度进行展开，去分析下，相邻两周的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 
      t
  )

2. 留存分析

留存的重要时点：

1.0 次日留存
2.0 周期(一个完整的使用周期)留存

留存指标重要的核心原因

1.0 拉新、渠道的优化等：也许会提高一定的留存率。
2.0 产品功能设计能否满足客户的核心需求：上一步的留存到底能不能留下来。
3.0 产品设计更好的、更快的、更方便地满足客户的核心需求。

• 七日留存率的计算

* | 
select 
  date_format(x.day, '%Y-%m-%d') as "日期", 
  x.regist_num as "新用户数", 
  round(y.day2 * 100.0 / x.regist_num, 1) as "次日留存", 
  round(y.day3 * 100.0 / x.regist_num, 1) as "3日留存", 
  round(y.day5 * 100.0 / x.regist_num, 1) as "5日留存", 
  round(y.day7 * 100.0 / x.regist_num, 1) as "7日留存" 
from 
  (
    select 
      date_trunc('day', __time__) as day, 
      count(DISTINCT uid) as regist_num 
    from log 
    group by day 
    order by day desc
  ) x 
  join (
    select 
      a.day as day, 
      count_if(
        date_diff('day', a.day, b.day)= 1
      ) as day2, 
      count_if(
        date_diff('day', a.day, b.day)= 2
      ) as day3, 
      count_if(
        date_diff('day', a.day, b.day)= 4
      ) as day5, 
      count_if(
        date_diff('day', a.day, b.day)= 6
      ) as day7 
    from 
      (
        select 
          uid, 
          date_trunc('day', __time__) as day 
        from log 
        group by day, uid
      ) a 
      join (
        select 
          uid, 
          date_trunc('day', __time__) as day 
        from log 
        group by day, uid
      ) b on a.uid = b.uid 
      and (
        date_diff('day', a.day, b.day) = 1 
        or date_diff('day', a.day, b.day) = 2 
        or date_diff('day', a.day, b.day) = 4 
        or date_diff('day', a.day, b.day) = 6
      ) 
    group by day 
    order by day
  ) y on x.day = y.day 
order by y.day

• 留存率曲线的计算

* | 
select 
  days, 
  counts, 
  round(
    counts * 100.0 /(
      min_by(counts, days) over()
    ), 
    2
  ) as "留存率%" 
from 
  (
    select 
      date_diff('day', a.day, b.day) as days, 
      count(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', __time__) as day 
                from log 
                group by day, uid
              )
          ) 
        where 
          day = m
      ) a on a.uid = b.uid 
      and (
        date_diff('day', a.day, b.day) >= 0 
        and date_diff('day', a.day, b.day) <= 7
      ) 
    group by days 
    order by days
  )

• 不同省份留存率曲线的计算

* | 
select 
  province, 
  days, 
  counts, 
  round(
    counts * 100.0 /(
      min_by(counts, days) over()
    ), 
    2
  ) as "留存率%" 
from 
  (
    select 
      province, 
      date_diff('day', a.day, b.day) as days, 
      count(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 
                  ip_to_province(ip) as province, 
                  uid, 
                  date_trunc('day', __time__) as day 
                from log 
                group by province, day, uid
              )
          ) 
        where 
          day = m
      ) a on a.uid = b.uid 
      and (
        date_diff('day', a.day, b.day) >= 0 
        and date_diff('day', a.day, b.day) <= 7
      ) 
    group by days, province 
    order by days
  ) limit 10000

3. 漏斗分析

漏斗分析是一套流程式数据分析，它能够科学反映用户行为状态以及从起点到终点各阶段用户转化率情况的重要分析模型。漏斗分析模型已经广泛应用于流量监控、产品目标转化等日常数据运营与数据分析的工作中。

例如在一款产品服务平台中，直播用户从激活APP开始到花费，一般的用户购物路径为激活APP、注册账号、进入直播间、互动行为、礼物花费五大阶段，漏斗能够展现出各个阶段的转化率，通过漏斗各环节相关数据的比较,能够直观地发现和说明问题所在，从而找到优化方向。

(
  os.platform : iOS 
  or os.platform :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.target : button_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_17,button_16,button_15,button_14,button_13,button_12,button_11', 
    "event.target"
  )