Facebook product feed errors: what the connector reports

Delivery on your catalog campaign thins out over a weekend. Nothing was changed. You ask Claude what happened to the feed, it pulls the upload history, and back comes a tidy table of runs: succeeded, succeeded, succeeded, and a column of numbers that do not quite add up.

The useful information is the arithmetic between two of those numbers. The thing most likely to be wrong is not in the table at all.

The upload history is a scoreboard

The tool that reads feed runs describes its own output plainly:

“Each session reports its outcome (status), timing (start/end), item counts (detected / persisted / invalid / deleted), and error/warning counts.”

Those map onto Meta's published node for a feed upload, which names them num_detected_items — “the number of items detected while reading the feed file” — then num_persisted_items, num_invalid_items, num_deleted_items, error_count and warning_count (Marketing API reference, read 2026-09-04).

Detected is what the parser saw in your file. Persisted is what survived into the catalog. The gap between them is your problem, and its size is the entire diagnosis available: no product ID, no reason attached to anything.

The severity split matters more than the totals, because Meta's own errors documentation says the two behave in opposite ways:

“Errors that are fatal mean those items are not created, while errors with a severity of warning are informational but items are created.”

So a warning is not a near miss. It is an item that went live with something wrong in it, and only fatal errors removed anything from your ads. Per-error detail — including the row and column numbers — lives on the errors edge, and the full report is a background job you run against one upload session, which writes a CSV. Neither is a tool on the connector.

Most of the work here is knowing which reply is silent about what, and the Claude Ads Operator course is built around exactly that — the readings that look like answers and are actually the shape of a missing field.

Three failures that look the same from the ad account

From where you sit — spend flat, products not showing — these are indistinguishable, they are answered by different tools, and only the first is a feed error at all.

The rule that fills in your blanks

Feed rules are transformations applied during ingestion, invisible from the ad account. Five kinds exist: mapping a column name onto a Meta attribute, translating values, changing letter case, running a regular-expression replace, and the one worth knowing about — the fallback. The schema's own example of it is the dangerous one:

“Sets a default value for a product field when the feed does not provide one. For example, setting a default availability of ‘in stock’ for products missing that field.”

Read that against a feed where the availability column goes blank for anything the warehouse system has not confirmed. Every one of those rows lands marked as in stock and every one becomes advertisable. Nothing in the upload counts flags it: the item was not invalid, it persisted correctly, and the rule did exactly what someone configured it to do while fixing a different problem.

One practical note. A rule's attribute and its type are fixed once created — only the parameters can be edited — so a rule pointed at the wrong column has to be deleted and rebuilt rather than corrected. Their advertiser-facing home is Commerce Manager, under Data Sources, then the feed, then Rules.

What to ask, in order

1. Get the feed IDs before anything else START HERE

   The upload-history and rules tools want a feed ID, and a catalog ID is not one. The schema says so outright and points you at the data-sources listing to resolve a catalog into its feeds. A catalog with several feeds will happily let you diagnose the healthy one. The trade: the feed listing loads expensive fields only when you name them, so the last upload and the schedules are absent from the default reply — ask for them, or you get a feed's identity without its behaviour.

2. Read several runs, not the last one

   The history comes back most recent first with a default cap. A feed set to pull hourly buries the run where things changed inside a day, and the run you want is the last one whose detected and persisted counts matched. The trade: the underlying file changed size between runs too, so a moving gap is a prompt to look, not proof on its own.

3. Force a refresh — if the feed can be refreshed

   There is a tool to trigger an immediate re-pull, and it is narrower than it sounds: it “only works for feeds that have a remote fetch URL configured”. A catalog filled by manual upload, by the batch endpoint, or by a store integration has nothing for it to fetch. The trade: concurrent runs are not supported. Fire it while one is going and it fails with an upload-already-in-progress error, and its schema has to tell the model not to retry immediately — which is what an eager assistant does otherwise.

• Reading zero fatal errors as a healthy feed. Warnings create the item anyway, so a clean run and a catalog of half-populated products are the same row in the history.
• Deleting a feed to stop it refreshing. Deleting removes the products it brought in, and the schema calls it permanent. Clearing the fetch schedule is the operation that means “stop pulling, keep everything”.
• Fixing the source file when a rule is doing the damage. You will correct the file, watch the run succeed, and see the same wrong value in the catalog.
• Letting a feed get created with the defaults. Created through the connector without a country or a currency, a feed is a US feed priced in dollars — a silent mismatch in every row if you sell anywhere else.

Try this tonight Pull your catalog's data sources, pick the feed with the most products, and read its last few upload sessions with one question: does detected equal persisted? If it does, the feed is fine and your missing products are a rules or a sync problem — read the rules list next. If it does not, that difference is your invalid count, and tonight's job is downloading the error report for that session in Commerce Manager, which names the row and column the connector will not.

The published guides to this — AdNabu, DataFeedWatch, GoDataFeed and the rest, checked 2026-09-04 — are Commerce Manager walkthroughs: here is the error string, here is the column to fix. Useful, and they assume the error report is already open. The connector's contribution comes earlier: it tells you in one question whether a feed run is your problem at all.