Audit every retailer listing
Track listing corrections
Keep a running log of every listing error you report, who controls that listing, when you asked, and whether it was fixed, so corrections do not vanish into email.
Why it matters
Corrections take weeks and pass through people who are not thinking about your book. Without a log, the same error is reported twice, or never followed up, or sent to a party that cannot fix it. With one, you can see what is outstanding, follow up politely, and stop re-learning who controls the Kobo listing.
Your part
- What you do
- Do it. You normally do this yourself.
- Who normally owns it
- Author. Author keeps the log; publisher, platform, or library makes the fix
- When
- Ongoing, from the first correction request onward (Audit every retailer listing: three months before publication, in launch week, and at each later audit)
How to do it
The full walkthrough
Every listing your book has is controlled by someone, and it is rarely the site you see it on. Amazon's print data comes from the publisher's feed or a print-on-demand platform; Google Books data from Partner Center or a library; WorldCat records from a cataloging library; Goodreads from its librarians. Reporting an error to the wrong party wastes weeks, and reporting it to the right party without writing it down means it is forgotten by both sides.
The log is a table: the listing (site and format), the error, the correct value, the party that controls it, the date you asked, how you asked, and the outcome with its date. Over time it becomes a map of who controls what for your book, which is worth more than any single fix, because the next error goes to the right place on the first try.
Who the rows name depends on your route, and that is the point of keeping them. At a publisher most rows will name the publisher, which lets you send one consolidated request instead of a trickle. On a hybrid contract they split between the press, its platform, and you. When you are the publisher most rows name you, and the useful column is which platform each fix went through and when it appeared.
Keep it for the life of the book. Errors reappear when data sources refresh.
Common mistakes
- Reporting an error and not writing it down.
- Sending the same correction to the retailer, the publisher, and the platform at once, and confusing all three.
- Assuming a fix is permanent; data refreshes can reintroduce errors.
- Not recording how the fix was made, so the next person cannot repeat it.
Identifiers for Track listing corrections
Set a status on any record and it joins this step. All book identifiers.
| My status | Identifier | Why this matters | Yours |
|---|---|---|---|
| ONIX for Books ONline Information eXchange: the standard file that carries your book's details from your publisher or platform out to retailers and libraries. | If your subtitle is wrong at one retailer, that is one mistake; if it is wrong at a retailer, in a library catalog, and on Google Books, that is usually not three mistakes but one, in the feed, copied three times. It also explains why correcting it in one store often does not stick, because the next feed writes the old value back over your correction. Nobody acts on the feed directly: traditionally and hybrid published authors normally find out who owns it, which is the publisher's metadata or operations team and sometimes a separate distributor, and send corrections there, while a self-published book's feed is generated by the platform from the fields you filled in on its dashboard. Find the person or team that owns the book's feed so a correction goes to the source that can keep it fixed. | Nothing to record |
Templates for this
Metadata correction requestA precise correction request that names the field, the current value, the correct value, and where the error appears, sent to whoever controls the master record.
When to use it: Use this when a detail about the book is wrong in a retailer, library, or database record and the error comes from the publisher's or distributor's metadata feed. Send it to the party that controls the source record. Do not use this when you control the source record yourself. Fix it in the distributor or platform dashboard first, and write only about what the dashboard will not change.
Retailer listing correction requestA clear request to a retailer's support team to fix one error on a product page, with the exact field, current value, correct value, and who supplies the listing data.
When to use it: Use this when a retailer's product page shows something wrong that you cannot change yourself, and you have already told the party that controls the metadata feed. Paste it into the retailer's author or publisher support form where one exists. Do not use this when you control the listing through a self-publishing dashboard. Change it there first; support can only help with what the dashboard will not let you edit.
What done looks like
- One table listing every correction requested, with listing, error, correct value, controlling party, date, method, and outcome.
- The controlling party for each major listing recorded even when nothing is wrong yet.
- Follow-up dates set for requests with no response.
- Consolidated requests sent to each party rather than one message per error.
- The log kept alongside the Book Identity Sheet.
Sources and last checked
- Official source
- No single official page for this step.
- Last checked
- Not checked against its source yet.
- How confident we are
- Verified