Six places, six versions of the same book
A new title is announced. Its details go into the distributor's system, the bibliographic data agency's portal, the ebook aggregator, the audiobook platform, your own website and the catalogue. Each wants the same things in slightly different forms: contributor names and biographies, a description of a set length, subject codes, trim size, extent, prices in several currencies, publication date and cover image.
Each is typed by whoever has time, from a Word document of copy that has been edited three times. Months later, the publication date changes and is updated in two places out of six. A retailer page shows the old description with a typo that was fixed long ago. The audio edition has no link to the print edition at all.
Why metadata drifts
There is no single record that everything else comes from. Each portal becomes its own source, and the Word document is the only thing they share.
- Portals have different field limits, so text is cut differently in each.
- Updates are made where someone notices the problem, not everywhere.
- Subject codes and audience codes are chosen afresh each time.
- Related editions (hardback, paperback, ebook, audio) are not linked consistently.
- Nobody can tell what was sent, when, and to whom.
Much of the text is written at different times by different people. The editor writes the first description, marketing rewrites it for the catalogue, and a sales rep shortens it for a buyer. Each version lands in whichever portal its author had open, and none of them is marked as the current one.
Why it matters beyond tidiness
| Metadata problem | Commercial effect |
|---|---|
| Wrong publication date | Pre-orders fail or the book appears unavailable |
| Weak or missing description | Fewer people buy from the retailer page |
| Poor subject codes | The book is hard to find in search and browse |
| Price mismatch | Retailers and your own site show different prices |
| Editions not linked | Reviews and ratings are split across editions |
Retailers and data agencies rely on your metadata to list and describe your books. Good data doesn't guarantee sales, but bad data reliably costs some.
One title record, many outputs
- A title record that holds every field once, with the full text of descriptions and shorter versions where recipients need them.
- Checks before anything is sent: ISBN check digits, required fields, field lengths, price and date formats, and a cover image of the right size.
- ONIX 3.0 output for recipients who take ONIX feeds, and the spreadsheet or portal format for those who do not.
- A send log per recipient, with the date and the exact content sent.
- Change handling: when a field changes, the system lists the recipients who need an update and sends it in the next feed once approved.
- A link to your website, so the book page is built from the same record.
If you already use a title management system that produces ONIX, we would not replace it. We may only build the pieces around it, such as validation reports or website feeds, and say so.
A new title, the week it is announced
The editor fills the record once, with help text on each field. The checks show that the description is too long for one recipient and that no audience code has been chosen. When it is ready, the publisher approves it, and it goes into the next feed to the distributor and the data agency, and onto your website. The audio edition is added later as a related product of the same work, so it links up.
When the publication date changes, it is changed once, the send list shows which recipients will receive it, and the log confirms it went.
Checklist: signs your metadata needs one home
- You type the same book details into more than two portals.
- Retailer pages show old descriptions or dates you corrected.
- You are not sure what data was last sent to your data agency.
- Your ebook and print editions are not linked at retailers.
- Subject codes are chosen differently each time.