Product Feed Identifier Checks Before Submission

Before a product feed leaves your store, check the identifier chain as a release artifact. The useful question is not simply “does the Barcode field contain digits?” It is: does the exact sellable item have the right identity, does the responsible source own the value, does the mapping send that value to the intended channel field, and can another operator prove what was submitted?

The short answer is to hold a feed when any of those links is unknown. A format or check-digit tool can find mechanical errors, but it cannot allocate a commercial GTIN, prove ownership, or promise destination acceptance. A populated source field is not the same thing as a verified identifier in the submitted payload.

This is a pre-submission operating check. It is different from defining a GTIN, choosing an identifier for a channel, or diagnosing a warning already visible in Merchant Center. The goal is a bounded release decision: release, release with a documented exception, or hold.

The release decision in one table

Check	Evidence to keep	Release decision
Product and variant identity	Product ID, variant ID, SKU, size, colour, pack count, capacity	Hold if the feed item cannot be matched to one source variant
Identifier ownership	Brand, manufacturer, GS1 or internal ownership record, source-system owner	Hold if a candidate number has no responsible owner
Packaging identity	Unit, multipack, case, bundle, shipped configuration	Hold if the value belongs to another packaging level
Field mapping	Mapping version and sample input/output	Hold if the destination field is inferred rather than observed
Mechanical value check	Length, allowed structure, check digit where applicable	Hold or correct the value; passing does not prove assignment
Brand and MPN	Authoritative values and variant relationship	Hold if blank, copied from another item, or contradictory
identifier_exists	Product fact plus current channel rule	Hold if it is being used to hide unresolved data
Page/feed consistency	Variant page, structured data where relevant, feed payload	Hold if identity or key attributes disagree
Release evidence	Export timestamp, file hash or sample, reviewer, destination readback plan	Hold if the change cannot be reconstructed

1. Name the exact item before checking its identifier

Start with a stable item key, not a title. Titles are useful for a human glance but are unsafe as the only join key when several variants share a name. Record the product ID, variant ID, SKU or offer ID, and the attributes that make the item sellable. For a clothing product that may be size and colour; for a food item it may be flavour and net weight; for a supplement it may be count and strength. Keep the same key in the source export, transformed record, final payload, and release note.

Then ask whether the identifier is a product-level or variant-level fact in your catalogue model. If the customer can order two variants separately, assume you need to verify them separately until the catalogue owner documents a different relationship. Never copy the first variant’s Barcode across a product merely because the titles look similar.

A small example

Suppose a shop sells a mug in a single unit and a two-pack. The names are almost identical. The single mug has SKU MUG-BLU-1 and a source GTIN; the two-pack has SKU MUG-BLU-2 and a different packaging identity. A feed exporter that joins on product title can attach the single-unit value to the two-pack. Both strings may pass a check-digit test, yet the release is wrong because the identity relationship is wrong. The safe fix is to repair the source or mapping and retain a before/after sample, not to generate another plausible number.

2. Assign source ownership before looking at the payload

An identifier needs a source owner. The owner may be the brand, manufacturer, GS1 member organisation, or another documented catalogue authority. A merchandiser may enter a value, and an engineer may transform it, but neither action alone proves that the value was assigned to this trade item.

Write down where the value came from and who can confirm it. Useful evidence includes an approved product master record, a manufacturer catalogue, packaging artwork, or a controlled identifier register. Avoid treating a marketplace listing, a search result, or a number copied from a neighbouring SKU as authoritative. When no owner can be identified, mark the candidate as assignment_unverified and hold the affected item.

GS1 standards explain identifier scope and allocation context. A local checker is a development aid, not an allocation service. Google’s product-data guidance explains how a destination handles submitted data; it does not replace the brand owner’s record. Keep those responsibilities separate in the release log.

3. Check variant, bundle, and package identity

Packaging is part of the check. A single unit, multipack, case, bundle, or shipped configuration may be a different sellable trade item. Compare the source item with the identifier record on unit count, dimensions or quantity where relevant, product formulation, model, colour, size, and any other customer-visible differentiator. Do not assume that a parent product identifier is valid for every child offer.

For bundles, record whether the channel expects the bundle to be represented as one offer or as component products. If your feed system creates an offer for a configuration that never existed in the product master, stop and resolve the catalogue fact first. “The identifier looks valid” is not an answer to “does this identifier belong to this offer?”

4. Inspect the mapping, not only the source field

Trace one known-good item and one changed item through every transformation:

1. source product and variant record;
2. canonical field used by the exporter;
3. connector or feed rule;
4. normalized intermediate record;
5. final channel payload;
6. destination processing and diagnostic row.

Capture the mapping version, export time, and a redacted sample. Check whether the destination’s identifier field is fed from Shopify Barcode, a product master field, a PIM value, a supplemental feed, or a manual override. A field called barcode, gtin, or identifier is not enough evidence; verify the actual mapping contract.

Common release defects include reading a product-level field for a variant-level output, trimming leading zeroes, converting a long value to a number, selecting the default variant, or allowing a supplemental file to overwrite the primary value. Preserve identifiers as strings. Compare the emitted value character by character, including leading zeroes, before deciding that the mapping is correct.

5. Separate four different kinds of validation

A useful release note labels the check type explicitly:

Validation kind	What it can establish	What it cannot establish
Format	The value has the expected shape or length	That it was commercially assigned or belongs to the item
Check digit	The arithmetic check digit agrees with the preceding digits	Ownership, packaging identity, or destination acceptance
Assignment	An accountable source says the value identifies the item	That your connector emitted it correctly
Channel processing	The destination received and processed the payload	That a different country, offer, or later export will match

This distinction is why a green tool result is only one release signal. Use the Ecomwith GTIN tool for structure and check-digit QA, then retain the source and mapping evidence separately. Do not write “verified” when you mean “mechanically valid.” Prefer precise labels such as format_pass, assignment_confirmed, payload_match, and destination_pending.

6. Review identifier_exists, brand, and MPN together

An identifier decision is a set of product facts, not a single toggle. If the product genuinely has no applicable GTIN, the current channel may provide a documented no-identifier treatment. That does not permit a blank or invented brand and MPN. Confirm who owns those attributes, whether they apply to this variant, and whether the channel rule permits the declaration.

Do not set identifier_exists to false merely because the source field is empty, the assignment record is missing, or the exporter failed. Those are unresolved data or process problems. A truthful no-identifier decision is different from hiding an error. If the product is custom, private-label, or otherwise outside the expected identifier situation, record the product fact and the rule version used for the decision.

Check that brand and MPN do not silently come from a parent or neighbouring variant when they should describe the offered item. If brand or MPN changes with the product identity, the mapping must express that relationship. If a field is not applicable, record why rather than filling it with a placeholder.

7. Reconcile the product page and feed

The landing page and feed are two surfaces that must describe the same offer. Compare the exact variant, title, brand, MPN, identifier when displayed or represented, pack quantity, and destination-relevant attributes. A product page can have correct structured data while the feed is wrong; page markup does not repair a feed mapping. Conversely, a feed can contain a value while the page resolves to another variant.

Use the canonical product or variant URL that the feed actually submits. Check that the URL resolves, the selected variant is visible, and the page does not change identity because of a default selection or unavailable option. Record the page check separately from the payload check. “The page looks right” is not evidence that the channel received the same record.

8. Build a release packet

Before submission, keep a compact packet that another operator can replay:

• scope: products, variants, countries, and channels included;
• source snapshot timestamp and owner;
• mapping and connector version;
• representative before/after payload rows;
• identifier check result and tool version if used;
• brand, MPN, and identifier_exists decision;
• page URL and variant readback;
• reviewer and review time;
• release ID, export timestamp, and destination processing plan;
• known exceptions, hold reasons, and rollback or re-export path.

Do not put credentials or unnecessary customer data in the packet. A file upload receipt or connector “success” message proves transmission, not acceptance. The destination needs time to process the data, and the same item must be read back in the destination before the release is called complete.

9. Use safe hold rules

Hold the smallest affected scope when evidence is local and specific. Hold the entire release when the defect is systemic or the mapping version is unknown. Examples:

Situation	Scope	Hold reason
One variant has a blank source	One variant	Source fact is missing
Several variants receive the default value	Product family or mapping rule	Variant join is unsafe
Leading zeroes disappear across export	Whole affected feed	Serialization defect
Brand and MPN changed without owner	Affected products	Assignment and source responsibility unclear
Destination rule changed and is unreviewed	Relevant channel/country	Current processing contract unknown

Do not “fix” a broad mapping defect by hand-editing hundreds of product fields. Freeze the release, save the failing sample, identify the first broken boundary, and use the documented rollback or prior export. A hold is a decision that evidence is insufficient; it is not a claim that the destination will reject the products.

10. What to verify after submission

After the payload is submitted, read back the same item using its stable identifier. Confirm the destination received the expected value, associated it with the expected offer, and processed the current version. If a warning or disapproval appears, preserve its exact text and timestamp. Do not convert “export completed” into “accepted.”

The supplied keyword record for this article is informational with KD 20 and no available volume value (volume_not_available). It does not establish traffic, ranking, or a business result. Likewise, this checklist does not promise Merchant Center approval. It gives you a reproducible release boundary so the next diagnosis starts with evidence rather than assumptions.

Frequently asked questions

A practical reviewer walk-through

The reviewer should be able to answer five questions without opening a second undocumented system. What is the exact offer? Who owns the identifier fact? Which transformation produced the submitted value? Which page represents the offer? What evidence will prove the destination processed this same row? If the answer to any question is “someone probably knows,” the row is not ready for a clean release decision.

Start with the release scope and choose a small sample from each mapping path, product type, packaging level, and country. A single sample cannot represent a feed that has several connectors or supplemental files. For each sample, write the source key beside the final item key. If the keys are not directly joinable, the mapping itself is a release risk and needs a documented join rule.

Next compare null behavior. An empty source value, a missing output field, a literal placeholder, and a value inherited from a parent are four different states. The exporter must not silently turn one into another. Check leading zeroes and character encoding as well as ordinary digits. If a value is normalized, record the exact normalization rule and why it is allowed.

Then inspect exceptions. A no-identifier product, a multipack, and a private-label item may follow a different path, but “exception” must describe a product fact, not an operator shortcut. An exception without an owner, rule reference, and expiry or review condition should be held. This makes the next release comparable instead of allowing an old exception to become permanent hidden logic.

Finally, make the release status observable. source_checked means the source record was reviewed; mapping_checked means the exporter was traced; payload_checked means the emitted row matched; submitted means transmission occurred; destination_pending means processing is not yet proven; destination_readback means the same row was directly confirmed. Do not collapse those states into one “green” column. The sequence is the evidence.

If a reviewer finds a mismatch, preserve the original sample before editing it. Record the first boundary where the values diverge, assign the owner of that boundary, and state the smallest safe hold. A good release packet lets the team repair one boundary and rerun the same comparison. It should never require guessing what the previous export contained.

Make the release manifest explicit

For a recurring feed, create a release manifest even when the platform does not require one. The manifest is not a second catalogue. It is a short index of the exact inputs and decisions used for this submission. Give it a release identifier, source snapshot time, export time, mapping version, channel and country scope, and the reviewer. Add the number of sampled paths without turning that number into a claim about performance or acceptance.

The manifest should point to the source snapshot and the redacted payload sample, rather than copying every product into an email. It should name the identifier field, the string-preservation rule, the packaging rule, and the precedence rule when a primary and supplemental feed both contain a value. If any rule differs by channel, make the channel boundary visible. A reviewer should be able to tell whether two apparently similar exports were produced by the same contract.

Use a simple status vocabulary in the manifest. planned means the scope is defined; source_reviewed means the owner checked product facts; mapping_reviewed means the transformation was traced; payload_reviewed means sample rows match; submitted means transmission was attempted or completed; destination_pending means the destination has not yet been read back; and closed_with_readback means the same offer was directly checked. These labels describe evidence, not a forecast.

Compare payloads as records, not screenshots

A screenshot can help a human see a warning, but it is a poor comparison tool for a release. Keep a structured, redacted row for each sample with the source key, variant attributes, source identifier, transformed identifier, destination field, brand, MPN, identifier_exists, landing-page URL, and mapping version. When comparing releases, show additions, removals, and changed fields separately. A missing field is not the same as an unchanged blank field.

Pay special attention to values that software commonly changes: leading zeroes, whitespace, Unicode punctuation, numeric coercion, nulls, and duplicate keys. If the export is sorted differently, sort by stable offer key before comparing. If a connector creates a new item ID, retain the source-to-destination join so the reviewer can still prove identity. If the same identifier appears on more than one offer, do not decide from the payload alone; ask the catalogue owner whether the duplication represents a documented packaging relationship or an error.

Worked release example

Imagine a store changes its product master and feed connector on the same afternoon. The catalogue contains a black backpack in 20 L and 30 L variants. The 20 L source row has an assigned identifier and an MPN; the 30 L row has a different MPN and an identifier awaiting confirmation. The connector test says “export successful.”

The reviewer does not release the full family. First, they match both source variants to their offer keys and confirm that the 20 L payload carries the 20 L values. They then find that the 30 L row inherited the 20 L identifier because the mapping joined on product ID instead of variant ID. The mechanical checker passes the inherited string, which is why that result is not treated as proof. The 30 L row is held, the mapping owner is assigned, and the 20 L row can proceed only within a scope that the release manifest names explicitly.

After the mapping is corrected, the reviewer compares the new payload with the saved failing sample. The 30 L identifier remains held until its owner confirms assignment; brand and MPN are checked independently. The product page is opened with the 30 L option selected, and the URL and visible attributes are recorded. The release status becomes payload_reviewed, then submitted; it remains destination_pending until the destination reads back the same offer. At no point does “checker passed” or “connector succeeded” become “accepted.”

Rollback and hold matrix

Keep the response proportional to the first broken boundary. If one source row is wrong, restore or correct that row and hold that offer. If a variant join is wrong, hold the affected product family and revert the mapping version before editing product facts. If serialization removes leading zeroes across the export, hold the affected channel feed and return to the last explainable export. If a supplemental feed overwrites a primary value, disable or isolate that precedence path according to the documented rollback procedure. If the destination rule is unclear, hold the relevant country and channel until the current rule is reviewed.

The rollback record should state what was restored, which release identifier it replaces, which products remain held, and what evidence is needed to reopen them. Do not delete source history to make a failed release disappear. Do not overwrite the only failing payload sample. A reversible release leaves enough information to explain both the bad row and the repaired row.

Should every feed release run a GTIN checker?

Run a mechanical check when the field is expected to contain a GTIN, especially after an import, mapping, or serialization change. Treat the result as one gate. Assignment, variant identity, source ownership, page consistency, and destination processing remain separate checks.

Is a SKU an acceptable replacement for a GTIN?

Not automatically. A SKU is usually an internal stock-keeping key, while a GTIN is a commercial product identifier with a different ownership and identity role. Use the channel’s documented fields and the product’s actual identifier facts; do not rename a SKU to make it look like a GTIN.

Can a feed be released while destination processing is pending?

You may record a transmission as complete if the release policy allows it, but keep the article or release in destination_pending until the same item is read back. Do not call it accepted, fixed, or fully verified before that evidence exists.

What is the first check after a connector change?

Compare a known-good item and a changed item from source through final payload. Pay special attention to variant joins, leading zeroes, null handling, packaging level, and supplemental-feed precedence. Stop the broad release if the sample is not explainable.

Where should I continue when a warning already exists?

Use the diagnostic path for Missing GTIN or another destination warning. This article is the pre-submission gate; it should leave a clear release packet that makes the later diagnosis faster.

Sources

• GS1 Global GTIN standard
• GS1 support: What is a product identifier?
• Google Merchant Center Help: Find a GTIN
• GS1 Canada: Global Trade Item Numbers

The sources support standards terminology and channel-data boundaries. They do not provide a guarantee of acceptance for a particular store, product, country, or release.