吴老师讲AMC——14期"如何在AMC中按广告产品类型筛选数据（How to filter by ad product type）"

今天我们继续讲一个非常重要的AMC Use case：

How to filter by ad product type

翻译成中文，就是“如何按广告产品类型进行筛选”。

这个Use case要解决的问题是：

当AMC里同时包含 Sponsored Products、Sponsored Brands、Sponsored Display、Sponsored TV、DSP、Fire TV、Twitch、IMDb、Prime Video、Amazon Live 等不同广告和媒体资源时，我们怎么把这些广告类型拆开分析？

很多卖家看AMC数据时，会遇到一个问题：

后台能看到曝光、点击、购买，但是不知道这些数据到底来自哪一种广告产品。

是SP带来的？

是SB带来的？

是SD带来的？

还是DSP里的视频、Fire TV、Twitch、Prime Video带来的？

如果广告产品类型不拆清楚，后面的预算复盘、素材判断、人群分析都会混在一起。

所以这篇Use case的价值，就是帮助我们建立一套广告产品类型识别方法。

PART.01

Introduction

官方文档中，这个Use case的背景是：

AMC包含来自不同广告来源的数据，主要包括：

1. Sponsored Ads：Sponsored Products、Sponsored Display、Sponsored Brands、Sponsored TV等；
2. Amazon DSP：例如Streaming TV、Fire TV、Online Video、Audio、Display、IMDb、Twitch等；
3. Amazon Live Events：Amazon Live直播相关事件。

官方也说明，这个Use case可以帮助我们理解如何查询AMC支持的广告产品类型，并查看某个时间段内运行过哪些campaign和line item。

PART.02

引言

这段话的意思很清楚：

AMC不是只看一种广告。

它可以把Sponsored Ads、DSP、Amazon Live等多种广告和媒体触点放到同一个分析环境里。

但是，数据放在一起以后，第一件事不是马上分析转化，而是先搞清楚：

这些数据分别来自哪些广告产品？

吴老师解读：

很多同学做广告复盘时，会习惯性地看总曝光、总点击、总订单。

但如果你把SP、SD、DSP、Fire TV、Twitch这些数据混在一起看，总数其实没有太多指导意义。

因为不同广告产品承担的任务不一样。

SP通常更接近搜索转化；

SB可能更偏品牌展示和关键词入口；

SD可能兼具商品浏览和人群触达；

DSP则更多承担种草、召回、跨媒体触达。

所以，这个Use case的核心不是“查一个字段”，而是帮我们先把广告类型拆开。

PART.03

AMC中哪些广告类型可以识别？

官方文档列出了AMC支持的一些广告来源。

Sponsored Ads部分，主要包括：

1. Sponsored Products，也就是SP；
2. Sponsored Brands，也就是SB；
3. Sponsored Brands Video，也就是SBV；
4. Sponsored Display，也就是SD；
5. Sponsored TV。

Amazon DSP部分，则包含Streaming TV、Online Video、Fire TV、Audio、Display、IMDb、Twitch等不同资源。

Amazon Live Events也可以进入AMC，但它的颗粒度和campaign、line item并不完全一样，通常要看broadcast id和broadcast name。

吴老师解读：

大家要注意一点：

AMC里的广告产品识别，不同广告来源的逻辑是不一样的。

Sponsored Ads相对简单，因为它有 ad_product_type 字段。

Amazon DSP会复杂很多，因为DSP campaign并没有像Sponsored Ads那样直接使用 ad_product_type 字段。

所以我们后面要分两条线来理解：

1. Sponsored Ads：重点看 ad_product_type；
2. Amazon DSP：重点看 line_item_type、supply_source、site、device_type，以及campaign或line item命名。

PART.04

示例一：识别所有Sponsored Ads广告活动

对于Sponsored Ads，官方文档说明，可以使用 ad_product_type 字段识别广告产品类型。

常见值包括：

sponsored_products sponsored_brands sponsored_display sponsored_television

如果我们想查询所有Sponsored Ads活动，可以参考下面的逻辑：

SELECT   campaign,   campaign_id_string,   ad_product_type FROM   amazon_attributed_events_by_traffic_time WHERE   ad_product_type IN (     'sponsored_products',     'sponsored_brands',     'sponsored_display'   ) GROUP BY   1, 2, 3

吴老师解读：

这是这篇Use case里最基础、也最常用的写法。

如果我们只想看SP，就保留：

'sponsored_products'

如果只想看SB，就保留：

'sponsored_brands'

如果只想看SD，就保留：

'sponsored_display'

这样我们就可以把不同Sponsored Ads广告类型拆开。

比如同一个产品线，我们可以分别看：

1. SP带来的曝光和订单；
2. SB带来的品牌触达；
3. SD带来的商品浏览和再营销效果。

PART.05

示例二：Sponsored Brands Video不能只看ad_product_type

Sponsored Brands里面还包含不同广告格式。

比如常见的Retail广告格式，也有Sponsored Brands Video，也就是SBV。

官方文档提醒，如果要区分SBV，可以看视频相关指标。

比如：

five_sec_views video_complete_views video_first_quartile_views video_midpoint_views video_third_quartile_views video_unmutes

这些视频指标只有在SBV广告中才会有值，其他SB格式可能为空。

吴老师解读：

这就是AMC比广告后台更有价值的地方。

广告后台里，我们可能看到它属于Sponsored Brands。

但在AMC里，我们可以进一步判断它是不是视频广告。

如果视频指标有数据，说明这个SB活动很可能是SBV。

这样后续我们就可以单独分析视频广告的曝光、播放、完播、互动和转化，而不是把它和普通SB混在一起。

PART.06

示例三：Amazon DSP不能直接依赖ad_product_type

官方文档中非常关键的一点是：

Amazon DSP campaign没有Sponsored Ads那种 ad_product_type 字段。

在Amazon DSP场景下，需要通过其他字段识别广告产品类型。

常用字段包括：

campaign campaign_id_string line_item_type supply_source site device_type

如果我们在归因事件表里看到 ad_product_type IS NULL，这往往可以帮助我们把DSP和Sponsored Ads区分开。

官方示例中也提到，可以通过DSP相关表识别流量事件：

dsp_impressions dsp_clicks dsp_views

转化事件可以看：

amazon_attributed_events_by_conversion_time amazon_attributed_events_by_traffic_time

吴老师解读：

这部分非常重要。

Sponsored Ads可以通过 ad_product_type 直接拆；

DSP不能这么简单。

DSP更多要看line item层级、供给来源、设备类型、站点来源，甚至要依赖campaign或line item的命名规则。

所以如果你的DSP命名不规范，后面在AMC里拆分Streaming TV、Online Video、Fire TV、Twitch、Prime Video时，就会非常吃力。

PART.07

示例四：用line_item_type识别视频广告

在Amazon DSP中，Streaming TV和Online Video都属于视频类资源。

官方文档中提到，视频类line item可以通过 line_item_type 识别，例如：

WHERE line_item_type = 'AAP_VIDEO_CPM'

这个条件可以帮助我们先筛出视频line item。

但如果同时投放Streaming TV和Online Video，仅靠 line_item_type 还不够。

因为它们可能都属于视频广告。

这时就需要进一步依赖line item或campaign命名。

比如命名中包含：

OTT streaming STV OLV Online video

就可以用 SIMILAR TO 进一步筛选。

吴老师解读：

这里就回到我们之前讲过的文本筛选Use case。

AMC中做文本筛选，不要用 LIKE，要用：

SIMILAR TO

如果大小写不统一，可以用：

(?i)

比如：

line_item SIMILAR TO '(?i)streaming' campaign SIMILAR TO '(?i)online video'

这也说明，广告命名不是后台管理的小事，而是AMC分析的基础。

如果你希望以后能在AMC里准确区分STV、OLV、Fire TV、Twitch等资源，就要提前在campaign或line item命名里写清楚。

PART.08

示例五：用supply_source识别DSP媒体资源

对于Amazon DSP，很多媒体资源可以通过 supply_source 识别。

比如：

1. Fire TV可以通过类似 MOBILEAPP_AMAZON_FIRE_TV 的供给来源识别；
2. Fire Tablet可以通过类似 MOBILEAPP_AMAZON_FIRE_TABLET 的供给来源识别；
3. Audio可以通过包含 audio 的供给来源或line item type识别；
4. IMDb可以通过包含 IMDb 的供给来源识别；
5. Twitch可以通过包含 twitch 的供给来源识别；
6. Prime Video ads可以通过 Prime Video ads 供给来源识别；
7. DOOH可以通过对应的 supply_source_id 识别。

官方Twitch示例中，就使用了类似下面的逻辑：

WHERE supply_source SIMILAR TO '(?i)twitch'

如果要进一步区分Twitch Audio、Twitch Mobile App Video、Twitch Web Video，也可以继续筛选具体的 supply_source 值。

吴老师解读：

DSP的拆分逻辑，本质上是“多字段联合判断”。

不要期待一个字段解决所有问题。

实际操作中，我们通常会组合使用：

line_item_type supply_source site device_type campaign line_item

这样才能比较准确地判断广告到底来自哪种DSP资源。

PART.09

广告命名在这个Use case中的作用

这篇Use case和广告命名是有关系的。

尤其是在DSP场景中，官方也提到：有些资源不能只靠 line_item_type 区分，需要通过campaign或line item名称来识别。

比如Streaming TV和Online Video，如果命名里没有写清楚 STV、OLV、Streaming、Online Video，后面就很难拆分。

所以吴老师建议，广告命名至少要固定几个要素：

广告类型-SKU-投放目标-广告投放位置-补充说明

在DSP或视频广告里，补充说明部分尤其重要。

比如：

DSP-CaC003-GRA-P-N-STV DSP-CaC003-GRA-P-N-OLV DSP-CaC003-GRA-P-N-FireTV DSP-CaC003-GRA-P-N-Twitch

吴老师解读：

这不是为了命名好看，而是为了后续AMC分析能筛得出来。

如果命名清楚，我们可以用 SIMILAR TO 快速筛选；

如果命名混乱，后面就只能靠人工判断，效率很低，准确性也差。

PART.10

这个Use case在运营中怎么用？

这个Use case适合用在以下场景：

1. 想拆分SP、SB、SD、SBV、Sponsored TV的广告表现；
2. 想单独分析DSP曝光、点击、购买；
3. 想区分Streaming TV和Online Video；
4. 想识别Fire TV、Fire Tablet、Twitch、IMDb、Prime Video等资源；
5. 想检查某个时间段到底跑了哪些campaign和line item；
6. 想为后续路径分析、人群分析、预算复盘提供更干净的广告类型维度。

吴老师解读：

广告产品类型拆清楚以后，我们才能回答更有价值的问题。

比如：

SP和SD谁更接近转化？

DSP视频是不是只带来曝光，还是也影响了后续购买？

Twitch、Fire TV、Prime Video这些资源到底有没有帮助品牌种草？

不同广告类型之间有没有形成组合影响？

如果不先拆广告产品类型，这些问题都没法回答。

PART.11

实操建议

大家在使用这个Use case时，可以按照下面顺序操作：

1. 先判断你要分析的是Sponsored Ads，还是Amazon DSP；
2. 如果是Sponsored Ads，优先看 ad_product_type；
3. 如果是SBV，额外看视频相关指标；
4. 如果是DSP，优先看 line_item_type、supply_source、site、device_type；
5. 如果字段无法完全区分，就结合campaign或line item命名；
6. 文本筛选使用 SIMILAR TO，不要使用 LIKE；
7. 最终输出只保留聚合后的campaign、line item、广告类型、曝光、点击、转化等指标，不要输出用户级明细。

这篇Use case本身很长，里面列了很多DSP资源的示例。

大家不需要一次性背下来。

真正要掌握的是这套判断方法：

Sponsored Ads：看 ad_product_type DSP视频：看 line_item_type + campaign/line item命名 DSP媒体资源：看 supply_source / site / device_type Amazon Live：看 broadcast id / broadcast name

只要掌握这套框架，后面遇到新的广告资源，也可以按同样逻辑拆解。

PART.12

最后总结

本期我们讲的是AMC中的一个基础Use case：

How to filter by ad product type

大家重点记住四件事：

1. Sponsored Ads可以用 ad_product_type 识别SP、SB、SD等广告产品；
2. SBV需要结合视频播放相关指标进一步判断；
3. Amazon DSP不能直接依赖 ad_product_type，要看 line_item_type、supply_source、site、device_type 等字段；
4. 对于STV、OLV、Twitch等资源，campaign和line item命名会直接影响AMC能不能筛得准。

这个Use case的价值，不是让我们记住每一个广告资源的SQL模板，而是建立一套广告产品类型识别框架。

先把广告类型拆清楚，再去看曝光、点击、转化、路径和人群，分析结论才有意义。

也欢迎大家收藏专题“吴老师讲AMC”，后面我们会继续用更容易理解的方式，把AMC中的Use case拆开讲清楚。

PART.13

想系统学习AMC，可以关注吴老师线下实操课

今天我们讲的只是AMC中一个非常基础的Use case。

但是大家通过这个案例应该能够感受到，AMC真正的价值，不是把一段SQL代码跑出来就结束了，而是要把广告数据和运营动作连接起来。

同样是一个广告产品类型筛选，如果只是从技术角度看，它只是字段过滤；但如果放到广告运营中，它就可以帮助我们拆分广告类型、理解媒体资源、判断预算结构，并为后续路径分析和人群分析打基础。

这也是吴老师一直强调的：

AMC不是单纯的数据工具，而是帮助我们看懂消费者购买路径、优化广告投放策略的分析系统。

如果你只是偶尔看一个报表，可能很难真正发挥AMC的价值。

但如果你能系统掌握：

1. AMC底层数据集怎么理解；
2. 不同广告类型在AMC中如何拆解；
3. 如何用Codex辅助生成和分析AMC SQL；
4. 如何把AMC结果转化为广告优化动作；
5. 如何通过路径、人群、转化数据找到新的投放机会；

那么AMC就不再只是一个“看起来很高级”的后台工具，而会变成你做广告增长决策的实战武器。

吴老师也准备了 Codex+亚马逊AMC王牌技能组合线下实操课，会围绕“用上帝视角洞察消费者购物全路径”来展开，带大家系统学习如何把Codex和AMC结合起来，用数据看懂广告、看懂消费者、看懂转化路径。

这门课更适合已经在做亚马逊运营、广告投放，或者希望从普通广告操作升级到数据化广告分析的同学。

如果你希望不只是看懂本文这个基础Use case，而是进一步掌握AMC在广告分析、人群洞察、路径拆解、预算优化中的高阶应用，可以扫码了解课程详情。