MeteorCat / SDK发行平台搭建(补充)

Created Fri, 17 Nov 2023 13:24:58 +0800 Modified Wed, 29 Oct 2025 23:25:05 +0800
3666 Words
联运发行

联运发行平台搭建(补充)

这里是对之前的 SDK发行平台搭建 的补充, 如果之前不清楚需要补充扩展.

之前说明还包含提供给 CP 其他平台的集成包:

  • Android平台接入包, 尽可能用比较少的依赖传统来接入包
  • iOS平台接入包, 按照平台SDK包直接接入IOS工程

这种其实扩展出来出来还有其他集成包:

  • Unity3D平台接入包, 用于游戏引擎接入
  • UE平台接入包, 同上

但是万变不离其宗, 内部所有变化全部都是准备让 CP 方账号入库之后推送账号信息到 我们发行方 接口之中( 走 Web+JSON 形式 ).

无论平台怎么变最后都是需要 CP 账号同步传递到我们发行接口进行账号绑定, Android/iOS/Unity/UE 平台底层主要工作就是集成 HTTP 推送数据功能类库.

这里以 游戏接入+Android 类型做处理, 需要实现这几个接口事件推送:

  • 创建角色, 必须
  • 进入游戏, 必须
  • 等级提升, 非必须
  • 退出游戏, 非必须
  • 游戏支付, 非必须

其中 "创建角色,进入游戏,角色升级,退出游戏" 这些步骤可能需要上报外部扩展数据( 必须角色VIP/角色昵称/角色服务器ID ), 以便直接监控玩家统计用户数据事件.

对应平台SDK已经集成 HTTP 请求库, 所以这里只需要关注提交上来 JSON 结构体数据即可, 但是可以考虑自己扩展 Web-JS 平台, 那么对应可能扩展平台接入包:

  • Android平台接入包, 尽可能用比较少的依赖传统来接入包
  • iOS平台接入包, 按照平台SDK包直接接入IOS工程
  • Web平台接入包, 是上面的平台都是封装Web平台的数据上报功能

很多第三方要求指定时间做玩家数据上报功能, 所以需要做事件上报接口监控; 同时事件上报和登录接口是不一致的, 不要混淆在一起

平台接口

这里以平台接口为主, 先说明下 API 应该如何设计:

上报地址: https://www.自己的域名.com/v1/event/push
请求方式: POST
请求参数:
    type: 事件类型[1:创建角色, 2:进入游戏, 3:等级提升, 4:退出游戏, ... ], 可以按照业务不断扩展
    server_id: 服务器所在id, 如果是单服游戏默认 1 即可方便后续 CP 方扩展
    server_name: 服务器所在名称, 这里实际上可以留空默认叫 '服务器1' 也可
    role_id: 玩家角色id, 不要和 uid 混淆, 在多服务器上可能存在 uid = 1 在服务器 1,2,3 各自都有账号指向同个 uid
    role_name: 玩家角色名称, 这字段其实比较麻烦, 因为是存在昵称名称修改但是又没有同步推送到发行的情况, 导致 role_id 和这个字段值常年保持不一致
    role_level: 玩家角色等级提升相关, 在 MMO 类型游戏有等级活跃升级情况, 所以需要上报玩家升级情况
    create_time: 玩家角色创建时间(秒), 这个主要玩家创建事件时候需要推送, 记录玩家创建事件作为有效获客, 比如想找到所有玩家创建事件只需要查找 type=2 AND create_time != 0 就能排出
    update_time: 玩家角色变化时间(秒), 这个根据 type 不同而覆盖不同含义, create_time 仅仅作为 type = 1 创建游戏的时间, 而后续其他 type = 3/4 则需要直接获取更新而排除 create_time
    vip: 玩家的会员等级, 有些玩家是带有高级会员需要计算返利折扣的情况, 这时候就需要该值做处理
    extra: 备用扩展字段, 可以考虑采用 JSON 包括复杂时间情况

这里就是对应客户端需要上报的玩家信息处理, 注意这是很重要事件, 关系到后续广告买量成本计算, 这里举个例子说明:

你作为买量发行方, M 作为客户作为CP研发方来接入你的SDK

  1. M 客户在你们花费 4000 块(每个用户均价2块) 获取推广的广告客源获取.
  2. M 客户端的游戏接入相关 SDK 之后在我们买量发行后台提交了应用.
  3. 我们买量发行确认没问题在后台配置付费 快手/抖音/Facebook 某个平台推广广告弹窗记录点击跳转下载游戏用户.
  4. 玩家通过 快手/抖音/Facebook 某个平台广告位点击下载应用, 这时候就是 SDK数据上报接口 type = 1 代表有玩家转化在投入 4000 块当中转化为用户.
  5. 客户端获取到推送事件记录获客信息, 发行买量需要跟踪这个玩家标识推送给 快手/抖音/Facebook 指定平台去跟踪玩家上报, 通知这个玩家是平台转化要求跟踪转化.
  6. 快手/抖音/Facebook 会在我们自己的发行平台资金上扣除投入买量资金,之后 我们这里也是同步告诉 CP 方 4000 - 2(花费2块有个玩家已经转化你们目标用户).
  7. 这里还没有结束, 这里计算仅仅作为注册成本, 注册玩家并没有给 CP 方带来任何收益, 更加重要的就是付费流水指标.
  8. 联系之前 SDK发行平台搭建 支付接口内部带了相同属性: server_id/role_id 这里就能对比推送事件将付费玩家注册玩家等关联到我们买量玩家对象.
    1. 比如在买量获取到关联映射 type = 1(创建玩家) 关联的 server_id + role_id(买量带来的玩家) 在我们订单数据库充值过, 这个就可以计算 付费率 100%( 注册的玩家直接付费, 这里指代单个玩家 ).
    2. 这时候如果这个付费玩家充值金额为 6 块钱首充, 那么相比 CP 方投入 4000 元(单用户2块钱), 那么这个用户单纯收益了 6-2=4 元, 这个玩家纯收益达到 4 块.
    3. 以这种指标模型扩展出来, 这里 4000 元买量成本买了 4000/2=2000 人, 其中 100 人充值了则计算付费率为 100/2000*100%=1/20*100%=5%, 付费率数值仅仅是作为付费意愿参考.
    4. 接下来衔接上面 4000 元的 2000 个注册玩家, 付费每个玩家(5%=100人)达到了人均充值首充 6 块钱, 这批玩家折算获取收益 600 元整; 假设不含其他付费项, 那么整体都是处于投入产出比失衡情况( 4000元转化600元, 极度失衡状况. ).
    5. 假设游戏内部扩展其他充值项多了付费 648 等充值项, 付费的 5%(100人) 中有 10 个玩家有 8 个充值这个 648 元档次项(648*8=5184), 得出这批付费玩家总付费 600(首充)+5184(付费)=5784 达到完美的纯收入状况( 5784-4000=1784元纯收入).
    6. 当然后续不止计算收入状况, 还需要知道 买量付费转化率/付费玩家流失率/推广分成/大R付费带动 等形形色色的计算收支情况.

这里就是为什么会有数据上报和自定义发行平台情况, 这些最后目标都是 CP能够获客达到盈利, 发行方能够推广中获取分成, 广告方能够赚取广告费, 实现三方共赢的局面.

另外, 如果作为游戏研发(CP)方, 如果查看到付费率一直处于比较低的情况可以考虑是否本身游戏吸引盈利方面有所不足, 而如果长期处于付费收支不平衡则要审视下游戏是否转化率本身和游戏品质有关.

为什么需要数据上报

之前说过服务端只需要 登录验证+支付唤起, 现在又多出数据上报处理步骤接口?

这里其实涉及到平台广告买量情况, 作为发行方不止需要帮助其接入支付相关分账, 还需要帮助 CP 方去 抖音/Facebook/Google 等平台发布广告位推广下载链接.

其他第三方广告系统一般都是需要在其后面提交自定义的广告链接, 当点击触发广告之后有两种方式( 直接应用下载/落地页展示下载 )选择引流.

注意下载之后是转发到我们发行地址, 同时这个地址格式带了可能是 base64 或者 md5 标识, 这个标识就是关联广告的玩家转换.

类似如果在广告落地页链接填写如下链接：

# 这种 __XXX__ 格式是广告平台自动填充转发跳转到下载落地页 
adid=__AID__&creativeid=__CID__&creativetype=__CTYPE__&click__id=__CLICKID__

# 注意: 我们发行服务端的落地页需要将拼接了参数的落地页 url 和用户线索做映射; 例如用户A/B/C均在页面上提交了表单, 其中用户A对应url1, 用户B对应url2, 用户C对应url3

跳转到落地页下载之后, 我们就需要将数据回传给 抖音/Facebook/Google 等平台, 用来跟踪有效用户广告计划的转化效果.

按照例子来说流程:

  1. 我们帮助 CP 代理推广他们游戏, 而让 CP 在我们自己广告计划平台提交游戏, 之后生成我们自己的落地页链接地址( 我们代理网站.com/download.html )
  2. 用户在广告栏位点击触发落地页跳转, 页面的后面添加上几个跟广告相关的参数回传给我们( 我们代理网站.com/download.html?IMEI=123&IDFA=321&clickid=CJPAgsnOmv== )
  3. 玩家跳转下载时候, 我们需要将下载转发过来信息回传给广告推广SDK地址( 注意回传可能事件id需要变动 第三方广告回传API/track?IMEI=123&IDFA=321&event_type=19&clickid=CJPAgsnOmv== )

广告展示点击用户的 IMEI/IDFA/MAC/ANDROID_ID/OPEN_UD_ID/IP/UA 等设备信息, 我们需要将其与自己监测到的转化用户的相关信息进行匹配. 例如, 第三方广告平台这边监测到 imei 号为 123456789 的用户在第三方平台客户端点击了我们发布的相关广告, 第三方广告平台会将该用户的相关信息通过监测链接发送给我们买量推广平台. 而我们监测到 imei 号分别为 123456789 和 abcdefgh 的两个新增转化用户, 则我们需要将这两个用户的设备信息与之前第三方广告平台发送给我们的用户信息进行匹配; imei 号为 123456789 的用户实现成功匹配, 则将该用户的信息通过回调地址回调给第三方广告平台(成功记为有效用户); imei 号为 abcdefgh 的用户无法成功匹配，则无需将其回传给第三方平台.

这时候我们推广发行平台拿到 event=1(注册玩家) 的 imei 信息一比较确认正式有效用户, 那么这一笔付费转换正式成功; 当季度完成之后, 就需要 发行平台(我们)/CP(游戏研发)/广告平台(第三方) 来对账, 对比三者的有效用户误差.

三方进行买量对账是最麻烦的事情, 哪怕我们事件上报的完整记录情况, 也会出现某些方面原因如: 广告买 100 的玩家安装量 / 我们上报数据注册量为 80 / CP方后台发现注册量60.

可以说买量当中允许少量误差, 如果量级误差过大则需要排查下是哪里步骤出现问题, 这也就是为什么会有数据上报记录进行排查.