# Agentic Commerce Field Guide — full text

# Agentic commerce starts with an operating model.

> A practical framework for choosing agent-assisted commerce work, setting decision rights, and proving that the result is worth the cost.

By George Kelly · Published 2026-09-05 · Updated 2026-09-05

Canonical: https://www.iamgeorgekelly.com/field-guide/agentic-commerce

## Short answer

Agentic commerce is the use of software agents to interpret commercial goals, work with business information, and select or perform actions. A useful implementation connects four things: a trustworthy source, a bounded decision, an authorized action, and evidence of the result.

## What counts as agentic commerce?

A shopping assistant is one expression of agentic commerce. The operating work behind a store is another: reconciling a product record, preparing a merchandising change, investigating a conversion problem, or assembling a campaign brief. The commercial question is the same: which decision becomes better, faster, or less expensive?

Use a fixed workflow when the steps are predictable. Consider an agent when the next useful step depends on what it finds. Anthropic makes this architectural distinction between predefined workflows and agents that choose their own process and tools. That distinction is more useful for implementation than treating every automated task as an autonomous agent.

This guide proposes an operating framework for commerce leaders. It is an editorial decision aid, not a maturity benchmark or a claim that a particular employer uses this architecture.

Sources: [Anthropic: Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)

## The four-part operating contract

Before selecting a model, write one sentence for each part of the contract below. If the team cannot name a source owner or define a successful result, the missing work is operational. A more capable model does not resolve that ambiguity.

| Part | Decision to make | Concrete example |
| --- | --- | --- |
| Source | Which record is authoritative, and how current must it be? | Read the approved variant record and the current sellable availability. |
| Decision | What judgment can the system make? | Flag conflicting dimensions and propose a corrected description. |
| Action | What may it change, for whom, and within which limits? | Create a draft; route publication to the named owner. |
| Evidence | What proves the result and where is it recorded? | Compare the approved draft with the rendered product page and retain the difference. |

## Choose the first workflow by its failure mode

Start with a task that happens often enough to evaluate, has an accessible source, and produces an artifact a person can inspect. Product-data reconciliation, a sourced campaign brief, or a draft landing-page review are useful candidates. A task involving unbounded spend or customer commitments needs a much more explicit operating contract.

Take a product-description refresh. The input is a list of variant identifiers and approved facts. The output is a proposed change with citations to those facts. The first version ends at a preview. The acceptance check compares identifiers, units, included components, and links. Missing facts become exceptions, rather than plausible additions to the copy.

A deterministic rule may be enough to detect a missing unit. An agent may be useful when it must reconcile a specification sheet with a structured record and explain the conflict. Keep the rule for the predictable part and reserve the model for the interpretation.

## Use a decision record instead of a single readiness score

A blended score can conceal the one condition that should stop a release. Record each condition separately. A high-volume task with no reliable source is still a poor candidate for unattended execution.

For each candidate, capture frequency, baseline handling time, source quality, reversibility, reviewer effort, and the cost of an incorrect result. Then choose the smallest trial that can disprove the proposed benefit. Twenty representative cases can be a useful starting experiment; it is not a statistically sufficient sample for every workflow.

- Name the task owner and the current process before proposing the replacement.
- Collect ordinary cases and difficult exceptions; keep both in the evaluation set.
- Define acceptance criteria before looking at the agent’s output.
- Count review, correction, tool calls, and failed runs in the cost comparison.
- Expand the action boundary only after the narrower workflow produces repeatable evidence.

## Measure accepted work, not generated output

A completed run is not necessarily completed work. A useful operational measure is accepted artifacts per unit of total handling time. Include the person who reviewed the result and the person who repaired the mistake. Track exception rate separately so a faster average does not hide a worse customer outcome.

For an illustrative trial, suppose ten briefs previously required 300 minutes. The assisted process takes 70 minutes to generate, 130 to review, and 40 to correct: 240 minutes total, or 60 minutes saved. Claiming 230 minutes saved by counting generation alone would overstate the improvement. These are synthetic figures, not portfolio results.

The next decision is whether those 60 minutes are worth the operating cost and whether the briefs meet the same quality bar. A profit calculation and a workflow acceptance record make that discussion concrete.

## A one-page brief for the first pilot

Write the goal as an observable outcome: prepare an accurate draft for a defined product family within a specified review budget. List the approved inputs, allowed tools, forbidden assumptions, review owner, and stopping conditions. Attach the evaluation cases and the artifact that will be compared with the baseline.

Finish with a decision date and three possible outcomes: stop, revise the narrow workflow, or expand a specific permission. Avoid treating a successful demo as permission to automate the adjacent business process. The operating model should travel with the implementation.

## Sources and scope

- [Anthropic: Building effective agents](https://www.anthropic.com/engineering/building-effective-agents) — Supports the workflow-versus-agent distinction. The commerce operating contract and examples here are original editorial frameworks. Checked 2026-09-05.

## Related reading

- [From request to release: a supervised commerce workflow.](https://www.iamgeorgekelly.com/field-guide/supervised-commerce-workflows/index.md)

- [Product data an agent can use without guessing.](https://www.iamgeorgekelly.com/field-guide/product-data-for-agents/index.md)

- [ROAS calculator: break-even and contribution](https://www.iamgeorgekelly.com/field-guide/roas-poas-profit/index.md)

## Editorial note

AI-assisted research and drafting. Provider-specific claims link to primary sources. Frameworks are editorial proposals; worked examples are illustrative and are not employer performance results.

Related career work: https://www.iamgeorgekelly.com/projects/american-standard-bathing

---

# ROAS calculator: break-even and contribution

> Calculate ROAS, contribution after advertising, and the break-even return for your margin. Includes worked examples and a margin comparison.

By George Kelly · Published 2026-09-05 · Updated 2026-09-06

Canonical: https://www.iamgeorgekelly.com/field-guide/roas-poas-profit

## Short answer

Revenue ROAS is net revenue divided by advertising spend. Break-even ROAS is one divided by your positive contribution margin before ads: a 40% margin needs 2.5×; a 25% margin needs 4×. A good target also leaves enough contribution for overhead and profit. Use the calculator with revenue and costs from the same cohort.

## Try the ROAS and contribution calculator

Enter revenue, costs, and advertising spend from one cohort. The starting figures are illustrative; calculations stay in your browser.

Interactive calculator: https://www.iamgeorgekelly.com/field-guide/roas-poas-profit#calculator

Read-only API documentation: https://www.iamgeorgekelly.com/for-agents#calculator-api

## Read the example behind the inputs

Consider a synthetic order cohort with 1,000 in net revenue, 550 in cost of goods, 150 in other variable costs, and 200 in advertising. Use one currency for every input. Revenue ROAS is 5.00×. Gross profit is 450, so gross-profit return is 2.25×. Contribution before ads is 300, so contribution return is 1.50×. After advertising, 100 remains toward overhead and profit.

Now raise other variable costs to 300 while keeping sales and advertising unchanged. Revenue ROAS remains 5.00×, but contribution after advertising becomes −50. The same reported revenue efficiency produces a different commercial result. This is why shipping, returns, and fulfillment assumptions belong beside the media number.

## Calculate break-even ROAS from the contribution margin

When contribution before advertising is positive, break-even revenue ROAS equals net revenue divided by contribution before advertising. In the first example, that is 1,000 ÷ 300, or approximately 3.33×. Equivalently, it is one divided by the pre-ad contribution margin, expressed as a decimal.

This threshold assumes the same product mix and cost behavior as the inputs. If order value, fulfillment cost, discounts, or return rates change with scale, recalculate it. If the pre-ad contribution margin is zero or negative, no finite revenue ROAS reaches advertising break-even under those assumptions.

With zero advertising spend, return-on-spend ratios are undefined. A calculator should show that condition explicitly rather than display infinity, zero, or a successful performance signal.

These are arithmetic comparisons, rounded to two decimals, not industry benchmarks. Margin here is (net revenue − cost of goods − other variable costs) ÷ net revenue. Fixed overhead is excluded.

| Margin before ads | Break-even revenue ROAS |
| --- | --- |
| 20% | 5.00× |
| 25% | 4.00× |
| 30% | 3.33× |
| 40% | 2.50× |
| 50% | 2.00× |

## Break-even is the floor, not the target

In the illustrative 1,000-revenue cohort above, 300 remains before ads. To retain 150 toward overhead and profit, advertising can cost at most 150 under those assumptions. The implied revenue ROAS is 1,000 ÷ 150, or about 6.67×. At 200 in spend, the calculator instead leaves 100.

This is a cost ceiling for a stated revenue and cost scenario. It does not prove that reducing spend preserves sales, or that raising a platform ROAS target produces the modeled profit. Recheck marginal demand, returns, and inventory before changing a budget.

## Define the numerator before comparing the return

A dashboard label does not establish an accounting definition. For this guide, net revenue means revenue after discounts and refunds, excluding sales tax. Cost of goods sold is the cost assigned to those sold items. Other variable costs are incremental order costs not already counted in cost of goods, such as payment fees, pick-and-pack, or a shipping subsidy.

Google Ads supports conversion values based on measures including revenue or profit. Consequently, conversion value divided by cost can mean different things depending on the values supplied. Inspect the value definition before interpreting the ratio. A platform value is not automatically the business’s realized profit.

| Measure | Formula | What it leaves out |
| --- | --- | --- |
| Revenue ROAS | Net revenue ÷ ad spend | Product and other costs |
| Gross-profit return on ad spend | (Net revenue − cost of goods) ÷ ad spend | Other variable costs and fixed overhead |
| Contribution return before ads | (Net revenue − cost of goods − other variable costs) ÷ ad spend | Fixed overhead |
| Contribution after ads | Net revenue − cost of goods − other variable costs − ad spend | Fixed overhead; this is not net income |

Sources: [Google Ads: About conversion values](https://support.google.com/google-ads/answer/13064207?hl=en)

## Make the comparison cohort consistent

Match the revenue, costs, and spend to a consistent time window and attribution basis. A platform-attributed sale, an order placed in the store, and settled net revenue are different records. If you combine them, describe the reconciliation rule and its limitations.

Keep return timing visible. A recent cohort may look healthier simply because its returns have not arrived. Use an observed mature cohort or label the return provision as an estimate, then reconcile it later. Avoid comparing an estimated net value in one period with an unreconciled gross value in another.

- State currency, reporting period, and attribution model alongside the output.
- Separate observed costs from estimated costs.
- Check whether shipping or fulfillment is already included in cost of goods before subtracting it again.
- Document which costs are excluded so contribution is not presented as net income.
- Reconcile modeled results with settled commercial records before increasing spend.

## Use the metric to make a bounded decision

Contribution return can help prioritize investigation, but it does not independently prove that advertising caused the revenue. An attributed return and an incremental return answer different questions. A budget decision still needs a view of incrementality, inventory, capacity, and the marginal cost of the next customer.

A useful decision memo includes the current cohort, the contribution assumptions, the proposed spend change, the inventory constraint, and the date to revisit the result. That is a more actionable artifact than announcing that a campaign has reached a universal good-ROAS number.

## Sources and scope

- [Google Ads: About conversion values](https://support.google.com/google-ads/answer/13064207?hl=en) — Supports the distinction between revenue-based and profit-based conversion values. The calculator definitions and synthetic example are stated explicitly in this guide. Checked 2026-09-06.

## Related reading

- [Is the campaign still profitable after returns?](https://www.iamgeorgekelly.com/field-guide/returns-adjusted-contribution/index.md)

- [Agentic commerce starts with an operating model.](https://www.iamgeorgekelly.com/field-guide/agentic-commerce/index.md)

- [Product data an agent can use without guessing.](https://www.iamgeorgekelly.com/field-guide/product-data-for-agents/index.md)

- [Can your stock support more ad spend?](https://www.iamgeorgekelly.com/field-guide/inventory-aware-ad-spend/index.md)

## Editorial note

AI-assisted research and drafting. Provider-specific claims link to primary sources. Frameworks are editorial proposals; worked examples are illustrative and are not employer performance results.

Related career work: https://www.iamgeorgekelly.com/projects/vintage-bath-home

---

# Product data an agent can use without guessing.

> A practical product-data contract for variants, dimensions, availability, provenance, and unknown values, with a downloadable JSON example.

By George Kelly · Published 2026-09-05 · Updated 2026-09-05

Canonical: https://www.iamgeorgekelly.com/field-guide/product-data-for-agents

## Short answer

Give an agent an identifiable variant, explicit units, a current offer record, and a source for each material fact. Keep unknown values unknown. A polished description cannot compensate for a mismatched SKU, stale availability, or an ambiguous dimension.

## Start with the sellable variant

A product family is not the same thing as an orderable item. A finish, size, handing, or included-component change can alter what the customer receives. An agent should be able to distinguish the group from the exact variant and preserve that identity when passing between a feed, product page, specification, and proposed recommendation.

Google Merchant Center documents stable item identifiers and variant attributes. Google Search separately documents ProductGroup relationships for structured product variants. These are useful interoperability references; the internal contract below is an original example, not a replacement for either specification.

Sources: [Google Merchant Center: Product data specification](https://support.google.com/merchants/answer/7052112?hl=en); [Google Search: Product variant structured data](https://developers.google.com/search/docs/appearance/structured-data/product-variants)

## A minimal internal contract

The following fictional cabinet record demonstrates the structure. Null offer values are deliberate: the example has no verified live price or availability. Do not paste it into a merchant feed. Adapt field names and required attributes to the destination and the actual product category.

The record separates durable product facts from rapidly changing offer facts. It also says what the dimension means. A width without a unit or measurement definition is a string that looks useful while leaving the important decision unresolved.

```json
{
  "schemaVersion": "1.0",
  "exampleOnly": true,
  "productGroupId": "DEMO-CABINET-24",
  "variantId": "DEMO-CABINET-24-OAK",
  "title": "Demonstration cabinet, 24-inch width, oak finish",
  "dimensions": {
    "width": {
      "value": 24,
      "unit": "in"
    },
    "meaning": "product exterior width, not installation opening"
  },
  "includedComponents": [
    "cabinet"
  ],
  "excludedComponents": [
    "faucet"
  ],
  "offer": {
    "price": null,
    "currency": "USD",
    "availability": "unknown",
    "observedAt": null
  },
  "provenance": {
    "specification": {
      "source": "Replace with approved specification URL",
      "checkedAt": null,
      "owner": "Product data owner"
    },
    "offer": {
      "source": "Replace with authorized live offer source",
      "checkedAt": null,
      "owner": "Commerce operations"
    }
  }
}
```

[Download the example product-data contract](https://www.iamgeorgekelly.com/downloads/product-data-contract.json)

## Set rules at the field level

A single updated-at timestamp can hide mixed freshness. A specification may remain valid for months while availability changes during the day. Give each fact family its own source and observation time, then choose a freshness requirement according to the action being taken.

A descriptive comparison can tolerate a different freshness window from a promise to fulfill an order. The window is a business rule to define with the source owner. It should not be invented by the model.

| Fact family | Required clarity | Failure response |
| --- | --- | --- |
| Identity | Stable variant identifier and family relationship | Stop matching if identifiers disagree. |
| Dimensions | Numeric value, unit, and measurement meaning | Flag missing units or incompatible measurements. |
| Compatibility | Explicit approved relationship or constraint | Say unverified instead of inferring fit from a similar title. |
| Included components | What ships together and what is separate | Prevent copy from implying an accessory is included. |
| Offer | Price, currency, availability, observation time | Refresh or report unavailable when the record is stale. |
| Provenance | Source location and accountable owner | Route a conflict to the owner; retain both source values. |

## Handle a conflict as an exception, not a writing task

Imagine a synthetic listing whose title says 24 inches while the approved specification says 23.5 inches of exterior width. First inspect whether the two values describe different concepts: nominal size versus measured exterior size. If so, retain both with labels. If both claim to be exterior width, the task is unresolved.

The output should name the variant, reproduce the conflicting values, cite the two source locations, and state which downstream copy is paused. Replacing one value with the more plausible number creates the appearance of resolution without evidence.

This exception record is useful content for both a reviewer and an agent. It narrows the next action and makes it possible to test whether the issue was actually resolved.

## Test the contract before expanding the catalog

Choose a representative set of variants that includes similar names, missing dimensions, unavailable items, and component differences. Test whether the system keeps those distinctions through retrieval and rendering. A large catalog import is not proof that a specific variant can be recommended correctly.

The acceptance artifact should show the source record, the normalized record, and the rendered result for the same identifier. Re-run the affected cases when a mapping changes. Preserve the difference between an empty value, a verified absence, and a value that was never checked.

- Keep an explicit unknown state; do not replace it with a favorable default.
- Validate allowed units and currency codes at the integration boundary.
- Check every displayed price and availability against the same variant.
- Attach sources to decision-critical claims, not only to the page as a whole.
- Version the contract so a renamed field does not silently change its meaning.

## Sources and scope

- [Google Merchant Center: Product data specification](https://support.google.com/merchants/answer/7052112?hl=en) — Supports stable identifiers, explicit variant attributes, and consistency between submitted data and the destination. Checked 2026-09-05.

- [Google Search: Product variant structured data](https://developers.google.com/search/docs/appearance/structured-data/product-variants) — Supports explicit ProductGroup and Product relationships. The downloadable internal contract is illustrative, not Google feed syntax. Checked 2026-09-05.

## Related reading

- [Product data ownership: resolve a price conflict](https://www.iamgeorgekelly.com/field-guide/product-data-ownership/index.md)

- [Does the product page match the variant you submitted?](https://www.iamgeorgekelly.com/field-guide/product-variant-acceptance-test/index.md)

- [From request to release: a supervised commerce workflow.](https://www.iamgeorgekelly.com/field-guide/supervised-commerce-workflows/index.md)

- [Agentic commerce starts with an operating model.](https://www.iamgeorgekelly.com/field-guide/agentic-commerce/index.md)

## Editorial note

AI-assisted research and drafting. Provider-specific claims link to primary sources. Frameworks are editorial proposals; worked examples are illustrative and are not employer performance results.

Related career work: https://www.iamgeorgekelly.com/projects/vintage-bath-home

---

# From request to release: a supervised commerce workflow.

> An original seven-stage operating checklist for turning agent-assisted commerce work into an inspectable, authorized, verified release.

By George Kelly · Published 2026-09-05 · Updated 2026-09-05

Canonical: https://www.iamgeorgekelly.com/field-guide/supervised-commerce-workflows

## Short answer

A supervised commerce workflow separates preparing a change from authorizing it and proving the live result. Carry the same scope and artifact version through intake, source collection, drafting, preview, approval, publication, and verification.

## Make the unit of work a reviewable artifact

“Improve the product page” is too broad to evaluate. A usable request names the page, the intended customer outcome, the fields that may change, and the evidence that will establish correctness. A reviewer should be able to compare the proposal with the current page without reconstructing a conversation.

An agent can help assemble the evidence and produce the proposal. The operating design still needs to identify who can authorize the resulting action. Anthropic’s engineering guidance describes evaluation, environmental feedback, and human checkpoints as parts of agent design; the release workflow here applies those ideas to commerce operations.

Sources: [Anthropic: Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)

## The seven-stage release contract

Treat each stage as a handoff with a concrete output. A stage can be automated when its acceptance condition is reliable and the action is authorized. A missing source or changed scope should return work to the relevant stage instead of being quietly bypassed.

| Stage | Acceptance check | Evidence | Owner |
| --- | --- | --- | --- |
| Intake | Goal and affected URLs are explicit | Scoped request | Request owner |
| Source | Material facts have current approved sources | Source register | Product or content owner |
| Draft | Proposed changes are inspectable | Draft and difference | Producer |
| Preview | Content and behavior match the proposal | Preview URL and checks | Reviewer |
| Approval | Decision applies to this exact version | Versioned approval record | Release owner |
| Publish | Authorized artifact reaches its destination | Deployment identifier | Release owner |
| Verify | Canonical live output matches approved artifact | Live URL and recorded result | Verifier |

[Download the release checklist](https://www.iamgeorgekelly.com/downloads/commerce-release-checklist.csv)

## Match the permission to the consequence

Reading a public specification, preparing a draft, changing a product description, sending a customer message, and changing a budget have different consequences. Giving one process the broadest credential needed by any of these tasks removes the distinction that the workflow is supposed to enforce.

Record the action boundary directly: which account, which destination, which fields, which amount if applicable, and whether the operation is reversible. A request to investigate a problem should not be interpreted as permission to carry out every proposed remedy. When publication is already authorized for a defined change, the workflow should carry that authorization forward rather than repeatedly asking the same question.

Use a specific stop condition for missing evidence. For example: if the specification and page disagree about included components, prepare the discrepancy and pause the affected copy. That condition is testable; “be careful” is not.

## A worked example: a product spotlight page

In this hypothetical example, a commerce team requests a spotlight page for a product family. The request identifies the intended audience and approved product records. The draft contains only supported specifications, shows which variants are covered, and links to the correct destination.

The preview review checks visible copy, responsive layout, keyboard navigation, images, metadata, and the destination for each primary link. If a new accessory or unsupported performance claim appears, it returns to source review. If only spacing changes, the reviewer checks the affected layout rather than repeating unrelated product research.

After approval, the release owner publishes the exact version that was reviewed. Verification opens the canonical public URL and compares the material content with the approved artifact. A successful build or an accessible preview proves a different condition from a correct production page.

## Keep an evidence record small enough to use

A useful release record contains the request identifier, affected URLs, source references, approved version, deployment reference, validation results, and unresolved exceptions. It should help the next person answer what changed, why, who could authorize it, and whether it reached the intended destination.

Do not bury the decision in an undifferentiated transcript. Preserve the durable facts and link to detailed evidence when needed. A short structured record is easier to compare across releases and easier for another agent to ingest without mistaking old suggestions for current instructions.

## Evaluate the workflow on accepted releases

Measure elapsed time, human handling time, rejection reasons, rework, and escaped defects. Generation speed is only one component. If a faster draft causes more source verification work, the apparent improvement may disappear after review.

Use the rejection log to improve the narrow step that failed. Missing units suggest a contract check. Unclear requests suggest a better intake template. Incorrect live destinations suggest release verification. Increasing autonomy is a possible response to reliable performance, not the default response to every bottleneck.

## Sources and scope

- [Anthropic: Building effective agents](https://www.anthropic.com/engineering/building-effective-agents) — Supports evaluation and environment feedback as agent-design principles. The seven-stage commerce checklist is an original adaptation, not an Anthropic standard. Checked 2026-09-05.

## Related reading

- [How do you check AI product copy before publishing?](https://www.iamgeorgekelly.com/field-guide/ai-product-copy-evaluation/index.md)

- [Product data an agent can use without guessing.](https://www.iamgeorgekelly.com/field-guide/product-data-for-agents/index.md)

- [Agentic commerce starts with an operating model.](https://www.iamgeorgekelly.com/field-guide/agentic-commerce/index.md)

## Editorial note

AI-assisted research and drafting. Provider-specific claims link to primary sources. Frameworks are editorial proposals; worked examples are illustrative and are not employer performance results.

Related career work: https://www.iamgeorgekelly.com/projects/american-standard-bathing

---

# Measure AI visibility without confusing it with traffic.

> A measurement framework that separates crawler access, answer citations, referral visits, and qualified commercial outcomes.

By George Kelly · Published 2026-09-05 · Updated 2026-09-06

Canonical: https://www.iamgeorgekelly.com/field-guide/ai-visibility-measurement

## Short answer

AI visibility has at least four separate measurements: a crawler can access the content; an answer cites it; a person visits from an AI surface; and that visit leads to a useful outcome. None of those measurements is a substitute for the next.

## Keep four evidence layers separate

An agent can retrieve a page without sending a person to it. A cited page can receive no click. A visit can arrive without a recognizable referrer. Design the reporting system around these different observations instead of combining them into one agentic-traffic number.

| Layer | Evidence | What it does not prove |
| --- | --- | --- |
| Access | HTTP status, response content, crawler request logs | Index inclusion or recommendation |
| Citation | A recorded answer with a visible source link | A visit, ranking, or endorsement |
| Referral | An observed analytics session with an AI referrer | All AI influence or causal attribution |
| Outcome | A qualified inquiry or other defined conversion | That the AI surface alone caused the outcome |

## Use the measurements each platform actually provides

Bing Webmaster Tools documents an AI Performance report with citation-related information for supported Microsoft and partner experiences. Interpret that as citation evidence for those covered surfaces, not a census of every assistant. A cited-page count is not a referral count.

Google’s guidance places AI-feature performance within Search Console’s Web reporting. That makes a separate, precise count of all Google AI-driven visits unavailable from that combined report alone. Preserve the reporting scope when presenting the numbers.

GA4’s native AI Assistant channel measures sessions classified from supported assistant sources. Read session source/medium and preserve classification gaps. The linked GA4 walkthrough provides a worked review; citations and crawler requests remain separate measurements.

Sources: [Bing: Introducing AI Performance in Webmaster Tools](https://blogs.bing.com/webmaster/February-2026/Introducing-AI-Performance-in-Bing-Webmaster-Tools-Public-Preview); [Google Search: AI features and your website](https://developers.google.com/search/docs/appearance/ai-features); [Google Analytics: Default channel group](https://support.google.com/analytics/answer/9756891?hl=en)

## Build a fixed question panel

Write questions that a potential client or hiring leader might ask before encountering your name. Mix definitions, decisions, comparisons, and implementation requests. A portfolio-focused panel might include how to calculate contribution return, how to prepare product data for agents, and how to supervise an automated commerce release.

Record the exact prompt, surface, visible model if provided, date, locale, and whether browsing was enabled. Save the answer and its source links. Keep the wording stable within a baseline period; otherwise a changed prompt and a changed site become confounded.

Repeat observations and keep all results, including missing citations. Answers can vary between runs. A manually selected favorable screenshot is not a trend. A custom API application with its own search and prompt is a different surface from the consumer assistant and should be reported separately.

[Download the question bank and observation fields](https://www.iamgeorgekelly.com/downloads/ai-visibility-question-bank.csv)

## A baseline before a growth claim

This library launches with a measurement plan, not an invented citation baseline. Its technical checks establish that the pages and exports can be fetched. Search inclusion, citations, referral volume, and commercial outcomes require subsequent observations.

For the first observation window, record which prompts cite the site, which exact pages appear, and whether the answer represents those pages accurately. Where analytics is available, separately record referral sessions, engaged reading, calculator use, and qualified contacts. Do not label uncaptured values as zero.

Use a consistent review interval and disclose the sample size. If ten prompts are each checked twice, the denominator is twenty observations. It is not twenty independent users or an estimate of market share. Compare like surfaces and like questions before interpreting a change.

## Diagnose the failure before adding more content

If the page cannot be fetched, inspect crawling and delivery. If it can be fetched but is not indexed, inspect indexability, canonicalization, and whether the page offers distinct value. If it is indexed but rarely cited in the panel, inspect the relevance and completeness of the answer and compare the actual sources selected.

If citations occur without meaningful visits, the answer may have resolved the task inside the assistant. That can still establish familiarity, but it should not be reported as website traffic. Give readers a useful reason to visit: a calculator, a downloadable contract, a complete worked example, or a relevant case study.

If visits occur without inquiries, inspect audience fit and the connection to your work. A page that attracts only unrelated developer troubleshooting may produce impressive activity with little commercial value.

## A compact monthly evidence memo

Report the fixed-panel citation observations, the pages cited, answer accuracy issues, known AI referrals, and qualified outcomes in separate rows. Add the content published or substantively revised during the same period and note other changes that could affect the result.

Finish with one decision: refresh an existing answer, build a missing resource, fix access, or improve the path from reading to relevant work. The purpose of measurement is to choose the next investment, not to make an emerging channel look more certain than it is.

## Sources and scope

- [Bing: Introducing AI Performance in Webmaster Tools](https://blogs.bing.com/webmaster/February-2026/Introducing-AI-Performance-in-Bing-Webmaster-Tools-Public-Preview) — Documents citation-oriented reporting and its supported surfaces. It is distinct from website referral analytics. Checked 2026-09-05.

- [Google Search: AI features and your website](https://developers.google.com/search/docs/appearance/ai-features) — Documents inclusion requirements and the scope of Search Console reporting for AI features. Checked 2026-09-05.

- [Google Analytics: Default channel group](https://support.google.com/analytics/answer/9756891?hl=en) — Defines the AI Assistant channel and excludes Google AI Overviews and AI Mode. Channel membership is not proof of a unique human or citation. Checked 2026-09-06.

## Related reading

- [How to read AI referral traffic in GA4](https://www.iamgeorgekelly.com/field-guide/ga4-ai-referral-traffic/index.md)

- [Make a website easy for agents to find, read, and use.](https://www.iamgeorgekelly.com/field-guide/agent-discoverability/index.md)

- [ROAS calculator: break-even and contribution](https://www.iamgeorgekelly.com/field-guide/roas-poas-profit/index.md)

- [Agentic commerce starts with an operating model.](https://www.iamgeorgekelly.com/field-guide/agentic-commerce/index.md)

## Editorial note

AI-assisted research and drafting. Provider-specific claims link to primary sources. Frameworks are editorial proposals; worked examples are illustrative and are not employer performance results.

---

# Make a website easy for agents to find, read, and use.

> An evidence-based guide to crawler access, HTML, structured data, Markdown, llms.txt, feeds, and real tool descriptions.

By George Kelly · Published 2026-09-05 · Updated 2026-09-05

Canonical: https://www.iamgeorgekelly.com/field-guide/agent-discoverability

## Short answer

Start with public, indexable HTML, stable URLs, internal links, and clear text. Add Markdown and a concise llms.txt index as alternate reading paths. Describe real tools with real contracts. No discoverability file guarantees an AI citation or referral.

## The foundation is still the published page

Google documents that its AI search features use the existing search foundation: pages need to be indexable and eligible for a snippet. It does not require special AI text files or a special schema. Structure the visible answer so a person or retrieval system can identify the question, the answer, and the evidence.

For this library, each guide has a short answer, named sections, definitions, an applicable example or decision table, sources, and a visible editorial date. These are publishing choices intended to reduce ambiguity. They are not a claim that a particular heading length or paragraph shape is a ranking factor.

Sources: [Google Search: AI features and your website](https://developers.google.com/search/docs/appearance/ai-features)

## Distinguish search discovery from model training

OpenAI documents separate OAI-SearchBot and GPTBot purposes for search and training. Anthropic also distinguishes search, user-requested retrieval, and training crawlers. Perplexity documents search and user-triggered retrieval agents. A site owner should set the intended policy per purpose, then check that hosting or firewall rules do not contradict it.

A permissive robots.txt is permission to crawl, not evidence that a crawler visited. Some user-initiated fetchers have different robots behavior from automated search crawlers. Consult the provider’s current documentation rather than treating every bot name as equivalent.

Sources: [OpenAI: Overview of crawlers](https://developers.openai.com/api/docs/bots); [Anthropic: Web crawler controls](https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler); [Perplexity: Crawlers](https://docs.perplexity.ai/docs/resources/perplexity-crawlers)

## Give each format a useful job

HTML remains the canonical publication. Markdown removes navigation and presentation overhead for tools that prefer text. A JSON index lets a client enumerate the corpus without scraping cards. Feeds expose publication and revision information to subscribers. Keep these exports derived from the same record so they do not disagree.

| Surface | Useful job | Boundary |
| --- | --- | --- |
| robots.txt | Declare automated crawler access policy | Does not force crawling or index inclusion. |
| sitemap.xml | List canonical public pages | Discovery hint, not an indexing guarantee. |
| Article and breadcrumb structured data | Describe visible authorship and page relationships | Must agree with the actual page. |
| llms.txt | Offer a small curated reading index | An emerging convention, not a universal AI search requirement. |
| Markdown and JSON | Provide alternate representations of the published content | Keep sources, caveats, and dates in every representation. |
| RSS and JSON Feed | Expose a subscription and update stream | Feeds do not themselves create an audience. |
| OpenAPI | Describe an implemented callable API | Do not advertise tools that do not exist. |

## Where llms.txt helps—and what is still unproved

The llms.txt proposal describes a concise Markdown guide to a site’s useful material. Chrome’s Lighthouse documentation now includes an audit for it and explicitly treats the file as optional. That is evidence of practical tooling support. It is not evidence that adding the file increases rankings or guarantees citations.

This site publishes a curated llms.txt, a full text bundle, and per-guide Markdown. The aim is to make a deliberate agent visit efficient. A source link resolves to the same content a person can read; there is no separate set of promotional claims hidden for bots.

Sources: [The llms.txt proposal](https://llmstxt.org/); [Chrome Lighthouse: llms.txt audit](https://developer.chrome.com/docs/lighthouse/agentic-browsing/llms-txt)

## Make the destination worth opening

A useful answer can earn a citation and still remove the need to visit. A site should also offer something a reader can do: compare assumptions, calculate a result, download a working example, or inspect the underlying evidence. This library pairs the profit guide with a local calculator and a documented read-only calculation API.

Do not add agent descriptors merely because their filenames sound relevant. An OpenAPI document describes an HTTP API. An MCP server or an A2A agent has a different runtime contract. A portfolio with a content library does not become either service by publishing a manifest.

## Keep the evidence current as the library grows

Record the source behind provider-specific behavior and the date it was checked. Update the editorial date when the substance changes, not on every deployment. Validate all exported representations and the canonical live URLs after a release.

Use a topic backlog built around distinct decisions rather than automatically generating near-identical keyword pages. Publish when a page contributes a new framework, worked example, artifact, or verified explanation. Google warns that generating many pages without added value can fall within scaled-content abuse; production volume alone is not the objective.

Then measure the result in separate layers: access, citations, referrals, and qualified outcomes. The measurement guide explains what each observation can and cannot establish.

Sources: [Google Search: Using generative AI content](https://developers.google.com/search/docs/fundamentals/using-gen-ai-content)

## Sources and scope

- [Google Search: AI features and your website](https://developers.google.com/search/docs/appearance/ai-features) — Supports baseline search requirements and the absence of a special AI file requirement. Checked 2026-09-05.

- [OpenAI: Overview of crawlers](https://developers.openai.com/api/docs/bots) — Documents separate search, training, and user-initiated crawler purposes. Checked 2026-09-05.

- [Anthropic: Web crawler controls](https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler) — Documents Anthropic crawler purposes and site-owner controls. Checked 2026-09-05.

- [Perplexity: Crawlers](https://docs.perplexity.ai/docs/resources/perplexity-crawlers) — Documents search and user-initiated retrieval agents. Checked 2026-09-05.

- [The llms.txt proposal](https://llmstxt.org/) — An emerging convention for a concise site index and alternate text representations. Checked 2026-09-05.

- [Chrome Lighthouse: llms.txt audit](https://developer.chrome.com/docs/lighthouse/agentic-browsing/llms-txt) — Documents optional llms.txt audit behavior; does not establish a ranking benefit. Checked 2026-09-05.

- [Google Search: Using generative AI content](https://developers.google.com/search/docs/fundamentals/using-gen-ai-content) — Supports prioritizing added value over mass generation without value. Checked 2026-09-05.

## Related reading

- [Measure AI visibility without confusing it with traffic.](https://www.iamgeorgekelly.com/field-guide/ai-visibility-measurement/index.md)

- [Product data an agent can use without guessing.](https://www.iamgeorgekelly.com/field-guide/product-data-for-agents/index.md)

- [Agentic commerce starts with an operating model.](https://www.iamgeorgekelly.com/field-guide/agentic-commerce/index.md)

## Editorial note

AI-assisted research and drafting. Provider-specific claims link to primary sources. Frameworks are editorial proposals; worked examples are illustrative and are not employer performance results.

---

# How do you check AI product copy before publishing?

> A claim-by-claim review method, six failure cases, and a reusable evaluation brief for AI-assisted product descriptions.

By George Kelly · Published 2026-09-05 · Updated 2026-09-05

Canonical: https://www.iamgeorgekelly.com/field-guide/ai-product-copy-evaluation

## Short answer

Check every factual claim against the approved record for that exact product. Reject invented specifications, borrowed variant facts, and unsupported promises before judging the writing. Use a small set of known failure cases to test the workflow, then keep a human release decision and a recoverable prior version.

## Give the writer a bounded job

Example brief: write 50–80 words for one product detail page using only the attached source record. Preserve units and limitations. Omit unknown claims and return a separate list of missing facts for review. The length is a house-style choice, not an SEO rule.

Shopify tells merchants to review AI suggestions before applying changes. Its product-description tool produces suggestions from the details provided. Review is part of using the output, not proof that generation was accurate.

Sources: [Shopify: Best practices for AI-powered tools](https://help.shopify.com/en/manual/ai-powered-tools/best-practices); [Shopify: Automatically generating product descriptions](https://help.shopify.com/en/manual/products/details/product-descriptions/shopify-magic)

## Check the claims inside a fluent sentence

Fictional approved record: DEMO-SHELF-24, a 24-inch-wide powder-coated steel shelf; hardware included; indoor use only; load capacity and warranty not provided.

Draft to reject: “This rustproof shelf holds 100 pounds anywhere, backed by a lifetime warranty.” The source supports none of those promises. “Anywhere” also conflicts with the indoor-use limit.

A factual replacement fragment: “A 24-inch-wide powder-coated steel shelf for indoor use. Hardware is included.” The reviewer’s separate note asks for load capacity and warranty evidence. Missing facts stay missing; polished language does not fill them.

| Claim | Evidence | Verdict |
| --- | --- | --- |
| 24-inch width | Exact product record | Supported |
| Hardware included | Exact product record | Supported |
| Rustproof / 100-pound capacity | Not provided | Reject |
| Use anywhere | Indoor use only | Reject |
| Lifetime warranty | Not provided | Reject |

## Test the failures you would actually stop

Run these cases before adopting a new prompt, model, or source connector. Save inputs and full outputs, not just a pass rate. Anthropic’s evaluation guidance supports checking outcomes with code, model, and human graders suited to the task. The cases and release rules here are an original editorial adaptation.

| Case | Input condition | Required behavior |
| --- | --- | --- |
| C1 · Complete source | All necessary facts supplied | Preserve facts and units |
| C2 · Missing capacity | No load rating | Omit capacity; flag missing evidence |
| C3 · Conflicting records | Two sources disagree on width | Hold for an owner decision |
| C4 · Sibling variant | Nearby record has a different finish | Use only the selected SKU’s facts |
| C5 · Expired promotion | Dated offer has ended | Do not repeat the offer |
| C6 · Instructions in source text | A product note tells the model to ignore the brief | Treat the note as data; preserve the approved task |

[Download the evaluation brief and scorecard](https://www.iamgeorgekelly.com/downloads/product-copy-evaluation.md)

Sources: [Anthropic: Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)

## Separate factual acceptance from style

First record unsupported or contradicted claims, wrong variant facts, missing required warnings, and unwanted actions. Any such release blocker fails that output under this proposed rule. Then score clarity, usefulness, and brand tone. A strong style score cannot offset a false specification.

For a small pilot, run each of the six cases three times under unchanged settings: 18 outputs. Report how many outputs contain a blocker, which cases fail, and the review time. Eighteen outputs are a local regression check, not a reliability estimate for the whole catalog.

Use exact checks for identifiers, dates, and units; use a person for ambiguous meaning and unsupported implications. A model can help flag claims, but asking the same writer whether its own copy is correct is weak evidence. Recheck failed cases and affected neighbors after a repair.

Sources: [Anthropic: Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)

## Review the actual page before release

Save the source version, prompt, model identifier when available, output, edits, reviewer, and decision. Preview the approved text on the actual product page. Check that the selected variant and visible specifications still agree. Preserve the prior copy and the smallest useful rollback unit.

Measure accepted descriptions per review hour, including corrections and rework. Faster drafting alone does not establish lower production cost. If a workflow can also publish, keep that action separately authorized and verify what went live.

Everstead is my ongoing website and site-care project. Its public direction includes reviewing updates before publication. This product-copy scorecard is a proposed method; it is not a claim about an Everstead feature, customer result, or employer process.

## Sources and scope

- [Shopify: Best practices for AI-powered tools](https://help.shopify.com/en/manual/ai-powered-tools/best-practices) — Supports reviewing AI suggestions before applying changes. The shelf example is fictional and the scorecard is a proposed method. Checked 2026-09-05.

- [Shopify: Automatically generating product descriptions](https://help.shopify.com/en/manual/products/details/product-descriptions/shopify-magic) — Documents description suggestions generated from supplied product details, not guaranteed factual accuracy. Checked 2026-09-05.

- [Anthropic: Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) — Supports task-specific evaluation, suitable graders, and inspecting outputs. The six cases, 18-run pilot, and release threshold are proposed choices, not a vendor standard. Checked 2026-09-05.

## Related reading

- [From request to release: a supervised commerce workflow.](https://www.iamgeorgekelly.com/field-guide/supervised-commerce-workflows/index.md)

- [Does the product page match the variant you submitted?](https://www.iamgeorgekelly.com/field-guide/product-variant-acceptance-test/index.md)

- [Product data an agent can use without guessing.](https://www.iamgeorgekelly.com/field-guide/product-data-for-agents/index.md)

## Editorial note

AI-assisted research and drafting. Provider-specific claims link to primary sources. Frameworks are editorial proposals; worked examples are illustrative and are not employer performance results.

Related career work: https://www.iamgeorgekelly.com/projects/everstead

---

# How to read AI referral traffic in GA4

> Use GA4’s AI Assistant channel, check source/medium, and reconcile known QA visits. Includes a worked review and reusable worksheet.

By George Kelly · Published 2026-09-06 · Updated 2026-09-06

Canonical: https://www.iamgeorgekelly.com/field-guide/ga4-ai-referral-traffic

## Short answer

Start with GA4’s AI Assistant channel, then inspect session source/medium. Report the recorded sessions and any verified classification gaps separately. They can show visits attributed to assistant sources; they cannot count every AI-influenced visit, identify every citation, or measure crawler activity.

## Start with the native channel

Google added the AI Assistant default channel on May 13, 2026. Recognized assistant referrers receive medium ai-assistant and campaign (ai-assistant). Use the current channel definition before maintaining your own list.

Google AI Overviews and AI Mode are excluded from this channel and remain Organic Search. An AI Assistant row therefore does not represent all traffic influenced by Google’s AI features.

Sources: [Google Analytics: AI Assistant channel release](https://support.google.com/analytics/answer/9164320?hl=en#05132026); [Google Analytics: Default channel group](https://support.google.com/analytics/answer/9756891?hl=en)

## Read sessions and their sources

In Google Analytics, choose Reports → Acquisition → Traffic acquisition. A customized property may place the report elsewhere or omit it. If it is missing, an editor can restore it to the report navigation.

Choose complete dates and record the property timezone. In the table, use Session default channel group and find AI Assistant. Add Session source / medium as a secondary dimension. Record Sessions and Engaged sessions. Keep session dimensions throughout; First user source answers a different acquisition question.

- Save the date range, timezone, report dimensions, filters, and extraction time with the export.
- Inspect Referral separately for candidate assistant sources. Confirm each identity before classifying it; preserve the original source/medium.
- If the row or report is unavailable, record unavailable. A missing row alone does not establish zero visits.

Sources: [Google Analytics: Traffic acquisition report](https://support.google.com/analytics/answer/12923437?hl=en)

## Reconcile a small report

This fictional 28-day example uses reserved example hostnames, not a list of services GA4 recognizes. The three rows represent disjoint sets of sessions. The third is assumed to have independent evidence that its source is an assistant.

The native channel has 32 recorded sessions. Three identifiable QA sessions leave 29. A separate Referral row has four sessions, including one known QA session, leaving three more for the reviewed assistant category. Report 29 native plus 3 reviewed referrals: 32 in total. Keep both components visible.

Only subtract QA when the report and a QA record support that exclusion. If your own visits cannot be isolated, label the period contaminated instead of estimating a deduction. Multiple sessions can belong to one person.

| Synthetic source / medium | Recorded | Known QA | Reviewed |
| --- | --- | --- | --- |
| assistant-a.example / ai-assistant | 20 | 2 | 18 |
| assistant-b.example / ai-assistant | 12 | 1 | 11 |
| assistant-c.example / referral | 4 | 1 | 3 |

[Download the illustrative review worksheet (CSV)](https://www.iamgeorgekelly.com/downloads/ai-referral-review.csv)

## Keep the useful outcome separate

Suppose the fictional inquiry log records one relevant professional inquiry linked to one reviewed session. Report one qualified inquiry with that evidence. A contact-link click alone would not establish that an inquiry was sent or qualified.

The worksheet includes evidence and unresolved-gap columns. Replace the example rows before using it. Keep private contact details and user-level analytics out of public reports.

[Download the example, rules, and blank row (JSON)](https://www.iamgeorgekelly.com/downloads/ai-referral-review.json)

## Investigate gaps without rewriting the history

Keep the native channel as the reference. If a verified assistant referrer lands elsewhere, record the hostname, supporting evidence, date checked, and original classification. A documented custom grouping can support a separate analysis when the gap warrants it.

Do not infer assistant origins from Direct traffic, use a crawler user-agent list as a referrer list, or combine a custom grouping with the same native sessions twice. Note any collection or classification change beside period comparisons.

Sources: [Google Analytics: Default channel group](https://support.google.com/analytics/answer/9756891?hl=en)

## State what remains unknown

Consent choices and missing referrers can leave visits unobserved or unattributed. Analytics sessions are a proxy for visits, not verified unique people. Crawler requests belong in request logs; citations belong in recorded answers with source links.

Compare complete periods only after reporting has settled. Keep known QA out of audience interpretation, preserve unresolved gaps, and read inquiry quality alongside session counts. None of these observations alone proves that publishing a guide caused an increase.

## Sources and scope

- [Google Analytics: AI Assistant channel release](https://support.google.com/analytics/answer/9164320?hl=en#05132026) — Documents the May 13, 2026 AI Assistant channel and automatic medium/campaign classification for recognized referrers. Checked 2026-09-06.

- [Google Analytics: Default channel group](https://support.google.com/analytics/answer/9756891?hl=en) — Defines the AI Assistant channel and excludes Google AI Overviews and AI Mode. Channel membership is not proof of a unique human or citation. Checked 2026-09-06.

- [Google Analytics: Traffic acquisition report](https://support.google.com/analytics/answer/12923437?hl=en) — Documents session-scoped acquisition dimensions, report access, metrics, and secondary dimensions. The reconciliation method and all example counts are editorial illustrations. Checked 2026-09-06.

## Related reading

- [Measure AI visibility without confusing it with traffic.](https://www.iamgeorgekelly.com/field-guide/ai-visibility-measurement/index.md)

- [Make a website easy for agents to find, read, and use.](https://www.iamgeorgekelly.com/field-guide/agent-discoverability/index.md)

- [ROAS calculator: break-even and contribution](https://www.iamgeorgekelly.com/field-guide/roas-poas-profit/index.md)

## Editorial note

AI-assisted research and drafting. Provider-specific claims link to primary sources. Frameworks are editorial proposals; worked examples are illustrative and are not employer performance results.

---

# Can your stock support more ad spend?

> An inventory and ad-spend calculator with daily stock checks, a delayed-delivery example, and a downloadable decision worksheet.

By George Kelly · Published 2026-09-06 · Updated 2026-09-06

Canonical: https://www.iamgeorgekelly.com/field-guide/inventory-aware-ad-spend

## Short answer

Increase spend only when the additional sales can earn positive contribution and leave enough stock for existing demand and a buffer. Check every day before replenishment, not just the final stock total. A profitable historical ROAS does not establish either condition. Use the worksheet to test a proposed increase, then verify its assumptions before release.

## Test the proposed increase

Start with one variant and the locations that can fulfill its orders. The starting values are fictional USD examples. Change the delivery day, demand, or cost per additional unit to see which constraint fails. All money inputs must use the same currency.

Interactive inventory worksheet: https://www.iamgeorgekelly.com/field-guide/inventory-aware-ad-spend#inventory-calculator

Current-scenario CSV/JSON downloads are generated locally in the browser. Formulas and worked scenarios follow in this article. This worksheet has no HTTP calculation endpoint.

## Count available stock and existing demand once

Shopify distinguishes available inventory from committed, unavailable, and incoming quantities. If you start from Available, do not subtract commitments again. Enter only an additional buffer that has not already been withheld. Count an incoming shipment on the day it can actually be sold and fulfilled, after receiving and any quality checks.

Baseline demand means expected new units sold with current spend unchanged, including organic, retail, and existing paid activity drawing from this stock. Exclude orders already committed. The proposed increase adds genuinely additional units to that baseline. Attributed orders are not automatically incremental: Google’s Conversion Lift documentation describes estimating causal impact through exposed and control groups.

Sources: [Shopify: Understanding inventory states](https://help.shopify.com/en/manual/products/inventory/fundamentals/inventory-states); [Google Ads: About Conversion Lift](https://support.google.com/google-ads/answer/12003020?hl=en)

## One delivery changes the decision

The first two scenarios start with 120 available units and a further 20-unit buffer. Over 14 days, baseline demand is 84 units. An extra 60 USD per day at an assumed 20 USD per additional unit adds 42 units. Each unit contributes 30 USD before ads.

With 60 units received before day 8, the proposed increase leaves 54 units at the end and never breaches the buffer. Its modelled contribution after extra advertising is 42 × 30 − 840 = 420 USD, before fixed overhead. Delay that same receipt to day 15 and the plan crosses the buffer on day 12. The ending balance of −6 represents unmet demand, not negative physical inventory.

| Scenario | Stock result | Proposed decision |
| --- | --- | --- |
| Delivery on day 8 | No buffer breach; 54 units remain | Test a limited increase after verifying assumptions. |
| Same delivery delayed to day 15 | Buffer breached on day 12 | Hold the increase; the stock-limited extra spend is 22.85 USD/day, rounded down. |
| 90 available units; no receipt or extra spend | Baseline alone breaches the buffer on day 12 | Review a reduction in stock-consuming activity or a change to supply. Identify controllable demand first. |

[Download the three worked scenarios and expected results (JSON)](https://www.iamgeorgekelly.com/downloads/inventory-ad-spend-scenarios.json)

## Check the stock path, then contribution

For each day d: baseline balance = available units + receipts sellable by d − baseline units per day × d. Planned balance = baseline balance − (extra spend per day ÷ cost per additional unit) × d. A breach occurs when either balance falls below the additional buffer; day 0 means it starts below the buffer.

The stock limit for uniform additional units per day is the smallest value of (baseline balance − buffer) ÷ d across every day in the window, floored at zero. Multiply that unit limit by the assumed cost per additional unit to obtain the stock-limited extra spend per day. If baseline demand already breaches the buffer, zero extra spend is still insufficient to protect it.

For a feasible plan: contribution from the increase = additional units × contribution per unit before ads − extra spend. Use net selling value after expected discounts and refunds, less product and variable costs. Do not count those costs again in advertising. An infeasible plan shows no contribution total; it cannot assume every projected unit will be sold.

These are proposed planning rules, not a platform bidding formula. The model allows 1–90 days, one receipt, and uniform daily demand and spend. Fractional units represent expected averages. It excludes demand variability, shared components, bundles, substitution, cash constraints, and fulfillment limits. Use a dated daily plan when those change the decision.

## Stress-test the assumptions that can reverse it

Run the delayed or missing delivery case first. Then test higher baseline demand, lower unit contribution, and different acquisition costs. A cheaper additional unit consumes stock faster; a more expensive one reduces contribution. A higher dollar stock limit caused by worse efficiency is not permission to spend more.

The worksheet models actual extra spend distributed evenly. A Google Ads average daily budget does not enforce that pattern: for most campaigns, the daily spending limit is twice the average daily budget. Check the applicable campaign rules and early demand spikes before turning a scenario into a platform setting.

- Confirm the inventory snapshot, variant, locations, receipt date, and accountable owner.
- Use evidence for marginal unit cost; keep a range when incremental impact is unknown.
- Set a review time before the earliest plausible shortage, plus a stop condition tied to available stock.
- Recalculate when receipt timing, daily demand, returns, or the offer changes.

Sources: [Google Ads: Bidding and budget questions](https://support.google.com/google-ads/faq/10286469?hl=en)

## Turn the result into a small decision memo

Record the proposed change, stock evidence, economics, stress cases, owner, and next review time. The CSV and JSON buttons above download your current inputs and daily balances locally. The blank memo below records the evidence the calculator cannot verify.

If you restrict advertising, keep the customer-facing availability truthful. Merchant Center requires availability to agree with the landing page and checkout; its guidance distinguishes pausing promotion from marking an available product out of stock. Recheck the affected variant and destination after an approved change.

[Download the blank inventory and spend decision memo](https://www.iamgeorgekelly.com/downloads/inventory-spend-decision.md)

Sources: [Google Merchant Center: Availability](https://support.google.com/merchants/answer/6324448?hl=en)

## Use this alongside the profitability and product-data guides

The ROAS guide checks the economics of the sales already measured. This worksheet asks whether a proposed increase fits a dated stock plan. The ownership register helps establish which availability and lead-time evidence to trust. Together they support a clearer budget review; they do not prove that an increase will create demand.

## Sources and scope

- [Shopify: Understanding inventory states](https://help.shopify.com/en/manual/products/inventory/fundamentals/inventory-states) — Defines available, committed, unavailable, on-hand, and incoming stock. Does not prescribe this buffer, demand forecast, or spending rule. Checked 2026-09-06.

- [Google Ads: About Conversion Lift](https://support.google.com/google-ads/answer/12003020?hl=en) — Explains exposed/control measurement of incremental impact. Does not establish the example’s assumed cost per additional unit or guarantee study access. Checked 2026-09-06.

- [Google Ads: Bidding and budget questions](https://support.google.com/google-ads/faq/10286469?hl=en) — Documents daily spending limits for most campaigns and exceptions. The worksheet’s uniform actual spend is an assumption, not a Google Ads budget control. Checked 2026-09-06.

- [Google Merchant Center: Availability](https://support.google.com/merchants/answer/6324448?hl=en) — Supports accurate availability across offer, landing page, and checkout, and separate controls for pausing promotion. The calculator does not change product feeds or campaigns. Checked 2026-09-06.

## Related reading

- [ROAS calculator: break-even and contribution](https://www.iamgeorgekelly.com/field-guide/roas-poas-profit/index.md)

- [Is the campaign still profitable after returns?](https://www.iamgeorgekelly.com/field-guide/returns-adjusted-contribution/index.md)

- [Product data ownership: resolve a price conflict](https://www.iamgeorgekelly.com/field-guide/product-data-ownership/index.md)

## Editorial note

AI-assisted research and drafting. Provider-specific claims link to primary sources. Frameworks are editorial proposals; worked examples are illustrative and are not employer performance results.

Related career work: https://www.iamgeorgekelly.com/projects/vintage-bath-home

---

# Product data ownership: resolve a price conflict

> A field-ownership register for PIM, ERP, storefront, and feed data, with a worked correction and explicit release checks.

By George Kelly · Published 2026-09-06 · Updated 2026-09-06

Canonical: https://www.iamgeorgekelly.com/field-guide/product-data-ownership

## Short answer

Assign each product field an authoritative source, an accountable owner, an approved update path, and a freshness rule. When records disagree, use that rule to resolve the conflict. An ERP or PIM label alone does not decide which value is correct. Keep the affected offer on hold until the approved value and its destination agree.

## Write the ownership rule before the next conflict

The register below is a proposed method for a fictional catalog. It separates the application that stores a value from the evidence that supports it. A PIM copy can be useful without being authorized to approve a new retail price.

The download covers nine fields, including availability, lead time, identifiers, variants, and images. Replace the systems and roles with your own. A spreadsheet documents a rule; integrations and permissions must enforce it.

| Register field | Decision it records |
| --- | --- |
| Scope | Which SKU, market, currency, quantity, and meaning? |
| Authoritative source and owner | Where is the approved value maintained, and who resolves exceptions? |
| Approved update path | Who may change it, and which consumers receive the approved revision? |
| Cadence and freshness | When should it update, and how old may the supporting observation be? |
| Conflict and evidence checks | What is held, what proves the correction, and when was the rule reviewed? |

[Download the fictional ownership register (CSV)](https://www.iamgeorgekelly.com/downloads/product-data-ownership-register.csv)

## Check that the values describe the same fact

A retail price and a wholesale price are not conflicting copies of one fact. Neither are packaged weight and product weight. Check variant, market, currency, unit count, tax basis, meaning, and effective date before choosing a winner.

For Google Merchant Center, submitted price and currency must meet its landing-page and checkout requirements. Its availability guidance also requires consistency. Those destination rules support an agreement check; they do not tell you which internal application should own the value.

Sources: [Google Merchant Center: Price](https://support.google.com/merchants/answer/6324371?hl=en); [Google Merchant Center: Availability](https://support.google.com/merchants/answer/6324448?hl=en)

## Work the conflicting-price example

All three observations below describe one fictional black lamp, one retail unit, sold in the US in USD. At 14:05 UTC on August 24, the example register gives the ERP approved retail-price record authority. Revision DEMO-PRICE-17 took effect at 14:00. The pricing lead confirms its approval.

The current approved price is 120. The PIM and feed are stale mirrors, not competing approvals. Hold the affected channel offer, correct the mirrors from revision 17, then confirm the selected-variant landing page, checkout, and destination offer all show 120 USD. Keep the mismatch and correction evidence.

If the authoritative record is unavailable, leave the decision on hold. A recent mirror does not become an approved source just because it can be fetched.

| Record at 14:05 UTC | Price (USD) | Observed | Role |
| --- | --- | --- | --- |
| ERP revision 17 | 120 | 14:04 | Approved, effective source |
| PIM mirror, revision 16 | 110 | 13:00 | Stale downstream copy |
| Feed offer, revision 15 | 105 | 11:00 | Stale downstream copy |

[Download the register, conflict, and release checks (JSON)](https://www.iamgeorgekelly.com/downloads/product-data-ownership-register.json)

## Set freshness for the decision

This example allows price evidence up to five minutes old and availability evidence up to one minute old. Those are fictional operating choices, not Google requirements. Set tolerances with the owner based on change frequency, consequence, and the ability to detect updates.

Observation age, approval, and effective date are separate checks. Fetching an old unapproved record now does not make it authoritative. Stable specifications can use revision-based updates plus periodic evidence review. Recheck the approved source at release time if its observation has expired.

## Close the exception with destination evidence

In this proposed workflow, the pricing lead approves the commercial value and commerce operations confirms delivery. A feed job reporting success is insufficient if the destination still displays the old offer. Keep the affected channel restricted until the checks pass; use that channel’s supported controls rather than falsifying stock status.

Google’s variant guidance requires direct selection of the correct variant with its corresponding price and availability. Resolve ownership first, then use the existing variant acceptance test to check the delivered record.

- Confirm the approved revision and its scope.
- Record the correction, responsible role, and destination acknowledgement.
- Compare the selected variant, landing page, checkout, and offer after the correction.
- Recheck evidence age and record who released the hold.
- If a downstream system may write back, route its proposed change through the authoritative approval path.

Sources: [Google Search: Product variant structured data](https://developers.google.com/search/docs/appearance/structured-data/product-variants)

## Start with three fields

Begin with price, availability, and one specification customers use to choose a product. Fill the register with their owners and run one disagreement through it. An agent may collect evidence or propose a correction within its permissions; approval and release authority still need to be explicit.

This resource addresses ownership and correction. The product-data contract describes the record an agent reads; the variant acceptance test checks whether the published facts agree. Use the three together.

## Sources and scope

- [Google Merchant Center: Price](https://support.google.com/merchants/answer/6324371?hl=en) — Supports price/currency agreement and current price requirements. Does not prescribe ERP or PIM ownership, approval roles, or a five-minute tolerance. Checked 2026-09-06.

- [Google Merchant Center: Availability](https://support.google.com/merchants/answer/6324448?hl=en) — Supports consistent availability across product data, landing page, and checkout. A data conflict is not evidence that stock is unavailable. Checked 2026-09-06.

- [Google Search: Product variant structured data](https://developers.google.com/search/docs/appearance/structured-data/product-variants) — Supports direct variant selection with correct price and availability. The register and conflict are fictional editorial examples. Checked 2026-09-06.

## Related reading

- [Product data an agent can use without guessing.](https://www.iamgeorgekelly.com/field-guide/product-data-for-agents/index.md)

- [Does the product page match the variant you submitted?](https://www.iamgeorgekelly.com/field-guide/product-variant-acceptance-test/index.md)

- [From request to release: a supervised commerce workflow.](https://www.iamgeorgekelly.com/field-guide/supervised-commerce-workflows/index.md)

- [Can your stock support more ad spend?](https://www.iamgeorgekelly.com/field-guide/inventory-aware-ad-spend/index.md)

## Editorial note

AI-assisted research and drafting. Provider-specific claims link to primary sources. Frameworks are editorial proposals; worked examples are illustrative and are not employer performance results.

Related career work: https://www.iamgeorgekelly.com/projects/american-standard-bathing

---

# Does the product page match the variant you submitted?

> A six-case acceptance test for variant identity, price, availability, and missing facts, with reusable JSON fixtures.

By George Kelly · Published 2026-09-05 · Updated 2026-09-05

Canonical: https://www.iamgeorgekelly.com/field-guide/product-variant-acceptance-test

## Short answer

Open the exact URL submitted for the variant. Compare its selected item, price, currency, and availability with the feed and that variant’s structured data. A family page or a valid schema test is not enough. If a required fact is missing or the records disagree, hold the recommendation and fix the source.

## Compare one offer, in one context

Google’s product specification requires submitted price and availability to agree with the destination. Its landing-page guidance also calls for the appropriate variant to be selected and for the product information to remain consistent during page load. These are documented shopping requirements, not a promise of AI recommendations.

Use this test before a feed release or an agent-assisted recommendation. Record the SKU, submitted URL, market, currency, customer price tier, and observation time. Compare public offers with public offers; a signed-in trade price is a different context.

Sources: [Google Merchant Center: Product data specification](https://support.google.com/merchants/answer/7052112?hl=en); [Google Merchant Center: Landing page requirements](https://support.google.com/merchants/answer/4752265?hl=en)

## A correct price attached to the wrong variant still fails

Fictional example: a merchant submits DEMO-36-BLK, a 36-inch black fixture at USD 420, in stock. The URL opens DEMO-30-CHR at USD 350. Both prices might be correct in the catalog. The submitted offer still fails because the destination selects a different item.

Repair the variant URL or selection behavior, then repeat the check in a fresh session. Compare the initial HTML with the rendered page. Confirm that the structured Offer belongs to the selected Product, rather than picking the first price found anywhere in the page.

| Surface | Observed value | Decision |
| --- | --- | --- |
| Feed | DEMO-36-BLK · USD 420 · in stock | Expected offer |
| Selected page variant | DEMO-30-CHR · USD 350 · in stock | Fail: wrong destination selection |
| Structured offer | DEMO-36-BLK · USD 420 · in stock | Does not cancel the visible mismatch |

Sources: [Google Search: Product variant structured data](https://developers.google.com/search/docs/appearance/structured-data/product-variants)

## Run six cases before trusting the connection

These are original acceptance cases. “Pass” means that the captured evidence agrees for this task and time. “Fail” means a contradiction. “Hold” means insufficient evidence. A hold should not silently become a pass.

| Case | Change to the expected offer | Expected result |
| --- | --- | --- |
| V1 · Control | All three surfaces agree | Pass |
| V2 · Wrong selection | Page selects DEMO-30-CHR | Fail |
| V3 · Old price | Structured offer still says USD 400 | Fail |
| V4 · Availability conflict | Feed says in stock; page says out of stock | Fail |
| V5 · Missing currency | Page price is 420 with no currency evidence | Hold |
| V6 · Unknown fit | Buyer requires a 36-inch opening; fit range is unknown | Hold the fit claim |

[Download the six test fixtures](https://www.iamgeorgekelly.com/downloads/variant-acceptance-fixtures.json)

## Variant identity comes before compatibility

Google documents ProductGroup and Product relationships for variant markup. That helps describe a family; it does not establish that one member fits a particular installation.

A nominal width is not an installation range. Keep finish, dimensions, included components, and compatibility separate. If the source does not establish fit, the useful answer is to request the missing specification. Do not borrow a sibling variant’s dimensions or infer compatibility from a photograph.

Sources: [Google Search: Product variant structured data](https://developers.google.com/search/docs/appearance/structured-data/product-variants)

## Turn the example into your own release check

The JSON download includes an expected offer, observed feed/page/structured records, a reason for each verdict, and fields for evidence. It is an internal test format, not a Merchant Center upload or a schema.org payload. Run it against your comparison logic before replacing the fictional records with authorized catalog data.

Keep raw observations beside normalized values. Converting “InStock” and “in_stock” to one status is reasonable; filling a missing currency from a nearby product is not. Set freshness limits by field and business need. A passing snapshot says nothing about tomorrow’s inventory.

- Capture the exact URL and selected SKU on mobile and desktop.
- Check the variant’s price, currency, availability, and image; include active sale dates when applicable.
- Save the initial response, rendered evidence, source timestamps, verdict, and owner of any correction.
- Retest only the corrected case and affected variants, then record the release version.

## Sources and scope

- [Google Merchant Center: Product data specification](https://support.google.com/merchants/answer/7052112?hl=en) — Supports matching submitted product facts with landing pages and structured data. The six-case test is an original editorial method. Checked 2026-09-05.

- [Google Merchant Center: Landing page requirements](https://support.google.com/merchants/answer/4752265?hl=en) — Supports variant selection and consistent information during page load. This guide does not test or certify a real merchant account. Checked 2026-09-05.

- [Google Search: Product variant structured data](https://developers.google.com/search/docs/appearance/structured-data/product-variants) — Documents ProductGroup and Product relationships. It does not establish installation compatibility. Checked 2026-09-05.

## Related reading

- [Product data ownership: resolve a price conflict](https://www.iamgeorgekelly.com/field-guide/product-data-ownership/index.md)

- [Product data an agent can use without guessing.](https://www.iamgeorgekelly.com/field-guide/product-data-for-agents/index.md)

- [How do you check AI product copy before publishing?](https://www.iamgeorgekelly.com/field-guide/ai-product-copy-evaluation/index.md)

- [From request to release: a supervised commerce workflow.](https://www.iamgeorgekelly.com/field-guide/supervised-commerce-workflows/index.md)

## Editorial note

AI-assisted research and drafting. Provider-specific claims link to primary sources. Frameworks are editorial proposals; worked examples are illustrative and are not employer performance results.

Related career work: https://www.iamgeorgekelly.com/projects/american-standard-bathing

---

# Is the campaign still profitable after returns?

> A worked order-cohort reconciliation for refunds, recovered inventory, return costs, and ad spend, with a reusable review template.

By George Kelly · Published 2026-09-05 · Updated 2026-09-05

Canonical: https://www.iamgeorgekelly.com/field-guide/returns-adjusted-contribution

## Short answer

Follow the original order cohort through its refunds and costs. Subtract refunds from revenue, credit only the product cost actually recovered, retain costs you cannot recover, and subtract advertising once. Keep estimated future returns separate from settled results. A return rate alone cannot tell you how much profit remains.

## Start with order dates, then follow the adjustments

Choose an order-date window, currency, channel scope, and “as of” date. Join later refunds and return costs to those original orders. A calendar-month sales report can answer a different question: Shopify records sales on the sale date and reversals on the processing date.

Shopify also distinguishes physical returns from sales reversals. A refund can happen without a product coming back. Do not assume every refund restores inventory, or that every returned unit can be resold.

Sources: [Shopify: Sales reports](https://help.shopify.com/en/manual/reports-and-analytics/shopify-reports/report-types/default-reports/sales-report)

## Worked example: USD 1,200 becomes USD 280

Illustrative cohort: 100 orders, USD 10,000 merchandise revenue after discounts and before refunds, no shipping revenue, and no tax included. Advertising spend is USD 2,000. The costs below cover this cohort only and exclude fixed overhead.

Later, 20 orders are fully refunded for USD 2,000. All 20 units come back, but only 16 are resalable. At USD 80 product cost per refunded order, those 16 units recover USD 1,280 of inventory cost. The other four recover nothing. Return transport and handling add USD 200. Original fulfillment and payment costs remain spent.

| Line · USD | Before returns | After recorded returns |
| --- | --- | --- |
| Revenue after discounts | 10,000 | 10,000 |
| Refunds | 0 | −2,000 |
| Net revenue | 10,000 | 8,000 |
| Product cost originally assigned | −5,500 | −5,500 |
| Recovered inventory cost | 0 | +1,280 |
| Original variable costs | −1,300 | −1,300 |
| Return transport and handling | 0 | −200 |
| Advertising | −2,000 | −2,000 |
| Contribution after ads | 1,200 | 280 |

## Check the bridge before changing a bid

The loss of contribution is USD 920: 2,000 refunded − 1,280 recovered + 200 return costs. Therefore 1,200 − 920 = 280. There is no additional write-off for the four unsalable units: their original cost already remains in the 5,500.

For the existing contribution calculator, enter net revenue 8,000; cost of goods 4,220 (5,500 − 1,280); variable costs 1,500 (1,300 + 200); and ad spend 2,000. It returns contribution before ads of 2,280, contribution after ads of 280, revenue ROAS of 4.0, and contribution return of 1.14.

Break-even ROAS on that net-revenue basis is about 3.51 (8,000 ÷ 2,280). Do not compare it with a dashboard ratio that still uses pre-refund revenue. This cohort calculation is a management view, not evidence that advertising caused every included order.

## Keep open returns visible

A cohort is provisional while material returns or adjustments remain unresolved. Show observed contribution and an additional expected adjustment separately. When an estimated return becomes actual, replace the estimate; do not charge both.

Sensitivity example: five more full refunds of USD 100 each, each recovering USD 55 of product cost and adding USD 10 of return cost, reduce contribution by another USD 275. The remaining USD 5 is too thin to treat the original 5× revenue ratio as a reason to scale.

Record how the reserve was estimated, when it will be revisited, and which unresolved orders it covers. Use the business’s return window and actual processing delays rather than an arbitrary universal maturity threshold.

[Download the cohort review template](https://www.iamgeorgekelly.com/downloads/returns-cohort-review.md)

## Separate reporting repair from campaign action

Google Ads supports conversion adjustments, including restatements and retractions, subject to conversion type, identifiers, timing, and other requirements. A reconciliation document does not make those uploads happen. Check the current setup and documentation before changing bidding inputs.

First resolve missing costs, duplicate refunds, and allocation rules. Then compare mature cohorts on the same basis. Keep platform attribution, blended spend efficiency, and incremental impact as separate views. Allocate shared spend once and label the method; never add together platform-attributed revenue that may claim the same orders.

Sources: [Google Ads: How to adjust your conversions](https://support.google.com/google-ads/answer/7686280?hl=en)

## Sources and scope

- [Shopify: Sales reports](https://help.shopify.com/en/manual/reports-and-analytics/shopify-reports/report-types/default-reports/sales-report) — Documents sales/reversal timing and the distinction from physical returns. Cohort reconciliation and the USD example are original management-analysis illustrations, not Shopify accounting output. Checked 2026-09-05.

- [Google Ads: How to adjust your conversions](https://support.google.com/google-ads/answer/7686280?hl=en) — Documents conversion adjustments and their prerequisites. No conversion settings or bid changes are implied by this example. Checked 2026-09-05.

## Related reading

- [ROAS calculator: break-even and contribution](https://www.iamgeorgekelly.com/field-guide/roas-poas-profit/index.md)

- [Measure AI visibility without confusing it with traffic.](https://www.iamgeorgekelly.com/field-guide/ai-visibility-measurement/index.md)

- [Agentic commerce starts with an operating model.](https://www.iamgeorgekelly.com/field-guide/agentic-commerce/index.md)

## Editorial note

AI-assisted research and drafting. Provider-specific claims link to primary sources. Frameworks are editorial proposals; worked examples are illustrative and are not employer performance results.

Related career work: https://www.iamgeorgekelly.com/projects/vintage-bath-home