At a glance
Listings Failing Feedonomics Validation is a cross-channel card. It measures the percentage of your listings that fail validation inside the Feedonomics feed pipeline before they ever reach JD.com, which means they never go live. The feed sits between your BigCommerce (BC) source-of-truth and JD: it transforms BC product data into JD’s required format and runs validation rules (mandatory attributes present, price format valid, image URL reachable, category mapping resolved, hanzi title within length). A row that fails those rules is silently held back, so the SKU you think is selling on JD is not even listed. A rising failure rate is the leading indicator that new and updated products are quietly not making it to market.
| What it counts | The percentage of feed rows (listings) that fail Feedonomics validation in the pipeline that pushes BC data to JD.com, measured over the trailing 7 days. A failing row is held back and does not publish to JD. |
| Sample type | Cross-channel feed-pipeline data from Feedonomics validation logs, compared against the JD.com listing set, refreshed on the standard data refresh. |
| Why it matters | Failed rows never reach JD, so the product is invisible and earns nothing despite being live in BC. A climbing rate often means a new validation rule, a mapping change, or a bad bulk edit in BC is blocking a whole batch at once. |
| Reading the value | Read the rate against its baseline and group failures by reason. A spike concentrated on one failure reason is a single fixable rule; a broad rise across many reasons points at a feed configuration or category-mapping change. |
| Currency | percent |
| Time window | 7D |
| Alert trigger | >5% |
| Sentiment key | jd_xc_feed_rejection_vs_listings |
| Roles | owner, operations, engineering |
Calculation
Calculated automatically as failing feed rows divided by total feed rows over the trailing 7 days, expressed as a percentage. A row is “failing” when it does not pass Feedonomics validation and is therefore held back from publishing to JD.com. The card also exposes the dominant failure reasons so you can batch fixes. See the worked example below.Worked example
A representative reading of Listings Failing Feedonomics Validation for a cross-channel JD.com seller. The card shows 9.2 percent of feed rows failing over the 7 days to 23 Jun 26, well over the 5 percent threshold and up from a 2 percent baseline. Grouping by reason, 80 percent of the failures share one cause: a category remap on 18 Jun 26 left the JD mandatory attribute “net content / specification” unmapped for the whole personal-care category, so every new and updated SKU in that category is being held back. Those products are live in BC but invisible on JD. This is one fix, not hundreds: restore the attribute mapping and the held batch republishes on the next feed run. Use Vortex Mind to rank failure reasons by row count, and ask Ask Viq “what is the single biggest feed failure reason this week?” to find the one mapping to fix.Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
jdc_xc_catalogue_drift_vs_bc | Feed failures cause the drift; this is the upstream sibling. |
jdc_xc_listed_but_oos_on_bc | Stock-sync failures that the feed should have caught. |
jdc_attr_completeness | Missing mandatory attributes are the top feed-validation failure. |
jdc_total_listings | A stalled feed shows up as total listings failing to grow. |
jd_rejected_listings | Rows that pass the feed but JD still rejects at its own review. |
jdc_revenue_at_risk | Quantifies revenue lost to products held back from JD. |
Reconciling against the vendor’s own dashboard
Where to look in JD.com’s own dashboard: JD will not show these failures because the rows never reached JD - that is the point of the card. Reconcile in the Feedonomics dashboard instead: open the feed export log for the JD.com channel and review the validation errors and held-row count for the same 7-day window. The held-row percentage in Feedonomics should match this card. Then confirm in JD Seller Centre that the affected SKUs are genuinely absent rather than off-shelf for a JD-side reason. Why the Vortex IQ value may legitimately differ:| Reason | Direction | What to do |
|---|---|---|
| Window basis. Vortex IQ uses a 7-day rolling window; the Feedonomics log may default to last-run or last-24h. | Variable | Match the window in the Feedonomics log. |
| Warnings vs hard fails. Some Feedonomics rules warn but still publish; this card counts only hard fails that block publishing. | Vortex IQ lower | Filter the feed log to blocking errors only. |
| Retry success. A row that failed once but passed on retry within the window may net out as published. | Vortex IQ lower | Count distinct still-failing rows, not raw attempts. |