Why SkuWatch AI Visibility Separates Readiness from Visibility

One large score is easy to market and impossible to diagnose. A merchant cannot tell whether 72/100 means a crawler block, wrong inventory, no provider mention, or a failed API request.

SkuWatch AI Visibility therefore stores readiness and visibility as separate event families.

The storefront case that exposes the problem

On July 27, 2026, SkuWatch AI Visibility’s own requests to the public Pierre the Penguin product page returned 200 under four substituted User-Agent values. The returned storefront evidence exposed a stable product canonical and contradictory commercial fields:

• visible page: Sold out
• two structured offers: InStock
• visible page: 1,874 reviews
• one structured aggregate: zero rating and zero count
• structured brand in two Product entities: Beginner

A single score cannot preserve these facts.

The substituted headers do not identify official crawler traffic. They are transport diagnostics. The availability, review, brand, and canonical findings come from inspecting the returned storefront body; answer-engine visibility must be measured separately with completed provider responses and citations.

If availability conflict subtracts ten points, why ten? If a ChatGPT request later times out, should it subtract more? The arithmetic hides the only useful information: which public field is wrong and whether an independent answer was completed.

Readiness event model

{
  "scan_id": "scan_20260727_001",
  "merchant_id": "public-case-woobles",
  "canonical_url": "https://thewoobles.com/products/penguin-crochet-kit",
  "check_id": "offer.availability.visible_match",
  "state": "conflict",
  "severity": "high",
  "observed": {
    "visible": "Sold out",
    "structured": ["InStock", "InStock"]
  },
  "source": {
    "selector": "buy-box",
    "json_path": "Product.offers.availability"
  },
  "verified_at": "2026-07-27T00:00:00Z"
}

This record is repeatable. A later scan can show whether the same URL and field changed.

Visibility observation model

{
  "run_id": "run_20260727_001",
  "query_id": "beginner-crochet-01",
  "provider": "provider-name",
  "state": "not_tested",
  "prompt": "Which beginner crochet kits include video instruction?",
  "mentions": null,
  "citations": null
}

A visibility record cannot be manufactured from the readiness scan. It begins only when an external answer is attempted.

Provider failures require a third dimension

Use explicit states:

success_mention
success_no_mention
refused
rate_limited
timeout
provider_error
parser_error

Only completed success states enter the mention denominator. The dashboard must show completion rate beside visibility rate.

Interface consequence

The readiness screen should answer:

• what failed
• where it failed
• observed and expected values
• affected products
• Shopify repair location
• verification and rollback

The visibility screen should answer:

• what was asked
• when and where it was asked
• whether the run completed
• which brand and product appeared
• which source URL was visible
• whether facts were correct

A merchant can move from one to the other through a workflow, not a shared score.

Example merchant workflow

1. readiness scan finds The Woobles-style availability conflict
2. merchant repairs the Product offer owner
3. SkuWatch AI Visibility verifies sold-out and in-stock fixtures
4. the readiness finding changes from conflict to pass
5. scheduled buyer prompts continue unchanged
6. later observations are compared without claiming the repair controlled the provider

Product rule

SkuWatch AI Visibility may summarize within a measurement family, but it must not publish one number called “AI visibility” that combines storefront checks with external answers.

This design is less impressive in a sales screenshot. It is more useful when a merchant needs to decide what to change on Monday morning.