The Run Succeeded. Is the Shopify Catalog Complete?
Read the request, manifest and coverage evidence together before treating a successful Shopify actor run as a complete catalog.
A process can finish its requested work without collecting an entire catalog. That distinction matters when another system treats a successful run as permission to trust every absence in the output.
Use this diagnostic guide when reviewing a Shopify actor result. Its aim is to help you decide what the records support before calculating changes or handing a file to another team.
Start with the request
Save the source URLs, selected scopes, product limits and requested file formats. A collection URL and a store URL are different inputs even if the visible names sound similar.
If you asked for five products, five returned products can be a useful test result. It is not evidence that the source has only five products. Keep intentional limits attached to the output so downstream code does not have to guess.
The Shopify Product Scraper on Apify has its own input settings and charges, separate from the Catalog Prep Chrome extension. Use its current documentation rather than assuming browser-plan limits apply to the actor.
Read the records and report together
The actor's normalized dataset contains product records with nested variants and images. Its export files provide variant rows and a workbook separating Products, Variants, Images and Coverage.
Inspect the manifest, issues and coverage information alongside the data. A spreadsheet row count is useful, but it cannot explain why collection stopped or which requested source remained unavailable.
Check several identities against the source. Keep long IDs and literal SKUs as text, and count products separately from variants.
Classify the result by what you can establish
| Situation | Defensible interpretation | Next step |
|---|---|---|
| Requested limit reached | A bounded sample was collected | Use it as a sample or revise the input |
| Source denial or challenge | Access was unavailable under these conditions | Preserve the issue and review the source |
| Interrupted or resource-limited work | Useful partial observations may exist | Inspect retained progress and stopping evidence |
| Source field absent | That field was not available in the returned data | Keep it unknown or seek an authorized source |
| Observed end of the requested public scope | The checked processing scope ended | Still distinguish that scope from private catalog history |
Use the actual report values and warnings from your run. These rows describe interpretation categories, not a promise that every field or state has a particular schema name.
Inspect two common downstream mistakes
The first is converting missing records into removed products. If today's capture is limited or blocked, an absent identity may reflect collection rather than a source change.
The second is treating missing fields as default facts. Unknown currency is not automatically the page currency. A missing availability value is not automatically false. A repeated SKU is not necessarily a duplicate variant.
Keep unknowns visible in your working model, then choose a documented review or exclusion policy. It is easier to investigate a qualified observation than to reconstruct a silent assumption later.
Decide whether the result is fit for its purpose
A partial sample may be sufficient for checking field mappings or reviewing a handful of product options. It may be unsuitable for a broad product-removal alert.
Name the intended use and the evidence it requires. The snapshot comparison exercise shows how partial coverage changes the conclusions you can draw. For a comparison, record scope equivalence, identity behavior, currency context and coverage sufficiency. For a manual review, record which records the reviewer actually inspected.
This turns “complete enough” from an intuition into a decision someone else can understand.
Put the check into the integration
Retain the original dataset and files with their run identity and observation time. Route results with insufficient evidence to review before your comparison logic sends business conclusions.
Scheduling a saved task repeats collection. It does not automatically build those review branches or a historical comparator. Add them explicitly and test with a deliberately capped sample before relying on a larger pipeline.
Start with a small run in the Shopify Product Scraper. Explain the dataset and coverage information in a few sentences before connecting the result to another automated decision.