Country and Currency Variants in Product Feeds

A product feed country setting describes where an offer is intended to be shown or sold within a particular integration. It does not, by itself, establish the offer's language, currency, stock eligibility, shipping coverage, or product identity. Before extending a feed to another market, connect the same physical variant to an approved local offer and a page that presents that offer correctly. Hold the affected market when any part of that connection remains uncertain.

This article is for the operator who already has a working catalog and is considering another country, language, or currency. The decision is whether a particular market version can be released without sending buyers to a different product or commercial promise. The tables and release records below are an editorial operating method, not a universal platform schema. Field names, supported combinations, tax treatment, shipping obligations, and destination eligibility need a current-spec check for the actual platform, account, product, and target country.

Separate the dimensions before copying a feed

“The Canadian feed” can mean several different things inside one team. A marketer may mean the audience, a catalog operator may mean a data-source label, and a storefront owner may mean an English page displaying Canadian dollars. Those descriptions are not interchangeable. Write the actual dimensions next to the offer so a reviewer can follow the intended customer journey without guessing what a filename means.

Use the following table as an internal comparison sheet. Its labels are descriptive; they are not instructions to add invented attributes to a channel upload.

Dimension	Question to answer	Evidence to retain	Common mistaken inference
Target country	Where is this offer intended to be eligible?	Destination configuration and approved sales scope	A country label proves delivery coverage
Content language	Which language describes the product and offer?	Approved copy and the linked page	Currency identifies the language
Currency	In what currency is the offer amount expressed?	Local price record and page observation	Replacing a symbol converts a price
Market	Which internal assortment and selling policy applies?	Market definition and catalog inclusion decision	One market always equals one country
Physical variant	Which exact item will be delivered?	Variant record and product evidence	Translated names mean different products
Destination identity	Which processed offer is being inspected?	Account, source, item identifier, and actual destination context	An item ID alone identifies every market view
Availability	Can this item be offered under this market's promise?	Approved inventory and fulfillment decision	Stock anywhere means sellable everywhere

Keep country of manufacture separate as well. The location where an item was made does not tell you which country the offer targets. Nor does the shopper's detected location establish the authorized assortment. If a supplier sheet has a column called country, ask its owner what it means before mapping it. An ambiguous column is a source question, not an invitation to choose the interpretation that makes the export pass.

A market may be an internal business grouping with its own catalog and price rules. Do not assume that every connector can represent that grouping directly. Maintain an explicit translation between your business market and the destination's supported configuration. If that translation is missing, keep the new market out of the release while the account owner resolves it.

Keep physical identity stable while the offer changes

Start with the product actually leaving the warehouse: its variant, size, color, configuration, and packaging. A translated description or a different selling currency is a change in presentation or offer terms. It is not sufficient evidence that the physical trade item has changed. Equally, similar photographs do not establish that two regional packages are identical. Ask the product owner to compare the actual supplied versions whenever regional packaging, contents, or configuration differ.

GTIN evidence belongs to that product comparison. Use the brand or supplier's verified product record rather than creating a number for each market. Google's Find a GTIN guidance is a useful route for locating existing identifiers; it does not turn an internal market label into a commercial identifier. If you need the terminology first, read what a GTIN identifies.

For Google, the product data specification currently directs merchants to keep the same product ID for the same product across countries or languages. Treat this as a current-spec check when reviewing a real integration. Do not casually append a country suffix to that attribute to fix a reporting collision. Your internal comparison record can carry market context without rewriting the destination's required identifier behavior.

The useful distinction is between a stable product reference and a complete observation address. To inspect a result, you may need the account, source, item reference, language, and other context exposed by your connector. Record those separately. The exact destination key must come from its current documentation and actual processed record; this article does not prescribe one composite key for every platform.

The GTIN checker can help with a narrow structure or check-digit question. A passing check does not allocate a commercial GTIN, establish ownership, verify the regional package, or guarantee acceptance. If the evidence points to a different physical item, hold that mapping for product review instead of using a mechanically valid number to bridge the uncertainty.

Give each local value an owner

The most useful preparation is a short ownership register. Name the person or system authorized to decide each value, then identify the transformations between that source and the feed. A spreadsheet that merely lists the final fields will not explain who should correct a disputed local price tomorrow.

For identity, retain the catalog or product owner's approved variant mapping. For localized text, retain the approved translation revision and the product facts it was translated from. For price, name the actual commercial source and its effective period. For availability, name the inventory and fulfillment decision that governs that market. For destination settings and URLs, name the integration and storefront owners. One person can hold several roles, but the decisions should remain distinguishable.

The diagram shows the shared product-data route, not a separate rule for each country. Use it to locate where a local override enters. A correction made only in the destination may disappear at the next scheduled sync if the upstream value still wins. Before making a correction, identify the layer that owns the fact and the layer that merely formats or transports it.

Consider a local title written in a feed rule while the storefront still uses an earlier translation. The issue is not resolved by declaring either screen authoritative. The copy owner must approve the intended wording, and the operator must trace both outputs to that revision. The same approach applies when an ERP price and a market price list disagree: get the commercial decision first, then repair the pipeline that is applying it incorrectly.

For a lasting responsibility model, continue to the product-data ownership lesson. This article stays with the narrower release question: whether the local offer in front of you is coherent enough to submit.

Localize text without changing the item

Translate the customer-facing meaning while protecting model names, capacities, pack counts, and variant distinctions. A fluent title that drops the pack quantity can describe a different purchase. A size translation that silently converts a supplier code into a familiar local size can create a fulfillment dispute. Preserve the original mapping and have a responsible reviewer approve any conversion or explanatory label.

Make an explicit list of translatable text and protected values. The list might include title and descriptive copy on one side, with identifiers, model references, and approved measurements on the other. Do not run a blanket translation over the whole export. Machine-readable attribute names and controlled values have their own specification. Google's product data specification distinguishes those values from free-form language; check the current requirements before submitting a localized source.

Review the page and feed side by side at the selected variant. A comparison at product-family level can miss the fact that the feed describes the large size while the page opens the small size. Look for the same quantity, color, material, and included accessories. The wording does not need to be a mechanical word-for-word copy for your editorial review, but it must not make competing claims about what the buyer receives. Destination-specific text requirements still need their own check.

Translation has its own freshness problem. If the source product changes after translation approval, do not treat the translated record as current merely because its status says approved. Compare its source revision. A pending translation can justify holding the new language while preserving an existing, accurate language version, provided the actual destination configuration supports that separation.

Review information inside product images as well. Translated prose can still conflict with an image showing another pack quantity or specification. Send that discrepancy to the product and asset owners; the translator should not independently change physical product facts. Whether the image meets a destination's requirements remains a separate current-spec check.

Treat currency as part of the price

A price record should make the amount, currency, applicable market, and effective period explicit. “49” without its context is not enough to compare two offers. Nor is a familiar currency symbol reliable evidence of the intended currency. Preserve the currency code in the review sheet and compare the actual approved amount, rather than mentally converting a screenshot.

Decide which system calculates or selects the local price. It could be an approved market price list or a configured conversion process; inspect the real implementation rather than assuming one. Record whether rounding, scheduled sales, or manual overrides participate. If two systems both convert the same base amount, the final feed can look plausible while disagreeing with the storefront. The repair is to remove the unauthorized transformation, not to add another compensating number downstream.

Do not infer current exchange rates or country tax rules from this article. The commercial owner must supply the applicable price policy. The destination's current documentation must establish what the submitted amount should include for the particular country and program. Missing tax or currency evidence should be an unresolved check, not a footnote attached to a release-ready row.

A scheduled promotion needs special attention at its boundary. Compare the effective time and timezone in the pricing source, feed output, and page behavior. If a sale has ended, restoring an expired sale price to match a stale feed would replace one error with another. Preserve the currently authorized price, correct the stale layer, and hold the affected offer if the discrepancy cannot yet be resolved safely.

A useful price comparison therefore reads like a short statement: this variant, in this market, at this observation time, is offered at this amount in this currency under this approved price revision. The statement gives the next operator enough context to distinguish a genuine business change from a localization error.

Availability belongs to the market promise

Inventory and market availability answer related but different operational questions. A warehouse balance tells you something about stock at a location. The market promise also depends on whether the business has approved selling and fulfilling that item to the intended destination. Do not turn an internal stock count into a universal claim that every localized offer is ready.

Ask the fulfillment owner which source determines the market's sellable state. Record relevant exclusions or routing decisions in the internal release record without exposing private operational details in public copy. If a particular variant cannot be fulfilled under the current market setup, its translated title and valid currency do not make that offer ready.

Inspect the selected page state and the permitted purchase path without creating a real order as part of this content review. In an actual operational workflow, any transaction test needs its own authorization. What matters here is that the operator defines the decisive check in advance: which visible offer, which destination, and which fulfillment evidence must agree before release.

Avoid inventing a destination value for a business state the connector cannot represent. The integration owner should map approved internal availability to the platform's supported values using current documentation. If the business says “review required,” keep that as an internal hold reason. Do not assume that uploading those words creates a recognized channel status.

Check the landing URL and canonical deliberately

Open the exact URL that the proposed feed will send. Start from a fresh viewing context as well as the normal merchant session, because saved location or language choices can conceal an incorrect default. Record the final destination after redirects, the selected variant, the displayed language, the amount and currency, and the visible availability. This is a proposed verification method, not a claim that any particular storefront already passes it.

A URL that contains a locale code is not proof of localized content. A currency selector can also change a visible amount without changing the underlying offer being submitted. Follow what the page actually presents. If a buyer must manually discover the right country before seeing the advertised offer, ask the storefront and integration owners whether that journey meets the destination's current landing-page rules.

Record the canonical URL separately from the feed landing URL. Canonical markup does not change the visible price or make a wrong variant correct. It also should not be rewritten automatically for every feed row. When a canonical points somewhere unexpected, send the exact source page and target to the SEO owner, who can compare them with the site's documented localization policy. This article does not prescribe a universal cross-country canonical pattern.

Inspect any product structured data separately too. A page can show the intended currency while its embedded offer still describes an older default. For the division of responsibilities, use product schema versus product feed. Treat a page/feed comparison, a structured-data comparison, and the channel's processed result as separate observations in the same review record.

Worked example: one bottle, three proposed offers

The following is a fictional planning example. The prices are invented for arithmetic-free comparison, not exchange rates, market recommendations, tax advice, or evidence of channel acceptance. The internal item reference is deliberately not a commercial GTIN.

A merchant has approved one blue 500 ml bottle, internally called BOTTLE-BLUE-500. The proposed offer set contains a US English version and two Canadian language versions. The operator is reviewing a local expansion, not creating three new physical products. The product owner supplies the same verified item evidence for all three proposed rows and retains the real identifier outside this illustrative table.

Internal review row	Intended country	Language	Approved illustrative price	Page observation	Release decision
US English	US	English	USD 24.00	Same bottle, English, USD 24.00	Candidate for remaining checks
Canada English	Canada	English	CAD 33.00	Same bottle, English, CAD 33.00	Candidate for remaining checks
Canada French	Canada	French	CAD 33.00	Same bottle, French, USD 24.00	Hold local offer

The French row has a coherent translation but an inconsistent offer. Copying the Canadian currency code into the feed again will not repair a landing page that still displays the US price. The operator sends the exact proposed URL and observed redirect path to the storefront owner. The pricing owner confirms whether CAD 33.00 is still the approved amount. Until those facts connect, the local offer stays on hold.

Now suppose the fulfillment owner says the bottle is not enabled for the Canadian destination under the current shipping setup. That changes the decision for both Canadian rows, including the one whose page already looks correct. The hold reason becomes market fulfillment evidence missing or unavailable, according to the actual business decision. It should not be disguised as an identifier error.

If instead the supplier reports that the Canadian shipment uses a different packaged configuration, the operator stops assuming identical product evidence. The product owner must establish the correct relationship and identifier assignment before either Canadian row proceeds. Neither a country name nor a language translation settles that question.

This example produces no accepted offer and no promised performance improvement. It shows why separate dimensions matter: a page-currency error, a fulfillment restriction, and a physical-product difference lead to different owners and different repairs even when they affect the same proposed market.

Release a bounded set and keep a usable record

Choose a small, representative set based on actual differences: a second currency, a translated variant, a scheduled local price, or a market-specific availability exception. There is no universal sample size here. The set should expose the transformations you are changing. Record what it covers and what it leaves untested so the next reviewer does not interpret a successful sample as catalog-wide proof.

Before submission, retain the exact source revision, transformation revision, destination configuration, and proposed output for the chosen set. Include the previous truthful configuration if it remains a possible recovery option. A rollback plan should explain how to stop a bad local offer without restoring expired prices, unavailable stock, or an obsolete product mapping.

Use this checklist as the release decision, then record the actual evidence beside each item:

• The target account and proposed market scope are explicit.
• Country, language, currency, and internal market are separately described.
• The physical variant and identifier evidence are resolved.
• Local copy refers to the approved product revision.
• Amount, currency, and effective period have a named source.
• Market availability and fulfillment have an owner and current evidence.
• The exact landing URL shows the intended offer in the tested context.
• Canonical and structured-data questions have been reviewed separately.
• Current destination rules and supported field mappings have been checked.
• The submitted version can be connected to the processed destination record.
• The hold or recovery action has an owner, scope, and next review condition.

After an authorized submission, preserve the receipt but do not stop there. Inspect the destination's processed record for the same item and market context. Compare it with the submitted version and recheck the page. If the destination still shows an older version, record the observation and the next check condition. Do not declare success merely because a connector accepted a file.

The release record can be a compact document with these headings: target, changed dimensions, product evidence, source revisions, page observations, current-spec references, submitted version, processed result, exceptions, owner, and next action. Keep submission time distinct from observation time. That separation makes it possible to explain why two screenshots differ without assuming someone changed the wrong data.

For a broad field-quality review, use the existing title, GTIN, price, and availability checklist. For the identifier background, use GTIN, UPC, and EAN in Shopify. Those articles answer adjacent questions; neither substitutes for the market-by-market comparison here.

Hold the uncertainty where it occurs

A useful hold is specific enough to act on: the French Canadian landing URL displays the wrong currency; the market price owner has not approved the effective amount; or the regional package relationship is unresolved. Name the affected rows and the missing proof. A blanket “feed not ready” status makes it harder to preserve an existing offer that remains truthful and independently verified.

However, narrow holds are only appropriate when the actual configuration isolates the affected scope. If one shared transformation changes every market, its failure may require holding the whole changed set. Inspect that dependency before promising that another country's offer is unaffected. Scope follows the implementation and the evidence, not the convenience of the release schedule.

Set a next review condition rather than an invented processing deadline. The condition might be an approved price revision, a corrected page observation, or a processed destination record that can be tied to the submission. If the check remains inconclusive, say so and keep the hold. Repeated submissions without new evidence can make the history harder to interpret while leaving the underlying disagreement untouched.

The feed-debugging lesson provides the broader diagnostic method when a disagreement spans several systems. The GTIN and product-data topic path groups related questions when the incident turns out to concern identity, page data, or submission quality instead of localization.

Frequently asked questions

Does a new country require a new GTIN?

Do not assign a new GTIN merely because the offer uses another country, language, or currency. Establish the physical item's identity from verified product evidence. If regional packaging or configuration differs, ask the product owner to review the identifier assignment before release.

Can I translate the title and change the currency code?

Those edits alone do not establish a valid local offer. Verify the approved local amount, selected variant, landing page, market availability, and actual destination settings. A currency code does not convert an amount or correct a page that displays another offer.

Should every market use a different product ID?

Follow the named destination's current specification. Google's product data specification directs use of the same ID for the same product across countries or languages. Keep internal market review context separate from destination identifier rules; do not add country suffixes automatically.

Is a successful upload enough to release the remaining catalog?

No. Inspect the processed offer in the intended destination context and compare the exact landing page with the approved source. Record what the sample covered. A submission receipt or a passing sample does not establish acceptance or consistency for every market and variant.

Sources and specification checks

• Google Merchant Center product data specification: current-spec reference for product ID and language handling. Follow its linked country, currency, price, availability, and landing-page documentation for the actual destination decision.
• Google Merchant Center: Find a GTIN: locating existing product identifiers. Product evidence remains necessary.
• GS1 GTIN standard: supplied project reference for trade-item identification. Check the applicable assignment guidance with the responsible product owner when the physical configuration changes.

Platform references were reviewed on 2026-09-07 where retrievable. The workflow, fictional comparison, and hold records are editorial recommendations. They do not establish country eligibility, regulatory compliance, an accepted feed, or a ranking outcome.