开发者谈数据分析和商业智能对项目重要性

原作者：Timothy Ryan 译者：Willow Wu

你是凭借自己的感觉来设计游戏的吗？

你认为自己对所在类型领域的核心机制了解得非常透彻吗？

你对自己知识面的判断是基于玩了多少游戏吗？

看到有人抄袭别人的游戏设计会让你感到反胃吗？

有人要求你为自己的设计观点进行论证，会不会让你感到不满？

你是否更在意独创性而非商业成功？

如果以上问题你所有的回答都是肯定的，那么也许，你就跟曾经的我一样，是一名非理性设计师（gut designer）。我们或许能创造出一些成功的游戏，但是也会有一些废品，或者终将会出现一些废品。这是无可避免的，因为我们并非总能做出正确的选择。设计观点和直觉在很大程度上是主观的。

就算你本身不是游戏设计师，你可能也见了不少游戏设计师之间的唇枪舌战。我们有时也会展现出相当自负的一面！游戏设计师就是由想法组成的生物，这也是别人会雇佣我们的原因。我们是玩家，主观事物是我们最擅长的领域，肩负着打造游戏的核心和灵魂的重任。但游戏最终还是要顾及商业成绩的，而不是一个单纯的用于表达自我的艺术品。这种依靠感觉的设计方式不能再继续下去了，或至少要纳入数据分析和商业智能。

背景

在我30多年的游戏开发&发行生涯中，我见证了很多变革——从单人游戏到大型多人线上游戏，从8位2D游戏到64位3D游戏再到VR游戏，从游戏卡带到光盘再到无实体游戏。最新的这次变革也带来了潜在的新商业模式和收入来源。我们不再局限于传统零售方式，而是可以通过所谓的免费游戏的微交易和广告收入来赚钱。这种盈利模式也出现在了主机和PC游戏中，并说服了发行商们接受游戏即服务的理念，持续地更新游戏从而更长久的留住玩家、提升游戏表现。由此一来，商业智能和数据分析就变得尤为重要了。产品经理也对游戏成败起到了关键作用。

关于产品经理

我已经不是非理性设计师了，我现在在公司中担任高级产品经理。不算太久之前，产品经理这个职位只出现在营销部门，他们负责广告、包装和销售渠道。首先我要强调的是，我并不是营销人员，未来也不打算进入那个圈子。所以这个职位跟游戏开发有什么关系吗？

在过去几年里，几乎所有游戏发行巨头公司都出现了这样一个角色，然而一般游戏开发团队或发行商并没有这种现象。这一角色是借鉴了SAAS（软件即服务）网站和其他软件公司。这种团队结构和职位的演变并不是什么新鲜事。早年EA公司就借鉴了电影行业，引入了“制作人”（producer）和“游戏总监”（game director）这两个职位。

就像SAAS网站和商业APP一样，现在很多游戏都是按照产品规划图分阶段发行的。每一次发行都是为了留住老玩家、吸引新玩家。这其中可能有内容更新，有一些关键优化，还有一些新特色。F2P游戏或者任何带有微交易的游戏也在尝试着将非付费玩家转化为付费玩家。这些涉及到内容、游戏货币或宝箱钥匙的微交易都有相关的游戏内广告和邮件广告，这是客户关系管理（CRM）计划的一部分。产品经理是整体产品规划、广告、以及CRM计划的主要负责人。

Alliance: Heroes of the Spire（from pocketgamer.biz）

产品经理vs游戏设计师

那么这个产品经理和游戏设计师是如何对接的，有哪些交叉领域？

1）很多设计师也会做关卡布局、状态录入和脚本创作或其他涉及源代码控制系统的工作。产品经理不做这些事，或者说不应该。

2）如果是高级主管或者总监，他们会给出设计文档。谷歌、亚马逊或Facebook把这些称为产品需求文档（PRD），而电子游戏行业则称其为游戏设计文档（GDD）或功能说明书。对于各种文件和工作职责中所要解决的why-what-how-when问题，这些设计文件针对的是why和what。不同之处就在于产品经理和游戏设计师各自的设计思维以及细节程度。

竞品分析

产品经理通过竞品分析来分辨哪些设计是有效的。很多设计要求是为了让游戏达到同价产品的水准。很多非理性设计者都不屑于这点，只专注于做出最具独创性的游戏。我想用一个比喻来反驳——汽车的制造方法有很多，但它们的功能都是一样的，如果你不想让潜在的消费者感到气恼或迷惑，那就不要重新发明方向盘，除非这种设计真的是汽车的卖点。所以产品经理首先要做的就是确定哪些游戏特色符合大众玩家需求。这一步骤可能就决定了游戏的特异之处——但应该是着眼于更加成功，也就是说，你不应该只为了特立独行而设计得与众不同，要把资源投入在真正的差异化优势上。

指标和KPIs

产品经理制作或设计仪表盘，使用商业智能（BI）呈现趋势、当前以及目标绩效。商业智能涉及到从数据源确定指标，包括应用商店购买、安装、登录、玩家进度等行为，还有玩家漏斗中的UI导航、用户规模、广告点击量、单次游戏时间等数据源，还涉及到一些非常重要的游戏指标——如收入、转化率、留存率、单次用户获取成本和生命周期总价值。产品经理就是根据这些主要绩效指标 (KPI)来制定设计决策的。

A/B测试

对于我们这些以往习惯凭感觉做事的人来说，也没有什么理由对提升KPI这种共同目标提出异议，因为这的确就是改进设计的意义所在。与其和同行设计师们争论不休，或者反驳你老板的滑稽想法，你可以通过实验来解决这些设计上的争论。你可能不知道，其实你每个月都有参与来自Twitter或Facebook的实验，因为他们要不断优化自家的应用。这是因为测试是在一小部分用户中展开的，称为队列研究（cohort study）。队列A是对照组，或者说没有任何新特色。队列B（通常是5%~10%的用户）是能够体验新特色的用户。收集了几周的数据后，开发公司比较两组的KPI，基于对比结果来决定究竟是要保持原状还是全面应用新特色。有时加入新特色的方法有好几种，你就需要队列A、队列B、队列C、队列D。这可能会让人抓狂，但只要有足够的统计数据和可信度模型，就算测试对象很有限，你也能挑选出最有效的应用方案。当然，敲定每个设计决策都可能要付出极大的成本。游戏设计师们，尤其是我们这些经历过卡带和光盘时代的人，我们曾经的想法是所有游戏的正式版都必须是完美的，因为你再也没有机会去修正了，然而现在我们应该意识到发行后还是可以继续优化提升的，你可以用A/B测试来验证你的想法。

设计细节

所以产品经理和游戏设计师在团队中是怎么合作的？首先，产品经理可能只参与发行方面的事。就跟所有出版商一样，他们应该只会给你个大致的目标框架，也就是WHAT的问题。很多时候，这些大框架需要被进一步分解，变成更倾向于HOW的问题，利用游戏设计者的专业知识来表现、改进这些创意。所以，即使他们都在同一栋楼里，产品经理也不会说得太具体，给游戏设计师和用户体验设计师一些发挥空间。只要不违背或跳出产品需求中确定好的框架，游戏设计师可以将自己的才华和独特想法应用到特色设计中，打造出一个兼具独创性和吸引力的产品。

分析性设计的倡导者

有些公司采用的另一种分工方式是让产品经理更多地关注CRM、指标、A/B测试分析、广告和游戏经济，将游戏设计等趣味事项留给创意总监。然而，这也是一个有缺陷的做法，因为不加分析或忽略游戏市场表现的创意指导注定要失败。为了避免这种情况的发生，产品经理需要大力倡导分析应用和商业智能。就像一个游戏制作人会因为预算或时间问题否决设计方案一样，产品经理也可以从数据分析的角度考虑，否决不可行的设计方案。如果新特色注定会拉低收益或留存率，或者收益对比成本投入并不划算，那就不应该加入到产品中。这就是我们这些老派非理性设计师所说的“物有所值”，这就是你应该从产品经理那里得到的反馈，而不是“不用头脑做事”，盼望着自己的感觉能够带来喜人的成果。

本文由游戏邦编译，转载请注明来源，或咨询微信zhengjintiao

Do you design games based on feel?

Do you take pride in your knowledge of core mechanics of the genre?

Do you measure your game knowledge based on the number of games you played?

Does the prospect of copying another game’s design turn your stomach?

Does someone asking you to justify your design opinion raise your hackles?

Do you favor originality over commercial success?

If the answer to some or all of these questions is YES, then maybe, like I once was, you’re a gut designer. As gut designers we may have made some successful games, but we’ve also shipped or eventually will ship a few duds. It is inevitable because we’re not always right. Design opinions and instincts are largely subjective.

If you are not a game designer yourself, you may have witnessed a design debate with a gaggle of game designers. We can be a very pretentious sort! Game designers are creatures of opinion. That is the reason we are hired. We are the gamers and subject matter experts that are entrusted with the heart and soul of the game. Yet this is ultimately a business with commercial goals, not just an art form for self-expression. This design-by-gut has to stop or at least be tempered with data analysis and business intelligence.

Background

In my 30 years making and publishing games, I’ve seen a lot of changes – from 8 Bit 2D games to 64 Bit 3D and VR games, from single player to massive multiplayer games, and from game cartridges and discs to downloaded games. It’s this last change that also opened up the possibility of new business models and revenue streams. We were no longer limited to hard-goods retail sales but could make money with so called free-to-play games with microtransactions and ad revenue. These ongoing revenue streams have made their way back into the console and PC games and moved publishers to embrace the idea of games as a service with a constant need to update the game to retain players and improve performance. This has made business intelligence and analytics extremely important. This also made the role of Product Managers critical to a game’s success.

Intro the Product Manager

I am no longer a gut designer. I am currently employed as a Senior Product Manager. Back in the not too distant past, product managers existed only in marketing departments as they dealt with advertising, packaging and the sales channel. I’d be the first to tell you that I am not a marketing person and don’t plan to be. So what does this role have to do with game development?

This is a product development role that popped up in just the last few years at every major game publisher, and yet it hasn’t made its way into every game development team or publisher. It’s a role borrowed from SAAS websites and other software companies. This evolution of team structure and roles isn’t a new phenomena. It was Electronic Arts after all that borrowed from the film industry when it introduced the “producer” and “game director” roles to game teams.

Like SAAS websites and commercial apps, many games are now released in stages according to a product roadmap. Each release is designed to retain and attract new players. This includes content packs but also some core improvements and new features. Free-to-play games or any game with microtransactions are also trying to convert non-paying customers into paying customers – what’s called conversion. These microtransactions for content, game currency or lockbox keys all have their own in-game and e-mail advertisements, which are part of an overall customer relationship management or CRM program. The product manager is chiefly responsible for this CRM program, the ads and the overall product roadmap.

Product Manager vs Game Designer

So how does this product manager role dove-tail with the game designer role and where is the overlap?

#1) Many designers also do level layout, stat entry and scripting or other forms of implementation that puts their hands in the source control system. Product managers don’t do that at all, or shouldn’t.

#2) But on a senior or director level, they both come up with design documents. Google, Amazon or Facebook will call these Product Requirements Documents (PRDs) while the video game industry calls them Game Design Documents (GDDs) or Functional Specifications. These documents universally define the WHY and the WHAT in the why-what-how-when questions that various documents and job responsibilities try to address. The difference is how they come up with their design and to certain extent the level of detail.

Competitive Analysis for Parity

Product managers use competitive analysis to identify what is working for others. Many of the design requirements are aimed at bringing the game up to parity. This is the area in which many gut-designers shirk the business goals of success and focus on the conceit of making original games, nothing derivative. I would argue with a metaphor – there are many ways of making a car but they all share certain functionality, and one doesn’t reinvent the steering wheel if they don’t want to frustrate or confuse potential drivers unless that design is really what sells the car. So a product manager first and foremost identifies the common features the game must have to meet common player expectations. Now how those are implemented may be where your game differentiates itself, but it should be with an eye to be more successful. Your design should never be different just for difference’s sake. Choose your battles. Invest in the real differentiators.

Metrics and KPIs

Product managers produce or design dashboards that report trends, current and target performance using business intelligence (BI). BI involves defining metrics from data sources such as app store purchases, installs, logins, player progress and other behavior, UI navigation in the player funnel, population size, ad clicks, session time, and ultimately some very important measures for games like revenue, conversion, retention, cost per acquisition and lifetime value. It’s these key performance indicators (KPIs) that drive design decisions for a product manager.

AB Tests

For those of us used to trusting our gut, it’s hard to argue about the common goals of increasing our KPIs, because indeed that’s the point of making improvements to the design. Instead of arguing with your gaggle of designers or pushing back on your bosses for their zany ideas, you can settle these design debates with an experiment. What you might not be aware of is the number of experiments you are subjected to every month from Twitter or Facebook as they look to improve their apps. This is because tests are conducted against a small subset of their users, called cohorts. Cohort A is the control or no new feature. Cohort B (often as little 5 to 10% of users) is seeing the new feature. Then after a few weeks of data, they compare the KPIs from A to B and make a decision based on the KPIs to either revert or commit the feature to everyone. Sometimes there may be multiple ways to implement a new feature, and you will have A, B, C and D cohorts. It can get pretty crazy, but with good statistics and confidence modeling, you can choose winners with a fairly limited subset of your players. Of course, this can get very expensive to do with every design decision. You wouldn’t want to do it with your parity features for your first release just the changes you are making to your game. Game designers, especially those of us who shipped games on cartridges and floppy discs where it all had to be perfect for the gold master cause you ain’t got any more chance to get it right, should embrace the fact that you CAN fix it and vett your ideas with AB Tests.

Design in the Details

So how do these two roles coexist on a team? Well for starters a product manager may only exist in the publishing side, and like all publishers should paint with only broad strokes as to WHAT they want in terms of goals. Very often, these broad strokes need to be broken down even further where it becomes more of a HOW question where the expertise of the game designers refine and interpret the ideas. So even if they are all in the same building, the product manager can refrain from being too specific and give some slack in the rope to the game designers and UX experts. This is how game designers can bring their unique talents and insights into the design feature to make it original and compelling, as long as it doesn’t contradict or step outside the box defined in the product requirements.

Advocates for Analytical Design

Yet another way some companies may divide the roles is to have a product manager focus more on CRM, metrics, AB tests analysis, ads and game economies while leaving the fun stuff like game design to the creative directors. Yet therein lays a flawed compromise, as creative direction done without analysis or ignoring the game performance considerations is doomed to fail. To avoid this, the product manager in these scenarios needs to be the advocate of analytics and what is commonly called business intelligence. Just like a game producer can push back on design from a budget or scheduling perspective, a product manager should push back on a design decision from a data analysis perspective, because if the new feature is doomed to reduce revenue or retention or be too big a cost for very little gain, then it shouldn’t be done. This is what us old school gut designers would call “bang for the buck”, and that’s how you should take that feedback from a product manager, rather than “shoot from the hip” and hope your gut serves you well.

（source:gamasutra.com ）