对于卡牌游戏品类而言，想要实现长线精细化运营，打磨游戏的平衡性、深度洞察玩家与公会十分重要。在这个过程中，如何通过数据分析打造出长线运营、精品化的卡牌游戏？
2023 年数造爆款·成都站，我们邀请了来自台风互动科技有限公司（以下简称“台风互动”）的制作人兼运营负责人钱维嘉 ，进行了《数据分析助力深度洞察卡牌玩家》的现场分享，解锁卡牌游戏背后的数据分析之道。
👇扫码领取 PPT &回放视频👇
以下是现场分享的主要内容整理（文字有部分删减）。
大家好，我叫钱维嘉，目前在台风互动负责自研产品的运营工作，同时也会做一些研发的工作。基于我们在卡牌品类的经验积累，今天想要跟大家分享一些卡牌品类的数据分析技巧。
卡牌游戏平衡性调整
格斗类卡牌游戏有各类竞技场和天梯，众多卡牌游戏平衡性的调整是一项长期且细致的工作，平衡性调整的基础则是建立在丰富的对局数据分析上的。在对局的日志设计中，我们常常遇到的一个问题是：记录了数据但是不太好整理。
如图所示，钱维嘉打了一场 PVP，打赢了，带的是刘备和关羽，孙笑川打了一场 PVP，打输了，带的是张飞和刘备。那么在这个场景里：刘备出场频次是 2，胜率 50%；张飞出场频次是 1，胜率 0%。
但是这个表格的处理会比较麻烦，即使用 SQL 处理也并不简单，要用到：hero_1=刘备 or hero_2=刘备， 然后需要把所有卡牌名都查一遍，再加上记录要很多字段，查询起来就更麻烦了。
想要优化这个日志和数据整理，这里推荐使用对象组的日志格式。
如图所示，对象组格式本质上是将一些相关联的数据，以数组的形式记录在同一个属性中。比如说，我方阵容中，第一个角色的 ID 是 91，第一个角色的伤害是 0，第一个角色的受伤是 27958，记录完第一个，再记录第二个角色……依次将阵容中的每一个角色的详情都记录完，然后放在我方阵容属性中。
以这种方式记录，后台数据看起来也同样是一个属性里面会挤进去很多信息。如果这里没有多个属性，只需要简单记录多组简单的属性，比如三个卡牌 ID，也可以用列表的形式记录，比如 [“15″,”25″,”35”]，也比较好用，通过这种方式，我们就可以实现更为简单的查询。
上图展示的是使用数数科技游戏大数据分析引擎 ThinkingEngine（以下简称“TE”） 的一个查询方法。我们可以直接：
· 用事件的总次数，对对象组中的 hero_id 分组，即每张卡的出场频次；
· 用事件的触发用户数，对对象组中的 hero_id 分组，即每张卡的使用人数；
· 用胜局除以总对局，对对象组中的 hero_id 分组，即每张卡的胜率。
采用这种方式，查询起来就变得更为简单。这个思路在我们内部的使用频率非常高。我们会重点关注主要流派的胜率变化，也会关注一些有特别表现的冷门卡组。
这是因为卡牌平衡性的调整是一个系统性工程，数据分析可以给到的是天梯环境的一些侧写，调整方案的确定上还是要对卡牌对局有理解和规划。
一些建议思考的维度有：
· 强度拉平——明确各卡牌定位，加强冷门卡牌，丰富对局体验；
· 克制关系——给予不同流派足够的克制压力，一套牌乱杀肯定不行；
· 商业化——配合商业投放；
· 群体照顾——尊重主流玩法乐趣，考虑主要群体的体验，如核心玩家、回流玩家、新手玩家群体等；
· 版本体验——规划不同版本内容体验；
· 对局节奏——根据游戏生态，优化局内节奏。
除此之外，还有类似：允许高操作门槛的小众玩法获得超越大众的胜率表现、策略深度调整……等等这些思考维度。
但是这一切思考都是基于天梯各类数据的基础上的，包括刚刚列举的卡牌胜率数据，还有阵容流行度数据、对局时长分布、越级挑战胜率、单卡局内表现等。如果没有数据分析做依据，平衡性调整一定类似于盲人摸象。
一方面是我们可以用虚拟属性写 SQL，再将对象组中任意需要的数据整理出来。
这里先来简单介绍一下虚拟属性。虚拟属性是将现有的每一条日志中的各个属性整理计算，生成一个新的属性的分析工具，工作中还是很常用的。这个思路本质上和我们平常写 SQL 的时候会建一些中间表、做一些简单的字段处理的思路是一样的。
使用虚拟属性是处理对象组的一个很好的手段。我们可以用遍历查询的方式，只提取出对自己有价值的结果数据，再次对虚拟属性进行整理就很方便了。
对象组在分布分析中也是非常好用的。
这里举一个我们在工作中所遇到的例子：在一个宝石养成系统中，宝石有类型、品质和等级三个属性，需要查询的是：拥有六级以上宝石数量的玩家分布。
然而，不同玩家拥有的宝石类别是不相同的，不像之前的出战卡组，都是三张卡或者四张卡，这里可能有玩家有一百多种不同的宝石，有的玩家就一个宝石。
面对这种情况，我们该如何查询呢？虽然我们可以用刚刚提到的遍历查询，但是还是比较复杂。
这种情况下，我们可以采取更简单的方法，即直接用分布分析工具。我们可以直接对等级大于 6 的宝石数量进行求和，然后查看分布情况，就可以轻松得出结果：level 大于 6，即六级以上宝石的意思；number 的总和，即对所有六级以上宝石的数量求和；最下面则是需要屏蔽的服务器。
这里我们重点讲下这个事件是否末次的计算方式。因为宝石的养成情况日志，一定是一个状态日志，这里每个玩家只需要取最近的一次日志即可。
那么该如何判断每条数据是不是最后一次呢？我们仍然可以使用虚拟属性，判断当前日志的时间和最后一次的事件时间是否相同，如果相同，那么便可以定义为最后一次事件；而最后一次的事件时间则可以用用户标签来确定。
滚服玩家分析
在重度卡牌品类，滚服引导是常见的设计，可以解决游戏生态中的很多问题。
“滚服玩家”和“新玩家”在养成、付费、参与度、留存和游戏理解上都有明显的区别。在日常的探索性数据分析中，如果问题只在“滚服玩家”或“新玩家”群体中出现，我们就可以快速圈定问题范围。
在平时的查询中，如果想要快速对比滚服玩家与新玩家的数据，我们可以使用 SQL 标签。
上图是 TE 系统中 SQL 标签的设置界面，SQL 标签是用户标签的一种类型。用户标签其实整体的思路和 SQL 查询中的中间表是类似的，就是提前给用户计算一些标签，然后在查询中直接使用这些标签。SQL 使用中间表，需要进行两个表的连接，然后才能对中间表的字段筛选、分组，用户标签的使用则简单得多，我们可以直接使用。
SQL 标签是一个比较万金油的功能，因为其他的首末次标签和指标值标签，定制化程度比较高，功能太过固定，SQL 标签却可以实现更复杂的标签制作。核心逻辑就是，比较在同一个游戏 ID 下，不同角色 ID 的注册事件的时间。时间最早的角色 ID 的标签为新服玩家，反之则为滚服玩家。
这个标签比较通用，我们在所有项目中，都加入了这个标签并一直在使用。在完成标签的制作后，使用起来就更方便了。当遇到有需要分析的数据，我们可以筛选或者分组来看。这里建议可以直接进行全看板筛选，批量操作更省心。
滚服玩家的标签，以及回流玩家标签、付费沉默标签……等等标签，这些标签内容的制作使用也是我们内部工作时所积累的工具，是公司平台化的一部分。
公会数据挖掘
其实面对这种情况，我们只需要添加“公会”为分析主体即可。在项目管理中，我们也可以进行分析主体的新增，就可以不再用默认的用户作为分析主体了。在新增公会为分析主体以后，我们就可以把刚刚说的针对用户的分析工具，比如留存、漏斗、分布、间隔、标签、分群对公会使用，从而估算公会科技升级的整体消耗。
以上是今天想要分享给大家的一些技巧。
在实际的工作当中，更为重要的是对产品和品类的理解与分析的能力，而这需要每一位游戏从业者在实际工作中不断磨炼、积累。每一个爆款产品都有其特殊性，其背后的成功之路很难做到百分之百复制。
对于品类的理解和产品逻辑能力类似于金庸小说中的内功，很难一蹴而就；而一些数据分析的工具技巧，则类似于武学招式，可以帮助我们在工作中快速上手、培养兴趣。
希望今天我分享的对象组、SQL 标签和转换分析主体的三种技巧，可以为大家的能力树锦上添花，与内功修炼相辅相成，打造出新的爆款产品。
关于「数造爆款」
数数科技游戏数据分析沙⻰旨在搭建⼀个开放的交流平台，分享数据分析驱动业务的实战案例，让更多游戏⼈掌握数据分析技能，并运⽤这些知识解决实际场景中遇到的难题，让数据价值触⼿可及。
过去，我们已经⾛过了杭州、武汉、⼴州、深圳、成都、北京等众多城市，邀请了⼼光流美、掌游科技、诗悦⽹络、Habby、玩蟹科技等知名游戏公司的资深游戏⼈，将⾃⼰的数据分析经验倾囊相授。
如今，「数造爆款」已经成为游戏数据分析领域极具代表性和影响⼒的知识分享交流平台。我们将充分发挥自身的纽带价值，聚焦更多资深游戏人，给行业带来更深、更全、更新的硬核内容，共同推动游戏行业创新发展。
END
关注公众号
在线咨询