2 月 23 日，由 TapTap 举办的 TDS（TapTap 开发者服务）游戏开发者圆桌顺利结束，TDS 运营负责人苑志鹏、TDS 产品负责人卫凯灵、TapDB 产品负责人陈诚与 30 余位游戏行业从业者分享了 TDS 的相关功能。此次沙龙举办的初衷，一方面希望通过线下的交流，向广大开发者更好的介绍目前 TDS 的功能，另一方面也是希望这些功能可以给不同体量的游戏开发者带来便利，从而助力整体行业的前进。
未来，TapTap 开发者系列活动也将持续推出，期待与更多开发者的交流。
以下为演讲实录：
（TDS 运营负责人苑志鹏）
苑志鹏：我在这边负责整体的 TDS 团队运营工作。今天为什么把大家邀请过来，因为我在跟一些开发者交流之中产生的一些思考，引用和一个独立游戏开发者的交流，这几年过的蛮难的，我们存在的意义也就是想让大家过得相对轻松一点。我们想通过更多的手段帮助各位开发者做一些成本节缩。通过长线的价值，给开发者提供一些方便，让游戏环境能够变的更好。
办这个圆桌的初衷，一方面是我们做了很多功能。在场应该有产品运营或者渠道运营的小伙伴，用过 TDS 服务的人可能看到林林总总介绍了十几个功能、技术服务的能力，有的免费，有的付费，有的比较好懂，比如说我们的登录功能，比如说防沉迷这样的功能，有一些也不是很好懂，包括云引擎。我昨天还在跟产品负责人讨教什么叫做云引擎，我作为内部人员都不一定真的理解这件事情，有必要让相关小伙伴给大家说说，这件事情比大家想的要简单，产生的价值可能会对大家有一些帮助。
在协助开发者把游戏做出来这件事情上我们做了很多尝试，包括登录、防沉迷，包括云存档、云引擎，但是之前一直没有大范围推广。下面交给产品负责人，让他给大家具体说说到底哪些功能是现在有的，哪些功能可能对大家产生一点点的作用。
TDS 技术服务能力分享
（TDS 产品经理 卫凯灵）
卫凯灵：今天主要给大家讲一下我们 TDS 在过去半年内做的 12 个比较关键的能力，大家知道我们自己第一方游戏《Flash Party》前两天在日本上线，拿下了免费榜的第一名，他们在过程当中使用了非常多 TDS 的能力。我们也是想说心动的第一方游戏用的比较成熟之后，让他们当小白鼠，再介绍给其他开发者。目前看来 TDS 服务不管是成本端的降低，还是在 TapTap 上有更多的曝光和露出，对开发者都是有帮助的。
我把这 12 项能力分成两部分，前 6 项是生态服务，和 TapTap 本身有更多的结合，包括像实名与防沉迷、内嵌动态、游戏好友等等，我们会让这些能力显示在 TapTap 客户端上面，让玩家知道这个游戏是有这些能力的。第二部分是把它称之为云服务，本质上来说还是帮助开发者避免重复造轮子，降低开发者的研发成本，不管是人力上还是时间上。
先从最关键的实名和防沉迷开始介绍，国家政策从去年 9 月份对防沉迷逐渐收严，之后不确定会不会有进一步的动作出现。对开发者来说理解这些规则，跟进这些规则成本都是挺高的。头部开发者还有精力自己去做这个事情，但是对于腰部、尾部游戏厂商就有一定的成本。TDS 帮助开发者做了一整套游戏实名认证与防沉迷系统。我们对接了中宣部的实名认证系统，如果在中宣部注册过，在我们后台填一下地址就可以了。第三是比较关键的能力，我们会将 TapTap 中已经实名的用户，让他们快速登录游戏，避免他们反复填写身份证信息，提高游戏转化率，降低获客成本。第四，我们提供了实名与防沉迷的全套界面。1 月份已经有 200 多个游戏，目前接入的游戏还是非常多的。
防沉迷主要是提供三个界面，左边第一个界面是玩家去填写自己的实名和身份证的界面。对于有版号的游戏会走中宣部的认证，对没有版号的认证我们对接了阿里云实名认证系统，这部分对开发者是完全免费的。第三个界面是 TapTap 账号的玩家，已经填过实名的，快速授权游戏。未成年玩家在游戏内收到防沉迷提示的界面。我们可以看一下案例《烹饪女巫》的整体流程。在进入游戏唤起 Tap 登录，登录成功后，唤起实名窗口，这是它的快速认证。这个功能的起因也是我们之前在 TapTap 游戏评论下面看到「我在 TapTap 实名过了，是不是可以直接实名」的留言而做的更新。目前有 200 多个游戏接入，差不多 120 万玩家完成过实名。在 TapTap 原生游戏（TapTap 原生游戏是指游戏的整体分发可能主要在 TapTap 进行分发的游戏）当中，使用 TapTap 认证占比超过 90%。这部分游戏的用户群重合度非常高，这些游戏 90% 的 TapTap 认证占比提高了很多游戏的转化率。
第二个是内嵌动态，也是去年重点推广的功能。我们自己的第一方游戏用的效果是最好的。玩家在游戏内就可以访问当前游戏的 TapTap 社区，并且现在 TapTap 社区支持游戏攻略，专门有一个攻略模块，可以通过联系我们的运营开启。攻略的生成是需要开发者自己去生成好攻略之后，按照我们的格式规范进行录入。我们在内嵌动态准备了运营的 Banner 位。我们支持场景化入口，比如说是格斗游戏，可以在英雄界面旁边放一个关于英雄的攻略入口，可以让玩家知道怎么使用英雄。以《Flash Party》为例，最受欢迎的角色其实是雪怪的角色，这个角色在这个界面里面通过场景化入口，查看攻略达到 10%，意味着 10% 的用户访问了这个攻略。包括内嵌动态支持完整的运营数据查看和运营管理。心动第一方游戏全部接入这个功能，外部游戏也有非常多。内嵌动态的攻略界面也有攻略索引页，针对不同的主题做不同的索引页。
比如说《香肠派对》的新手攻略，就有效提升了新手留存率。这是《香肠派对》S3 赛季的攻略，提高了玩家的参与度。现在因为攻略的承载形式还是帖子本身，我们也会考虑有更多的内容展现形态。在竖屏下的攻略一般来说阅读效率更高，这是刚才相同页面在竖屏的展示情况。我们提供了横屏游戏也可以竖屏看攻略。
此外，《香肠派对》在主界面动态旁边加一个小红点，能提高内嵌动态的打开率，进而提高官方帖和社区内容的阅读数据，对做社区内容的小伙伴来说是非常重要的能力。接了小红点之后，官方发布的帖子有一半以上的浏览量来自于内嵌动态。在没有小红点的时候，整个内嵌动态使用率是 3.5%，有了之后能提高到 20%。
这是《Flash Party》的日本区的案例，在英雄旁边有一个攻略，可以引导用户查看攻略内容。公告也是用场景化入口的形式做的，他们的公告用非常大的图片来展示，点进去之后通过场景化入口进入到社区帖子。这样对运营来说也有一个好处，官方帖发一次就足够了，并且帖子里面承载了和玩家互动、点赞、转发、评论等能力。这是《香肠派对》在游戏内的成就，获得成就之后可以一键分享到内嵌动态。我刚才在玩一个游戏叫《我的舅舅是魔法师》，在它的内嵌动态里，有大量的玩家在分享游戏当中的成就，我发现这类的分享玩家会发帖非常多。
这是《香肠派对》的吃鸡界面，可以把战绩分享到内嵌动态里面。下面展示的是《香肠派对》将自己的个人资料发到内嵌动态，进行交友的能力。大家可能会好奇为什么叫内嵌动态，这不是一个社区吗，我们在做这个产品本身，不仅是从社区考虑它，也是从社交圈的角度考虑它，因为我们里面有一个叫关注流，玩家可以看到我的好友在这个游戏下面发布的动态。
这有一个案例《人类跌落梦境》，在好友界面显示访问他的朋友圈，进入到好友的朋友圈里面。有两个场景，对于游戏内如果小红和小明想社交，一开始不认识你，通过朋友圈了解你是怎样的玩家。如果本身已经认识，也可以通过朋友圈知道你最近又在游戏内有什么新的动态，对于新老的关系形成都是有帮助的。内嵌社区大家可能会疑虑会不会看到其他游戏的内容，这不会的，我们都是对游戏做了筛选，玩家只会看到在当前社区里面的内容。这是截止到 1 月份的数据，我看了一下最近一个月接入的游戏还是蛮多的，之前有 56 个游戏接入了内嵌动态。《Flash Party》海外版本使用率 40%，访问内嵌社区的人数除整体的游戏活跃人数，可以看到日本玩家使用动态的比例非常高。人均屏展数 19（屏展数是指一个玩家平均看了多少个动态的卡片）。内嵌动态占论坛活跃 60%。《T3》因为还没有上线，使用率 21%，屏展数 18，内嵌动态占论坛活跃 50%。内嵌动态对社区运营的伙伴来说是非常关键的能力，降低运营成本，提高对玩家内容的触达率。内嵌动态后续的迭代计划包括场景化入口支持攻略，也会支持搜索，也会支持玩家把自己经常看的帖子或者攻略收藏起来，一键分享支持视频，比如说游戏内的五杀时刻、精彩瞬间，都是可以一键分享到内嵌动态里面来的。
第三个模块是游戏好友，也是游戏内非常常见的功能模块。TDS 把整个游戏好友的能力都做了，并且我们支持两种模式，一种是好友模式，一种是关注模式。好友模式是像微信一样，我加你，你需要同意，才会成为好友。关注模式有点像自己的 TapTap，包括像微博、推特都是关注模式，我关注了你，你回关了我，我们才是好友，两种模式开发者可以自己选择。好友基础里面会根据昵称或者好友码搜索好友，也可以通过长连接显示玩家在线状态。如果想展示更多游戏状态，可以用富信息实现。比如说有些玩家，正常会是在线和离线状态，可能有些想定义我这个人正在组队中，正在房间中，正在匹配中，这些能力可以通过富信息来实现。支持接入第三方社交平台好友，像 TapTap、脸书，也会支持海外推特这样的社交平台。我们自己的 T3 在 3 月份上线，他们接入的是 TapTap 和脸书两个社交好友关系。支持通过分享链接，邀请别人加我为好友。
我们自己的第一方游戏基本上都用了这个 TDS 好友能力。这是《T3》的案例，它的好友界面。下面蓝色图标是 TapTap 标志，意思是这个人是 TapTap 好友，这是添加好友的界面。这是富信息的案例。
这是《Flash Party》，在状态这一栏，蓝色这里就区分了很多状态，组队中、战斗中、观战中。这是海外的案例，它是接了 Line 好友和脸书好友，这个能力 TDS 好友是支持的，开发者可以参考这些游戏，看怎么做好自己的游戏好友系统。后续迭代分几个，第一支持黑名单的能力，第二支持好友排行榜，很多开发者好友界面想要按照某一个信息进行排序，奖杯数、心数等等。有些游戏好友上限是一千到两千人，这样的排序是比较困难的，我们会对这部分做重点的优化。第三，有开发者给我们反馈过，我们会提供好友的界面版本，对中小游戏或者是独立游戏，他们可能就免去这部分工作量，《人类跌落梦境》自己一开始也没有做界面，也是用 TDS 的版本。
开发者可以获取 TapTap 的同玩互关好友，比如小明和小黄都对这个游戏进行过好友授权，都是玩过这个游戏，他们两个才会添加好友在游戏内，这跟接脸书好友是一模一样的逻辑。这是《香肠派对》的案例。上面第一个没有 TapTap 头像，意思是在游戏内加的好友。
成就系统也是非常标准的能力，有推荐游戏进行接入。首先游戏内成就可以在 TapTap 主站进行展示，目前功能已经上线发布，如果游戏接入了成就系统，新版本客户端可以在客户端-我的页面查看自己游戏的成就。第一期上线的游戏比较多，像《我的舅舅是魔法师》、《人类跌落梦境》等等，成就系统可以设置普通成就、隐藏成就、分步成就，我们参考了 PSN 的系统，为高质量、氪金不影响公平性的游戏，颁发白金奖杯，如果符合这个资格，要向后台申请，因为我们会评估这个游戏是否能够拿到白金奖杯，最终想做成的效果，你发现在 PSN 上面很多奖杯的玩家，他们甚至为了白金成就玩这个游戏，本质上也是变相对我们的游戏进行分发，代表了这个游戏对奖杯来说是非常厉害的游戏。我们支持自动结算稀有度，玩家达成之后成就感非常强。支持客户端上报成就或服务端上报成就，当然我们建议能服务端上报就服务端上报。对了，我们提供了 UI 面板，这是可选功能。即将在 3 月份玩家可以看到的游戏。
这是在客户端主站显示的页面，目前放在个人主页里面，可以查看成就列表，之后会在更多的页面分发我们的成就页面，让更多玩家触摸达到我们的成就系统。成就面板分两个部分，一个是获得成就之后顶部的弹窗，还有查看自己的成就面板。
这是两个稀有度非常高的游戏，两个成就达成率只有不到 0.1%，挑战难度非常高。截止到 1 月份，第一期上线的游戏有 11 个，有 4 个白金游戏，7 个普通游戏，玩家平均获得成就数是 1.5-8.5 之间，有超过 500 万玩家获得成就。主页上线之后，接入的游戏会越来越多，大家可以先看一下效果，再决定是不是接入。成就系统后续迭代，第一个支持更多页面展示自己的成就系统，支持客户端内和别人对比成就。成就也支持分组，像赛季成就、DLC 成就，根据不同分别的成就。成就系统现在只是在国内客户端展示，如果开发者想出海，国外客户端也会在今年找时间做上去。
排行榜支持各种类型的排行榜，像全服、活动、好友排行，也有丰富的计算方式，当前排名、Top100 排名等等。数据更新策略（最大、最小、最新、累计），根据不同场景使用。排行榜这个能力本身并不复杂，但是它的难点在于海量用户的频繁更新，在高负载下甚至能够表现的非常好。之前有些游戏可能自己做的排行榜，但是他们自己的后端负载处理的不是特别好，游戏上线的时候可能会因为这个功能导致整体游戏稳定性出现问题，TDS 排行榜帮助游戏解决了这个烦恼，这是非常关键的一点。
云存档，这个也非常简单，单机游戏都是非常建议接入的。首先我们支持基础的上传、下载、冲突。为云存档提供元数据，包括存档封面、存档描述、游戏时长、游戏进度。
接下来是 IM 系统，我们自己的心动第一方游戏都是使用自己的 IM 能力，像《天天打波利》、《香肠派对》等等，因为他们对聊天的依赖性非常强。我们的聊天系统非常强大，不仅能够用于游戏本身，会支持像单聊、群聊、聊天室等等。它有很多高级的聊天类的场景诉求可以满足，像带有提醒的 @ 能力，消息的撤回和修改，像某某正在输入的状态信息。包括接收方离线的时候，会自动转为推送通知。我们有标准的基础能力，黑名单、禁言、消息过滤等等。我们的 IM 系统承载游戏内的聊天诉求非常足够，甚至可以玩更多的花样出来都是可以的。我们也是集成了文本检测系统，会把那些不合规的文字进行屏蔽和过滤。这是《香肠派对》在游戏内的 IM 的场景，因为有开发者问过我，像 IM 支持去添游戏内的设备链接，我在 IM 窗口发一个装备链接，对方点进去就可以看装备的详情，这也是支持的。
实时语音 RTC，这是语音聊天功能，我们 TDS 的聊天支持两人和多人的实时音频通话，低时延、高音质。弱网环境下做了很多优化。我们也会支持 3D 语音和范围语音，对 FPS 的游戏比较有用，可以增加玩家的临场感，把玩家的脚步声也可以听得到。我们也是自动集成了语音合规，针对广告、脏话、涉政涉黄这些语言会调给开发者，开发者可以自己选择把玩家进行禁言或者踢下线处理。这套系统也是支持游戏出海，我们是全球部署海量加速节点，不管开发者去发布到哪个国家，都可以支持。实时语音的 RTC 底层供应商就是腾讯 GME，相比开发者去对接 GME，我们额外赠送了语音合规，从价格上来说更加优惠一些。这套系统因为本身是会产生费用的，本身的成本还是不低的，我们每天也是赠送了 700 分钟的免费使用时长，大家可以先试一下。
客服的话可能是偏向于平台类的功能，我们的客户首先是做了一个面向玩家的客服界面，我们也有可以提高客服日常工作效率的客服后台，客服系统支持自定义工单分类、模板。因为开发者团队有大有小，像大团队可能有不同的工单流转流程，可能涉及到多个部门，我们也可以设置工单的具体流转流程。也可以设置快捷回复、触发条件，方便客服统一话术。内部回复的时候，可以在工单上面做内部的标签，让接下来的客服人员知道之前聊过了哪些内容，降低内部沟通成本。支持知识库的能力，开发者可以把游戏内常见的问题建立分类和索引，进行快速的回答。这个系统目前在内测中，大家在官网上看不到，大家感兴趣可以通过工单的形式给我们发送内测的资格。我们自己心动内部的客服系统全都是使用这套系统，包括自己的 TapTap 加速器也是。这是我们的客服界面，通过工单的对话形式，玩家可以上传像图片、视频，都是可以发送上来的。这是一个比较标准化的界面。
客服系统支持快捷回复的内容，设置一些触发点，设置官方回复。之前我们有发现可能不同的客服回复的话术不一样，有时候不同的话术会给玩家带来不必要的误解，这个能力可以帮助我们统一对外的输出规范。客服系统提供数据统计和定期报告，方便开发者了解客诉的分布和情况，以及回复工单的平均时长。
TapCanary 这个工具大家比较陌生一些，TapCanary 可以将游戏的测试包在指定时间分发给指定测试人员，支持三重环境下的测试，原生环境、云玩、沙盒，并且如果开发者通过 TapCanary 进行分发，一定程度可以防止包体的泄露。开发者不需要在开发者中心先创建应用，才能使用 TapCanary，它是完全独立的系统，后台可以上传任意游戏或应用。支持沙盒模式和云玩模式下的游戏测试。如果游戏想上云玩分发，可以自己先去云玩模式试一下有没有问题。我们也可以设置测试时间，测试时间之外不允许玩家进入游戏。目前最多支持 1000 名测试人员。
这是我们 TapTap 团队的官网，目前没有什么限制，可以创建自己的测试计划。这个测试内容也有面向玩家的 APP，在那边可以看到填写的当前版本测试内容。添加测试人员的方法还是要通过添加 TapTapID 进行测试的。创建好之后，会有一个 TapCanary 的客户端，可以在第一个页面看到目前有资格测试的游戏，当前版本信息和测试时间，第三个是目前已经测试完成的游戏。TapCanary 适用场景非常多，比如说新游戏在早期的时候想要把游戏开放给特殊用户，但是要防止它的包体和资源流出。譬如说三类用户，第一个会把游戏发给媒体做评测。第二，给早期的作者和 KOL 写攻略。第三，会给核心玩家进行试玩和收集反馈。在三种场景下都是希望包体不要流出去，通过 TapCanary 支持早期面向特殊用户的游戏包体分发。
我们自己的 QA 阶段，也是可以通过 TapCanary 进行测试人员的管理。测试人员通过 TapCanary 来测试的话会有更多的上报信息，我们自己本身应用知道什么时候崩溃，可以通过这些信息，帮助开发者知道更多的错误信息。TapCanary 的后续迭代，我们会支持更多的反馈方法，譬如截屏反馈、录屏反馈、文字反馈，我们也支持更多的上报的错误日志，减少反馈成本。开发者打包后可以直接推到 TapCanary 环境，无需在手动上传。后台增加更多测试数据报告，譬如支持查看测试用户的激活数，有多少测试人员激活了，每天的测试时长是多久。
最后两个模块更偏开发方向一些，结合案例给大家讲解下。数据存储+云引擎，这两个概念，近年来有一些云服务的概念在市场上冒出来，像函数计算，它其实本质上来说可以帮助开发者节省后端的从构建到部署，以及后端的开发成本，包括运营层面的很多事情使用我们的数据存储+云引擎，也可以一站式解决的，所以我们的数据存储和云引擎是 TDS 面向开发者的低代码平台，Serverless。我们可以把结构化的数据，像玩家表、角色表、武器表，游戏内的基础数据可以放到数据存储里面。我们也支持存储文档、图片、视频、音频，而且我们是 CDN 加速。有些游戏有工会系统，像做工会墙，这个图片属于工会内的成员都可见，可以通过数据存储进行使用。接下来举例的两个游戏是整套后端系统都使用 TDS 的云引擎和数据存储。
这款 SLG 游戏的用户系统就是使用了 TDS 的内建账户系统，它们游戏的武器表、玩家活动、战斗数据，这些核心数据都是用结构化数据存储进行保存。本身运营活动信息等数据也保存在云端。使用云引擎搭建自己的活动页面，包括自己的运营管理后台也是使用云引擎自己搭建出来的。
第二个游戏案例是做棋牌的一家公司，这家公司在脸书上运营了非常多的棋牌游戏，也是使用我们的系统。用户系统使用内建账户，玩家对战数据全部保存在云端。他们想做排行榜服务，但是它没有使用 TDS，是用云引擎+云原生的 Redis 自己做了一个排行榜服务。他们自己这套服务搭下来，每天的成本只有几块钱，对他们来说不到一杯咖啡的价格，他们自己也是觉得非常划算。这家公司的内部数据中台也是部署在我们的云引擎上面。
大家可能有一些疑问，我为什么不自己做后端系统，而使用你 TDS 呢。说五个优势：
第一是我们这套后端系统使用非常简单，程序上来说无需定义表结构或者 Schema，文件存储自带 CDN 加速。我们的性能游戏，网络请求延迟一般不超过 100ms。
第二，功能本身齐全，后端里面基础的像多端同步、全文检索、数据挖掘，包括运维层面的日志收集、查询性能分析等辅助功能都是完备的。这套系统上线运行多年，很多游戏使用我们做后端，每天可以支撑数亿次的请求，并且支持通过水平扩展进一步提升上限。租户和应用之间完全隔离，不会因为某个游戏的爆火导致连累其他的游戏服务端受到影响。数据存储的后续迭代分两个层面，因为很多开发者使用我们的数据存储存储一些比较基础的图片信息，我们会集成一些图片智能检测服务，避免内容出现。因为有些游戏有玩家自己 UGC 在里面，比如说游戏支持玩家自定义一个地图或者时装，这些也是可以使用云存储进行存储信息的。我们会增强底层数据仓库的能力，帮助大家支撑更多的灵活性，满足更多的统计分析的需求。随着游戏业务的扩大，对数据分析的需求也越来越强，这方面后续会做更多的支持。
整个工程师如果想完成一个游戏的后端，通过云引擎只要经过 4 个步骤，首先工程师在本地写好自己的业务代码，然后通过我们的数据把整个源代码上传到 TDS 云端，我们的云端会自动进行编译和构建，再打包，最后在游戏平台上运行起来，这样我们的客户端或者浏览器就可以访问这个服务了。云引擎这个能力总结下来，主要是解决开发者三大痛点，第一个从构建到部署、运维，三个层面的问题全都解决了。底层支持了 Docker 容器技术，可随负载变化自动弹性伸缩。越来越多的游戏上线的时候会面临炸服问题，开发者自己没有想到有这么多玩家进入到这个游戏，使用这套底层运行，帮助大家避免这类问题的出现。
第三，完善的云原生插件和运维系统支持。
这是整个云引擎的系统结构，在这部分有一个应用托管模块，它能够做两件事情，一是可以响应存储数据库的事件，做实时处理。比如说想在玩家登录事件发生的时候，做一些通知的处理，这个处理方法叫做函数计算。处理的第二个事物，可以直接对外提供 API 或者资源服务，可以拿它来做游戏的某个活动页面，甚至用它做一个自己的数据统计后台。这个我们称之为应用托管。这边有一个中间层，刚才提到的支持云原生的插件，市面上非常常见的，可以开发者购买，通过云引擎代码访问，实现不同数据的方案。最下面是底层运维支持系统。开发者三大方面的成本降低，第一省去大量的后端开发成本，不管是时间上还是人力成本上。
第四，底层运维能力非常强大，我们支持日志的收集、监控报警，尽量避免游戏的炸服。它可以托管游戏的活动页或者抽奖页面，这是前端工程师最喜欢的一种用法，在游戏运营中可能运营提一些临时的活动需求，前端就可以直接使用云引擎部署一套简单的后端系统，前端访问这些数据就可以实现非常简单的抽奖页面，帮助开发者快速进行活动页面上线。
第五，开发者可以使用 hook 机制，在存储服务中发生一些事件后立刻进行响应。譬如说有些开发者想在业务登录之后做靶点处理，这时候就可以非常方便的实施方案。通过云引擎开发一个完整的 Web 服务，这边输入机器人就可以告诉我哪些同事请假了。在开发者中心里面的工单系统，这个纯粹是使用自己的云引擎和数据存储实现这个能力。
截止到目前为止一共 12 个功能的介绍，对于这些业务更多希望可以在 TapTap 上进行独家的发行，我们会在 TapTap 独占期内，免费开放这些能力。
Q：支持海外吗？
A：除了成就没有支持，其他都是支持的。
Q：底层云采用哪个系统？
A：我们的基础架构本身不依赖于任何云服务，不同的节点用的云平台也是不同的。像国内的话，像腾讯、阿里、Ucloud 都有用，国外像阿里云海外，还有传统的物理机也有用，中立的架构，没有特别依赖。
Q：之前看到 GME，以为都是用的腾讯。
A：有的时候会集成一些第三方的服务，让开发者接入之后，各种能力都能比较方便的使用。有一些服务也不可能所有底层公司都自己去做，比如说登录短信，也是要找合作的短信服务商，下层的技术也有合作伙伴。
Q：如果游戏包里有一些和你们重合的内容，会并存还是优先你们。比如说一些模块有类似的东西，包括排行榜这些。
A：我们属于模块化的结构，你们需要哪个模块，你们下载的就只有那些模块的功能，不会包含上面所有的功能，是你们先自己选的。
Q：我选择接入之后，会优先用你们的模块吗？
A：这也是看你们自己的调用，我们不会决定你们游戏用哪个模块，由你们自己去控制的。
TapDB 的价值与能力分享
苑志鹏：游戏内部的数据来源、数据分析这样的内容，对于每个游戏厂商都是相当有价值的。对于一些比较大的成体系的厂商，比如说腾讯、网易，它们有一套自己的准则。但我个人观察看到更多体量没有那么大的游戏，反而缺少类似的分析手段。我最近聊过一些比较独立的开发者，他们有自己接友盟的，有自己去处理的，但是实际上给出来的结论也很模糊，包括分析也并不是很准确。TapDB 我们现在已经有一些内容沉淀了，也在逐步迭代，所以想要给一些游戏开发者更多的游戏数据侧的决策支持。接下来交给 TapDB 的产品经理。
（TapDB 产品负责人陈诚）
陈诚：我在 TDS 这边负责 TapDB 这款产品，还有心动数据服务相关的工作。TapDB 官网有一个 Demo，大家可以体验一下，就能了解一个简单的概念。TapDB 是自助化接入和使用的平台产品，目前核心功能是有几个比较关键的看板，这里是我们非常基础的运营看板，只需要接入两个事件，一个账号登录，一个付费事件，就可以得到大家日常需要的数据，像留存率、付费等等这样很基础又很好用的数据，每个看板有核心的主题，里面会有细分的不同的报表，方便大家继续往下翻数据。同时还包含了广告投放监测的功能。因为 TapDB 是历时比较长的产品，我们在 2020 年 - 2021 年做了一次比较大的重构和迭代，核心加上了自定义事件上传和分析的能力，现在 TapDB 是可以比较方便上传各种各样的自定义事件，并且可以自助进行分析，上报完成之后，可以有一些 QA。
对我们来说一个很重要的问题，为什么我们会想做 TapDB 这个产品，并且把它面向开发者，至少现在是完全免费的开放。对于我们来说，因为心动自己做游戏也比较长的时间了，我们在做的过程中，自然的产生了相当多的数据需求，产生这些数据需求之后，就选择了自己开发一个数据平台产品，去承载这些需求。在使用的过程中，我们逐渐抽象出一些比较具备通用性的指标或者说用法，我们觉得这些东西是不是同样可以帮助到 TapTap 开发者，这是最早的一个初衷，希望把我们心动自己研发所使用的能力共享给开发者。
谁在使用 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：要看接哪些服务，如果全接入的话， 包体会多 100-200 兆，昨天我们小游戏的项目组也在问这个问题，它游戏包大概只有 30 兆，它接了我们的服务之后，整个游戏包体要到 100 多兆。这跟使用的功能有关系，像大部分游戏可能不会，比如说我们的十几个功能全都接入，对包体的大小增加会很小的，我们后面也会持续优化，尽可能把功能模块化，对使用部分功能的游戏尽可能只包含使用到的东西。这里面有很多后续还可以优化的地方，像有些 SDK 里面使用第三方的库，游戏里面也使用到了，之前为了避免冲突，会把我们用到的第三方，有一些情况下会存在有的库游戏页面有一份，SDK 里面也有一份，像这些后面会有更多的技术手段优化。