A regional restock signal should create one human review task for the operator responsible for that market—not an automatic customer message or order. The smallest useful rule is a state transition on one fully identified offer: the variant, seller, fulfillment route and market must all match. This guide gives a cautious, synthetic policy for turning valid observations into reviewable restock episodes.
1. Give one operator one decision
Write the key before collecting: offer_id | variant | seller | fulfillment_method | market. The review owner asks: “Did this exact offer become available for customers in my market, and should I now take the approved business action?” The action can be a manual merchandising check, a support update or an approved internal follow-up. It is not an automatic order or notification system.
A public r/ecommerce question from March 2022 asks how to keep UK and US restock notices tied to their own inventory. It supports the existence of the regional-routing problem only; it supplies no workflow result, product recommendation or demand evidence.
2. Name states before calling anything a restock
| Observed state | Meaning in this policy | Can it begin a restock episode? |
|---|---|---|
| OUT_OF_STOCK | Not purchasable under the defined market context. | It can establish a verified prior state. |
| IN_STOCK | Purchasable under that same context. | Only after a verified OUT_OF_STOCK state and confirmation. |
| PREORDER | Order accepted before normal availability. | No. It resets a pending candidate and replaces the baseline; require a later OUT_OF_STOCK before allowing the next episode. |
| BACKORDER | Order accepted but fulfilment waits for availability. | No. It resets a pending candidate and replaces the baseline; require a later OUT_OF_STOCK before allowing the next episode. |
| UNKNOWN | Missing fields, stale/uncertain context or an unvalidated response. | No. It resets a pending candidate. |
Google Merchant Center documents in stock, out of stock, preorder and backorder as distinct availability values. Its definitions are a useful vocabulary, not evidence that an unrelated retailer uses the same states. Do not invent an out-of-stock baseline: an initial IN_STOCK observation is only a baseline, not a restock.
3. Preserve the regional context with the observation
The market key needs more than an IP country. Record the selected market or region identifier, landing URL and its explicit parameters, seller, fulfillment method, variant, retrieval time, source-update time when published, and validation result. A proxy can help observe an authorized regional experience, but it cannot by itself prove a customer’s delivery eligibility, account state or inventory allocation.
Google’s regional availability guidance describes a retailer-defined region_id and says regional landing pages should render the corresponding price and availability; it also says the parameter should not be overridden by cookies, previous visits or IP detection. That is Merchant Center guidance for participating retailers, not a generic retailer-inventory API. See the official regional availability and pricing guide.
4. Use a modest confirmation rule, then assign one review
This editorial policy uses a 15-minute confirmation gap as an illustrative parameter: two eligible IN_STOCK observations for the same full key must be in increasing time order with 0 < second_time − first_time ≤ 15 minutes, after an eligible OUT_OF_STOCK baseline. Equality at 15 minutes is accepted. It is not an optimal rule or proof of noise reduction.
UNKNOWN or a confirmation-gap breach clears the pending IN_STOCK candidate; it never becomes a negative observation. A key mismatch clears a candidate only when evidence expected for that same key conflicts; a valid observation under a different full key belongs to its own market and neither clears nor advances this candidate. Neither case invents a new OUT_OF_STOCK baseline: the older verified baseline may be reused only when it is < 4 hours old in the synthetic replay, or under a separately configured limit in a real pilot. These time parameters are examples, not an optimized universal policy. If no baseline-age limit is configured, HOLD: do not reuse it or assume OUT_OF_STOCK. A 403, 429 or other access restriction is STOP, not UNKNOWN: block the restricted path until an owner resolves permission or the supported access method.
Before the pilot, configure a baseline-age limit and a review deadline or a rule that computes it. At confirmation, the deadline must be strictly later than that time; a missing or elapsed deadline means HOLD, with no new task. Episode status is OPEN, CLOSED after an owner records a decision, or EXPIRED at the deadline. Expiry alone never proves a new stock change.
If the confirmation gap exceeds the limit, discard the old candidate; the current eligible IN_STOCK observation may start a new first candidate only while the OUT_OF_STOCK baseline remains valid. All times in the following example use the same UTC day. Eligibility is an explicit example input, not an inventory measurement.
Synthetic key: jacket-7 | M | seller-A | ship-to-home | GB-LON
09:00 OUT_OF_STOCK eligible baseline → no episode
09:15 IN_STOCK eligible, first candidate → pending
09:20 UNKNOWN source context incomplete → reset; no episode
09:35 IN_STOCK eligible, first candidate → pending
09:40 IN_STOCK eligible, second candidate → create REVIEW-001 for GB-LON operator
09:55 IN_STOCK same OPEN episode → no duplicate task
10:10 no new observation; REVIEW-001 expires → status EXPIRED
12:00 OUT_OF_STOCK eligible after expiry → re-arm for a future episode
Control: same offer in GB-MAN at 09:40 IN_STOCK → no GB-LON episodeEvery item above is synthetic. The exact replay uses a baseline age strictly < 4 hours and a 10:10 review deadline. The 09:00 OUT_OF_STOCK remains eligible after the 09:20 UNKNOWN reset; 09:35 starts a new candidate, and 09:40 is five minutes later, so it creates exactly one task, REVIEW-001. There is no task at 09:15, 09:20 or 09:55, and the GB-MAN control cannot affect the GB-LON key. The episode is OPEN until an owner records a decision and sets CLOSED, or it expires exactly at 10:10. The 12:00 eligible OUT_OF_STOCK can allow the next episode only after that closure/expiry; a later episode gets a new ID and needs a new two-observation transition. An initial IN_STOCK has no prior OUT_OF_STOCK transition and never creates an episode.
5. Review the evidence, not just the state label
| Check | Operator result |
|---|---|
| Full key matches the assigned market | Confirm offer, variant, seller and fulfillment route; otherwise close as key mismatch. |
| Both observations are eligible and fresh enough | Confirm timestamps, source context and no intervening UNKNOWN reset. |
| State is actually IN_STOCK | Separate preorder/backorder and unavailable choices; do not reinterpret them. |
| Evidence supports the operator’s action | Record review decision and reason. Human review decides any customer or business follow-up. |
Use the data-quality workflow to quarantine invalid fields before this policy sees them. Use the regional QA matrix to test a one-time site journey. This page instead governs recurring, valid observations and a single market operator’s review queue.
6. Pilot with action and cost measures
Start with a small authorized set and one named market operator. Record planned observations, eligible observations, UNKNOWN resets, transition candidates, review tasks, duplicate-suppression events, review minutes and actions marked useful, not useful or insufficient evidence. Keep retrieval time separate from published source-update time; if source update time is unavailable, keep it UNKNOWN.
At the end of the pilot, calculate review minutes per completed episode = total review minutes ÷ completed episodes only when completed episodes are greater than zero; otherwise record the rate as UNKNOWN, not zero. Compare it with the operator’s pre-agreed action value. Do not turn the count of candidate transitions into a value claim. Stop or simplify when a first-party feed, merchant report, manual check or direct authorized access already supports the action, when no owner acts, or when records remain UNKNOWN too often to meet the deadline.
7. Start from the bilingual worksheet
Download the bilingual worksheet. It contains fixed policy definitions and blank template rows for one authorized offer-market key. Copy the template per key, preserve prior episodes, and leave missing evidence as UNKNOWN rather than filling a state.
If a recurring authorized regional workflow genuinely needs a residential route, review residential proxies and contact the team with the source category, markets, key structure and review deadline. Confirm permissions, current suitability and limits before changing collection. This guide makes no IPHTML inventory, delivery, alerting or recovery-time promise.
Sources checked October 23, 2026: the linked Google Merchant Center availability and regional-availability guidance, plus the linked historical public question. The state policy, timeline and worksheet are editorial teaching material.