目录映射工作台
产品集不是广告后台里的临时筛选器。
Meta Catalog、Shopify 集合页/集合规则、产品集和 Pixel/CAPI content_ids 必须使用同一套稳定映射。否则动态广告会把错误商品稳定放大出去。
本课产出
Meta Catalog 商品集治理表
完成标准:产品集能解释商品来源、排除规则、事件匹配和业务用途。说不清这些,不扩大预算。
目录商品项 id
必须和 Pixel/CAPI content_ids 对齐。
item_group_id
把颜色、容量等变体归在同一商品组。
产品集规则
规则、排除项、业务用途和负责团队可导出复查。
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、库存或预算。
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。问题是覆盖数刚变过,没人能说清哪些颜色和套装已经被排除。
12 比如一款保温杯商品演练
节日礼品产品集要能解释集合页、广告和事件。
比如一款保温杯商品原来集合页叫 Gifts under $50,Meta 产品集叫 Gift Cups,两者并不完全一致。重构后,它们共享稳定字段和复核截图。
Shopify 集合页叫 Gifts under $50。
定义用户可见商品池和价格规则负责人。
Meta 产品集叫 Gift Cups,来源不清。
产品集读取稳定字段,并写明排除缺货颜色和套装。
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、库存、集合页和利润边界问题。