Product Feed QA Log: What to Record Each Release

What should a product feed QA log record?

A product feed QA log should connect each release to its exact source snapshot, changed offers, submitted payload, page checks, destination observations, and release decision. Record who prepared the change, who reviewed the evidence, when each observation was made, and what remains unresolved. Keep the earlier record when you correct a mistake. A useful log lets another operator establish what was checked without asking the original editor to reconstruct the release from memory.

This article covers the evidence record for one release. For the actual field checks, use the existing product feed QA checklist. That article owns the broad title, identifier, price, and availability review. Here the question is narrower: what must be retained so that a later reviewer can connect a decision to the product data that supported it?

The structure below is an editorial recommendation for a working log, not a mandatory Google or GS1 template. Adapt the fields to your integration and access controls. No record format can guarantee channel acceptance, ranking, or sales. A successful submission establishes a different fact from a processed offer, and a processed offer establishes a different fact from an accurate storefront at a later time.

Start with a release identity that survives the next edit

Give the release a stable internal reference before the first review. Link that reference to the store, destination account, data source, market, language, and currency under review. Record the purpose in one sentence, such as correcting an approved price mapping for selected variants. The identifier is an internal record key; it is not a reason to change product IDs, SKUs, or GTINs in the destination payload.

Separate a planned release date from actual preparation, submission, and observation times. A calendar slot tells people when work was intended. It does not establish when a source changed or a channel processed it. Use timestamps with an explicit timezone, or a consistent UTC convention, so people in different locations can compare the sequence without guessing. Keep the original destination timestamp alongside your retrieval time when both are available.

Also name the baseline. “Compared with yesterday” becomes ambiguous when yesterday contained several exports. Reference the specific previously reviewed snapshot and the candidate snapshot. If a later edit changes the candidate, create a new revision and reopen the affected checks. Carrying the release name forward is fine; silently carrying its old approval onto a different payload is not.

A spreadsheet can hold this structure. One row can summarize a release, with linked evidence for individual offers and observations. Avoid putting every screenshot into the summary cell. The summary should make the current decision visible, while the linked evidence allows someone to inspect the values and the comparison behind it. Choose a record system the team can maintain consistently before adding more automation.

A practical record layout

Record group	Minimum useful content	Question it answers
Release identity	Release reference, revision, store, destination, source, market context	Which change and target are we discussing?
Source evidence	Baseline and candidate snapshot references, capture times, field owners	What approved data did the change start from?
Scope	Exact offer or variant list, included changes, exclusions	Which products does the review cover?
Payload comparison	Before and after values, transformation version, unexplained differences	What would the destination actually receive?
Page checks	Exact URL, selected variant, market context, observed values, time	What did a shopper-facing page show?
Destination observations	Submission reference, processed offer, diagnostic text and timestamps	What did the named channel report?
People and decision	Preparer, reviewer, hold reason, rollback target, next observation owner	Who can act, and on what evidence?
Closure	Final checked revision, remaining issues, evidence links, follow-up condition	What is complete, and what is still open?

Keep status and evidence in separate fields. A green cell reading “passed” is difficult to audit unless it names the check, observed value, and evidence location. An empty diagnostic cell is equally ambiguous: it might mean no issue was observed, the channel was not checked, or access failed. Use explicit values such as not checked, unavailable, pending processing, or observed without the named issue.

Do not turn this table into a requirement to collect secrets. A feed log usually needs product and release evidence, not customer orders, access tokens, or a complete account export. Use access-controlled references when the source material contains private commercial information. Remove credentials from URLs before saving them. Keep enough context to find the intended evidence without copying unrelated account data into every release.

Preserve the source, not only the final export

Save a stable reference to the product source used for the release. That could be a versioned catalog export, a dated supplier specification, or an approved product record. Include the capture time and the responsible owner. A live document link alone can lose the value that the reviewer actually saw when someone edits it later. Retain a snapshot or revision reference where your normal data policy permits it.

Distinguish the commercial source from the system field. A supplier record may explain which trade item an identifier belongs to; the Shopify variant field shows what the store currently holds; the output payload shows what a mapping sent onward. These are different observations. Record each one when the release changes that relationship. A matching final string cannot reveal whether it came from verified product evidence or an accidental copy.

GS1 describes GTINs as identifiers for trade items. Use its GTIN standard overview for that terminology, and keep the relevant product evidence with the release. For an existing identifier, Google's Find a GTIN guidance provides a source route. Neither a release reference nor a spreadsheet formula establishes that a number belongs to the item being sold.

If a supplier sends a correction after review, attach it as new evidence. Note which offer rows and decisions it invalidates. Do not replace the earlier file and leave its old approval unchanged. The record should let a reviewer see that the original decision was based on one source revision and the corrected decision on another. For the broader responsibility model, continue to product-data ownership.

This shared product-data diagram shows the surfaces the log must distinguish. It is not a picture of a particular release or a channel acceptance result. Add evidence references for the surfaces actually inspected; leave unobserved surfaces explicitly open.

Record changes at the variant and offer level

Use the internal product and variant references that let the team locate the precise item. Add the destination offer reference separately. A parent product title may be identical across several sizes or packs, so title alone is weak evidence. Record the selected options and relevant pack configuration in readable text as well as IDs. That gives the reviewer a practical way to notice a mismatched variant.

For identifiers, retain the previous value, proposed value, evidence source, and reason for change. Preserve leading zeros and the original string representation in the evidence copy. If the field is intentionally absent, explain why and identify who confirmed the product evidence. Do not fill an empty identifier cell with a generated number just to make a release look complete. The GTIN answer helps separate identity questions from mechanical validation.

For prices, retain amount and currency together. Include the market and selected variant used for the comparison. Record whether a promotion or other price condition is relevant, and cite the approved source of that condition. A number without its currency or offer context cannot support a useful comparison. A reviewer should be able to tell whether a difference is expected, accidental, or still awaiting a pricing decision.

For availability, write the source value and the observed offer value rather than compressing everything into “inventory checked.” Record the observation time because stock can change during review. If a later stock movement explains a difference, append that observation with its source. Do not rewrite the earlier snapshot to make two legitimately different times appear identical. The decision should use the latest relevant evidence while preserving the historical sequence.

Include expected non-changes where they matter. A price-only release might explicitly expect identifiers and variant mappings to remain stable. If the payload comparison shows an identifier change anyway, that is an unexplained difference requiring review. The log then helps enforce scope instead of merely listing intended edits. Record excluded variants too, particularly when the source export contains a broader catalog than the approved release.

Save the payload diff that was actually reviewed

Compare the baseline output with the candidate output at the field level. Retain the original files or stable artifact references alongside a readable summary. The summary should identify additions, removals, changed values, and unexpected differences. A count of changed rows helps orientation but does not replace the actual affected-offer list. A one-row change can still affect the wrong variant.

Record the mapping or transformation revision when it influences the output. If a rule populates a fallback identifier or converts availability labels, a source snapshot alone cannot explain the submitted result. Keep the rule reference and the specific before-and-after example that the reviewer inspected. This article does not prescribe a mapping implementation; it asks the log to preserve enough context to trace its visible effect.

Distinguish raw differences from normalized comparisons. A tool may sort rows or standardize whitespace for readability. Say what it normalized and keep the raw evidence available. Do not let normalization erase a meaningful identifier string or hide an omitted field. When the reviewer cannot explain a difference, mark that row unresolved and name the person responsible for investigating it before release.

After submission, connect the submission reference to the exact reviewed artifact. If the integration generates output dynamically and the actual transmitted content cannot be retrieved, record that limit. A candidate file on a laptop does not prove what a scheduled integration later sent. Use the strongest available evidence, such as a retained transmitted payload or an integration observation, and state precisely which part of the chain remains unverified.

Keep page and feed observations separate

For each checked offer, retain the exact landing-page URL and selected variant. Add the market, language, currency, and any relevant session context that influenced the display. Record the visible price and availability with the observation time. A screenshot can help, but it needs the URL and context in the log. A cropped price without a variant or currency cannot establish which offer was observed.

Record page structured data separately when it is part of the review. Visible copy, page markup, the submitted feed, and processed channel data may be observed through different surfaces. Read product schema versus product feed if the team currently treats them as interchangeable. The release log should retain their agreement or disagreement rather than letting one passing surface stand in for all the others.

State the sample and its selection reason. A reviewer might inspect every changed offer in a small release, or select examples covering distinct mapping rules in a larger one. This is a review choice, not a universal sample-size rule. Write the number checked and the eligible set, then identify any changed branches not covered. “All samples passed” says little when the sample contains only one easy variant.

If a page redirects or selects a different variant, preserve the requested and observed destination details. If access fails, record the failure rather than substituting a cached screenshot without disclosure. The log should support a bounded statement such as “these offers agreed at these times.” It should not imply a complete shopper journey or future inventory consistency when those checks were outside the review.

Capture diagnostics as dated observations

Save the exact issue wording, affected offer reference, account or source context, and the time the channel associates with the issue when available. Also record when the operator retrieved it. Those times can differ. A warning visible after a release may describe an earlier processing cycle. The sequence is useful evidence, but timing alone does not prove that the latest edit caused the warning.

Keep submission received, processing pending, processed value observed, and issue status observed as separate events. Avoid a single “channel passed” status that collapses all of them. If the destination exposes only some of those observations, record what it exposes. Do not invent a processing timestamp or assume a queue receipt means the current offer matches the reviewed data. Missing evidence should remain visible to the next operator.

When an issue disappears, append the new observation and retain the previous one. Name the offer and context inspected again. A reduced account-wide issue count cannot establish that the particular edited variant is resolved. Likewise, an unchanged count can conceal one resolved item and a different new problem. Item-level evidence is more useful for a release decision than a broad dashboard number alone.

Choose a follow-up owner and a trigger for the next observation. It might be the destination reporting completion or the next agreed operating review. Do not promise a universal processing delay. The feed-debugging lesson is the next route when the observations expose a cross-system disagreement. The log's job is to preserve the evidence that makes that investigation possible.

Make holds and rollback decisions readable

Record a decision with its scope, reason, owner, and evidence references. “Hold identifier changes for these variants pending supplier confirmation” gives the next person a concrete boundary. “Blocked” without a reason does not. Separate a hold on an unsubmitted candidate from a decision to remove, correct, or restore already submitted data. Those actions have different effects and require their own target checks.

Before calling something a rollback option, identify the exact earlier source or output revision and the affected fields. Ask whether those values are still correct. Restoring an old price or availability snapshot may reintroduce information that is no longer true. A correction to the current source can be more appropriate than a wholesale restoration. The log should record that choice and its rationale without presenting rollback as an automatic undo button.

If a rollback or corrective release is carried out, give it its own revision and observations. Record who executed it, what changed, and what was read back afterward. Keep the failed or held release linked in the history. A successful command response does not close the record by itself; the reviewer needs evidence from the affected surface to establish which values are now present.

For a small team, the preparer and reviewer may be the same person. State that honestly, and separate preparation time from the later evidence review. Do not invent independent approval. Where an independent reviewer is available, ask them to inspect the affected values and decision basis, not merely acknowledge that a file exists. The identity field is useful only when it reflects actual responsibility.

Worked example: a price release with a pack mismatch

The following is a fictional example showing how to write a record; it is not an Ecomwith customer result. A store prepares a price update for a single item and a multipack. The approved scope changes prices while keeping identifiers and pack mappings unchanged. The reviewer compares the candidate payload with the retained baseline and notices that the multipack now carries the single item's identifier reference.

Example entry	What the operator records
Release and baseline	Internal release reference, candidate revision, exact prior reviewed export
Intended scope	Price changes for the named single-item and multipack variants
Unexpected difference	Multipack identifier mapping changed despite the price-only scope
Evidence	Source snapshot, two affected rows, payload diff, selected-variant page observations
Decision	Hold the candidate; product-data owner to confirm mapping against product evidence
Next step	Produce a corrected revision and repeat affected comparisons before any submission

Notice what the record does not say. It does not claim that Merchant Center rejected the item, because the candidate was held before submission. It does not claim ownership of either identifier from a format check. It does not assign a revenue impact. The evidence supports a specific finding: the candidate changed a mapping outside the approved scope, so its review remained incomplete.

Suppose the owner subsequently supplies the correct mapping evidence. Append it, create a new candidate revision, and record a fresh comparison. If the page and payload agree for the checked variants, describe that bounded result. After any later submission, add the destination observations separately. The example ends with the evidence sequence to collect; it does not invent a later approval or successful business outcome.

This example also explains why retaining the baseline matters. Without it, an operator might see a plausible-looking current identifier and miss that it changed during a price update. The log is valuable because it joins intended scope, actual differences, and the decision taken. It does not require a complicated dashboard to make that relationship visible.

Checklist before closing a release record

• The release reference identifies the target store, source, destination, and market context.
• The reviewed revision matches the artifact named in the decision.
• Source and baseline references preserve the values inspected at review time.
• Changed variants, identifiers, prices, and availability are traceable to evidence.
• Unexpected payload differences have an explanation or an explicit hold.
• Page checks identify URLs, selected variants, observation times, and sample coverage.
• Destination events distinguish receipt, processing, values, and diagnostic observations.
• The preparer, reviewer, next owner, and any independence limit are recorded.
• Hold, correction, or rollback decisions name the affected scope and evidence.
• Closure states unresolved issues and what would require another review.

Read the closure sentence as if you were taking over the work tomorrow. Could you locate the exact candidate, see what was excluded, and identify the next action without a chat search? If not, improve the reference or decision wording. More screenshots will not fix an unclear target. Keep the summary short enough to scan while preserving the underlying evidence for inspection.

What the log proves, and what it leaves open

The log can support that named people inspected named artifacts and observed named values at recorded times, provided the underlying evidence is retained. It can show that a decision followed an identified difference and that a later correction received a new review. These are useful operational facts. They are narrower than claiming the whole catalog was correct or that every downstream system used the same revision.

The Ecomwith GTIN tool can help record a structure or check-digit result for development and QA. Its generated test values do not allocate commercial GTINs, establish GS1 or brand ownership, or guarantee channel acceptance. Keep mechanical validation, product-assignment evidence, and destination observations as separate log entries. A passing result in one entry must not silently fill the others.

The log also cannot establish search indexing, rankings, advertising performance, or revenue effects without separate measurements and their own context. For product identity background, use the existing GTIN, UPC, and EAN article. For adjacent operating questions, the GTIN and product-data topic path helps choose the next page without turning this release record into an entire feed-management course.

Frequently asked questions

Can a spreadsheet be the QA log?

Yes. Use stable release and revision references, explicit status values, and links to retained evidence. Keep the summary readable and preserve earlier observations when corrections arrive. The format matters less than whether another reviewer can reconstruct the exact scope and decision.

Does a successful upload close the release?

No. Record the submission receipt separately from processed values, page observations, and diagnostic status. If destination evidence is pending or unavailable, leave that part open and name the next observation owner. Do not label the entire release accepted on the strength of an upload alone.

Should the log contain every product in the catalog?

Record the exact affected set and the actual review coverage. A full catalog review and a sample of changed variants support different conclusions. Keep exclusions and untested mapping branches visible instead of implying that a passing sample proves the entire catalog.

Can a rollback reuse the previous approval?

Treat a rollback as a new decision against current facts. Identify the earlier revision and confirm that the values to restore remain appropriate, especially price and availability. Record execution and affected-surface readback separately; the previous approval is historical evidence, not automatic approval of today's restoration.

Sources and scope

• GS1 GTIN standard overview: trade-item identification and standards context.
• Google Merchant Center: Find a GTIN: a route for locating existing identifiers, distinct from creating test numbers.
• The linked Ecomwith product-data answers, tool, and lessons provide the project-specific distinctions between field checks, source responsibility, and diagnostic work. The log layout, example, checklist, and decision wording here are editorial recommendations, not an official platform approval process.