At a glance
Brand-Authorisation Coverage is the percentage of your restricted-category JD.com listings that hold a valid brand authorisation. JD gates many categories behind brand qualification: to sell a branded product you must hold authorisation documents proving you are entitled to list that brand, and listings without valid authorisation are blocked at the next JD audit. A coverage gap is a queue of listings waiting to be pulled. This hero gauge tells executives and operations in one number how protected the restricted slice of the catalogue is, and feeds directly into the account-health tripwire.
| What it counts | The percentage of active restricted-category listings that have a valid, in-date brand authorisation on file. |
| Sample type | Real-time evaluation from the JD.com integration, matching restricted-category listings against held brand-authorisation records. |
| Why it matters | Listings without valid authorisation are blocked at JD audits, removed from sale, and can put the whole account-health score at risk. Coverage is a leading indicator of audit exposure and directly drives one pillar of the account-health alert. |
| Reading the value | Higher is better; 100% means every restricted-category listing is authorised. Below the 98% safe band, a slice of the catalogue is exposed and should be remediated before the next audit. |
| Currency | percent |
| Time window | RT |
| Alert trigger | <98% of restricted-cat listings |
| Sentiment key | jd_brand_auth_coverage |
| Roles | owner, operations, finance |
Calculation
The denominator is the count of active listings that sit in a JD restricted (brand-gated) category. The numerator is the subset of those listings that map to a brand for which you hold a valid, in-date authorisation record. The gauge value is:coverage % = (restricted-category listings with valid authorisation / total restricted-category listings) x 100
Listings in unrestricted categories are excluded from both numerator and denominator, because they do not require authorisation. An authorisation that has expired no longer counts toward the numerator, so coverage falls automatically as authorisations lapse, even with no change to the catalogue.
Worked example
A representative reading for a POP marketplace seller on JD.com. On 17 Mar 26 the gauge reads 96.4%, below the 98% safe band, and the account-health tripwire is flagging this pillar. Of 500 restricted-category listings, 18 lack valid authorisation. Drilling in shows two causes: 12 listings belong to a brand whose authorisation expired on 15 Mar 26 and was not renewed, and 6 are newly added listings for a brand never authorised in the first place. The fix splits accordingly: renew the lapsed authorisation to restore the 12 listings, and for the 6 unauthorised listings either obtain authorisation for the brand or remove the listings. After renewing on 18 Mar 26 and removing the 6 unauthorised listings, coverage rises to 100% and the account-health pillar clears. To get ahead of the next lapse, pair this with the expiring-authorisations card; to ask which brands are closest to expiry in plain English, use Ask Viq. To trace which audit window the exposure falls into, use Vortex Mind.Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
jd_expiring_brand_auths | Early warning before authorisations lapse and coverage drops. |
jd_account_health | The tripwire that fires when coverage falls below 98%. |
jd_off_shelf_24h | Removals that authorisation gaps trigger at audit. |
jd_attribute_completeness | The other major compliance gauge on listing health. |
jd_shop_health | The composite shop-health score coverage contributes to. |
Reconciling against the vendor’s own dashboard
Where to look in JD.com’s own dashboard: JD shows held brand qualifications and category permissions in the brand-authorisation / qualification management area, and flags listings lacking permission in the product-management view. Reconcile by checking that the brands the card counts as authorised match the valid, in-date qualifications JD lists, and that the restricted-category set matches JD’s gated categories. Why the Vortex IQ value may legitimately differ:| Reason | Direction | What to do |
|---|---|---|
| Expiry timing. Vortex IQ drops an authorisation from the numerator the moment it expires; the vendor view may show a grace period. | Vortex IQ lower | Confirm JD’s effective expiry, including any grace period. |
| Category scope. Which categories count as restricted may differ between the profile and JD’s current gated list. | Variable | Align the restricted-category definition. |
| Authorisation sync. A newly approved authorisation may not have synced when Vortex IQ refreshed. | Vortex IQ lower | Allow for authorisation-sync lag, then refresh. |