进阶65分钟第 4 课

Meta Catalog:产品集、动态广告和集合页同步

把 Shopify 集合页、Meta 产品集和 Pixel/CAPI content_ids 对齐,先验收商品池事实,再进入 Meta Ads 放量判断。

4
当前进度
4/8 课时

作者与维护者

卫染风

发布日期

更新日期

最近复核

维护边界 结合 Shopify、Google 搜索、广告、数据分析与独立站运营流程复核。

课程进度
学习进度
4/8 课时
当前章节已解锁继续按顺序推进

目录映射工作台

产品集不是广告后台里的临时筛选器。

Meta Catalog、Shopify 集合页/集合规则、产品集和 Pixel/CAPI content_ids 必须使用同一套稳定映射否则动态广告会把错误商品稳定放大出去。

本课产出

Meta Catalog 商品集治理表

完成标准:产品集能解释商品来源、排除规则、事件匹配和业务用途。说不清这些,不扩大预算。

目录商品项 id

必须和 Pixel/CAPI content_ids 对齐。

item_group_id

把颜色、容量等变体归在同一商品组。

产品集规则

规则、排除项、业务用途和负责团队可导出复查。

先读完案例,再操作工作台

24 个商品看起来都在产品集里,真正可以交给广告的只有 21 个。

延续 NorthPaw 保温杯案例。2026 年 7 月 18 日 09:00–11:00(America/Toronto),美国市场的 Meta 动态广告准备推广“50 美元以下礼品”。团队在 Shopify 用 gift_ready 标签维护买家能看到的集合页,又在 Meta Catalog 建了一个同名产品集。表面上,两个地方都显示 24 个商品,于是投手准备扩大预算。问题是,名称相同和数量相同,都不能证明它们读取的是同一批可投放变体。

先把四个对象分开。Shopify 集合是店内导航对象,决定买家在集合页看见什么;Catalog item 是 Meta 实际接收的一条商品或变体记录;product set 是从 Catalog 中按字段规则圈出的广告商品池;Pixel/CAPI 的 content_ids 则告诉 Meta 用户刚刚浏览、加购或购买了哪个目录对象。集合决定页面入口,产品集决定广告可读范围,事件 ID 决定行为能否匹配到那个范围。任何一环使用不同主键,动态广告都可能召回错误颜色,或者根本找不到用户看过的商品。

本篇只作一个决定:这 24 个候选商品中,哪些已经满足字段、库存和事件身份条件,可以进入广告产品集。它不判断素材好坏,也不预测 CPA 或 ROAS。你最终要留下PD-004《Meta Catalog 商品集治理记录》,让商品数据、站点、分析和投放人员都能从同一行证据解释“谁进入、谁退出、为什么”。

链路节点NorthPaw 样例值谁读取通过证据
Shopify 变体SKU NP-TB20-SAGE
variant_id 48201755024681
Shopify、同步应用20oz / Sage / $24.99 / available
Catalog itemshopify_US_48201755024681Meta Catalogitem id、价格、库存与落地变体均回读一致
item_group_idNP-TB目录变体分组20oz/Sage 仍是独立可买变体,不被父商品替代
Pixel/CAPIcontent_ids=["shopify_US_48201755024681"]
content_type=product
事件匹配与动态广告ViewContent、AddToCart、Purchase 均匹配同一 item

抽样时,团队发现 20oz/Sage 的浏览事件发的是 SKU NP-TB20-SAGE,而 Catalog item id 是 shopify_US_48201755024681。两者都能唯一指向内部商品,并不等于 Meta 会自动把它们视为同一个目录对象。当前事件能发出,只能证明埋点有请求;只有 Test Events 中的 content_ids 与 Catalog item 完全相同,并且落地页默认选中 20oz/Sage,才通过这一条身份验收。

完整覆盖计算也要保留中间步骤。初始规则 gift_ready=true AND in_stock=true 显示 24 个候选项;逐项回读发现 2 个颜色已经缺货,却还没完成同步排除;另有 1 个 20oz/Sage 因事件 ID 不匹配而不能进入动态广告验收。24 − 2 − 1 = 21,所以当前可发布覆盖率是 21 ÷ 24 = 87.5%。这个比例只描述本次治理检查的合格范围,不证明 21 个商品会带来更高转化,更不证明产品集具有增量效果。

还要注意地区边界。本案例是美国店铺,因此可以把 Shopify 集合作为集合治理的一部分;但当前 Shopify 官方说明提示,集合向 Facebook 的同步能力具有店铺地区条件。非美国店铺不能因为 Shopify 页面上存在同名集合,就假设 Commerce Manager 已经收到同一个集合。稳定做法是分别回读 Shopify 集合、Facebook & Instagram 渠道的商品状态,以及 Commerce Manager 中实际的 product set 规则。

八步发布路线:位置、证据、失败动作都要写

  1. 1. 先锁定业务用途:这次只做美国市场“50 美元以下礼品”动态再营销,负责人和结束日期同时写入 PD-004。用途说不清就不建集合。
  2. 2. 在 Shopify Products/Variants 确认 gift_ready、价格、库存和变体主键的作者位置;截图或导出 24 个候选项。
  3. 3. 在集合与 Facebook & Instagram 渠道回读商品状态和错误。Shopify 正确但渠道仍旧,先处理同步,不在 Meta 下游手改源事实。
  4. 4. 在 Commerce Manager 的 Catalog items/Sets 固定 catalog、market 和更新时间,核对 item id、item_group_id、set rule、价格、库存和落地 URL。
  5. 5. 写明排除:2 个缺货颜色、浅库存、价格错误和 ID 不匹配项必须先退出;产品集名称不能替代排除条件。
  6. 6. 抽 5 个边界 SKU:正常进入、明确排除、变体选择、浅库存和促销项各一个。逐个从 Shopify 追到 Catalog 和落地页。
  7. 7. 在 Test Events 检查 ViewContent、AddToCart、Purchase 的 content_ids、content_type、value 和 currency。任一关键事件仍发 SKU 时,先 Hold 产品集。
  8. 8. 同步后重新回读 24 个候选项。只有 21 个合格项稳定出现、3 个排除项不再可投、5 个样本均匹配时才 Go;否则保留截图、时间戳和 owner 后停止放量。

PD-004

填好的一行治理记录

用途与 owner
US Gifts under $50;商品数据 owner + 投放 approver
成员规则
gift_ready=true AND in_stock=true
范围算式
24 候选 − 2 缺货 − 1 ID 不匹配 = 21 合格
事件格式
shopify_US_{variant_id}
证据包
24-item 导出、5-SKU 映射、3 个 Test Events、落地页变体截图、同步时间
停止与回滚
事件 ID、价格或库存任一回读失败,停止放量;恢复上一版规则并交回对应 owner

进入互动前,先预测什么会改变

下面的工作台会让你切换产品集用途、集合/产品集规则、边界场景和压力场景。默认状态代表上面的礼品池:24 个候选、21 个合格,20oz/Sage 的事件 ID 需要修复。切换为高毛利池时,成员字段和排除条件会变化;Shopify 变体、Catalog item 和事件必须共享同一身份层级这一条不会变化。

先预测每次切换应该改变哪一列,再点击。互动反馈可以帮助比较路线,却不能替代静态结论:产品集覆盖率不证明广告表现,单个测试事件不证明三个事件和全部 SKU 都匹配,Shopify 集合成员也不自动等于 Meta 产品集成员。证据不足时回到身份链和 24-item 回读,而不是继续调预算。

What:这篇治理什么

治理的是 Meta Catalog、产品集、Shopify 集合页/集合规则和 Pixel/CAPI 事件之间的商品身份链路,不是后台里一个产品集名称。

Why:为什么会影响经营

链路分叉以后,预算会稳定推给错误商品;看起来像 CPA、素材或受众问题,实际是商品池不可信。

How:点完怎么用

先选产品集用途,再选边界场景和压力场景;最后把第一证据、禁止动作、负责人和复查时间写进复制笔记总结。

本课边界

这里先管商品池事实,不替你设计广告结构。

本课负责回答产品集读哪些商品、哪些商品必须排除、事件 ID 能不能匹配、截图证据在哪里。Meta Ads 产品集放量课负责 campaign、ad set、Advantage+ Sales 和预算节奏。先把商品池事实验收清楚,再去投放课决定怎么放量。

去看 Meta Ads 产品集放量课

规则确认后,还要把同一套商品事实写回集合页职责和变更日志,避免广告、集合页和 Feed 各自维护一份规则。

名词先说清楚

先把本课会用到的词讲清楚。

Meta Catalog

Meta Catalog 是 Meta 广告读取商品资料的目录,里面有商品、变体、图片、价格、库存和产品集。新手可以把它理解成 Meta 广告用的商品库。

目录映射错时,动态广告可能稳定放大错误商品。

产品集

产品集是广告可读取的一组商品规则,比如夏季新品或高毛利商品。它不是站内集合页,但经常需要和集合页保持同一套商品事实。

节日礼品产品集要写清包含规则、排除规则、归档时间和负责团队。

item_group_id

item_group_id 用来把同一款商品的不同颜色、尺寸、容量归到一个商品组。没有它,平台可能把每个变体都当成完全无关的商品。

同一款宠物胸背带的 S/M/L 尺码应该属于同一个商品组。

事件商品 ID

事件商品 ID 是 Pixel/CAPI 在浏览、加购、购买事件里发送的商品编号。它要能和目录商品项对上,否则再营销和动态广告会断链。

同一商品不要在变体 ID、SKU 和目录商品 ID 之间随意混用。

variant ID / 变体 ID

variant ID 是 Shopify 给每个颜色、尺寸、容量变体生成的记录 ID。它通常比 SKU 更适合做广告和事件的商品身份,因为它指向具体可购买变体。

蓝色 20oz 保温杯和黑色 20oz 保温杯应该能分别对上自己的 variant ID、目录 item id 和 content_ids。

CPA

CPA 是拿到一单或一个目标行动的广告成本。本课里 CPA 用来判断商品池能不能承受放量成本,不是唯一成功指标。

高毛利 SKU 能承受的 CPA 和低毛利套装不同,混在一起会误导预算。

Merchant Center

Merchant Center 是 Google 读取商品 Feed 的商品数据中心。它不是 Meta Catalog,但两边经常依赖同一套商品标题、价格、库存和 GTIN。

如果 Google Feed 与 Meta Catalog 的价格或库存不同,两个广告系统会读出相互冲突的商品判断。

SKU margin / SKU 毛利

SKU 毛利是单个 SKU 扣掉商品成本、物流、折扣、退款等直接成本后还能留下的利润空间。

best-seller 标签不能直接定义高毛利池,必须再看 margin_tier 和净订单证据。

01 用途路由

先说产品集为什么存在,再决定怎么建。

同样叫产品集,动态广告再营销、节日礼品、高毛利放量和清仓排除的字段来源、排除规则、事件验收和归档方式完全不同。先选用途,再写规则。

当前用途

动态广告再营销

读取来源

目录商品项、Pixel/CAPI content_ids、可用库存和当前价格。

必须排除

缺货、价格异常、事件 ID 匹配失败的商品。

事件验收

测试 ViewContent、AddToCart、Purchase 是否能匹配同一目录商品项。

关闭规则

事件和目录能互相解释后再扩大预算。

02 规则对照表

同一个商品池,Shopify 集合页和 Meta 产品集读的不是同一个规则。

先点选一个业务场景,对照 Shopify 集合页/集合规则、Meta 产品集规则、事件要求、排除项和写回动作。不要把买家导航用的集合页规则,直接当成广告放量用的产品集规则。

操作提示:先选最接近你当前活动的场景,再看对照结果。能同时解释集合页规则、产品集规则和 content_ids,才算能交给广告放量。

当前对照

节日礼品:Gifts under $50

逐行对照买家集合规则、广告产品集规则和事件要求。每一行都要能回到当前规则或截图。这里比较的是当前场景,不会替任何广告组改规则。

Shopify 集合页/集合规则

集合页规则:price < 50、tag = gift_ready、available = true,并确认买家能看到配送承诺。

Meta 产品集规则

产品集规则:读取 gift_ready 或 custom label,同时限制库存天数、活动日期和 Catalog 可用状态。

事件要求

事件要求:ViewContent、AddToCart、Purchase 的 content_ids 要匹配 Catalog item id,而不是只匹配集合页 URL。

排除规则

排除:低于 14 天库存、发货承诺不稳定、活动结束后仍带旧标签的 SKU。

写回治理表

写回:集合页负责买家导航;Meta 产品集负责广告读取;活动结束 24 小时复查覆盖数和事件匹配。

03 映射表

先让每个节点有来源、用途和验收。

目录商品项、item_group_id、产品集规则、集合页/集合规则、事件 content ID 和广告目标要互相解释,不能靠投手记忆。

节点

目录商品项 id

Shopify 变体 ID 或 SKU

必须和 Pixel/CAPI content_ids 对齐。

目录商品项 + 事件测试截图

item_group_id

父商品或款式组

把颜色、容量等变体归在同一商品组。

目录商品项 变体关系

产品集规则

集合页/集合规则、标签、product_type、自定义标签

规则、排除项、业务用途和负责团队可导出复查。

Meta 产品集规则

集合页/集合规则

Shopify 集合页/集合规则

说明是否和产品集同源,价格变化后谁更新。

Shopify 集合页覆盖截图

事件 content ID

Pixel/CAPI 事件

content_ids、content_type、value、currency 能匹配目录商品项。

Events Manager / 测试事件

广告目标

动态广告、活动商品组、再营销

解释为什么使用这个产品集。

广告组设置

04 商品池边界练习

不要只问产品集叫什么,要问它该把谁排除出去。

产品集治理的难点不是建一个集合,而是在 ID、库存、地区同步和毛利之间画边界。下面选一个压力场景,再选择本轮动作,看看能不能安全放量。

当前压力

20oz 保温杯 content_ids 对不上目录 ID

先确认当前商品池的边界,再选择本轮动作。第一证据要能定位被纳入或排除的具体变体、规则或事件。下面的反馈只评估当前选择,不会修改 Catalog、库存或预算。

隐藏风险:如果直接扩大预算,系统会学习到错误或不完整的商品身份链路,后续再营销和相似商品推荐都会偏。
第一证据:抽 5 个 SKU,对照 Shopify 变体 ID、目录 item id、item_group_id、Pixel/CAPI content_ids 和 Purchase 事件。

05 ID 匹配

目录 ID 和事件 ID 必须对齐。

动态广告能不能召回用户看过或加购过的商品,取决于事件里的 content_ids 是否能匹配 目录商品项。

同一 ID 格式

变体 ID、SKU、目录商品项 id 和 content_ids 不要混用。

同一变体层级

用商品组还是变体,要和 item_group_id 与 content_type 一起确认。

同一测试证据

用目录商品项和 Pixel/CAPI 测试事件截图做复核。

06 事件匹配检查

content_ids 对不上时,先查 ID 层级,不要先重建广告。

很多 Catalog 问题看起来像广告问题,实际是事件、目录商品项、item_group_id、产品集覆盖和集合页来源没有对齐。下面这张表把常见错配拆成第一证据和禁止动作。

场景

事件发商品组,目录读变体

ViewContent 有 content_ids,但动态广告只能召回少数颜色或显示父商品。

对照事件 content_ids、目录商品项 id、item_group_id 和产品集覆盖。

先决定广告读取变体还是商品组,再统一事件和目录的 ID 层级。

不要先重建产品集;产品集规则可能没错,错的是 ID 层级。

SKU、变体 ID 和目录 item id 混用

Catalog 有商品,事件也有商品编号,但匹配率低,大小写、前缀或分隔符不一致。

抽 5 个 SKU,比对 Shopify 变体、目录商品项、Pixel/CAPI 事件和购买事件。

把 ID 格式写进治理表,后续所有事件、Feed 和产品集规则都按同一格式验收。

不要在不同工具里分别加前缀或手工修字符串。

产品集覆盖还在读旧活动标签

活动结束后,缺货颜色或低毛利 SKU 仍进入动态广告商品池。

对照集合页/集合规则、活动标签、产品集规则、排除列表和目录更新时间。

先归档活动标签或写结束日期,再刷新产品集覆盖和事件样本。

不要只在广告组里排除几个商品,源规则还会把它们带回来。

同一商品进入多个目录来源

Meta 目录里出现重复 item,事件匹配到旧来源,产品集覆盖数突然变化。

对照数据源、目录商品项 id、上次更新时间、产品集规则和事件命中商品。

保留一个可解释的数据源,记录旧来源下线时间和复查窗口。

不要同时让多个同步源改同一批商品。

06A 可保存的范围与预览复查记录

把商品来源、产品集预览和事件匹配留成可恢复的复查记录。

这份记录帮助你发现同名集合、多个 Catalog 或不同商品形态造成的断链;它不连接 Meta、Shopify、Feed 应用或真实广告账户。

先同时固定实现来源、Catalog / market、商品身份层级和产品集预览。 这是一份复查记录,不会读取、上传或修改任何目录、事件、商品、广告或预算。

只有 Catalog item id 与抽样 content_ids 完全相同,并且产品集预览与三个关键事件都能当前读回,才能准备一次同范围读回。 同名产品集、相同数量或只有 item_group_id 都不能代替这条验证。

不要粘贴客户、订单、登录信息、令牌或其他敏感数据;角色、非敏感证据位置和当前界面已经足够用于本课。

当前判断:保持 Hold,补齐来源、目标、身份、预览、事件、角色与下次读回。

已完成 0/9 个记录条件。

07 目录规模策略

5 个 SKU 是教学样本,不是所有目录的通用门槛。

产品集治理要随目录规模调整。小目录可以全量检查;中等目录抽主推、边界、库存、促销和高毛利样本;大目录要按规则、市场、库存深度、margin_tier 和事件量分层。

小目录

直接检查产品集内所有商品。

SKU 数量少、活动商品池清楚、人工复核成本低。

保留完整产品集覆盖、低库存排除和事件匹配记录。

中等目录

抽主推 SKU、边界 SKU、库存/促销/高毛利样本。

产品集覆盖几十到几百个商品,不能逐个检查,但仍能按活动重点抽样。

每个样本都要能对上 Shopify 变体、Catalog item、content_ids、库存和毛利层级。

大目录

按产品集规则、市场、库存深度、margin_tier 和事件量分层抽样。

目录很大、市场很多或动态广告覆盖面广,单纯 5 个 SKU 只能当教学样本。

每层都要有覆盖数、排除逻辑、事件匹配和暂停/继续判断。

08 后台证据路径

每条治理结论都要能回到具体后台位置。

不要只写“已确认”。写清 Shopify、Meta Catalog 和 Events Manager 分别在哪里看,看到什么,哪一条记录支持暂停或继续。

后台面

Shopify 商品和变体

Products / Variants,检查 SKU、variant ID、价格、库存、标签和 product_type。

商品事实源头记录,说明目录 item id 和 content_ids 应该读哪一层。

Shopify 集合页和渠道

Collections;Sales channels and apps -> Facebook & Instagram,检查集合规则、渠道可用商品、产品状态和错误。

集合页服务买家导航;渠道可用性只证明商品可同步,不等于 Meta 产品集规则。

Meta Catalog 和产品集

Commerce Manager / Catalog / Items / Sets,检查 item id、item_group_id、数据源、覆盖数、排除项和更新时间。

产品集治理表写清广告读取哪组商品,以及为什么这组商品可以放量或必须暂停。

Pixel/CAPI 事件

Events Manager / Test events / Pixel or CAPI payload,检查 content_ids、content_type、value、currency 和 Purchase 样本。

事件必须能匹配 Catalog item;只看到事件触发,不代表动态广告能正确召回。

09 三张截图验收

Catalog 问题经常不是目录自己坏了。

每次改产品集前,先留 Shopify/集合页/集合规则、Meta 目录商品项、Pixel/CAPI 事件三张截图。如果它们互相解释不了,就先修映射。

Shopify 商品 / 集合页/集合规则

SKU、变体 ID、标签、product_type、库存、价格。

商品事实从哪里来。

Meta 目录商品项

item id、item_group_id、图片、可用性、更新时间。

目录是否读到正确版本。

Pixel/CAPI 事件

content_ids、content_type、value、currency。

事件能否匹配目录商品。

这三类记录必须互相解释:Shopify 说明商品事实从哪里来,Meta Catalog 说明目录读到了什么,Pixel/CAPI 说明事件能否找到同一个商品。解释不通时,先修映射,不扩大预算。

10 规则审计

产品集要写业务用途,不只写名字。

节日礼品、热卖商品、50 美元以下、新品这些商品池,都要能说明来源、排除项、负责团队和活动后如何处理。

规则来源

集合页/集合规则、标签、product_type 或 custom label,不能只靠广告后台手动点选。

排除项

缺货颜色、套装、价格区间、低毛利 SKU 是否排除。

业务用途

动态广告、节日礼品、再营销、活动商品池分别写清。

归档规则

活动结束后保留、归档还是改成 evergreen。

11 商品池放量压力练习

真正容易出错的地方,是会议里每个人都想先上线。

产品集治理不是后台命名规范,而是放量前的商品池验收。下面选一个真实压力:排期、ID、集合页同步或利润边界。每个场景都要写清诱人的错误动作、更稳读法、第一证据和禁止动作。

当前治理压力

Advantage+ 销售活动今天要上

广告排期已经定了,团队想直接把 Gift Cups 产品集接进 campaign。问题是覆盖数刚变过,没人能说清哪些颜色和套装已经被排除。

诱人的错误动作: 诱人的错误动作:先上线,明天看 ROAS;产品集名字看起来已经对了。
更稳读法: 更稳读法:产品集名字不是证据。先看覆盖数、排除规则、库存深度和活动后归档规则能不能互相解释。
第一证据: 第一证据:导出或截图产品集规则、当前覆盖数、低库存排除、广告组引用的产品集和活动结束日期。
禁止动作: 禁止动作:只改产品集名称、只在广告组手工排除几个 SKU、没有覆盖截图就放大预算。
复制到笔记: 笔记行:ASC 上线前先锁产品集覆盖、排除项、库存和归档时间;证据不齐,不放量。

12 比如一款保温杯商品演练

节日礼品产品集要能解释集合页、广告和事件。

比如一款保温杯商品原来集合页叫 Gifts under $50,Meta 产品集叫 Gift Cups,两者并不完全一致。重构后,它们共享稳定字段和复核截图。

1

Shopify 集合页叫 Gifts under $50。

定义用户可见商品池和价格规则负责人。

2

Meta 产品集叫 Gift Cups,来源不清。

产品集读取稳定字段,并写明排除缺货颜色和套装。

3

Pixel/CAPI content_ids 未核对目录商品项。

上线前 7 天查覆盖,活动后 24 小时查事件和目录匹配。

落地时要继续写清:集合页读取哪条价格规则,产品集读取哪些标签或 custom label,缺货颜色是否排除,Pixel/CAPI content_ids 是否匹配 Catalog item id,以及活动结束后标签什么时候归档。

这里的目标是让商品池可信,再把同一套商品事实交给 SEO、站内搜索和集合页治理;广告结构和预算动作留在对应的投放判断里。

14 快速自测

映射不清楚,不扩大预算。

比如一款保温杯商品要放大节日礼品动态广告。Shopify 集合页是 Gifts under $50,Meta 产品集是 Gift Cups,但 Pixel/CAPI content_ids 还没和目录商品项对齐。现在应该怎么做?

15 停止/继续

广告到底在放大哪一组商品?

Catalog、产品集、集合页/集合规则和事件 ID 不能互相解释时,先修映射,再谈素材、受众或预算。

Catalog、产品集、集合页/集合规则、事件 ID 对齐

继续,进入动态广告或活动放量

目录商品项、产品集规则、事件测试截图

产品集规则只存在广告后台记忆里

暂停,写入治理表

规则来源、排除项、业务用途和负责人

content_ids 无法匹配目录商品项

暂停,修事件和目录映射

Pixel/CAPI 事件和目录商品项对照

集合页和产品集商品池不一致

复核,确认业务用途和排除规则

Shopify 集合页、产品集覆盖和排除列表

活动前没有覆盖截图

不扩大预算

上线前覆盖数、缺货排除和事件匹配截图

16 常见搜索问题

先回答谁读什么,再决定要不要改产品集。

这些问题把常见的搜索意图转成可复查动作:先确认对象、字段和证据,再判断能不能放量。

问题

Shopify collection 会自动变成 Meta product set 吗?

先判断什么

不一定。先看店铺地区、Facebook/Instagram channel 可用商品、Commerce Manager collection 和产品集规则。

执行动作

站内集合页负责买家导航,Meta product set 负责广告读取;用同一标签、custom label 或目录规则对齐,不要把两者当成同一个对象。

Pixel / CAPI 有 content_ids,为什么动态广告召回很少?

先判断什么

先查事件发的是 SKU、variant ID、catalog item id 还是 item_group_id,以及目录读取的层级是否一致。

执行动作

抽 5 个 SKU 对照 ViewContent、AddToCart、Purchase、Catalog item 和 item_group_id;ID 层级没统一前,不要先重建产品集。

Advantage+ / 动态广告产品集应该选热卖还是高毛利?

先判断什么

先看业务用途。热卖不等于高利润,高毛利也不等于库存能承接放量。

执行动作

用 margin_tier、库存天数、退款率、Purchase value 和 Shopify 净订单定义产品集;不要只按 ROAS 或 bestseller 标签放量。

能不能手动选商品建一个临时产品集先跑?

先判断什么

可以小范围验证,但不能成为长期规则。没有归档时间、排除项和同步证据时,活动结束后很容易继续污染商品池。

执行动作

即使临时跑,也要写清业务用途、覆盖数、排除项、活动结束时间、负责团队和 24 小时复查动作。

17 复制笔记总结

把目录映射规则变成复制笔记总结。

复制出去的是目录、产品集、集合页/集合规则、事件、广告目标、当前压力和验收截图,不是一句产品集已建好。

Meta Catalog 产品集复制笔记总结

把可回读的证据和下一步留在笔记里。至少写清 Catalog / market、产品集纳入与排除、样本 content_ids 和 Test Events 的当前读回。这份笔记是可复查记录,不是已经发布、同步或放量的证明。“产品集已建好”不是可交接的结论;记录缺一项,就保持 Hold 并补当前界面证据。

复制前验收

  • 证据能被复查,不只是标记为已确认。
  • 负责团队或负责人清楚,不是让大家一起看。
  • 下一步动作有时间、对象和验收指标。
  • 如果判断错了,已经写出最可能的反证信号。
  • 复核周期写清楚:活动前查覆盖,活动后 24 小时查事件和目录匹配。

当前压力场景:Advantage+ 销售活动今天要上

笔记行:ASC 上线前先锁产品集覆盖、排除项、库存和归档时间;证据不齐,不放量。

产品集用途

先写动态广告再营销、节日礼品、高毛利放量或清仓排除,不要只写产品集名称。

身份链路

Catalog item id、item_group_id 和 Pixel/CAPI content_ids 要能在 5 个 SKU 抽样里对上。

边界证据

覆盖数、排除规则、库存深度、地区同步、毛利层级和活动归档时间必须可截图复查。

当前判断

明确写继续、暂停、修事件映射、修集合规则或排除低毛利 SKU,不能只写待观察。

下一步动作

写清本周只改一个对象:产品集规则、Shopify 标签、Catalog 字段、Pixel/CAPI content_ids 或广告组引用。

负责人和复查指标

写清负责人、复查时间和指标,例如覆盖数、事件匹配率、缺货排除、margin_tier 覆盖或 24 小时 Purchase content_ids 抽样。

禁止动作

不要用改名、手工排除几个 SKU 或扩大预算来掩盖 ID、库存、集合页和利润边界问题。

下一步:进入 SEO、搜索与集合页数据角色

课程 FAQ

本课只保留这一组常见问题

Shopify collection 会自动同步成 Meta product set 吗?

不会自动变成同一个规则。Shopify 集合页主要服务买家导航,Meta 产品集主要服务广告读取、事件匹配和预算放量。它们可以读相似商品,但集合页规则和产品集规则要分别验收;用规则对照表拆开看,而不是把集合页名字直接当成广告产品集边界。

Shopify 集合页规则可以直接当成 Meta 产品集规则吗?

不建议直接照搬。集合页可以为了用户选择放入礼品、场景或新品,Meta product set 则要考虑 catalog item id、content_ids、库存、毛利、地区同步和排除规则。先问这组商品是给用户逛,还是给广告系统学习和放量。

Pixel / CAPI 有 content_ids,为什么动态广告还是召回很少?

有 content_ids 不等于匹配正确。要抽样检查 Shopify variant ID、catalog item id、item_group_id、Pixel/CAPI content_ids 和事件里的商品是否指向同一件商品。如果事件 ID 和 Catalog 商品身份对不上,动态广告会看起来有信号,但实际召回很少。

Advantage+ 或动态广告产品集应该用热卖商品还是高毛利商品?

不能只看热卖。热卖商品可能库存薄、毛利低、退货高;高毛利商品也可能样本少。先用商品池边界练习检查 ID、库存、地区同步和毛利边界,再决定核心产品集、测试产品集、排除产品集或高毛利放量池。

能不能手动选商品建一个临时产品集先跑?

可以小范围测试,但要写清为什么临时、哪些 SKU、对应 content_ids、预算边界、结束时间和负责团队。临时产品集最危险的地方是跑完没人回收,最后和 Shopify 集合页、Meta 产品集规则、库存和毛利分层全部分叉。

清仓商品要不要放进主产品集?

通常不要默认放进主放量池。清仓商品要看库存深度、售后风险、毛利、地区可售和页面承诺;如果只是为了清库存,可以建单独 clearance / exclusion 规则,避免系统把低毛利或售后风险 SKU 当成主力学习样本。

Meta Catalog 和 Shopify 商品数据不同步时先查哪里?

先查 Catalog item 预览、Shopify 源字段、Feed / channel 同步时间、content_ids、item_group_id 和产品集规则。不要先改广告结构;如果 Catalog 商品身份或规则边界错了,广告层再怎么优化也可能在推错商品。

Catalog Rule Comparator 主要解决什么问题?

它解决的是“网站给人看的集合”和“广告系统读取的产品集”被混成一件事。节日礼品、高毛利放量、清仓排除三类场景,分别要写 Shopify 集合页规则、Meta 产品集规则、事件 content_ids 要求、排除规则和写回治理表。这个规则对照只负责商品池事实,广告结构和预算节奏要去 Meta Ads 放量课里判断。

学完这一课后,复制笔记总结应该写什么?

写当前规则对照场景、Shopify 集合页规则、Meta 产品集规则、事件 content_ids 要求、排除规则、负责团队、复查时间和下一步动作。不要只写“产品集已建好”。

本课 HowTo 步骤

按本课步骤完成

  1. 1

    用规则对照表拆开集合页和产品集

    先选一个场景:节日礼品、高毛利放量或清仓排除。分别写 Shopify 集合页规则、Meta 产品集规则、事件 content_ids 要求、排除规则和写回治理表。先判断这是给买家导航,还是给广告系统读取和放量。

  2. 2

    抽样核对目录身份和事件身份

    用事件匹配检查抽 5 个 SKU,核对 Shopify variant ID、catalog item id、item_group_id、Pixel/CAPI content_ids 和事件里的商品是否指向同一件商品。身份错配时,先修商品数据或事件映射,不要先改广告结构。

  3. 3

    运行商品池边界练习

    运行商品池边界练习:检查 ID、库存、地区同步和毛利边界。重点看低库存放量、地区同步漂移、高毛利池污染和错误商品进入产品集;缺证据时先缩小产品集或设置排除规则。

  4. 4

    按目录规模调整抽样

    小目录检查产品集内所有商品;中等目录抽主推 SKU、边界 SKU、库存/促销/高毛利样本;大目录按产品集规则、市场、库存深度、margin_tier 和事件量分层抽样。5 个 SKU 只是教学样本,不是通用门槛。

  5. 5

    复制产品集治理笔记

    最后写回复制笔记总结:当前规则对照场景、Shopify 集合页规则、Meta 产品集规则、事件 content_ids 要求、排除规则、负责团队、复查时间和下一步动作。不要只写“产品集已建好”。

返回课程目录
8
查看所有教程

把这节课发给一起复盘的人

建议连同本课的复制笔记一起分享,让对方看到同一组数据、判断线和下一步动作。