Revenue Recognition v30.doc

The Guidelines for Implementing aRevenue Recognition System forVirtual Goods in F2P Mobile GamesVersion 30BNGA, January 27, 20151. Revenue Recognition in Social Games and Free-to-Play Titles对于社交网络和F2P的收入确认Social games and free-to-play (F2P) titles are available for both mobile, console, and PC. 社交游戏和F2P的标题可以适用于手机，控制台，和PC。For these games and the corresponding sale of virtual currencies/goods, 对于这些游戏和相应的虚拟货币和商品的销售the Company will recognize revenue in accordance to SAB Topic 13. 公司将按照SAB Topic 13确认收入At the time the virtual currency or virtual good is purchased, 当购买了虚拟货币和商品的时候generally the only remaining revenue recognition criterion to be met is that of delivery大体上来说剩下的收入确认已经交付了 (i.e., delivery has occurred or services have been rendered例如交付已经实现或者服务已经呈现). In most situations在大多数情况下, a user purchasing a virtual good expects that good will be available anytime s/he plays the game当一个用户购买了虚拟商品那么那个商品对于用户来说应该是随时可以使用的 (i.e., the period of delivery for the virtual good is not clearly defined). The revenue recognition model selected by the Company is dependent upon the Company having the appropriate data to support its revenue model.公司选择相应的收入确认模式应该按照其支持的数据2. Main revenue recognition models in social games and F2P titles对于社交游戏和F2P的主要收入确认2.1 Game-based revenue model (M1)游戏基本盈利模式i) Revenue from the sale of all virtual goods is recognized ratably over the estimated life of the game虚拟商品的收入应该是根据游戏寿命可股价的ii) If there are no internal data, then the Company may rely on industry data of similar type of game如果没有永久数据，公司应该根据产业数据，和类似游戏类型2.2 User-based revenue model (M2)用户基本盈利模式i) Revenue from the sale of all virtual goods is recognized ratably over the estimated life of an average user 虚拟商品的收入应该根据平均用户游戏寿命可股价的ii) Average user life is determined from the time a user purchase a virtual good to when the account is inactive:平均玩家游戏寿命是被当玩家购买了虚拟货品到账户不活跃的时间所决定的a) The Company considers a user account that has been idle for 30 days,用户30天不上线视为不活跃 to be inactive. (example: if a user account was active for 6 months and then is idle for 30 days, then the life of that account is 6 months如果用户上线6个月，然后30天不上线，那么这个账号寿命为6个月)b) After 180 days of inactivity, the Company will recognize revenue on any unused currency.2.3 Item-based revenue model (M3)项目基础盈利模式Revenue will be recognized based on the nature of the virtual goods:收入确认根据虚拟物品的特性a) Consumable goods (drink, power boost) revenue can be recognized when fully consumed or at expiration date.消耗商品如饮料等当消耗完或者到期了已经可以被确认 For the time being, for revenue recognition, we will treat consumables as durables (revenue recognized ratably over the consumable estimated life). 暂时，为了确认收入，我们把消耗品看做不可消耗品（根据估计的消耗时间确认收入）The consumption-based model for consumables will be developed later.根据消耗基础模式的东西马上再说b) Durable goods (car, house) revenue recognized ratably over their est. life (or life of an avg. user)不可消耗品例如汽车房子-根据他们预计寿命确认收入Fig.1 Nested models (M1 is required for M2, and M2 is required for M3)这个图看不懂告诉我，涉及到逻辑学，解释你们也听不懂3. Implementation安装启动HTTP headers should contain a custom header with a game title, e.g. X-Game-Title: Outcast-Odyssey Http页眉应该包含一个有游戏标题的自订页眉The data from the test devices and/or the test accounts should not be sent to the production TX site. 测试设备和测试账号的数据不应该发送到产业TX地址Please make sure that the data from the test devices and/or the test accounts is sent only to the test TX site (e.g. 确保他们只发送到测试tx地址/txAPI/test/)!Watch for fake purchase receipts! 小心假的购物收据Developers must validate the in-app purchase receipts before sending the transaction info to the TX server.研发者在发送给tx服务器之前必须验证APP内的购买收据 That is, game server (not the game client) should securely send the receipt to a service controlled by the developer, then have that service confirm with Apple that the receipt is legitimate.确保收据的合法性 If it checks out, 如果确定了that service can then tell the application to honor the receipt.就可以说这张收据是真的了 We recommend that developers dont discard the fake receipt transactions but log them separately in a local log file for future analysis.我们建议开发人员不抛弃假收据交易,但他们分别登录本地日志文件为未来的分析。收入确认、虚拟优惠包必须被分解成单个组件。For revenue recognition, virtual good bundles have to be broken down into individual components. Each component should generate its separate transaction.每个组件应该生成单独的事务Use the same User IDs across multiple data systems: 跨多个数据系统因该使用相同的ID game database, analytics (e.g. Flurry), revenue recognition, etc. To pass UIDs to Flurry:游戏数据 分析On iOS (converted from a C string): NSString* userId = NSString stringWithCString:pUserID encoding:NSASCIIStringEncoding; Flurry setUserID:userId;On Android, the FlurryAgent Java class has a setUserID method as well (/sdkdocs/android/v3.3/classcom_1_1flurry_1_1android_1_1_flurry_agent.html#a16388fb0539d09869c553078ca698403)In production environment, 在产业环境中JSON objects or compressed logs (with JSON objects) should come directly from the game servers (no proxies or any intermediate agents please).JSON objects or compressed logs (with JSON objects) 应该直接来自游戏服务器（不要有任何代理）The TX server is now available to receive postings.Posting methods:a. For an instant post, for example to Table 1, use this URL: /txAPI/test/?accessKey=test&tbl=1 To post to Table 2, use: /txAPI/test/?accessKey=test&tbl=2Command line example to test posting to Table 2:# json=gid:65656,uid:bnga1740,ts:2014-09-24 23:59:59, “aux”:”4” # curl -XPOST -H X-Game-Title:Big-Bang -d $json /txAPI/test/?accessKey=test&tbl=2You should receive ok response after a successful post. 你发布成功了之后会得到一个“ok”回应If you get failed to insert data, 如果插入数据失败that means that identical/duplicate records have been entered into Table 2 in the past.那说明之前重复的记录被插入进了Table 2 RDBMS will reject duplicate data according to a primary key setting. RDBMS会在主要设定中拒绝重复数据You may need to modify your JSON object and retry. 你需要修改你的SON object然后再试一次b. For log-file upload, use: /txAPI/test/?accessKey=testThe command line example:# curl -i -H X-Game-Title:Big-Bang -F file=65656_tb1_2014-07-24.log.gz /txAPI/test/?accessKey=test Please keep in mind that a successful posting will return an ok response.记住成功发布后会收到一个“ok”回应 If you havent received an ok response, you may or may not get an error message, 如果你没收到，你也许会也许不会得到一个错误的信息e.g. if network times out. Please make sure that you receive an ok response, before considering the post successful!如果网络超时，确认你会收到一个“ok”回应3.1 For games that have a game server对于有服务器的游戏For games that have a game server, there are two ways to send the revenue recognition data from the game server to the transaction server.对于有服务器的游戏，有两种方式可以发送确认收入从游戏服务器到交易服务器 We recommend implementing both ways (3.1.1 and 3.1.2) and implementing a programmatic switching between the two, e.g.我们建议两个都使用if (method = 312) Write the JSON object to the local log fileelse Send the JSON object immediately to the TX server via https3.1.1 Sending data in individual JSON objects immediately when transactions occur当交易发生时立即给独立JSON objects 发送数据The developers may choose to implement this method first and then extend it to the more efficient method described in 3.1.2.研发者可以先用这个方法再扩展到更有效的方法中类似于3.1.2Game server (not the game client) should construct JSON objects, which carry the information specified by the Tables below. Game server should then send these objects with POST method to Transaction (TX) server by calling the URLs:游戏服务器应该建立JSON objects，携带下面的详细数据。游戏服务器应该用POST方法发送到TX 服务器通过这些URLs /txAPI/?accessKey=xxxxxxxxxxxxx&tbl=enum(1,2,3) /txAPI/?accessKey=xxxxxxxxxxxxx&tbl=enum(1,2,3)Each title will be pre-assigned to one of the TX servers and the accessKey will be issued to each game server node. Param tbl is one of the three values which points to target TX tables respectively.JSON notation should use the double quote( “) on both key-value pair for both alphabetical andnumerical values. For example, “gid”:”1740”, “uid”:”some-kind-of-hash-value”,”vg_qty”:”16.5”On successful posting,当成功发布 game server will receive ok response from TX server. 游戏服务器会从TX服务器收到一个“ok”回应。In case of the network interrupt or unavailable TX server, 为了预防网络被干扰和tx服务器的不可用game server should log transactions to a local file to keep journal going. 游戏服务器应该在本地文件中登陆交易确保分类账的继续Game server should send the journal log to the transaction server using the method described in 3.1.2 at the end of each day.游戏服务器应该在每天结束的时候用3.1.2的方法登录交易服务器发送分类账Use the following URL to test posting./txAPI/test/?accessKey=test&tbl=enum(1,2,3)Example: Sending a JSON object to Table 2 /txAPI/test/?accessKey=test&tbl=23.1.2 Writing/batching data into a local log file as transactions occur and uploading log file once a day每日交易完成和上传登录文件时写入/批处理数据This method is faster, more robust, and more scalable than that in 3.1.1 above. 这个方法更快，更野蛮，比3.11伸缩性更强This method is recommended to handle a large number of concurrent users and a large volume of transactions. 这个方法建议在用户在线人数庞大和交易量庞大的时候使用Instead of making millions of https calls a day, 以代替每天做很多https it batches data in the local log files and uploads them to the transaction server once a day.他在本地登录文件中批处理数据并且每天在交易服务器中上传Every day, at 00:00:01 am UTC, game server should open 2 local empty log files named:a) gameid_tb1_date.log (e.g. 65442_tb1_2014-06-17.log)b) gameid_tb2_date.log (e.g. 65442_tb2_2014-06-17.log)For every in-game transaction and every game launch, game server should construct JSON objects, which carry the information specified in tables 1 & 2 below. During the day, game server should write these objects into log files (a) and (b).Every day, at 00:00:01 am UTC, game server should log files (a) and (b) from the previous day, compress them using gzip, in separate files, e.g.gameid_tb1_date.log.gz (e.g. 65442_tb1_2014-06-17.log.gz) gameid_tb2_date.log.gz (e.g. 65442_tb2_2014-06-17.log.gz) and upload the compressed files using POST method to the following transaction servers: /txAPI/?accessKey=xxxxxxxxxxxxx /txAPI/?accessKey=xxxxxxxxxxxxxIf upload is unsuccessful, send the gzip together with the future gzips next day.如果上传失败，和下一天的gzips一起上传Each title will be pre-assigned to one of the TX servers and the accessKey will be issued to each game server node.JSON notation should use the double quote( “) on both key-value pair for both alphabetical andnumerical values. For example, “gid”:”1740”, “uid”:”some-kind-of-hash-value”,”vg_qty”:”16.5”In case of network interrupt or unavailable TX server, game server should keep the log files locally and attempt to upload them to the TX server later.为了防止网络瘫痪和tx服务器不可用，应该保存本地数据库和再尝试上传Use the following URL to test log file uploading. /txAPI/test/?accessKey=test3.2 For games that do not have a game server (this section is under construction)给那些没有游戏服务器的游戏For games that do not have a game server, there are two ways to send the revenue recognition data to the transaction server.对于没有游戏服务器的游戏，有两种方法给交易服务器发送收入确认 The BNGA team will set up a “dummy” game server (DGS) for such games, BNGA团队会为了这样的游戏建立一个DGSso that game clients can send the revenue recognition data to the transaction server (via DGS).所以游戏伺服器可以给交易服务器发送收入确认（通过DGS）3.2.1 Writing/batching data into a local log file as transactions occur and uploading log file once a game session ()At the beginning of every game session, game client should check if the log files with the following names exist 每个游戏会议开始时候，游戏伺服器要检查每个存在的民称的上传文件a) gameid_tb1_date.log (e.g. 65442_tb1_2014-06-17.log)b) gameid_tb2_date.log (e.g. 65442_tb2_2014-06-17.log)and try to upload them to the DGS. If it cant upload, it should not retry and move along. After uploading or failing to upload, game client should re-open 2 local empty log files named:再试着在DGS上上传他们，如果不能上传，就不能重试和接着来。a) gameid_tb1_date.log (e.g. 65442_tb1_2014-06-17.log)b) gameid_tb2_date.log (e.g. 65442_tb2_2014-06-17.log)For every in-game transaction and every game launch, game server should construct JSON objects, which carry the information specified in tables 1 & 2 below. During the day, game server should write these objects into log files (a) and (b).每一个游戏内交易和每一次游戏启动，游戏服务器应该建立JSON objects, 它携带者具体的信息在下面的1,2中。 https:/dgs_/txAPI/JSON notation should use the double quote( “) on both key-value pair for both alphabetical andnumerical values. For example, “gid”:”1740”, “uid”:”some-kind-of-hash-value”,”vg_qty”:”16.5”Use the following URL to test log file uploading. https:/dgs_/txAPI/test/4. Table descriptions Table描述These tables reside on the transaction server and are designed to receive revenue recognition data from game servers.4.1 Table 1 (required for M1, M2, and M3 revenue models) Transactions are made in real-world or in-game currencies Every time in-game currency is acquired by the user, its a transaction that has to be recordedo If in-game currency is acquired with real-world money, the transaction has a non-zero USD value (or whatever the receipt currency type is)o If in-game currency is acquired for free (e.g. reward/gift), the transaction has a zero USD value and “USD” in the currency type field Every time currency (real or in-game) is spent, its a transaction that has to be recorded4.1.1 Header Section GID(Game ID, 32-bit integer, SKU Number from BNGA Finance, ask your Producer) UID(User ID, either number or string, e.g. Apple or Google assigned ID, or a game own internal user ID. UID should survive between game re-installs. UID should be the same if the game is played by the same user on multiple devices. The iOS UID may be different from the Android UID) TS(Time Stamp in MySQL format, i.e. “2008-11-24 11:45:34”) TXID(Transaction ID, 64-bit integer, initialized to 0 and incremented by 1 before each transaction. The very first transaction should have TXID=1. Separate transaction counters should be implemented PER user UID PER game GID, i.e. in the database, a primary key is based on (GID,UID,TXID) AUX(AUX parameter, a 32-bit integer, may be used by developer for a variety of purposes, e.g. to specify a bundle number, currency sub-type, some user info, etc. Please initialize to 0 and reserve 0 to mean “undefined”)4.1.2 Virtual Goods Section VG_TYPE(Virtual goods type, i.e. IGC, DUR, CON, INS, 8-bit integer ENUM)o IGC = 1(In-Game Currency, e.g. tokens, gold, gems)o DUR = 2(Durable virtual goods, e.g. cars, armor)o CON = 3(Consumable virtual goods, e.g. potions, bullets)o INS = 4(Instantaneous offerings/service, e.g. instant car delivery, level unlock) VG_ID(Game specific virtual item ID, 32-bit integer, e.g. Helmet = 101, Token = 201. Items and their respective upgrades should have their own unique VG_IDs) VG_QTY(Quantity of virtual goods, 32-bit floating, e.g. 7.30 )4.1.3 Currency Section CUR_TYPE(Currency Type. For real-world currencies, use 3-character strings as defined in ISO 4217 currency codes, e.g. “USD”, “CAD”, “EUR”. For in-game currencies, use 32-bit integers, which represent VG_ID, e.g. 0x0201. Please acquire the local currency type and amount paid from the Apples/Googles purchase receipts and send this info to the TX server). CUR_QTY(Currency Quantity, 32-bit floating, e.g. 1,000, or 7.50)Example 1: JSON object for a purchase of 10 in-game tokens using USD 7.50 “GID”:“0033”, “UID”:“0004”, “TS”:“%Y-%m-%d %H-%M-%S”, “TXID”:“0001”, “AUX”:“0000”, “VG_TYPE“:“1”, “VG_ID”:“0201”, “VG_QTY”:“10.0”, “CUR_TYPE”:“USD”, “CUR_QTY”:“7.50” Example 2: JSON object for a purchase of 5 in-game tokens using USD 5.50 for UID456 (using a separate TXID counter) “GID”:“0033”, “UID”:“0456”, “TS”:“%Y-%m-%d %H-%M-%S”, “TXID”:“0001”, “AUX”:“0000”, “VG_TYPE“:“1”, “VG_ID”:“0201”, “VG_QTY”:“5.0”, “CUR_TYPE”:“USD”, “CUR_QTY”:“5.50” Example 3: JSON object for a purchase of 1 car with 5 tokens “GID”:“0033”, “UID”:“0004”, “TS”:“%Y-%m-%d %H-%M-%S”, “TXID”:“0002”, “AUX”:“0000”, “VG_TYPE”:“2”, “VG_ID”:“0445”, “VG_QTY”:“1”, “CUR_TYPE”:”201”, “CUR_QTY”:“5” Example 4: JSON object for a purchase of an instant car delivery option with 2 tokens “GID”:“0033”, “UID”:“0004”, “TS”:“%Y-%m-%d %H-%M-%S”, “TXID”:“0003”, “AUX”:“0000”, “VG_TYPE”:“4”, “VG_ID”:0503, “VG_QTY”:”1”, “CUR_TYPE”:“201”, “CUR_QTY”:“2” 4.2 Table 2 (required for M2, M3 revenue model) User activity records are sent as JSON objects Every time a user launches a game, a game client should try to connect to a game server and request sending a user activity record to the TX server or writing the record into a log file local to the game server. If a game device/client is off-online, dont request/write.o Game launch is defined as: Launching an app (if not in memory) Bringing an app to the foreground (after it was minimized/sent to the background) Please place the code which sends the data to Table 2 as early in the game flow as possible, i.e. early in the game launch code. Other systems, such as Flurry, Chartboost, may collect user activity data too, and we want the numbers from different systems match.4.2.1 Header Section GID(Game ID, 32-bit integer, SKU Number from BNGA Finance, ask your Producer) UID(User ID, either number or string, e.g. Apple or Google assigned ID, or a game own internal user ID) TS(Time S