TDS 游戏开发者圆桌（下）-TapDB 的价值与能力分享

苑志鹏：数据分析，包括游戏内部的数据来源、数据分析这样的内容，对于每个游戏厂商都是相当有价值的。对于一些比较大的成体系的厂商，比如说腾讯、网易，它们有一套自己的准则。但我个人观察看到更多体量没有那么大的游戏，反而缺少类似的分析手段。我最近聊过一些比较独立的开发者，他们有自己接友盟的，有自己去处理的，但是实际上给出来的结论也很模糊，包括分析也并不是很准确。TapDB 我们现在已经有一些内容沉淀了，也在逐步迭代，所以想要给一些游戏开发者更多的游戏数据侧的决策支持。

接下来交给 TapDB 的产品经理。

陈诚：我在 TDS 这边做 TapDB 这款产品，还有做心动数据服务相关的工作。TapDB 官网有一个 Demo，大家可以体验一下，就能了解一个简单的概念。TapDB 是自助化接入和使用的平台产品，目前核心功能是有几个比较关键的看板，这里是我们非常基础的运营看板，只需要接入两个事件，一个账号登录，一个付费事件，就可以得到大家日常需要的数据，像留存率、付费等等这样很基础又很好用的数据，每个看板有核心的主题，里面会有细分的不同的报表，方便大家继续往下翻数据。同时还包含了广告投放监测的功能。因为 TapDB 是历时比较长的产品，我们在 2020 年-2021 年做了一次比较大的重构和迭代，核心加上了自定义事件上传和分析的能力，现在TapDB 是可以比较方便上传各种各样的自定义事件，并且可以自助进行分析，上报完成之后，可以有一些 QA。

对我们来说一个很重要的问题，为什么我们会想做TapDB 这个产品，并且把它面向开发者，至少现在是完全免费的开放。对于我们来说，因为心动自己做游戏也比较长的时间了，我们在做的过程中，自然的产生了相当多的数据需求，产生这些数据需求之后，就选择了自己开发一个数据平台产品，去承载这些需求。在使用的过程中，我们逐渐抽象出一些比较具备通用性的指标或者说用法，我们觉得这些东西是不是同样帮助到 TapTap 开发者，这是最早的一个初衷，希望把我们心动自己研发所使用的能力共享给开发者。

谁在使用 TapDB？

首先心动所有游戏项目都是会使用TapDB 的支持，这是心动目前最核心的数据分析工具。刚才在现场大致查了一下数据，至少昨天 TapDB 有 800 多个项目是开发者在用的，现在大概是这样一个状况。

从流程化的角度讲解一下 TapDB 大概能做哪些事，再进入比较细节的东西。刚才大家看到的像运营概览这样的东西，它核心解决的是一些基础数据的看板。

像刚刚有提到尤其是一些中小开发者可能想看数据，但是又不知道怎么去比较好的应用数据，至少我们把心动自己的经验，我们觉得数据该怎么看，怎么样构造指标是比较好的，首先以预制的形态提供给大家，大家在接入TapTap 的 SDK 之后，可以天然获得比较多的指标和相当多的维度，这是我们自己在日常使用最多的，并且帮助比较大的。

在游戏研发或者大家做数据分析一个逐渐进化的过程中，我们逐渐的也会发现对于数据分析这件事来说，如果我只提供那些非常预制的东西，不允许开发者自己其上传自定义事件，不允许他对自己游戏比较特性的东西想去做分析的话，这个分析的深度和贴合度也是不够的，所以我们在2020 年-2021 年花了很大力气重构底层架构，目的就是为了支撑目前已经落地的自定义事件分析的体系。包括从整个自定义事件和它的属性创建、管理以及到分析，目前都已经非常完整的上线，并且也有不少的项目在用了，这一块核心想解决的就是，不知道大家平时有没有发现，很多时候我们想看一个比较特定的数据，如果不是在已经做好的看板里面，你可能需要数据分析师帮你写好，甚至需要程序帮他做这件事情，这个周期会比较长。我听到比较夸张一次，找程序去解决一个取数据的需求，要排两三天，等两三天之后拿到这个数据，这个数据当时需要用来决策的东西，可能是一个广告投放，它已经过期了，这个数据本身在拿到的时候已经失去价值了，并且对游戏开发团队也好、发行团队也好，来回取数据的成本实在太高了。做这套系统的目的，当我们基于对自己游戏的理解和了解，实际上是知道游戏中有哪些行为是这个游戏特有的但是又很重要的行为，可以作为自定义的事件上报上来，可以通过面板看一下，通过一些比较简单的面板交互，能让所有包括运营、策划的同学很简单的取出自己想看的数据，因为我们这套系统的实时度在一秒左右，整个查数的速度还是比较快的。本质上是把语句界面化，比较简单翻译成人类比较好理解的一种语言，直接去使用，这个门槛至少在我看来会比较低，我们自己用下来的话效果还是比较不错的。

因为是我们自己项目的数据，当时自己构造出来两个比较有用的场景，上面是对这个游戏的 DAU 进行分层，它注册日期是30 天以前在这个 DAU 中占比多少，注册日期是 1-7 天以前的在 DAU 中占比多少。只知道 DAU 是一万这个是不太好的，要知道 DAU 是怎么构成的，当超强老用户产生流失和新用户产生流失，对我们的意义是完全不一样的。下面这个图是另外一个场景，这个场景解决的是什么呢？可能很多做游戏的同学都没有刻意去关注过的，或者没有很好的关注到，用户在真正进入到游戏之前的这么一个流失，这是什么意思呢？很多时候我们看数据，这个起点是用户登录之后的数据，用户登录之前会遇到什么问题，需要更新、需要加载，会不会在这个过程中遇到失败的情况，会不会导致用户从打开到注册的步骤而产生损失。我们绝大多数的产品在观察用户数据的时候起点都是用户登录和注册，对我们来说我们想做的更精细化，在用户登录前所有的步骤拆成非常细致的埋点，这些对用户来说本身不是天然很容易感知到的东西，但是发生在客户端内SDK 有时候可能会出一些问题，虽然打码了一些数据，还是可以看到整个更新完成率没有我们想的那么好。用户其实会在更早的阶段流失，这些流失点位对我们来说也是比较想关注的，现在这个也是成为像心动我们比较标配的一个分析模式，我们希望能尽可能细致的看到我们所关心的东西，避免用户在我们不知道的情况下发生流失。

TapDB 因为它是心动一个比较通用的数据平台工具，除了游戏内的分析，可能更多的自定义事件会更多服务于产品研发团队，我们同时也做了广告投放这块的相关能力，主要是发行团队会更关心一些。在广告投放监测这件事情上，国内比较核心的媒体，头条、快手等都已经对接好了，接入这个产品的SDK 就可以正常使用。整个报表还有很多可选的指标，为了节省空间截断了一点，整个报表大概是这个形态。因为我之前自己在其他一些公司做过，我发现很多公司比较常见的一个情况是它的整个广告数据系统和整个产品研发分析的数据系统有一些割裂，它的广告发行数据和研发数据是割裂的，这个会产生什么问题呢？对于研发同学来说，或者说对于偏运营产品的同学来说，可能发现自己最近用户有一些异常行为，但是如果没有办法和用户来源关联上的话，可能就缺少了一些信息，其实有时候可以更快速归因，有时候它就归不到。对投放的同学来说其实是一样的，投放同学往往会关注的留存、付费、ROI这些比较通用，比较直接的一些结果，但实际上我们从用户行为上还能做一些更早期的风控也好，我们可以做更多的事情，在心动我们希望所有的数据能够更好的串在一起，并且都在一个地方去用，不管对于发行团队还是产品研发团队来说，它的信息量会更充分一些，我们做到一个工具上去解决。

毕竟数据平台我们提供了一些辅助的工具，去帮助大家更好的使用这个产品，我们的核心目的还是把它做成一个非常高度自助的，开发者可以非常轻松自助接入，并且完成像埋点QA 这样的，我们提供了专门的埋点 QA 工具，帮助开发者完成自己的 SDK 接入之后，比较简单判断自己接入的埋点是否按照自己预期的上报。一个核心的分析工具是用户分群，基于工具要解决的人效问题的思想，尽可能再把一些不该人去做的东西自动化，我们最近更新了像报警这样的功能，可以针对一些核心的指标，大家可以设定一些阈值，现在可以设置的某个绝对值，或者相对于昨天同时段低了10%，可能会给大家发个报警邮件，有一些很核心的数据，大家非常关心，避免了需要靠人去盯着它，人可以解放出来做更多的像分析决策这样的工作。

TapDB 有一个比较特色的东西，我们有专门做一个移动端，因为毕竟移动年代，我们希望数据也能随着移动，这不是一个网页端的工具，这是我们专门开发的 APP，给它做了一些适配，大家应该会发现它在看数据方面比大家通过手机打开一个网页方便得多。比如我在公司外的时候，老板想看什么东西，或者我想看什么数据用手机打开一个网页，其实还是蛮痛苦的。到这里都是关于 TapDB 功能上大致的介绍。

我们做 TapDB 这个产品的时候，也经常在反思一个问题，为什么开发者要用我这个产品，虽然我可能是面向开发者是免费的，类似的产品也是有的。我们接下去或者现在正在做的一个事，想把整个 TapTap 中和开发者本身项目相关的所有数据也放到 TapDB 中给开发者。比如说商店的转化数据，关于 TDS 所有服务的数据，现在已经落地的像内嵌动态的数据，只要你接入了内嵌动态以及 TapDB，我有能力在 TapDB 中把内嵌动态的数据直接呈现给你，并且可以做比较细致的分析。包括和开发者自己这个产品相关的一些社区数据，我们在做这件事的时候核心想解决的问题，提供一个比较方便的运营工具，帮助开发者判断我自己在 TapTap 的社区做的到底怎么样，我在 TapTap 经营这个产品的商店也好，社区也好，我做的怎么样，我的转化率，用户看到了我的详情页之后，他们真正转化为下载的情况到底是怎样的，是不是最近有一些异常。最近通过一些设备上的算法，尽可能的帮大家把转化都串联起来，尽可能去回答清楚，比如说昨天有多少用户看到了我整个商店在 TapTap 的，看到了我的详情页，这些用户中有多少人点击了这个产品的下载按纽，有多少人点了下载按纽之后真实完成下载，这些完成下载的人当中有多少是真实激活的。比较大的转化漏斗希望能够给开发者呈现清楚，不同场景下有不同的问题，大家也可以有针对性的解决。因为转化漏斗可能之前看到的是游戏激活了多少人，实际上不太清楚中间的转化流失到底发生在哪，我们接下去会把这件事情在数据上讲的更清楚一些。

苑志鹏：关于数据这件事情，其实对相当一部分开发者来说是有意义的，因为我们把整体商店的数据加上游戏的数据，整个全链路已经打通了，我们也在考虑一系列这些数据能不能不用，怎么用，怎么呈现给开发者。在这些项目上我们遇到的挑战还是蛮大的。整体数据这块还是蛮抽象的，后续有问题也可以直接找我。

Q：这个系统面向海外市场吗？

A：现在开发者中心今天接入上线，在海外的开发者中心也可以去用。

Q：海外的广告平台对接的是？

A：海外现在因为大部分媒体还是仅支持所谓他们有证书比较认可的第三方，要对接的话我们的方式还是开发者需要先自己对接这些第三方，我们可以通过一个接口把它的数据拿回来之后，你可以整合到跟你的游戏数据一起看。

Q：接入这些之后包体会大多少呢？

A：要看接哪些服务，如果全接入的话，报体会多一两百兆，昨天我们小游戏的项目组也在问这个问题，它游戏包大概只有 30 兆，它接了我们的服务之后，整个游戏包体要到100多兆。这跟使用的功能有关系，像大部分游戏可能不会，比如说我们的十几个功能全都接入，对包体的大小增加会很小的，我们后面也会持续优化，尽可能把功能模块化，对使用部分功能的游戏尽可能只包含使用到的东西。这里面有很多后续还可以优化的地方，像有些 SDK 里面使用第三方的库，游戏里面也使用到了，之前为了避免冲突，会把我们用到的第三方，有一些情况下会存在有的库游戏页面有一份，SDK 里面也有一份，像这些后面会有更多的技术手段优化。