移动端 App 或 PC 客户端归因及数据回传指南

本文档简要说明了移动 App 和 PC 客户端（以端游为例）的归因逻辑及转化数据回传（Postback）对接方法，供您的技术团队参考对接。

针对移动端 App 的推广（尤其是 PC 端网页跳转至移动端下载的跨屏场景），本平台支持以下主流归因方式，确保转化数据的准确捕获。

此方案为 Android 端主推方案，精准度极高，不受网络环境影响。

业务流程： 用户点击广告（或扫描落地页二维码）时，AdWork 广告系统生成唯一的 click_id（即#adwCode#变量参数）。服务器不直接提供静态 APK，而是将该 click_id 动态写入 APK 安装包中。
技术实现（渠道包注入）： 利用类似 Walle 的多渠道打包技术，在不破坏 APK V2/V3 签名的情况下，将 click_id 写入 APK 的 META-INF 目录或 Signing Block 中。
技术实现（动态重命名）： 将下载的 APK 文件名重命名为包含参数的格式（例如 app_click_12345.apk）。
数据上报： （以用户激活数据回传为例）用户安装并首次启动 App 时，您的 App SDK 需读取包体内部或文件名中的 click_id，并通过 API 接口将该 ID 上报至您的服务器，随后通过 AdWork 广告转化回传 API 将转化数据回传即可。

由于 iOS 系统的沙盒机制及 App Store 的封闭性，无法动态修改安装包，推荐采用指纹归因结合剪贴板的方案。

业务流程： 用户点击广告或扫码进入 H5 落地页，系统记录当前设备的“指纹”（IP 地址、User Agent、操作系统版本等）并与 click_id 绑定，有效时间窗口通常设为 1-3 小时。随后引导用户跳转 App Store 下载。
数据上报： 用户首次启动 App 时，SDK 采集当前设备的 IP 和 UA 上报至您的服务器。
归因匹配： 您的服务器将 App 启动时的指纹与之前 H5 页面记录的指纹进行比对。若在时间窗口内匹配成功，则视为该渠道的转化。
精度提升技巧： 在 H5 落地页引导用户点击“复制专属福利码”，将 click_id 隐式或显式写入系统剪贴板。App 首次启动时读取剪贴板，若存在合法的 click_id，即可实现 100% 精准归因。

适用于需要在网页端先注册、后下载 App 的业务（如金融、电商）。

PC 客户端（例如端游）通常体积较大，且均在同一设备（Windows PC）上完成点击与激活，无需跨设备握手。我们推荐采用“微端（Launcher）参数注入”方案，兼顾服务器带宽与归因精准度。

这是端游（.exe 文件）推广中最主流、最硬核的无损打包技术。

核心原理： Windows 的可执行文件（PE 格式）允许在文件末尾追加任意数据而不影响其正常运行。
动态下发： 用户点击广告下载微端（通常几 MB 到几十 MB）时，服务器拦截下载请求，在基础 Launcher.exe 文件的二进制末尾动态追加标识符和唯一的 click_id，然后流式返回给用户。
激活上报： 用户双击运行微端。微端程序在启动时，以只读模式读取自身文件，定位到文件末尾提取出 click_id，并向服务器发起激活上报。随后微端再从 CDN 拉取数十 GB 的游戏主程序。

对于技术开发资源有限的广告主，可采用此轻量级方案。

业务流程： 用户点击下载时，服务端通过修改 HTTP 响应头，将下载的文件名动态命名为 GameLauncher_click_12345678.exe。
激活上报： 游戏客户端启动时，调用系统 API（如 Windows 下的 GetModuleFileName）获取自身文件名，正则提取出 click_id 后完成上报。
注意事项： 若用户在保存时手动修改了文件名，或使用了会截断长文件名的下载工具，会导致归因数据丢失。

当您的服务器成功完成上述（App端或PC端）的归因比对后，或者您的系统检测到用户发生了高价值行为（如激活、注册、付费）时，需要通过 S2S（Server-to-Server）API 接口将转化数据提交给本联盟，接口说明详见您的广告转化统计页面文档。