自建系统与 TA 系统本身不冲突,可以融合互补当然我们说了这么多 TA 系统的好话,并不是在踩一捧一。公司自己的数据看板系统和 TA 系统其实并不冲突,大家无论已经有了一套自建的数据分系统,还是说未来打算自己搭建一套,这都是不会和 TA 系统有什么冲突的。简单来说 TA 系统是以项目为单位,数据是以项目划分。如果你有一些公司层级的数据,你可以将自建系统与 TA 系统做一个打通。而且 TA 系统还能和 AppFlyer、Adjust 等上下游数据系统做接入,来帮助你公司层级更好地计算 ROI 等数据。我待会儿会在第三部分详细阐述这块。
o2
TA 系统使用经验
这是你打开 TA 系统的第一个面板,大多数人都是非常懵逼的状态:
因为大多数人已经习惯了“直接呈现报表”这个事情,只要前端 SDK 接入了,你应该可以看到很多数据。单个公司做数据产品会根据不同的项目组需求来完善这款产品的功能,但是一个公司无论再大,它都很难从有限的项目当中提取出一个需求共性,这也是许多自建系统常出现的问题,即某个面板仅仅能够满足某个项目组的某个单一数据分析需求。但是数数科技把“解决问题”作为所有项目的核心使命,并已经在游戏行业深耕了 5 年时间,服务了超百家游戏公司。数数科技更加关注的是这套系统能不能适配到的足够多的业务场景,他们就能够提炼出他们大多数数据诉求的本源在什么地方。所以初心者使用 TA 系统相对于写 SQL 肯定是简单很多,但相对于那些很“香”的免费游戏数据分析工具来说,还是存在难度。不过 TA 系统的门槛并不在于这个工具有多么地难上手,而是在于很多同学做的都是策划、运营的工作,大家需要在产品设计上增加新一层的思路:我的设计最终应该呈现出什么样的报表。我们在做数据分析需求的时候,讨论会一定会花时间在梳理一个项目的数据反馈是怎么一回事,然后去讨论他们都是怎么分析验证这件事情。举一个简单的例子:我现在做一个活动,我应当怎样验证这个活动效果?我应该看什么数据?以此逐步地推到如何设计埋点。比如一个活动,我们需要看参与度,那么“参活用户/当日日活”就能拿到参与率。参与过这个活动的用户,最终付费的用户比例是多少,那么就是“参活付费人数/参活人数”。我们梳理出这些需求后,我们再针对刚才提到的一些事件去设计一些买点,最后才到刚才 TA 系统空白的页面去调配设置面板。这是我们公司现在使用 TA 系统的一个流程:我们甚至会在功能还没做的时候,就会制定好我们在功能迭代上新增、修改已有埋点的思路。比如:1. 数据分析需求梳理我们需要清晰了解玩家在游戏中不同消耗场景的货币支出。玩家使用金币的情况非常多,道具、英雄、复活等场景。不同场景下玩家的货币消耗情况,会直接为后续的版本货币消耗设计提供数据依据。2. 讨论分析验证方式 & 设计对应埋点我们可能使用 TA 系统的事件分析功能,对货币消耗的事件做分场景的统计。分场景的统计需要我们在货币消耗的事件相关的埋点属性上,将场景信息埋上去,这样才能满足我们后续的数据分析要求。3. 制作 TA 看板完成埋点后,我们只需要把分析对象的钻石消耗拉出来,用户单次的金币、钻石消耗数量便会直接展示。
其实刚才的埋点需求,大家传统会设计一个“ A 场景使用金币”,“B 场景使用金币”……,这样虽然也能完成数据分析的要求,但是会导致整个埋点的管理会非常冗余。这里我们可以考虑将 A、B 场景都视为事件的一个属性,以此大大简化埋点的复杂度,并增加数据管理的灵活性。数数科技提供了非常多能够灵活拆解事件的功能,帮助大家更清晰明了地管理自己的项目数据。项目组一旦足够了解这套系统,并根据这套系统去反向要求自己的埋点设计更加合理化,我们所需要做的事情只有“明确我们想要什么(埋点)”这一件事了。我觉得一个好的事件埋点需要能够回答这么几个问题:
数数科技的 TA 系统对我们在数据分析有很高的要求,你所有的产品设计不仅仅需要考虑“如何上线”“玩家体验”等一阶段的问题,这套系统其实在推动我们不断地考虑“这之后我们该如何复盘”等二三阶段的问题。所以我们设计产品的第一步就是规范功能模块的打点设计,这让产品的创作过程也会变得更加灵活,模块易于拆解。2. 封装通用埋点SDK,跨项目基础埋点一致性TA 系统也是有 SDK 的,但是 SDK 是没有任何事件的。如果公司项目很多,特别是后期会比较吃跨项目数据分析时,其实最好在 TA 系统前端 SDK 的基础上在做一个封装,把一些游戏的通用玩家指标、内购、广告点击等等项目之间通用的数据维度,使用统一的封装保证每一个项目接入的时候,他们发的这些基础数据维度都是一样的。这会方便后期在 TA 系统上打通跨项目间的数据对比分析,使用同一个事件名称、属性名称,会让公司层级的数据管理提升很多各层级