Tuesday, May 22, 2007

Amazon's Descriptive Content

Ok, well, now I've been told by two people that they actually read this, so I better get moving...

About six weeks or so ago, we discovered an interesting issue when we send data to Amazon. The issue is related to updating descriptive content (such as Book Descriptions, Author Bio's, etc.).

First, some background. Amazon uses the ONIX files we send them in two separate processes. The first, is what they call the bibliographic update, and the second is the descriptive copy update. Bibliograhic information - for the purposes of this entry - refers to Title, Author, price, status, Publisher, trim size, etc. This is an important distinction to make as I wouldn't want anyone to walk away from reading this thinking that the problem is bigger than it really is.

What we have found, however, is that if a Publisher changes it's Distributor (ie. vendor of record), then the Descriptive content (ONLY) cannot be updated automatically via ONIX records anymore. This is a big problem now that so many publishers have shifted distributors in the recent past.

We found this problem when several of our customers complained (independently of one another) that when they uploaded new descriptions to us, they weren't showing up on Amazon's website. Tracking through these problems and discussing them with Amazon's catalog department, only gave us the answer that these titles would have to be updated manually through the online form.

This problem has probably been around for a very long time, but it has flown under the radar - until now. Why? Because, one, publishers didn't move around very much. And, if they did, that distributor did not send data to Amazon via ONIX. Second, how often do book descriptions change after the book has been published? Not too often, but when they do, it is usually for a reason that there is some type of new publicity associated with the title, like a big endorsement, or movie tie-in. So, handling these one-offs through the catalog department was a manageable alternative to fixing the system.

But now, it's not. This is a conundrum for the publisher on three fronts:

First, publishers (at least those who use our services... plug, plug) have never had to worry about which titles they updated before. They just updated the information in the database and went about their business. The systems did the rest - identifying which titles have been changed, and which needed to be resent out to the trade via ONIX. Now, they need to track which titles have come from publishers who were distributed by someone else previously, and keep track of precisely what change was made to the record.

Second, once a publisher uses the online form to make a change to a title, that title is given a status in Amazon's systems saying it was manually updated. Amazon considers that a 'sticky' change. In other words, once a title is changed manually, nothing on that title can be changed except through the online form. So, that means that what was a descriptive copy problem now becomes a bibliographic data problem as well. So, if a publisher updates the price of a book, and that title is 'stuck', then the price update will not go through (at Amazon).

Lastly, Amazon does not have any way to give us, or any publisher a listing of which titles they consider to be 'stuck'. The only way that we can find out is to query the catalog department on a case by case basis.

So, essentially we are left with a situation where we don't know whether our ONIX updates will update Amazon's site or not. This puts all the weight back on the publisher to check and see whether Amazon really updated the information. Some of our publishers send 2000 - 5000 changes a week! There is no way to check all that!

Emails to Amazon's people about this issue have gone unanswered and unacknowledged. Hopefully, as the questions start to flood into the catalog department, now that so many publishers have changed distributors in the past 6 weeks, they will see the problem as critical enough to address. Otherwise our friend in the catalog department - who is incredibly responsive, and helps us out tremendously - won't be able to get anything else done.

No comments: