Merchant Feed Health Check

Orphex Merchant Feed Health Check

Review the supplied Merchant Center product data, destination-specific issues and matching website/checkout evidence. Eligibility issues and economic performance are different analyses.

With an Orphex connection

If an Orphex connector is available, check it before asking for exports. Run capability_search with platform orphex and limit 100; use a read only if that search returns its id, and ask which workspace to use when several are bound. Read controller.catalog then controller.fetch at level product for product cost and attributed revenue when exposure matters. Feed items and diagnostics are live Merchant Center reads: run capability_search with platform merchant_center and use platform_management.entities_read for product items and platform_management.opportunities_read for destination-specific issues, only when that search returns them. Then list guides with skill_catalog (kind guide, topic platform_reads) and follow a matching one through skill_read; choose by title, never by a stored id.

If a read is not returned, this connection cannot reach that Orphex data for the workspace: say so, then use the live platform reads it offers or the supplied exports. An absent, refused or empty read is not evidence of zero, none or healthy. Describe each read with capability_describe before run_read, keep date_end no later than yesterday, disclose request adjustments, and name each number's source, workspace and window. This skill's evidence rules still govern any guide, insight or playbook label, and no read authorizes account changes. Ask the user only for what is still missing.

Establish product identity and freshness

Record merchant scope, target country/language, destination, stable item/variant ID, feed source/update, diagnostic/crawl timestamp, and site/checkout observation time. An item can have different status across destinations; keep unique item-destination rows and their denominators explicit. Do not call a partial export a complete catalog audit. Preserve account-level versus item-level issues and statuses exactly as supplied.

Check mismatches in price/currency/tax convention, availability, variant, link, required identifiers and attributes, images, and source precedence only when supporting evidence is present. Conditional identifier/variant/shipping requirements depend on product, country and destination; check current official requirements rather than inventing blanket GTIN, image-size or title rules. Do not invent identifiers or change in-stock/out-of-stock to gain eligibility.

A site observation and an eligible status can conflict because timestamps or definitions differ. Verify the exact variant, checkout and data source before calling a live regression or failed correction. Actual source errors, unsupported observations, and pending verification should be distinct. Do not fetch or modify private merchant data without the requested access scope.

Approval is a recorded destination-specific status, not evidence of actual impressions, clicks, or active delivery. Do not describe an approved item as serving unavailable inventory without matched delivery evidence. Preserve a supplied stock or price mismatch as a repair finding while keeping exposure and business impact unknown when delivery rows are absent.

A common snapshot capture time does not establish when the feed was updated, the site was crawled, or eligibility diagnostics were processed. Do not exclude update, crawl, or processing lag merely because observations were captured together. Request the relevant state timestamps and item/destination identity, and distinguish the confirmed value mismatch from its unresolved synchronization mechanism. Recheck the processed source and diagnostics after repair before claiming closure.

Prioritize a repair queue

Rank actual disapprovals/limited eligibility, scope, business-provided importance, freshness and repair dependencies. Historical spend/revenue may describe exposure when correctly joined; it does not predict lost or recoverable sales. Feed coverage alone cannot explain a ROAS decline or prove incremental demand.

For each issue show item/destination, evidence, source of truth to inspect, proposed repair, owner if supplied, and recheck condition after update/crawl/diagnostics. Correct the upstream source rather than recommending conflicting manual edits blindly. Appeals, feed uploads, item exclusions and price/stock changes require explicit action scope. Finish with coverage limits and untested destinations.

Official references

• Merchant Center product data requirements
• Google product diagnostics

Portable inputs and examples

• Read the input contract when mapping a new export or checking the example's scope and definitions. Copy the header-only CSV template when preparing data; equivalent supplied exports remain acceptable.
• Read the reusable business context only for business facts or constraints this task needs. Reuse user-supplied facts with their source/date; the template contains no default targets.
• Inspect the complete fictional input with its example output when learning the output and calculation boundaries. Never use fictional values for a real account.

State whether the result is complete, partial, or blocked for the requested decision. Link material findings to actual supplied rows/sources and separate observed metrics, hypotheses, and estimates. Lead with a short business conclusion, then evidence, uncertainty, and the next measurable check. A data export or installed skill does not authorize account changes.