前言
在开发跨境电商 ERP、广告自动化投放系统或数据分析平台时，如何准确将亚马逊广告活动（Campaign）与对应的 ASIN（推广商品）及企业内部的产品主数据进行关联，是一个看似简单却极具挑战的技术课题。
特别是在 Sponsored Brands（SB，品牌推广广告） 场景下，官方 API 并未提供像 SP/SD 那样直观的"推广 ASIN 绩效报表"，极易导致数据归因混淆、指标虚高或历史版本错配。
本文将结合 Amazon Ads API (v3/v4) 官方规范与行业主流 ERP 架构实践，深度解析 SP、SD、SB 三种广告类型的 ASIN 关联方案、双轨模型设计、SQL 优化技巧及避坑指南。
一、 核心原则：广告活动的唯一身份标识
在处理 Amazon Ads API 数据时，切忌仅使用 campaign_id 作为广告活动的唯一定位。
在多店铺、多站点的复杂业务场景中，不同店铺（Store）或授权配置文件（Profile）下的 campaign_id 可能会发生碰撞。因此，在数据库设计与后端查询中，广告活动的业务唯一主键必须使用复合键：
唯一分组键=store_code+profile_id+campaign_id\text{唯一分组键} = \text{store\_code} + \text{profile\_id} + \text{campaign\_id}唯一分组键=store_code+profile_id+campaign_id
各广告类型的活动基础绩效表均需按此复合键进行聚合：
| 广告类型 | 官方 API 报告接口 | 数据库聚合分组键（GROUP BY） |
|---|---|---|
| SP (Sponsored Products) | /v2/sp/campaigns/report 或 Reporting v3 |
store_code + profile_id + campaign_id |
| SB (Sponsored Brands) | /sb/v4/reports 或 Reporting v3 |
store_code + profile_id + campaign_id |
| SD (Sponsored Display) | /sd/campaigns/report 或 Reporting v3 |
store_code + profile_id + campaign_id |
二、 SP 与 SD 广告：原生商品报表精准映射
对于 SP 和 SD 广告，亚马逊官方提供了直接到商品维度的绩效报表，关系链路非常清晰。
1. SP（Sponsored Products）链路
Plaintext
广告活动报表 (sp_campaign_report)
└── (store_code + profile_id + campaign_id + date)
└──> 商品维度报表 (sp_product_report)
├──> advertised_asin (推广商品 ASIN)
└──> advertised_sku (推广商品 SKU)2. SD（Sponsored Display）链路
Plaintext
广告活动报表 (sd_campaign_report)
└── (store_code + profile_id + campaign_id + date)
└──> 商品维度报表 (sd_product_report)
├──> promoted_asin (推广商品 ASIN)
└──> promoted_sku (推广商品 SKU)注意 ：在特定日期范围内查询到的 ASIN 列表，代表的是在该时间段内有广告数据产生（被观测到）的关系，并非广告活动当前的完整商品结构配置。
三、 SB 广告深度解析：双轨模型与多分支解析
SB 广告是广告数据关联中最核心的难点。
🚫 两个常见误区
- 误把
purchasedAsin当作推广 ASIN ：sbPurchasedProduct报表返回的purchasedAsin代表的是买家点击广告后最终出单购买的商品 ，并不等于广告素材上实际展示/推广的商品（存在光环效应/Halo Effect）。 - 以为
creative.asins包含所有 SB 广告商品：Amazon SB 统一 OpenAPI（v3/v4）按创意格式分层，不同广告格式的产品定义存放在不同的 JSON 嵌套结构中。
💡 解决方案：推广与出单"双轨模型"
为了兼顾"广告投放配置分析"与"出单转化分析"，推荐建立 推广关联（Promoted） 与 出单关联（Purchased） 的双轨模型：
Plaintext
┌──> 1. 创意配置解析 ──> CREATIVE_PRODUCT (推广关联)
│
SB Campaign + 授权信息 ──┼──> 2. 购买报告解析 ──> PURCHASED_ASIN_* (出单关联)
│
└──> 3. 无静态/购买证据 ──> UNRESOLVED (品牌通用/未解析)1. 推广关联（Promoted）的多分支解析
针对 Amazon Ads API 中的创意设置对象，需要按创意类型分别提取商品：
JSON
// 示意：统一 OpenAPI 中不同创意格式的产品字段位置
{
"productCollectionSettings": {
"products": [{"productId": "B08XXXXX01"}] // 格式 1：商品集合 (Product Collection)
},
"manualCollectionSettings": {
"productInclusions": [{"productId": "B08XXXXX02"}] // 格式 2：手工集合 (Manual Collection)
},
"productVideoSettings": {
"products": [{"productId": "B08XXXXX03"}] // 格式 3：视频广告 (Video)
},
"storeSpotlightSettings": {
"cards": [ // 格式 4：店铺聚光灯 (Store Spotlight)
{"products": [{"productId": "B08XXXXX04"}]}
]
},
"autoCollectionSettings": {
"productExclusions": [{"productId": "B08XXXXX05"}] // 格式 5：自动选品 (仅含排除商品)
}
}- 自动选品 (Auto Collection) ：由于官方仅提供
productExclusions（排除商品），公开创意配置无法还原最终的动态选品列表。此时应将该活动标记为UNRESOLVED（未获得静态证据），前端可打上"品牌通用广告"标签，但严禁虚构或乱套 ASIN。
2. 出单关联（Purchased）
- 来源于
sbPurchasedProduct报告。 - 明确作为"购买结果"独立展示，不应强制反写为广告创意的推广商品。
🕒 时间维度：历史版本的快照与匹配
如果一个 SB 广告活动在半年前推广 ASIN A/B/C，三个月前修改为推广 ASIN X/Y/Z：
-
粗粒度估算：取最新一次成功的 Creative 快照。虽开发成本低，但在查询一年前的报表时会发生 ASIN 错配。
-
高精度匹配 ：应根据广告报告日
report_date，按时间区间匹配当时生效的创意快照：生效条件：observed_from≤report_date<observed_to\text{生效条件：} \text{observed\_from} \le \text{report\_date} < \text{observed\_to}生效条件：observed_from≤report_date<observed_to
四、 关联 ERP 产品主数据与性能优化
将广告侧获取到的 store_code 和 asin 进一步关联到 ERP 产品主表（如 erp_product_master），可以补充产品名称、负责人、销售状态等业务信息。
Plaintext
广告报表 (store_code, asin)
└──> 店铺主表 (sp_store.store_code -> sp_store.store_name)
└──> ERP产品主表 (erp_product_master: store_name + asin)
└──> 获取属性：product_name, owner_name, sales_status...1. 数据虚高（Fan-out/笛卡尔积）防范：两步查询法
在"1 个 Campaign 对应多个 ASIN"的场景下，如果在 SQL 主查询中直接 LEFT JOIN 1 对多的产品表，会导致广告活动的花费、曝光量、销售额等指标被重复计算。
推荐架构：指标聚合与产品回填分离
Plaintext
【步骤 1】：对广告活动表进行 GROUP BY，分页获取当前页的 Campaign 列表与真实汇总指标。
【步骤 2】：根据当前页的 [store_code + profile_id + campaign_id] 复合键，
批量查询对应的 ASIN 及 ERP 产品信息，回填至返回结果的 productInfos 数组中。JSON 返回结构示例：
JSON
{
"campaignId": "C10029384",
"storeCode": "US_STORE_01",
"impressions": 12500,
"cost": 340.50,
"productInfos": [
{
"asin": "B09X111111",
"sku": "SKU-BLACK-M",
"productName": "降噪无线耳机 - 黑色",
"ownerName": "张三"
},
{
"asin": "B09X222222",
"sku": "SKU-WHITE-M",
"productName": "降噪无线耳机 - 白色",
"ownerName": "张三"
}
]
}2. 多条件筛选优化：使用 EXISTS 子查询
当用户在前端根据"产品名称"、"负责人"、"销售状态"对广告活动列表进行筛选时，应当在主 SQL 中使用 相关 EXISTS 子查询：
SQL
SELECT
c.store_code,
c.profile_id,
c.campaign_id,
SUM(c.impressions) AS total_impressions,
SUM(c.cost) AS total_cost
FROM ads_sp_campaign_report c
WHERE c.report_date BETWEEN '2026-09-01' AND '2026-09-15'
-- 使用 EXISTS 进行产品维度筛选，避免 JOIN 导致的行数膨胀
AND EXISTS (
SELECT 1
FROM ads_sp_product_report p
JOIN erp_product_master m
ON p.advertised_asin = m.asin
WHERE p.store_code = c.store_code
AND p.profile_id = c.profile_id
AND p.campaign_id = c.campaign_id
AND p.report_date = c.report_date
AND m.owner_name = '张三'
)
GROUP BY c.store_code, c.profile_id, c.campaign_id;五、 证据链分层与推荐实施路线
为了确保数据架构的可扩展性，建议在后端数据库中将 ASIN 关联来源进行分类标记（Evidence Tagging）：
| 证据代码 (evidence_type) | 来源说明 | 优先级 |
|---|---|---|
CREATIVE_PRODUCT |
SB 创意配置中的 products / productInclusions |
1（最高） |
CREATIVE_STORE_CARD |
SB 店铺聚光灯卡片绑定的商品 | 1 |
CREATIVE_LANDING_PAGE |
静态 ASIN 列表落地页商品 | 2 |
PURCHASED_ASIN_PROMOTED |
sbPurchasedProduct 报表中归因类型为 Promoted 的商品 |
3 |
PURCHASED_ASIN_HALO |
sbPurchasedProduct 报表中归因类型为 Brand Halo 的商品 |
4 |
UNRESOLVED |
动态选品或缺失证据（打上"品牌通用"标签） | 保留 Campaign 绩效，不强行绑定 ASIN |
总结
解决 Amazon Ads API 广告活动与 ASIN 关联问题的核心点在于：
- 主键唯一性 ：始终使用
store_code + profile_id + campaign_id三元组； - 分类处理：SP/SD 走官方商品报表，SB 建立"推广关联"与"出单关联"双轨模型；
- 正确解析 SB ：针对 OpenAPI v3/v4 多分支 JSON 结构进行解析，动态选品标记为
UNRESOLVED； - 性能与指标准确性 ：采用"两步查询法"与
EXISTS子查询，彻底消除笛卡尔积引发的指标虚高。