Google Merchant Feed – Secret Rejection Policies Offer an Important Lesson to Programmers

Posted In: Google Merchant Center

If you are not yet familiar with Google’s suite of promotional products, the Merchant Center is the merchant’s product data management portal.  Once product data exists in the Merchant Center, we can set up a campaign in Google Adwords that will display items in the Google “Shopping” tab.

Google uses a variety of rules to ensure their customers have a positive shopping experience, including rules about which products they will promote.  Most of the rules are completely logical, and their high-quality reporting tools make it easy to identify and fix errors.  The support we receive is consistently high quality, and we highly recommend this product suite to our customers.

What’s the big secret?

Given our consistently positive experience with the Google Merchant Center, it was puzzling when we were unable to determine why one of the classic detective novels offered by Zephyr Books had been automatically rejected for a policy violation.  The title (“The Lady in the Lake”) is un-offensive, the book cover image is innocuous, and the author is well-known.  All of the data for the item is accurate and populated according to policy as far as we can see.  There are other copies of the item available through Google Shopping, so the book itself is not problematic. Even after a 45-minute chat and several email exchanges with the support team, we were unable to figure out what policy the item violates.  In the first follow-up email I received following the chat, the customer service representative said it doesn’t follow a policy that “we cannot disclose” – a secret policy!  Really?  This is a first!

In the next exchange, they re-iterated a hint that they’d first offered in our chat – the policy might have something to do with the word “spine” (in the description of a used book) being interpreted as a medical word.  In our case, the gilt wording on the spine and the slightly bent spine are critical parts of the item description, and don’t reference anything medical.  Obviously, if the secret policy has to do with anatomical spines, this rejection was inaccurate; I thought there must be a way for a human to intervene and fix the problem.

The only solution offered was to “guess and check” which combination of words might be causing the rejection and edit the item accordingly.  This feed is automatically generated every night, and the word “spine” is used several times in the product (as it is in many of our other products). Frustrated with the secrecy and a solution that I felt was ridiculous, I requested escalation, and the second tier service representative I spoke with, although just as kind and polite as the first, was no more able to offer a solution.  Apparently, there is no manual override for ‘secret policy’ type automated rejections.  From the second-tier rep who tried to help me out:  “….we understand that this is an issue affecting your account, as well as other accounts and that our technical & engineering teams are diligently working on providing a fix for these sorts of issues. However, at this point, I do not have an expected date by which the issue will be resolved…”

Zephyr Books has over 1000 books, so one rejection isn’t a make-or-break deal. For now, the inaccurately rejected item will not be available through Google Shopping (though it will continue to be available on the Zephyr Books site).  It’s an annoying bump in the road – with the silver lining that this interaction offers us some lessons to keep in mind when we’re doing our own programming.

Things we can learn from Google’s secret rejection policy

  1. Every automated decision should have a manual override.
    I am completely surprised that Google forgot this critical element of programming.  We’re all human, even programmers.  Sometimes, algorithms fail when they encounter novel data.  These situations are always frustrating, but building a manual override at the same time as we build the automation allows us to more effectively support our customers when something unexpected happens.
  2. Customer support teams need to be empowered to be effective.
    The poor support team member who was trying to help me deal with my automated rejections wasn’t even allowed to tell me what policy I was failing to follow, and nobody on the team that I interacted with had the power to fix my issue.  After a significant time investment, both on my part and on the part of the support team, the issue is completely unresolved.  An empowered support team can describe what’s causing the problem and describe the process for addressing it (if they can’t just fix it right away).
  3. Put people first.
    Our systems are a tool that should empower the people using them. When we put people first, from the initial design to the final product, we have systems that give people the information they need and the power to make a difference.  This is the reason we are programmers – we are here to make the world a better place!

If you are ready to start publishing your products to Google’s shopping feed, but aren’t sure where to start, Comment Coders are standing by to help.  Reach out to us today for a quote.


Post Tags: lessons learned

No Comments »

Leave a Reply

Your email address will not be published. Required fields are marked *