Merchant 商品数据源规则更新后字段消失？核对 self 与补充源顺序

最容易误解的是取值方法：它按每个属性依次找来源，前一个源有值，就用那个值；没有，才看后一个源。主源与补充源都提供价格时，顺序就会改变最终价格。

先看是谁提供价格

主源通常提供商品的基础资料，补充源用来增加或调整某些属性。下面是教学例子：主源P给商品A17标题和价格，补充源S原来只加标签。不要先改顺序，先把同一商品在两个来源里的值放在一起。

来源	价格	标签
主源P	120 USD	未提供
补充源S，原配置	未提供	autumn
补充源S，新增价格后	96 USD	autumn

如果S只有标签，P在前还是S在前，通常都从P取得120美元，而标签来自S。若S后来也提供96美元，事情就不同：P在前，价格先取120；S在前，价格先取96。

所以，“补充源排前面”不意味着所有字段都被换掉。要看它到底提供哪些属性。官方数据源指南说明了这种逐属性取值与回退的顺序；真实商品还要检查自定义规则及处理结果。

为什么漏掉self会出问题

在规则里，self就是“这个主源自己”。想让商品先从主源取值，再用补充源填缺项，完整列表应保留self和需要的补充源，而不是只写这次新增的一项。

更新默认规则相当于交一份新清单，原清单不会自动留在后面。Google特别提醒，创建或更新会替换整套默认规则；漏掉主源引用，不能指望原有标题和价格仍按原方式参与。

2026年7月13日当周的新验证要求默认规则恰有一个self或一个主源引用；7月6日当周已把primaryDataSourceName标为弃用，建议改用self。新请求按这个要求检查，不要复制较旧参考里的宽松描述。

这部分交给接口维护者做。他先保存旧的完整takeFromDataSources列表，核对当前主源与补充源ID，再准备patch；updateMask应对应要改的默认规则。一个引用也不能混填不同来源字段，具体格式查资源参考。

只是使用平台插件、没有自己管理这类规则的商家，不必为这条更新主动加self。高级多客户账号的补充源与规则当前也不能通过该API管理，要在Merchant Center界面处理。

请求错误与商品变化，分别查

请求被拒，说明新配置尚未被接受。先读实际错误，检查主源引用数量、字段和完整列表；不要先去改商品价格。修正后，读回规则，确认需要的来源没有丢。

请求成功但价格变了，回到A17：先读回主源规则，看S是否已排在self之前，再查看S有没有96美元。读回列表对应维护者的dataSources.get；核最终商品对应products.get。

最终Product已结合规则和补充源处理，写入后可能需要几分钟。若列表正确但商品仍是旧值，等待处理后再核输入及问题提示。搜索结果中的旧价格，不适合用来判断刚才哪条来源规则生效。

一件商品查清，再扩到全店

用同一个A17检查标题、价格和标签。想保留120美元却得到了96，就判断是顺序让S优先，还是S本不该提供价格；修法可能是恢复顺序，也可能是清理S中的错误字段。两种操作针对不同原因。

修完保存完整规则与同一商品的处理结果，确保能说清每个值来自哪里。再扩大到其他商品。价格正确、运费或退货仍不同，则接着查商品与结账政策。跨运营和开发难以定位时，可向跨境YOUNG提供脱敏后的来源顺序及一件商品的字段差异。