Resolve metadata corrections
Follow up on pending corrections
Keep a list of every listing error you have reported, who has it, and when you last asked, and check in every two weeks until each one is actually fixed on the public page.
Authors often hire help with this: metadata or distribution.
Why it matters
An error reported once and never checked stays an error. Most corrections fall through gaps between systems rather than through anyone's neglect, and a fortnightly check is the mechanism that catches them. It also builds a record: if the same error recurs, or the same retailer never updates, that is useful to know before the next book.
Your part
- What you do
- Monitor. Check again on a schedule, or after something changes.
- Who normally owns it
- Author and publisher together. Whoever owns the record corrects it; author tracks and follows up
- When
- Every two weeks until each reported item is resolved (Resolve metadata corrections: two to six weeks after each correction is reported)
How to do it
The full walkthrough
Corrections to book data travel slowly. A fix made in the publisher's system goes out in the next feed, is processed by each retailer on its own schedule, and may be overwritten by a stale feed from a different source. A correction reported to a platform support desk gets a ticket number and then waits. The only way to know a correction has landed is to look at the public page, and the only way to keep it moving is to ask again, politely, at intervals.
Keep a corrections list: what is wrong, where, who was told, on what date, any ticket or reference number, and the date of the last follow-up. Every two weeks, open each unresolved item's public page. If it is fixed, close it with the date. If it is not, send a short follow-up to the same person or ticket, referencing the original report.
Traditionally published authors follow up with the publisher contact who took the original report; the publisher in turn chases the retailer. Hybrid authors do the same. Self-published authors follow up with the platform's support desk, and with the aggregator if the error is at a third-party retailer.
Some corrections cannot be made: a retailer may refuse to change a field that comes from its own data source, or a library record may belong to a cataloger who has moved on. When that is the answer, record it and close the item as unresolvable rather than chasing forever.
Common mistakes
- Reporting an error and assuming it is fixed because someone said it would be.
- Following up daily, which produces no faster result and a worse relationship.
- Losing the ticket number and starting over each time.
- Continuing to chase a correction the retailer has already said it will not make.
A template 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.
What done looks like
- One list of every reported error with location, link, who was told, date, reference number, and last follow-up.
- A check of each unresolved item's public page every two weeks.
- One short follow-up per cycle to the same contact or ticket, referencing the original report.
- Items closed with the date fixed, or marked unresolvable with the reason.
- A summary of open items carried into the 30-day and 90-day audits.
Ask your publisher
Copy this into an email. Replace the bracketed parts with your details.
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