如何用对话方式分析游戏出海多平台买量数据

摘要：本文以 Google Ads 接入和五个平台的示例数据，介绍如何通过 Amazon Quick 用自然语言比较游戏出海广告投放表现，并追溯到广告系列和每日明细；结合 Amazon Bedrock AgentCore 与 Amazon S3 Tables，说明多平台报表采集、字段适配器开发测试和数据入表的参考架构。

01 一、引言

02 二、一游戏出海广告数据分析的挑战

03 三、二基于 Amazon Quick 的广告投放分析示例

04 四、三方案架构与查询流程

05 五、四适配器开发发布与数据入表

06 六、五多平台接入与扩展

07 七、六总结

08 八、参考资料

一、引言

游戏出海团队通常需要同时分析多个广告平台的投放表现，既要按一致的指标口径比较平台表现，也要在成本变化时，快速定位需要核查的广告系列和日期。为此，数据团队需要持续维护各平台接口，处理币种、转化定义、数据回传延迟和重复采集等问题；运营人员则往往需要反复提出取数需求，等待数据团队返回结果。

本文介绍一套可扩展的接入与分析参考架构。各平台报表通过 Amazon Bedrock AgentCore Gateway 提供的统一工具入口采集和校验，转换为一致口径后写入 Amazon S3 Tables；运营人员在 Amazon Quick 中用自然语言比较和下钻。新平台的字段转换代码由 AgentCore Harness 编写，经过隔离测试、独立样例比对和审批后才能上线，接入流程可以在不同平台之间复用。

这套方案主要带来三方面的优势：

从问题到答案的路径更短。运营人员可以在同一段对话中，从平台总览一路追问到广告系列和具体日期，完成比较、下钻和汇总，不必为每个新问题单独提取数需求。
结论有据可查。每个回答都能查到对应的 SQL，数据可以追溯到原始报表和处理版本。运营与数据团队讨论的是同一组数据，出现分歧时可以直接回到源头核对。
接入新平台的成本更低。报表工具入口、任务编排、测试和发布流程都可以复用，数据团队主要关注新平台的字段含义和指标口径；运行时只执行与批准记录一致的代码版本。

本文以 Google Ads 接入说明实现方法，并用五个平台的示例数据展示投放成本调查。收入、留存和预算优化需要接入更多数据并结合业务验证，本文不展开。

二、游戏出海广告数据分析的挑战

广告花费、展示和点击来自各广告平台，安装、收入和留存数据则可能来自移动归因平台（MMP）与游戏服务端。分析时需要按账户、广告系列和日期关联这些数据，并处理标识、命名和报表粒度的差异。

跨平台比较需要核对账户时区、币种和转化定义。CPI、CTR 等比率应基于汇总后的花费、安装量、点击数和展示数重新计算；判断投放回报时，还需结合留存和收入，避免仅凭获客成本调整预算。

花费、安装回传和收入的更新时间可能不同，接口分页、授权或采集异常也可能造成数据缺口。看到指标波动时，需要先确认数据是否齐备，再区分投放表现变化与数据延迟或缺漏。

平台汇总报表可以显示成本变化，进一步核查通常还要查看广告系列和每日明细。固定看板未覆盖所需维度时，运营与数据团队需要通过补充查询逐步验证，并将异常日期与当日投放变更对照。

新增平台及接口变更需要同步调整字段转换、金额单位、分页和回补逻辑。接入程序应经过测试，并保留原始报表和处理版本，便于核对结果、定位错误和复现历史数据。

本文适合需要自行扩展平台接口、维护字段转换逻辑的团队：定时采集与临时查询共用工具入口，AgentCore Harness 辅助开发适配器，后续测试与发布沿用统一流程。

三、基于 Amazon Quick 的广告投放分析示例

下面通过一个示例，看运营人员如何在 Amazon Quick 中用对话调查投放成本。示例数据是 5 个广告平台一周投放数据，金额统一为美元，不代表真实投放表现。整个调查在同一段对话中完成：先比较各平台，再追问到广告系列和每日明细。

运营人员用自然语言提问，Quick 中的大语言模型理解问题并生成 SQL。Quick 通过原生 S3 Tables 数据源，直接查询存放在 Amazon S3 Tables 中的 Apache Iceberg 表，不需要另外部署查询服务。模型再根据查询结果组织回答，并可以计算占比、降幅等派生指标。为了让比率能够正确比较，示例中的每次安装成本（CPI）按总花费除以总安装量计算，点击率（CTR）按总点击数除以总展示数计算，不直接平均各行的比率。

3.1 选择要查询的数据集

Quick 通过数据集决定聊天可以查询哪些表和字段。在本方案中，各平台报表经过采集和统一口径处理后，写入 S3 Tables 中的一张广告指标表，每行是某个平台、某个广告系列一天的数据，包含花费、展示、点击和安装量等字段。数据团队基于这张表创建 Quick 数据集，本例中名为 Advertising analysis DEMO v1，然后共享给运营人员。连接步骤见第三章。

运营人员在 Quick 中新建聊天，点击输入框左下角的数据范围菜单，选择“特定数据”（Specific data），勾选该数据集后保存。之后的提问都会基于这个数据集回答。

3.2 比较平台表现

首先询问 2026 年 10 月 16 日至 22 日各平台的花费、安装量、CPI 和 CTR，要求按花费排序。

[图 1]

AppLovin 安装量为 16,002，CPI 为 5.10 美元；Google 花费最高，为 91,191.44 美元，安装量为 15,106。接下来查看 Google 各广告系列对总花费的贡献。

3.3 查看 Google 广告系列

继续追问 Google 各广告系列的表现，并比较花费最高系列与 Google 整体的 CPI。

[图 2]

game-ua-search-sea 花费为 20,622.90 美元，占 Google 总花费的 22.6%；安装量为 2,242，CPI 为 9.20 美元，比 Google 整体的 6.04 美元高 3.16 美元。我们选择这个系列继续查看每日表现。

3.4 确定后续核查对象

花费和 CPI 可以帮助确定调查顺序。判断是否调整预算，还要结合游戏、市场、操作系统、投放目标和用户质量。定位到具体日期后，运营人员可以检查当日预算、出价与定向变更，数据团队则核对安装回传和统计口径。

3.5 按日期定位差异

接着询问 game-ua-search-sea 的每日花费、安装量和 CPI，并计算剔除关键日期后，整个期间的 CPI 会如何变化。

[图 3]

10 月 17 日花费为 4,449.52 美元、安装量为 88，CPI 达到 50.56 美元。这一天占该系列期间花费的 21.6%，安装量占比仅为 3.9%。

3.6 汇总调查结论

最后请 Quick 用简短文字和对比表汇总调查结果。

[图 4]

剔除 10 月 17 日后，汇总花费为 16,173.38 美元，安装量为 2,154，CPI 为 7.51 美元，比完整期间的 9.20 美元低 1.69 美元（18.4%）。

这一对比说明了 10 月 17 日对该系列 CPI 的影响。18.4% 是剔除该日后的计算差异，并非实际节省的成本。回答中“获客效率不及 AppLovin”“最大单日因素”等说法是模型对数值的概括：CPI 高低只说明单位安装成本不同，不能直接说明渠道质量或差异原因。是否调整投放，还需结合市场、操作系统、用户质量和当天的投放记录判断。

四、方案架构与查询流程

图 5 展示平台报表接入、日常采集和聊天查询的参考架构：接入阶段准备并发布适配器；运行阶段按指定范围读取报表，确认完整后转换入表，再由 Amazon Quick 查询。图中的任务提交与采集链路以 Google Ads 接入程序为例，其他平台需要配置对应的连接器与任务路由。第四章介绍适配器开发发布与数据入表，第五章介绍其他平台的扩展方式。

[图 5 广告数据接入、处理与聊天查询架构（任务提交与采集链路以 Google Ads 为例）]

4.1 为什么选择 AgentCore

定时采集也可以由程序直接调用各平台 API，或者使用现有的数据连接器。本方案选用 AgentCore，是因为接入工作不止一次性的报表同步：平台数量会持续增加，定时采集与临时查询需要共用同一套报表工具，平台凭证和调用权限需要集中管理，新平台的字段转换代码也希望借助 AI 开发并可控地上线。各组件的分工如下：

AgentCore Gateway 提供统一的工具访问与治理入口。Collector 等调用方通过同一个工具目录发现和调用报表工具，Gateway 负责验证调用方身份并转发请求；新平台以 MCP、OpenAPI 或 Lambda 目标的形式加入，调用方式保持不变。
AgentCore Runtime 托管需要自定义的平台工具。本例的 Google Ads MCP Server 封装 API 只读调用、分页和 Raw 文件写入，平台凭证只由它读取，团队无需自行运维服务器。
AgentCore Harness 辅助开发字段转换模块。它根据平台字段说明、报表样本和目标表定义编写候选代码，供后续测试和审批。
AgentCore Code Interpreter 提供隔离的测试环境。候选代码在 SANDBOX 网络模式、不配置执行角色的会话中运行，测试结果由沙箱外的判定程序比较。

跨平台指标的含义由数据团队定义；日常采集和转换执行的都是经过测试和批准的程序，运营人员通过 Amazon Quick 查询已入表数据，完成平台比较、广告系列下钻和调查结果汇总。如果只需要从主流平台同步固定日报，成熟的数据连接器通常更简单；本方案更适合需要持续扩展平台、自定义报表工具，并让定时采集与临时查询共用入口的团队。

4.2 接入阶段准备并发布适配器

图 5 上方的接入阶段准备平台适配器，即将原始字段转换为目标表结构的模块。AgentCore Harness 根据接口说明、样本和目标表定义生成候选代码；AgentCore Code Interpreter 执行测试，独立判定程序核对输出。经测试和审批的适配器集成到 Normalizer，完整程序打包为容器镜像存入 Amazon ECR，再部署为 Normalizer Lambda。

4.3 采集完整报表并转换入表

图 5 中的 02 部分从 Collector Lambda 开始执行采集。Collector 运行预先实现的 Python 采集与校验程序，以 ZIP 包部署到 Lambda。AWS Step Functions 启动采集步骤后，Collector 按账户、日期和报表类型，经 AgentCore Gateway 调用 Google Ads MCP Server（广告报表接入程序）。MCP Server 通过模型上下文协议（MCP）提供报表工具，封装 Google Ads API 的只读调用、分页和凭证处理。

AgentCore Gateway 负责检查调用方身份并转发工具请求，AgentCore Runtime 负责托管 MCP Server。这样，Collector 专注于采集任务和结果校验，MCP Server 处理平台接口细节。后续接入其他平台时，可将对应的报表工具加入 Gateway 的统一目录，供采集程序通过同一入口调用。

MCP Server 将每页报表分块保存到普通 S3 桶的 Raw 区域，并生成文件清单，记录分块文件的位置、行数和校验信息。完成读回校验后，MCP Server 经 Gateway 向 Collector 返回清单的 S3 地址及校验信息。Collector 据此读取各页清单，确认分页连续且查询已结束，再生成供 Normalizer 使用的完整批次清单。

Normalizer Lambda 随后从 Raw 读取完整批次，执行接入阶段已批准并发布的 Google Ads 适配器，将结构快照和日绩效分别写入 S3 Tables。保留 Raw 便于核对源报表，也支持转换失败后的重新处理。图中的绿色实线表示报表结果与文件的流向。

4.4 编排任务并控制访问权限

图 5 中的 03 部分负责让采集与处理按计划运行。Amazon EventBridge Scheduler 触发任务派发 Lambda（Dispatcher）。本例的 Dispatcher 根据配置确定账户范围和报表类型，并按来源时区生成快照日期或绩效业务日期，组成采集请求，经 AgentCore Gateway 调用 start_report 工具。按需采集也可通过该工具提交请求。

start_report 工具由报表任务服务 Lambda 实现，该 Lambda 以 Lambda 目标的形式注册在 Gateway 上，同时提供任务状态查询和重试等工具。报表任务服务在 Amazon DynamoDB 中创建状态为 QUEUED 的任务记录，并固定本次处理使用的 Normalizer 版本和适配器发布标识；相同任务已存在时复用记录。仅当任务状态为 QUEUED 时，该服务才调用 AWS Step Functions 启动工作流。

Step Functions 依次编排采集、归一化和表提交确认，其中 Collector Lambda 经 Gateway 调用平台报表工具。DynamoDB 持久化任务范围、状态、处理版本和提交结果，支持进度查询与失败恢复。Amazon CloudWatch 监控失败与更新延迟，恢复程序按设定次数重试或回补。图中蓝色虚线表示任务调用与控制方向。

入口权限与平台凭证分别管理。Gateway 通过 Amazon Cognito 验证调用方身份，报表规则限制可查询的账户和日期。Google OAuth 凭证集中保存在 AWS Secrets Manager，仅由 Runtime 中获授权的 MCP Server 读取，Collector 和适配器开发、测试环境无需持有平台凭证。刷新令牌失效时暂停相关采集，重新授权后再恢复。

4.5 通过 Amazon Quick 查询分析表

图 5 的 04 部分由 Quick 通过原生 S3 Tables 数据源查询数据。这里以第二章使用的广告指标表为例，它在 S3 Tables 中的命名空间为 ad_data，表名为 ad_metrics。连接分三步：管理员为 Quick 配置读取表桶和表数据的权限；在 Data sources 中用表桶 ARN 创建 Amazon S3 Tables 数据源；在 Datasets 中选择命名空间 ad_data 和表 ad_metrics，以 Direct Query 模式创建数据集 Advertising analysis DEMO v1，再共享给运营人员。点击回答下方的 Explanation，可以看到模型生成的 SQL 和基于查询结果的计算。下图为“按日期定位差异”一节回答中的 Explanation：右侧 SQL 按日期汇总花费和安装量，左侧是剔除 10 月 17 日后 CPI 降幅的计算。

[图 6]

同一回答的 Explanation 局部截图拼合。左：CPI 差额与降幅计算；右：每日汇总 SQL 的节选。

生产环境配置每日调度后，采集与归一化程序按计划更新 Quick 数据集连接的 S3 Tables 表。数据提交后即可通过聊天查询，无需手动刷新 Quick 数据集。

五、适配器开发发布与数据入表

本章以 Google Ads 适配器说明如何约束生成代码、判定转换结果并固定运行版本，以及如何统一指标口径、处理入表与重试。API 或 MCP 的 schema 可以描述参数和返回类型，字段的业务含义仍需查阅平台定义。交给 AgentCore Harness 的材料包括官方字段说明、获授权的报表样本和目标表定义，并明确数据粒度、去重规则、金额单位、时区和归因口径。

AgentCore Harness 通过内置 shell 和 file_operations 读取材料，编写 Python 字段映射模块并运行自测。模块只转换已采集的数据，不读取平台凭证，也不提交数据表。发布前的静态检查只允许导入 datetime、decimal 和 re，拒绝 open、eval、exec 和 __import__ 等名称及私有属性访问。候选代码随后进入独立测试流程。

5.1 用独立样例判定候选代码

例如，将 conversions 直接当作安装数，可能算出数值正确、含义却错误的 CPI。为检验这类问题，生成代码前先准备并冻结标准输入和期望输出（golden dataset），不向生成器提供期望答案。独立测试依据数据约定判断转换结果，生成器的自测用于辅助修正代码。

测试程序将候选代码和输入交给两个独立的 Code Interpreter 会话，均采用 SANDBOX 网络模式且不配置执行角色。判定程序在沙箱外读取冻结的期望输出并比较结果，候选代码无法通过修改沙箱内文件改写期望答案。测试覆盖字段含义、平台样本、异常输入、重复执行的一致性和输出结构，并检查输入是否被修改。错误代码、输入修改和超时场景用于检查发布流程是否拒绝不合格候选。

5.2 将测试和审批结论绑定到本次发布

Normalizer 容器镜像通过 Docker 或 CI 构建并测试。发布程序核对候选代码、测试资料、判定程序、依赖版本、镜像摘要和审批记录；报告缺失、不匹配或过期时阻止发布。测试报告与审批记录应由获授权的测试和发布人员维护，摘要校验用于确认文件一致性。镜像存入 Amazon ECR，S3 注册表保存发布清单及校验记录。

[图 7 Harness 接入与适配器发布架构。]

图 7 的 01 部分整理平台说明与样本，02 部分生成候选并自测，03 部分进行独立测试、核验审批并交付运行版本。不合格候选沿红色虚线退回修正，不能进入发布步骤。

图 7 中的 03 部分使用 S3 适配器注册表保存代码摘要、数据约定、测试和审批记录。Normalizer 按部署时固定的清单摘要核验记录，并确认镜像内适配器与批准版本一致后才执行。运行代码由 Amazon ECR 中固定摘要的镜像交付，不从注册表动态加载。

下方的发布流程使用 AWS Serverless Application Model（AWS SAM）管理 Normalizer Lambda 的版本与别名，以镜像摘要固定部署内容，并保留旧版本供重试与回退。任务创建时，DynamoDB 即记录所用的 Lambda 数字版本及适配器发布标识，重试沿用原记录，避免升级改变同一任务的处理逻辑。开发适配器的智能体没有切换运行版本的权限。Normalizer 执行批准的适配器并检查输出后，通过 PyIceberg 提交到 S3 Tables。

5.3 统一指标含义

Google Ads 的结构属性与日绩效分别存储，避免混淆预算和实际花费。面向运营查询时，需按平台、广告系列和日期整理分析字段，并明确金额与转化口径。

表	行粒度	内容与用途
结构快照	账户 × 广告系列 × 快照日期	名称、状态、渠道和预算等结构属性
日绩效	账户 × 广告系列 × 业务日期	展示、点击、原币花费和平台转化指标

两张表均保留平台、环境、账户、币种、时区和报表定义，以及采集批次、时间、文件清单摘要和适配器版本。新增国家、设备或创意维度时，也要将这些维度纳入唯一键，避免不同明细在去重时被覆盖。

Google Ads 适配器保留账户原币。cost_micros 除以 1,000,000 只是单位换算；账户币种为 SGD（新加坡元）时，金额仍为 SGD。第二章示例数据的 spend_usd 按美元定义。真实账户跨币种比较前，须按约定的汇率来源、生效日期和版本换算，不能直接相加不同币种的金额。

第二章示例数据的 installs 表示安装量；Google Ads 接入保留 conversions，不直接将其当作 installs。实际分析须核实转化事件定义和筛选条件。计算安装后 7 天的广告支出回报率（D7 ROAS）时，还需按安装日期分组的收入、明确的归因窗口和满 7 天的数据。收入可来自 MMP 或服务端记录，缺失值应与零收入区分。

关联成本与收入时，账户、应用、日期和其他细分维度必须一致。例如，将按国家拆分的花费直接关联未按国家拆分的收入，可能重复计算同一笔收入。汇总 ROAS 应使用对应的总收入除以总花费。

5.4 提交与重复处理

分页连续性由平台分页令牌和清单之间的关联共同校验。MCP Server 使用上一页返回的分页令牌读取下一页；Collector 逐页核对页号、账户、查询条件和批次，并检查当前清单记录的上一页摘要是否与已读取清单一致。只有最后一页没有后续令牌、查询结束标记一致，且各页清单摘要与行数汇总通过校验，才将批次标记为原始数据就绪；校验失败则停止后续归一化。

Normalizer 校验文件清单、完整性、查询规则和处理版本后，执行已批准的适配器，并检查输出。随后使用 Python 的 Iceberg 客户端 PyIceberg，通过 S3 Tables 的 Iceberg REST 接口提交数据。S3 Tables 管理表存储与维护，业务主键、覆盖范围和重试规则由应用实现。

完整报表按授权账户和业务日期覆盖写入，数据与记录账户处理进度的水位在同一张 Iceberg 表的事务中提交。同批数据重放不会重复追加，旧批次也不会覆盖新结果。任务只有在确认表提交，或确认属于符合规则的重放后，才标记为完成。仅有 Raw 文件落盘或 Lambda 调用成功，还不能确认数据已入仓。

结构快照与日绩效分别提交。若业务要求多张表的同一批数据同时可见，需要增加统一发布标记或版本切换机制，并让查询端按该标记读取。

图 3 展示 Google Ads 结构数据采集工作流。Normalizer 确认表提交结果后返回状态，VerifyCommit 检查该状态是否满足完成条件，再进入 Committed 完成状态。

[图 8 Google Ads 结构数据采集工作流。]

六、多平台接入与扩展

新增来源时，可以根据平台提供的接口选择接入方式。API 和 MCP 服务通过 Gateway 调用，文件和事件由接收端处理。各入口都要记录数据来源，并检查文件或报表是否完整。

来源能力	接入与执行方式	原始数据保存位置
已有 MCP Server	注册 MCP target；可用 Runtime 托管服务	Collector 或连接器写 Raw
标准 REST API	OpenAPI target 提供查询工具	Collector 收齐结果后写 Raw
SDK 或特殊签名	Lambda 连接器，或容器封装为 MCP	连接器校验结果并写 Raw
平台或 MMP 文件推送	S3 交付；SFTP 可评估 AWS Transfer Family	接收文件后校验并发布清单
Webhook 事件	Amazon API Gateway 与 Lambda 验签、去重	接收端按约定的事件格式写 Raw
授权网页报表导出	AgentCore Browser 加导出执行器；封装为 Lambda 或 MCP 工具	下载报表文件并核对后写 Raw

本文以 Google Ads MCP 接入为例，表中列出其他来源可采用的接入方式。REST API 可使用 OpenAPI target，特殊签名或 SDK 可封装在 Lambda 中。平台允许网页导出、又缺少合适 API 时，可考虑 AgentCore Browser，但需维护登录态、页面适配和下载文件校验。

MMP、邮件等文件来源还需要格式解析和报表校验规则。同一广告系列的花费若同时出现在平台 API 和成本聚合报表中，不能直接相加。数据团队应确定采用哪个来源，并保留对账与去重规则。

多平台扩展时，任务派发与任务管理可以复用，不要求每个平台各部署一个 Dispatcher Lambda。当前 Dispatcher 按 Google Ads 的配置调用固定的 start_report 工具；若改为统一派发多个平台，需要增加平台配置，以及到对应工具和工作流的路由。

平台差异主要由各自的连接器和字段适配器处理。连接器可按接口能力封装为 MCP 服务、OpenAPI 工具或 Lambda；需要独立管理权限、并发或发布周期时，再拆分部署。任务编排与发布流程可以复用，平台专属的接口调用、字段映射和入仓结果仍需分别测试。

七、总结

本文通过 Amazon Quick 展示了游戏出海多平台买量数据的对话分析过程：运营人员可以在同一段对话中，从平台整体表现追问到具体广告系列和日期，完成平台比较、花费贡献分析、异常定位与结果汇总，并通过 SQL 和计算依据复核结果。团队可以从一个广告账户和一类报表起步，借助 Amazon Bedrock AgentCore 与 Amazon S3 Tables 打通采集、入表和查询流程，再复用已验证的接入方式与测试发布流程，逐步扩展平台和分析维度。原始报表与处理版本为结果追溯提供依据，让运营人员能够围绕业务问题持续探索，也让数据团队积累可复用的接入经验，形成可扩展的多平台投放分析能力。

相关产品：