云派游戏VP 赵天泽:「解决问题」是休闲游戏做数据分析的核心

首页 行业干货 您的位置
有一些朋友经常问起“ TA 系统似乎更倾向于管理中大型的游戏。这套系统对于小游戏,甚至超休闲游戏来说到底有多大的价值呢?”
为了解答这个问题,11 月 21 日“数说变革”城市巡演的第二站《数说变革·走进成都》,特邀了休闲游戏头部厂商的云派游戏成都负责人赵天泽老师来演讲,阐述休闲游戏厂商如何立足数据中台,以迭代自身的项目管理体系。
以下为部分分享逐字稿:
我先简单介绍一下我所负责的云派游戏的概况吧。
云派游戏从2015年做海外开始的一系列产品,迄今为止我们已经在海外的Google商店、App Store中发行了超 200 款休闲游戏产品。我们已有超 5 亿的游戏下载量,千万 DAU 的数据。我们的产品主要发力点在美国、欧洲等地,新兴开拓的市场包括南美洲、印度等地。

section

 

云派游戏与 Google 和 Facebook 不管在广告端还是在变现端都有非常深度的合作。去年我们也拿到了 Google 颁给我们的飞跃大奖,而一同获奖的公司基本都是涉猎于休闲游戏广告变现领域的代表。
介绍完我们出海休闲游戏的背景后,我就介绍一下关于当初

o1

数据分析系统的选型

免费的数据分析工具,它不香吗?
大家肯定或多或少都使用过一些简单的数据分析工具,他们大多数都是免费向开发者开放的。我们最初使用的也是这些免费的工具,它们只需要简单地接入集成 SDK ,就会自动地在你的数据面板上展示出基本的留存、日活、付费等数据。
但当你的产品与项目达到一定的用户规模时,需要去做一些精细化运营时,免费的数据分析工具的问题就会暴露出来。
1. 数据更新不及时
对我们做休闲游戏的项目组来说,项目迭代的周期基本都是以周为单位,甚至更短。我要快速优化、产出我的产品,希望得到市场给我的一些及时反馈。
比如说,我周五发一个版本,就需要周一甚至第二天就能看到我新版本带来的数据反馈。但是对于大多数的数据反馈时间大部分都是 T+1,甚至 T+4 。
免费数据分析平台的及时性是严重丢失的,这是非常大的问题。
2. 分析方式和分析维度受限
那些免费的数据分析工具接入的时候当然非常简单,但是如果你想突破这些报表给你的数据分析思维局限时,你就没有办法做更多的事情
第二个问题其实只是一个表象结果,它深层次的原因是涉及到第三个问题:没有数据主权的“数据孤岛”。
3. 数据孤岛
所有上传到免费游戏数据分析工具的数据都是存在第三方的服务器当中,你没办法做一些数据的开发、定制需求,公司没有产品数据的所有权
除了第三方数据平台展示给你的结果以外,数据本身已经跟你没有任何关系。
云派在那个时间点上还没有到可以自己做数据团队的规模,我们非常依赖于第三方的数据平台,但同时第三方数据平台的数据维度限制,使我们很难利用数据深入地解决我们产品本质上的问题。
因此当我们产品已经有起色时,我们公司所面临的数据矛盾也从“需要一个数据分析平台”变为“需要一个数据中台”。我们当时急需一款优秀的数据中台软件来解决云派的数据痛点。
为什么不选择自建数据分析系统
其实我们最早看了很多云服务商的封装,不是所有人都能够像数数科技的周津老师那样从头去自己搭建一套系统。
包括阿里云、Google 的一些产品,其实也能够解决游戏行业高并发、高时效性的数据分析功能需求。但他们依旧有不少的问题,包括:
section
1. 前期搭建成本高
这个搭建成本不仅仅是资金上的投入,更多是人力上的大量投入,你需要在公司层面找到这样的技术专家,去帮你执行这样的事情。
2018 年的时候云派游戏还只有 30-40 个人,我们更希望把人力精力放在游戏产品上面,我们不可能花大量的成本去搭建这样的一套系统。
2. 分析系统上手难度高
就算我们把分析系统搭建出来了,最基本的技能就是需要会写 SQL 。但是大多数做产品的人就算掌握了 SQL 的编程能力,也不会花太多的时间在数据分析系统的操作上。所以在公司层面你必须得有专门的数据团队,帮助各个项目去解决数据层面的问题。
对于我们来说,我们不想在这个方面投入太多的成本。
3. 运维成本高
就算系统能跑起来,人员也足够,但是系统能不能稳定的运行又是另外一个难题。
除了技术团队、数据团队以外,我还需要额外的一个运维部门来不断保证我数据分析系统的稳定性。
因此我们评估完自建数据分析系统的挑战后,我们不想在这件事情上消耗太多事情。那个时候也是机缘巧合,我看到了 TA 系统的产品。
TA 系统让我当时决定下来对接的有点有 4 :

section

1. 前期投入少,部署快
我们只需要把这些事情交给数数科技的团队,几乎所有的部署工作大概仅需一天他们就能够完成,TA 系统就能够直接跑起来。
2. 数据实时入库
这个对于快速迭代产品的需求来说是非常重要的。
3. 灵活的分析方式,较低的上手难度
所有数据都储存在我们私有化部署的服务器当中,支持我们随时调取数据来做分析。TA 系统是一个可视化非常清晰的界面,你不需要写 SQL,只要把自己的数据分析需求想明白透彻,就能够在系统上拿到准确的数据。
4. 运维工作
最后一点就是我们完全不需要担心运维方面的工作。
在私有化部署的基础上,系统的运维工作完全可以交付给数数科技去完成。2 年多合作下来,集群的稳定性、云服务的波动产生的问题,数数科技都能够很快结束。
所以这几个优势让我们很快地决定下来用数数科技这块产品。
自建系统与 TA 系统本身不冲突,可以融合互补
当然我们说了这么多 TA 系统的好话,并不是在踩一捧一。
公司自己的数据看板系统和 TA 系统其实并不冲突,大家无论已经有了一套自建的数据分系统,还是说未来打算自己搭建一套,这都是不会和 TA 系统有什么冲突的。

section

简单来说 TA 系统是以项目为单位,数据是以项目划分。如果你有一些公司层级的数据,你可以将自建系统与 TA 系统做一个打通。
而且 TA 系统还能和 AppFlyer、Adjust 等上下游数据系统做接入,来帮助你公司层级更好地计算 ROI 等数据。我待会儿会在第三部分详细阐述这块。

o2

TA 系统使用经验

这是你打开 TA 系统的第一个面板,大多数人都是非常懵逼的状态

section

 

因为大多数人已经习惯了“直接呈现报表”这个事情,只要前端 SDK 接入了,你应该可以看到很多数据。
单个公司做数据产品会根据不同的项目组需求来完善这款产品的功能,但是一个公司无论再大,它都很难从有限的项目当中提取出一个需求共性,这也是许多自建系统常出现的问题,即某个面板仅仅能够满足某个项目组的某个单一数据分析需求。
是数数科把“解决问题作为所有项目的核心使命,并已经在游戏行业深耕了 5 年时间,服务了超百家游戏公司。数数科技更加关注的是这套系统能不能适配到的足够多的业务场他们就能够提炼出他们大多数数据诉求的本源在什么地方。
所以初心者使用 TA 系统相对于写 SQL 肯定是简单很多,但相对于那些很“香”的免费游戏数据分析工具来说,还是存在难度
不过 TA 系统的门槛并不在于这个工具有多么地难上手,而是在于很多同学做的都是策划、运营的工作,大家需要在产品设计上增加新一层的思路:我的设计最终应该呈现出什么样的报表

section

我们在做数据分析需求的时候,讨论会一定会花时间在梳理一个项目的数据反馈是怎么回事,然后去讨论他们都是怎么分析验证这件事情。
举一个简单的例子:我现在做一个活动,我应当怎样验证这个活动效果?我应该看什么数据?以此逐步地推到如何设计埋点。
比如一个活动,我们需要看参与度,那么“参活用户/当日日活”就能拿到参与率。参与过这个活动的用户,最终付费的用户比例是多少,那么就是“参活付费人数/参活人数”。
我们梳理出这些需求后,我们再针对刚才提到的一些事件去设计一些买点,最后才到刚才 TA 系统空白的页面去调配设置面板。这是我们公司现在使用 TA 系统的一个流程:

section

我们甚至会在功能还没做的时候,就会制定好我们在功能迭代上新增、修改已有埋点的思路。比如
1. 数据分析需求梳理
我们需要清晰了解玩家在游戏中不同消耗场景的货币支出。玩家使用金币的情况非常多,道具、英雄、复活等场景。不同场景下玩家的货币消耗情况,会直接为后续的版本货币消耗设计提供数据依据。
2. 讨论分析验证方式 & 设计对应埋点
我们可能使用 TA 系统的事件分析功能,对货币消耗的事件做分场景的统计。分场景的统计需要我们在货币消耗的事件相关的埋点属性上,将场景信息埋上去,这样才能满足我们后续的数据分析要求。
3.  制作 TA 看板
完成埋点后,我们只需要把分析对象的钻石消耗拉出来,用户单次的金币、钻石消耗数量便会直接展示。

section

 

其实刚才的埋点需求,大家传统会设计一个 A 场景使用金币”,“B 场景使用金币”……,这样虽然也能完成数据分析的要求,但是会导致整个埋点的管理会非常冗余。这里我们可以考虑将 A、B 场景都视为事件的一个属性,以此大大简化埋点的复杂度,并增加数据管理的灵活性。
数数科技提供了非常多能够灵活拆解事件的功能,帮助大家更清晰明了地管理自己的项目数据。项目组一旦足够了解这套系统,并根据这套系统去反向要求自己的埋点设计更加合理化,我们所需要做的事情只有“明确我们想要什么(埋点)”这一件事了。
我觉得一个好的事件埋点需要能够回答这么几个问题:

section

 

1. 我是谁
用户属性是一个强调用户最终时间点的状态值,记录的是事件发生的时候的用户状态。比如我前几天开启了 A/B 测试,当他开启某个事件的时候,他是“A 组的用户”。所以我需要记录下来。
2. 我在哪
我们会记录下玩家在事件发生时的场景信息,比如可以记录玩家所在的游戏模块是什么,或者说一些页面信息。
3. 我从哪里来
我们会记录一些玩家的前置信息,特别内购页面的进入渠道等。
4. 我做了什么
这个部分更多是记录事件的定量属性,比如说刚才的内购行为,我们会记录他内购了 10 个还是 20 个金币。
埋点建议
1. 事件管理表
针对刚才埋点的设计,我们每一个项目都会为了回答这些问题,都会维护这样一张埋点事件管理表格

section

 

数数科技的 TA 系统对我们在数据分析有很高的要求,你所有的产品设计不仅仅需要考虑“如何上线”“玩家体验”等一阶段的问题,这套系统其实在推动我们不断地考虑“这之后我们该如何复盘”等二三阶段的问题。
所以我们设计产品的第一步就是规范功能模块的打点设计,这让产品的创作过程也会变得更加灵活,模块易于拆解。
2. 封装通用埋点SDK,跨项目基础埋点一致性
TA 系统也是有 SDK 的,但是 SDK 是没有任何事件的。如果公司项目很多,特别是后期会比较吃跨项目数据分析时,其实最好在 TA 系统前端 SDK 的基础上在做一个封装,把一些游戏的通用玩家指标、内购、广告点击等等项目之间通用的数据维度,使用统一的封装保证每一个项目接入的时候,他们发的这些基础数据维度都是一样的。
这会方便后期在 TA 系统上打通跨项目间的数据对比分析,使用同一个事件名称、属性名称,会让公司层级的数据管理提升很多各层级

热门文章。