商品 Feed QA 日志：每次发布要记什么

商品 Feed QA 日志每次发布要记什么？

商品 Feed QA 日志应把一次发布与当时的来源快照、受影响销售项、实际提交数据、页面检查、渠道观察和最终决策连起来。每条记录写清谁准备、谁复核、何时观察、还有什么没有确认。发现错误后保留旧记录，再追加修正。这样下一位接手的人能找到当时检查的版本，而不用依靠编辑者回忆。

本文只讨论一次发布留下的证据记录。标题、标识、价格和可售状态具体怎么检查，可以继续阅读已有的商品 Feed 基础质量检查。那篇文章负责字段检查，本篇负责把检查对象、实际差异和放行依据保存下来，方便以后复查。

下面的字段是一份工作记录建议，并非 Google 或 GS1 规定的官方模板。团队可以按现有系统调整。日志不能保证渠道接受，也不能证明排名或销量。提交成功、渠道处理后的商品值、稍后打开的商品页，各自代表不同的观察，不能用一个“通过”把它们合并。

先确定一个下次编辑后仍能找到的发布编号

开始复核前，为这次变更分配内部发布编号，并关联店铺、目标渠道账户、数据来源、市场、语言和币种。用一句话写明目的，例如修正指定变体的已批准价格映射。内部编号用于查记录，不应因此修改提交给渠道的商品编号、库存单位或全球贸易项目代码。

把计划日期与实际准备、提交、观察时间分开。排期说明原本打算哪天做事，无法证明商品资料何时修改，也无法证明渠道何时处理。时间戳应带时区，或者统一使用协调世界时。渠道显示的问题时间与操作员读取时间都能拿到时，两者分别保存，避免跨地区同事把不同时间误认成同一次处理。

基线也必须指向具体版本。“与昨天比较”在一天导出多次时很难追查。记录上一个已复核快照和当前候选快照的位置。如果复核后又改了候选数据，就建立新修订，并重新检查受影响部分。发布编号可以延续，旧批准不能在没有说明的情况下跟着新数据一起延续。

普通表格就能承载这些信息。一行汇总本次发布，再通过链接查看销售项证据和多次观察。不要把所有截图塞进汇总单元格，让决定和待办藏在长串附件里。汇总负责让人迅速看懂目前能否继续，附件负责让人追查具体值；先把这个分工做好，再考虑自动化。

一份能够接手的记录结构

记录部分	建议保留的内容	回答的问题
发布身份	发布编号、修订、店铺、渠道、来源、市场上下文	讨论的是哪次变更、哪个目标？
来源依据	基线与候选快照、采集时间、字段负责人	当时依据什么商品资料？
检查范围	精确销售项或变体清单、包含的改动、排除项	这次结论覆盖哪些商品？
提交数据比较	前后值、转换规则版本、无法解释的差异	渠道准备收到什么？
页面观察	准确网址、选中变体、市场、观察值和时间	顾客页面当时显示什么？
渠道观察	提交回执、处理后的销售项、诊断原文与时间	指定渠道实际报告了什么？
人员与决定	准备人、复核人、暂缓原因、恢复目标、下次观察负责人	谁负责行动，依据是什么？
结束记录	最后检查的修订、遗留问题、证据链接、复查条件	什么已完成，什么仍未确认？

状态和证据应分栏保存。“通过”需要对应具体检查、实际观察值和证据位置，否则很难复核。诊断栏空白同样含糊：可能没看到问题，也可能没检查、打不开页面或没有权限。直接填写“未检查”“无法取得”“等待处理”或“本次未观察到该问题”，下一位操作员才知道缺的是什么。

这张表不要求收集密钥、客户订单或完整账户导出。通常只需要商品与发布证据。涉及非公开商业资料时，保存有权限控制的来源引用，避免把无关账户信息复制到每一次发布记录。含凭证的网址应先去掉凭证再保存，截图也应只保留理解目标和差异所需的范围。

保存来源依据，不能只保存最终导出

给这次发布使用的商品来源留下稳定引用，例如带版本的目录导出、注明日期的供应商规格资料，或已批准的商品记录。一起保存采集时间和资料负责人。如果只放一个持续更新的在线文档链接，后来编辑可能覆盖当时复核的值。按团队正常的数据管理规则保留快照或修订引用，才能重现批准依据。

商业资料、系统字段和提交结果应分别记录。供应商资料解释标识属于哪个贸易项目；店铺变体字段反映系统当前存了什么；输出数据说明映射实际向外传了什么。发布改变这些关系时，就保留各处观察。最终字符串相同，并不能说明它来自可靠商品证据，也可能只是从另一行复制过来。

GS1 的 GTIN 标准说明用于校准贸易项目标识的含义。日志还需要对应的具体商品资料。查找已有号码时，可以参考 Google Merchant Center 的查找 GTIN 说明。内部发布编号或表格公式，都不能证明某个号码属于正在销售的商品。

如果供应商在复核后发来修正，追加这份新证据，并指出哪些销售项和决定需要重查。不要覆盖原文件后留下原来的批准状态。记录应能解释：原决定依据哪个版本，后来的修正又依据哪个版本。涉及长期字段归属与责任分工时，再进入商品数据责任教程，不用把整套治理方法复制进这张日志。

这张共享商品数据图说明日志需要区分哪些表面，不代表某次发布的实际结果。为已经检查的表面添加证据引用，未观察的部分明确留待核实，不要因为图上画出了连接就认为数据已经一致。

把变化记录到变体与销售项

使用能定位具体商品的内部产品编号、变体编号，并把渠道销售项编号单独列出。父商品标题在多个尺寸或包装之间可能完全相同，仅靠标题难以发现错配。除编号外，也写出选项和包装配置，便于复核人直接辨认当前记录对应单件、组合装还是另一个规格。

标识变更保留原值、拟用值、来源和修改理由。证据副本应保留前导零与原始字符串形式。如果字段有意留空，写明依据以及谁核对了商品资料。不要为了让表格看起来完整就生成一个号码填进去。团队混淆商品身份与机械格式时，先看GTIN 标识什么，再决定这次日志缺的是哪一种证据。

价格要把金额和币种一起记录，同时注明市场与选中变体。存在促销或其他价格条件时，写明相关条件及其批准来源。单独一个金额无法支持可靠比较。复核人应能看出差异来自已批准调整、意外映射，还是价格负责人尚未作出的决定，而不是看到两个数字不同就随手改成相同。

可售状态记录来源值和观察到的销售项值，不要缩成“库存已检查”。库存可能在复核期间发生变化，观察时间不可省略。如果后续库存流水解释了差异，追加这次观察与来源。保留先前快照，让不同时间的真实状态各自存在；不能为了让两栏看起来一致，就改写已经记录的历史值。

必要时也记录预期不变的字段。例如只改价格时，标识和变体映射应保持原样。如果实际提交数据出现标识变化，这就超出了原范围，需要解释。这样日志不仅罗列编辑意图，还能发现意外输出。来源导出比批准范围更大时，把排除的变体列清楚，避免把整份导出误当成整份已获批准的目录。

保存复核时看到的提交数据差异

按字段比较基线输出与候选输出，保留原文件或稳定的产物引用，并附一份可读摘要。摘要区分新增、移除、改值和意外差异。变更行数可以帮助快速理解规模，却不能替代受影响销售项清单；哪怕只改一行，也可能改到了错误变体。

输出受映射或转换规则影响时，记录规则版本。例如规则决定备用标识怎么填、可售状态怎么转换，单看来源快照就无法解释提交结果。日志应保留规则引用，以及复核人实际检查过的前后示例。这里不规定如何开发映射程序，只要求留下足够信息，让后来的人看懂规则对输出造成了什么影响。

原始差异与工具整理后的比较也要分清。有的工具会排序或统一空格以便阅读，记录它整理了什么，同时保留原始证据。不能让整理过程吞掉有意义的标识字符串，也不能把字段遗漏藏起来。遇到无法解释的差异，将对应行标为未解决，并指定谁在发布前调查。

提交后，把回执与实际复核的产物关联起来。如果系统动态生成输出，无法取得真实传输内容，就明确写出这个限制。本地候选文件不能证明定时任务稍后发出的就是同一份数据。保存能够取得的最直接证据，例如已传输内容或集成记录，并注明来源到提交这一段还有哪里没有被证实。

页面检查与 Feed 检查分开留证

每个已检查销售项都记录准确落地页、选中变体、市场、语言和币种，以及影响显示的会话条件。保存可见价格、可售状态和观察时间。截图可以辅助说明，但日志仍需网址和上下文。只截出一个金额，没有变体与币种，无法确定当时看到的是哪个销售项。

如果此次复核包含页面结构化数据，就另存一条观察。可见文案、页面标记、提交的 Feed 和渠道处理后的数据来自不同表面。团队把它们当成同一件事时，可以先读商品 Schema 与商品 Feed 的区别。日志应保留各处的一致或分歧，不能让一个表面的通过代替全部检查。

样本范围与选择理由都要写清。小批次可能逐个检查全部改动，大批次可能挑选覆盖不同映射规则的销售项。这是具体复核选择，不存在本文规定的通用抽样比例。记录检查数量、候选总范围，以及没有覆盖的变更分支。只检查一个简单变体后写“样本全部通过”，很容易让接手人高估覆盖程度。

页面重定向或默认选中了其他变体时，保留请求地址和实际观察结果。访问失败就记录失败，不能无说明地换用旧截图。最终措辞应限定为某些销售项在某些时间的一致情况。如果没有检查完整购物过程，就不要暗示购物全程正确；当时一致也不能保证未来库存继续一致。

把诊断信息写成有时间的观察

保存问题原文、受影响销售项、账户或数据源上下文，以及渠道提供的问题时间；再记录操作员读取时间。这两个时间可能不同。发布之后仍显示的警告，可能来自较早处理周期。时间顺序有助于调查，但仅凭先后关系，不能认定最新编辑导致了警告。

将“收到提交”“等待处理”“观察到处理后数值”“观察到问题状态”分别记录。不要用单一“渠道通过”概括所有阶段。渠道只暴露部分信息时，就只记录实际可见部分。没有处理时间就注明未取得，不能自己推算；收到队列回执也不能代表当前销售项已与复核数据一致。

问题消失时追加新观察，保留旧观察，并再次写明检查的销售项和上下文。账户总问题数下降，不能证明本次修改的那个变体已解决；总数不变，也可能同时存在一个旧问题消失和一个新问题出现。发布决定需要具体商品证据，宽泛的仪表盘数字只能辅助定位。

指定下一次观察的负责人和触发条件，例如渠道显示处理完成，或进入团队约定的下一次运营复核。不要承诺所有渠道统一多久处理完。观察暴露出跨系统分歧时，继续阅读商品 Feed 排错教程。日志负责让排查能接着证据往下走，不负责把尚未发生的处理结果补齐。

暂缓与恢复决定要让接手人看得懂

每个决定写明范围、原因、负责人和证据引用。“这些变体的标识改动暂缓，等待供应商确认”给出了可执行边界；只写“阻塞”没有说明谁该做什么。候选数据尚未提交时的暂缓，与已提交数据的移除、修正或恢复，是不同动作，应分别记录目标和依据。

把某个版本称为可恢复版本之前，先指定其准确来源或输出修订，以及准备恢复的字段，再核对这些旧值现在是否仍正确。旧价格或旧可售状态可能已经过时。修正当前来源有时比整体恢复更合适。日志应解释为什么选择某种处理，不能把恢复描述成无需重新判断的一键撤销。

执行恢复或修正发布时，建立独立修订并追加观察。记录执行人、改动内容，以及执行后从受影响表面读到了什么。保留与先前失败或暂缓发布的关联。命令成功返回无法单独结束这条记录，复核人还需要知道目标表面现在实际呈现的值。

小团队可能由同一个人准备和复核，如实填写即可，并把准备时间与之后检查证据的时间分开。不要虚构独立批准。确有另一位复核人时，请其检查具体受影响值和决定依据，而不只是确认附件存在。人员字段只有对应真实责任才有用，签名数量本身不会提高商品证据质量。

示例：价格发布中出现组合装映射变化

以下是假设情境，用来说明记录写法，不代表 Ecomwith 客户经历或真实发布结果。某店铺准备调整单件与组合装的价格，批准范围只包含价格，标识和包装映射应保持不变。复核人比较候选输出与保留基线时，发现组合装现在引用了单件的标识映射。

示例条目	操作员如何记录
发布与基线	内部发布编号、候选修订、上次复核导出的准确引用
原定范围	指定单件和组合装变体的价格调整
意外差异	组合装标识映射变化，超出仅改价格的范围
证据	来源快照、两条受影响记录、提交数据差异、选中变体的页面观察
决定	暂缓候选版本，请商品数据负责人依据商品资料确认映射
下一步	生成修正后的修订，提交前重新比较受影响部分

这条记录没有声称 Merchant Center 拒绝了商品，因为候选版本在提交前已经暂缓。它也没有通过格式检查推断任何号码归属，更没有计算营收影响。证据只支持一个具体发现：候选数据改变了批准范围之外的映射，因此复核尚未完成。

假设负责人后来补充了正确的映射依据，就追加证据，建立新的候选修订，再记录新的比较。如果所检变体的页面与输出一致，应说明这个有限结果。后续真的提交后，再补渠道观察。本例提供的是应该收集的证据顺序，不虚构后来获批或经营改善的结局。

这个情境也说明为什么需要基线。没有旧版本，操作员可能只看到一个形式正常的标识，忽略它是在价格更新中意外改变的。日志把原定范围、实际差异和处理决定连接起来，普通表格就能做到；复杂仪表盘无法替代这三者之间的清楚关系。

结束记录前的检查表

• 发布编号能定位店铺、来源、渠道和市场上下文。
• 决定对应的产物就是实际复核的修订。
• 来源与基线引用能够还原当时看到的值。
• 变体、标识、价格及可售状态改动都有证据可查。
• 意外输出差异已经解释，或明确处于暂缓状态。
• 页面检查包含网址、选中变体、时间和样本覆盖范围。
• 渠道回执、处理、数值和诊断观察分别记录。
• 准备人、复核人、后续负责人及独立复核限制如实填写。
• 暂缓、修正或恢复决定都写明受影响范围和依据。
• 结束说明列出了遗留问题，以及什么变化会触发重查。

把自己当成明天接手的人再读一次结束说明：不翻聊天记录，能否找到准确候选版本、知道哪些商品不在范围内、看懂下一步由谁做？不能的话，优先改清引用和决定措辞。增加截图数量无法修复目标含糊的问题。汇总应足够短，让人看见决定；底层证据仍应能够打开查看。

日志能证明什么，还有什么不能证明

底层证据保留完整时，日志可以支持这样的陈述：指定人员检查了指定产物，并在记录时间观察到指定数值。它也能说明某次决定依据哪个差异，以及后来修正是否重新经过复核。这些是有用的运营事实，但范围小于整个目录全部正确，也小于所有下游系统都已使用同一个修订。

Ecomwith GTIN 工具可以为开发和质量检查留下结构或校验位结果。生成的测试值不会分配商业 GTIN，不证明 GS1 或品牌归属，也不保证渠道接受。日志应把机械校验、商品分配证据和渠道观察分成独立条目。某一条通过，不能顺手把另外两条也填成通过。

日志本身也不能证明搜索收录、排名、广告表现或营收变化，这些需要单独测量及其上下文。需要商品身份背景时，阅读已有的 Shopify GTIN、UPC 与 EAN 文章。如果问题转向其他商品数据场景，可以通过 GTIN 与商品数据主题路径继续选择文章，本篇无需扩展成完整的 Feed 管理课程。

常见问题

用普通表格保存 QA 日志可以吗？

可以。保留稳定的发布编号和修订引用、清楚的状态值，以及能够还原当时资料的证据链接。汇总应便于阅读，修正到来后保留早先观察。关键在于另一位复核人能否重建准确范围和决定，而不是使用哪种软件。

上传成功就能结束这次发布吗？

不能。提交回执与处理后的数值、页面观察、诊断状态分别记录。渠道证据仍在等待或无法取得时，这部分保持未完成，并指定下一次观察负责人。仅有上传成功，不足以把整次发布标为已获接受。

日志需要包含目录里的每件商品吗？

应记录准确受影响范围，以及实际检查覆盖程度。全目录复核和抽查改动变体支持的结论不同。保留排除项与未测试的映射分支，不要让通过的样本暗示整个目录已经通过。

恢复旧版本可以沿用上次批准吗？

恢复是针对当前事实的新决定。指定准备恢复的旧修订，并确认旧值仍适用，尤其是价格和可售状态。执行与受影响表面的再次读取应另行记录。上次批准属于历史依据，不能自动批准今天的恢复。

来源与适用范围

• GS1 GTIN 标准说明：贸易项目标识和标准背景。
• Google Merchant Center：查找 GTIN：寻找已有标识的参考路径，与生成测试号码分开。
• 文中链接的 Ecomwith 答案、工具和教程用于区分字段检查、来源责任与排错工作。日志字段、示例、检查表及决定措辞是本文的编辑建议，不是平台官方批准程序。