開發者談數據分析和商業智能對項目重要性

原作者：Timothy Ryan 譯者：Willow Wu

你是憑藉自己的感覺來設計遊戲的嗎？

你認爲自己對所在類型領域的核心機制瞭解得非常透徹嗎？

你對自己知識面的判斷是基於玩了多少遊戲嗎？

看到有人抄襲別人的遊戲設計會讓你感到反胃嗎？

有人要求你爲自己的設計觀點進行論證，會不會讓你感到不滿？

你是否更在意獨創性而非商業成功？

如果以上問題你所有的回答都是肯定的，那麼也許，你就跟曾經的我一樣，是一名非理性設計師（gut designer）。我們或許能創造出一些成功的遊戲，但是也會有一些廢品，或者終將會出現一些廢品。這是無可避免的，因爲我們並非總能做出正確的選擇。設計觀點和直覺在很大程度上是主觀的。

就算你本身不是遊戲設計師，你可能也見了不少遊戲設計師之間的脣槍舌戰。我們有時也會展現出相當自負的一面！遊戲設計師就是由想法組成的生物，這也是別人會僱傭我們的原因。我們是玩家，主觀事物是我們最擅長的領域，肩負着打造遊戲的核心和靈魂的重任。但遊戲最終還是要顧及商業成績的，而不是一個單純的用於表達自我的藝術品。這種依靠感覺的設計方式不能再繼續下去了，或至少要納入數據分析和商業智能。

背景

在我30多年的遊戲開發&發行生涯中，我見證了很多變革——從單人遊戲到大型多人線上遊戲，從8位2D遊戲到64位3D遊戲再到VR遊戲，從遊戲卡帶到光盤再到無實體遊戲。最新的這次變革也帶來了潛在的新商業模式和收入來源。我們不再侷限於傳統零售方式，而是可以通過所謂的免費遊戲的微交易和廣告收入來賺錢。這種盈利模式也出現在了主機和PC遊戲中，並說服了發行商們接受遊戲即服務的理念，持續地更新遊戲從而更長久的留住玩家、提升遊戲表現。由此一來，商業智能和數據分析就變得尤爲重要了。產品經理也對遊戲成敗起到了關鍵作用。

關於產品經理

我已經不是非理性設計師了，我現在在公司中擔任高級產品經理。不算太久之前，產品經理這個職位只出現在營銷部門，他們負責廣告、包裝和銷售渠道。首先我要強調的是，我並不是營銷人員，未來也不打算進入那個圈子。所以這個職位跟遊戲開發有什麼關係嗎？

在過去幾年裏，幾乎所有遊戲發行巨頭公司都出現了這樣一個角色，然而一般遊戲開發團隊或發行商並沒有這種現象。這一角色是借鑑了SAAS（軟件即服務）網站和其他軟件公司。這種團隊結構和職位的演變並不是什麼新鮮事。早年EA公司就借鑑了電影行業，引入了“製作人”（producer）和“遊戲總監”（game director）這兩個職位。

就像SAAS網站和商業APP一樣，現在很多遊戲都是按照產品規劃圖分階段發行的。每一次發行都是爲了留住老玩家、吸引新玩家。這其中可能有內容更新，有一些關鍵優化，還有一些新特色。F2P遊戲或者任何帶有微交易的遊戲也在嘗試着將非付費玩家轉化爲付費玩家。這些涉及到內容、遊戲貨幣或寶箱鑰匙的微交易都有相關的遊戲內廣告和郵件廣告，這是客戶關係管理（CRM）計劃的一部分。產品經理是整體產品規劃、廣告、以及CRM計劃的主要負責人。

產品經理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 ）

相關文章