@bdap
2017-01-10T08:53:30.000000Z
字数 1964
阅读 1810
BA
待补充
数据源
采集方式
数据源
- 平台提供给数据中心的数据有平台充值数据和平台消耗数据。平台消耗数据相当于是游戏的流水数据,我们这里的计费数据就是平台的消耗数据,每款游戏的实际充值流水(包含退单等情况)的实际订单数据。计费数据一般用于财务对账、审计等。
接入方式
- 目前数据中心暂时通过接口的方式从国内或国外的数据库从库,或者独代联运的游戏方进行取数,然后再导入到hive。接口众多,链路太长。接口众多,数据质量和时效难以得到保障,且对账机制不健全。
- 改进后,通过打包和接口方式两种方式共同保证数据的质量:
国内平台将保持五个系统不变,海外平台将会把所有数据整合为一个系统。平台部门将每天的充值数据打包到hive的表里(一个系统一张表),然后对打包的数据进行合服处理并将处理后的数据统一写入到数据中心指定的表里。同时,数据中心通过接口的方式从平台拉取对账数据。最后数据中心比较拉取的对账数据和按对账粒度聚合处理的流水数据,并将差异展现出来并对差异超过一定阈值的数据发出报警。
核数对账的时间为北京时区,粒度为日期、游戏ID、运营商ID、币种,对账字段为金额、订单数、人数(角色或者账号)、充值次数。
数据源
- GM数据为游戏后台(GM平台)数据,数据来源为游戏方。
接入方式
- 游戏方通过接口方式推数据到数据中心,数据统一为北京时间,粒度为游戏、天、服、货币单位,聚合字段有角色日活、充值金额、新角色数、充值角色数、充值订单数等。
(需要优化到游戏、天、运营商、服)
接口文档
海外相关要点
对账流程图:
BA三方对账页面
三方对账数据差异原因
- 货币问题:对账币种为原币,各平台数据需统一转化为原币比对
- 时区问题:对账时区为北京时间,各平台数据需统一以北京时间结算数据
- 其他原因:游戏中存在的退单,黑卡等问题可能导致数据差异
相关数据定义
- GM数据:GM数据取自游戏GM平台,数据来源为游戏方
- SDK数据:BA流水数据为SDK数据,SDK数据不包含退单等相关数据,一般用于游戏运营分析、活动效果分析等
- 计费数据:计费数据取自平台,数据包含退单、充值不到账等相关的详细数据。由于以上原因,计费数据会与SDK数据存在一定差异。计费数据一般用于财务对账、审计等
计算口径
- 时区:各数据源的对账时区统一为北京时间
- 货币:对账币种为原币
- 粒度:对账粒度为游戏、运营商、区服
- 官网/联运说明:
对账时间间隔
- 时效:目前内部三方对账支持的数据时效为T+2
流程图、业务负责人、技术接口人、自测方法
连接到另一个页面或上传文件
已接入游戏,接入排期表,各游戏对接人
对账流程图:
BA黄金审计页面
黄金审计出现对账差异的可能原因
相关数据定义
- 计算后留存 = 期初 + 充值 + 赠送 + 非转充 -消耗
- 计算后留存(审计) = 期初 + 平台充值 + 赠送 + 非转充 - 消耗
- 期末差异 = 计算后留存 - 期末
- 期末差异(审计) = 计算后留存(审计) - 期末
- 游戏内差额比 = 期末差异 / 期末
- 审计差额比 = 期末差异(审计) / 平台充值
- 充值差异= 充值 - 平台充值
- 充值差额比 = 充值差异 / 平台充值
计算口径
- 时区:各数据源的对账时区统一为北京时间
- 货币:对账币种为原币
- 粒度:对账粒度为游戏、运营商、区服
- 官网/联运说明:黄金审计数据仅进行官网付费数据审计,不审计联运数据。不同游戏对应各自的官网op_id,具体对应表如下。
对账时间间隔
- 时效:目前黄金审计支持的数据对账时效为T+2
实时-历史
日表-周表-月表
role-account
历史-预算