超110个国家发行，热门放置游戏如何快速提升数据效能？

【GameLook专稿，未经授权不得转载】

GameLook报道/3月23日，数数科技主办的「数聚新生·游戏数据分析行业沙龙」首期线上直播邀请到了资深海外游戏运营Hay，基于一款代表性放置游戏的海外发行经验，为各位分享提升数据效能的经验指南。

该游戏于2019年上线海外市场，目前已在超过110个国家和地区成功发行，曾进入过美国下载榜前二十、畅销榜三十名。

作为项目的海外运营负责人，Hay认为项目的成功与团队对用户、产品维度相关指标的数据分析密切相关。得益于有效数据赋能，团队在后续对产品进行了成功运营调整。会上，Hay就如何快速提升数据效能进行了分享。

以下是GameLook整理的演讲实录

该游戏在2019年开始上线海外市场，目前发行超过110个国家，曾进入过美国下载榜前二十、畅销榜三十名左右。

那么该游戏能有这样的成绩，数据其实一直提供着强有力的赋能作用。首先我们从产品出发来简单聊一聊，作为放置类产品，我们会更关注哪些游戏指标？

我觉得第一点是用户的成长反馈。玩家在放置一段时间后需要得到一定的成长反馈，例如关卡的进度、开放的新功能、获得的新角色等。当然每一次成长反馈需要放置时长，会随着游戏阶段的延后慢慢增长。

因此，需要关注的数据就是等级成长、等级流失、副本成长、副本流失，以及对流失原因的一个深入分析。得到这些数据之后，我们就可以进行调整日常产出、副本难度、系统开放等等，来让玩家获得更合适的成长反馈时间。

第二点就是用户的行为习惯。像放置类这种收菜的玩法会更易于玩家养成习惯，它非常不容易改变，而且具有地区差异性。其实放置类产品在前期会有一个特殊性，因为大R用户可以加快放置的进度，他们会体验更多的内容，同时获得更多资源，能对阵容策略有更多的研究。因此就会出现一个现象，越氪的人往往也会越肝。

亚洲用户会完美符合这个特征，而欧美玩家会相对佛系很多，当然欧美内部也会有区别，例如说欧洲玩家非常的活跃，但是他们会花大量的时间在如聊天等事情上。因此我们需要了解各个地区的用户习惯，并进行取舍。

最典型的就是在线时长登录频次，也会有玩法的偏好，这个要因游戏而异。在获取这些数据并了解地区差异化之后，就可以做很多的事情。比如依据用户的习惯进行功能调整，或者说当我们需要调整用户习惯的时候，也会需要用到数据来进行循序渐进。像是拉高长线留存需要更高的在线时长，但是在线时长增长需要循序渐进。

我们刚才也提到发行了很多的国家地区，不同地区对数据指标又会有怎样的侧重呢？首先我们会针对不同地区制定不同的核心指标要求。就拿留存和付费这两个核心指标来说，比如在东南亚等T3国家，关注重点会在于留存，而美国等T1国家，我们对留存和付费都会有一定的要求，具体要求多少也需要和投放成本进行关联，这边我就不详细展开了。之后，我们就可以依据不同国家数据以及服务器生态要求，及时在投放侧对各国家地区人群进行调整。

第二点，我们会关注不同用户的用户喜好。例如欧美地区在我们游戏中会更喜欢收集卡牌进行PVE推关，对于PVP关注度相对较低，因此会造成数值类的道具相对难卖。而亚洲用户更多以强度为最终目标，因此他们在不同道具中的花费占比会有一定的不同。

不同地区的玩家喜好在不同游戏中也会有所不同，因此我们要根据数据尽快地发现玩家的喜好，并对不同地区的数据进行取舍，来对版本进行调整。当然这个调整可能是遵循玩家喜好去做一些功能、优化，也可能是去通过引导来改变玩家的喜好。

刚才我们提到了很多的数据，那么如何提升数据的效能？首先我们从最基础的数据分析流程来看，也就是数据采集——经过数据分析提出假设——通过数据分析验证假设的最基础的流程。

在游戏中，这个假设可能是内部讨论的想法，也可能是功能或者是优化。当然这个假设或者改动也不一定完全依靠数据分析，也可能是游戏理解或者玩家反馈等等。在这个基础流程中，我们要提升数据效能，首先在数据采集上要保证数据准确性的同时，增强数据在运营策划或者分析师手上的易用性。另外，这部分数据分析提升效能的一个有效方式就是模板化。

这里举两个例子，分别是全球化游戏的时间处理和礼包分析的模板化。

从全球化游戏的时间处理开始。先来看一下全球化游戏和单地区发行游戏在时间上的区别。一是玩家真实所在的时区是有差异的，玩家可能会处于服务器时区和他生活时区不一样的环境中进行游戏。二是游戏服务器可能会设置多个不同时区的服务器供玩家选择，可能还会有中心服的概念对玩家进行分流。另外，不同时区的服务器会存在冬夏令时的问题。

那这里会遇到什么样的问题或者注意点呢？首先分析时间的维度会有一定的变化性。例如在同一时刻可能某一个时区的服务器活动。另一个时区的服务器活动还没开，做数据分析时就就需要用到服务器时间来进行。而一些财务相关的结算一般要需要用到北京时间来整理。

其次就是时间使用上的人群会非常的多，因为时间不只用于数据分析，例如客服确认问题，运营进行BUG补发的时间确定都会用到。我们也曾经历过小伙伴搞错时区，采集错误的数据，导致发放了错误补偿的事件。因此这一块的易用性其实是非常重要的。

在使用数数之前，我们采用的是纯SQL语句的形式来获取和整理数据的。这种方式确实有一个好处，就是任何的需求都可以很轻松来满足，毕竟可以用SQL函数去随意修改自己想要的时区，但就会有一些易用性的问题。比如使用者需要一定的功底，必须对每一张数据表所在时区非常很清晰，这对于一些新同学来说其实是非常折磨的。

这个问题在接入数数科技后也得到了彻底解决。数数科技可以对项目设置一个时区偏移属性。同时在进行数据分析时，可以基于这个属性改变分析的时区维度。因此我们需要做的就是在记录时间的同时，获取此时间的时区偏移属性。

接下来以iOS端为例。该游戏拥有美区、亚区、欧区三个大区，服务器间分别所属纽约时间、北京时间、巴黎时间。在新用户进入游戏时，会根据用户特征分配到指定大区的服务器，开始正常游戏。会有非常多的用户，他们的时区跟游戏中的服务器时间是不一样的，而且本身服务器时间也会有一定的差异化。

在游戏中，我们会遇到这四个时间，分别是用户手机时间、用户所在时区的时间，游戏三个大区的服务器时间，以及后续用到的数据分析用时间，如创角时间、首次充值时间等等。

因为用户可以自己修改手机时间，所以用户手机时间和所在时区的时间会有差异，甚至用户手机时间可以在未来。所以用户手机时间其实是需要舍弃或校准的参数。

因此第一步需要在数数客户端SDK初始化完成的时候，第一时间用苹果公司的NTP服务对时间进行校准。后续客户端SDK采集到的时间就是准确且带有时区偏移属性的用户所在市区时间。

那么剩下的就只有三个时间。这里需要特别注意“数据分析用时间”，因为数数的时区转换仅针对于事件时间，而像这种数据分析用时间或者后续一些通过计算来得到的用户标签，需要时区转换的时候，会用到虚拟属性。一是增加操作，另外会提高使用者的要求，降低数据易用性。因此我们需要让更多的时间进行统一。

因此第二步，在用户连上服务器的第一时间，我们又做了一次时间校准，将时间校准到了服务器的时间，同时记录下了他所在的大区。

我来解释一下为什么会选择服务器时间来进行校准。首先第一点，该游戏不同的服务器时间不同，我们需要进行维度的统一；第二点是服务器时间是我们游戏最常使用到的分析维度，这个大家需要根据自己游戏去进行判断；第三点，后续我们记录的分析用时间，如注册时间等，都是依据服务器时间来进行采集，所以我们选择了服务器时间。

那么，我们为什么要记录大区属性？第一点是因为iOS的服务器时间是依据大区而定的，记录大区其实是为了后续通过虚拟属性计算来得到不同大区时区偏移属性。第二点，因为冬夏令时的原因，直接获取时区偏移属性会比较麻烦。当然如果能直接获取的话，直接获取也是可以的。

以下是使用虚拟属性来获取时区偏移属性的代码。简单逻辑就是先通过一定的数据特征来判断是否进行服务器时间的校准，如果没有就直接采用数数客户端SDK采集的时区，也就是#zone_offset这个字段。如果进行了校准，就先判断大区，再判断冬夏令时，然后去分配一个指定的时区。之后，就可以通过时区偏移统一时区。除了启动游戏连上服务器之前的日志是用户的当地时间，其他全是服务器时间。另外我们也可以对这边获取到了当前时间做用户标签，后续通过标签分析不同时区用户在游戏中的一些行为差异。

另外需要指出的是，这部分希望大家能够在设计埋点的时候，更多地去思考数据在未来的使用场景，而不是简单地把数据记录下来那么简单，不然很可能会遇到数据无法使用或者使用很麻烦的问题。

第二部分是礼包分析的模板化。

相对于礼包来说，相信大家最想知道的是“什么样的用户会去购买什么样的礼包”。因此我们首先将用户和礼包进行了一个拆解。我把用户拆解到两个维度：一是不同的付费能力，对应大中小R；二是不同的游戏阶段，也就是游戏的前、中、后期，这个维度包含游戏天数、玩家等级、玩家战力等等，不同游戏会有所不同，需要大家自行判断。

对于礼包，我拆解成了礼包内容和归属系统，礼包内容很简单，就是玩家购买礼包实际想要获得的道具。归属系统则是因为不同的系统在游戏中会存在着不同的曝光度和折扣，因此它具有很强的分析意义。“模板化”就是根据这些维度去进行分类，得到每类、每周期内的指标值。

举个例子，我制作、获取了每日、每个游戏阶段玩家的付费占比。因为这边是举例的数据，所以会显得稍微有一些乱。正常的数据一般可以看出变化趋势，我们由此可以比较便捷地去验证版本活动有没有达到预期的效果。

借着这四块内容，我形成了四个看板，从这四个维度对每日付费情况的变化进行观察，这个也确实帮助我们的产品做了很多的决策。下面我分享一下用数数如何建立这样的看板。

首先我们从用户层面的看板开始。第一步就是设置游戏阶段和付费能力的用户标签，将这两个维度进行一定的分组。类似这个例子，我将充值进行了多类分组，分类具体要看游戏的数据分析需要。

第二步就是使用事件分析，对每一个分好的阶段建立指标。以付费占比为例，我对每一个付费区间计算指标——其实就是满足付费区间的充值，除以每日的总充值额，并按月展示，就获得了该数据。我们会发现，头部充值玩家的占比其实是不断走低的，而游戏侧并没有针对对低付费人群进行一些改动。通过进一步分析，我们发现头部地区的大R玩家，他们的阵容其实基本已成型，卡牌趋于一个饱和的状态。而该地区对于购买数值的兴趣度不高，导致了充值下滑。

第三步就是建立ARPU、付费率等看板，强化应用的场景。比如在思考提升哪个游戏阶段的充值额对收入更有意义时，我就会选择去看收入百分比。而在思考不同游戏阶段用户的付费动力是不是有所下滑，我就会去看ARPU。

接下来是礼包层面。礼包层面相对复杂一点，并且有一些需要特殊处理的东西。首先第一步，我们需要对每一个礼包设置维度表，在维度表中设置它的主要商品跟所属系统。例如我给每个礼包添加主要商品跟搜索系统，在每次更新礼包时及时维护这张维度表即可。

礼包方面会存在一些特殊情况，比较典型是运营推送礼包和自选礼包，在获取这两个值的时候需要进行额外的处理。运营推送礼包其实就是由运营去根据线上的情况和玩家的特点，额外推送的适配礼包。它具备几个特征，一是它的配置周期间隔比较短，经常需要做调整。

第二个是每个礼包都拥有各自的id，礼包种类非常多，该放置游戏每周会产生超过一百五十个运营推送礼包。如果都把它们都加入维度表的话，维护成本会大大增加，同时整张维度表会非常臃肿。

那么我们要如何对这种礼包进行处理呢？首先我们会在运营推送礼包记录埋点的时候，给予一定的特征性。例如充值记录中会有一个自行配置的描述字段，以这个礼包为例，它的描述前两个字培养，说明这是培养用的道具。而运营的标识则表明它是运营推送礼包。

第二步就是通过虚拟属性去获取所有礼包的归属和主要商品。其实主要就是对推送礼包增加一些判断。例如，归属的简单逻辑就是如果这个礼包满足推送礼包的标识，那么它的归属就是推送礼包，否则就会取礼包ID维度表中的值。礼包内容同样如此，如果满足推送礼包的标识，那么礼包内容取描述的前两次，否则取礼包ID维度表的值。

接下来是自选礼包。自选礼包大家都很熟悉，礼包实际购买商品是依靠玩家主动进行选择的，它会具有一定的不确定性，无法使用维度表来进行匹配。

那么首先我们需要增加一个埋点，去记录自选礼包玩家选择的道具代码，并且通过维度表来获取售卖的实际道具。记录的时候需要额外记录一些其你需要用到的信息，比如礼包价格，后续可用来计算。

第二步就是通过虚拟属性，将自选礼包商品选择的日志与充值日志进行一个合并。然后再通过虚拟属性去获取实际的商品。最终的虚拟属性如图所示，即先判断是否为合并过来的自选礼包日志，如果是则取自选礼包中的获取到的主要商品，如果不是则重复先前运营推送礼包的判断。

最后是事件分析建立看板。与用户层面相同，使用数据分析对每种礼包、归属、收纳道具建立指标。需要注意的是，由于通过了虚拟事件的合并，自选礼包数据会存在两份，需要把原充值表中的自选礼包删除掉。

以道具付费占比为例，我增加了每个道具的指标，并在全局筛选中去除了重复的自选礼包，然后就可以得到一个数据，以及每天玩家在每种道具上的付费占比。

另外这些维度其实是可以组合进行更深维度的分析。例如当你想知道后期玩家选择商品的变化趋势，就可以在售卖商品的看板中加入后期玩家的筛选即可，非常方便。因为像我们的游戏，它主要收入来源是售卖卡牌，如果这些后期玩家卡牌收入占比越来越低的话，那么游戏中后期的商业化就可能存在一些问题，届时我们就得想一些措施了。