Clearing data rubbishWhether you’re in B2C or B2B,
product data influences buyer behaviour. The quality and clarity of your data
will influence the decision making success of website visitors.

Good decisions require high quality data. The more complex the purchase
decision, the higher the demand for detailed product information.

There is a direct cost to
poor product data; someone has to retroactively go back and make changes, which
can be incredibly time consuming.

In previous roles, I have spent long evenings
correcting data mistakes because it wasn’t done properly in the first place.
Not a good use of anyone’s time.

Error management is an essential
part of e-commerce because nothing is perfect. However, there is value to
reducing the volume of errors and the negative impact this has on e-commerce
teams, not to mention boredom thresholds.

Poor quality product data can lead
to several negative outcomes:

  • The user doesn’t think the product
    matches their needs.
  • The user doesn’t understand
    exactly what the product is/does.
  • The user can’t find the
    information they need and exits to another website to provide it.
  • The user makes a purchase
    based on inaccurate data and then is rightly vexed when what is delivered doesn’t
    stack up with expectations.

All of these potentially lead to
lost revenue, additional cost and negative word-of-mouth for your business.

I’ve worked with a lot of websites
over the years and a common headache is data inconsistency. This blog gives my
thoughts, borne from experience and mistakes, on the steps you can take to
improve the quality and consistency of your product data for your website(s).

I
am using the term “product data” to include all elements of data that are visible
to the customer on the website including copy, pricing, attributes and images.
Enjoy…

Step 1. Nailing down the process

Yawn, yawn. I said process. But
someone has to. It may be the ugly sister to sexy copywriting but without this
little beauty your product data consistency and integrity will be shot to
pieces.

The process for product data should
include the following:

  • Where the raw data comes from for
    new products.
  • How this data is reviewed and
    enriched for the web to make it web friendly/compatible.
  • Quality control criteria that have
    to be met for a product to be added to the web catalogue.
  • The escalation route for products
    that don’t satisfy these criteria.
  • The systems involved for getting
    data onto the website.
  • Timelines for regular, repeat
    actions such as weekly uploads.
  • How changes to existing products are
    handled.
  • The roles and responsibilities of
    everyone involved.
  • The check and control process for
    reviewing product data before it is uploaded to the live website.

To make this work, all people involved
must buy-in and commit to this process. That can result in a few ‘dolls out of
prams’ moments (e.g. “I’ve got better
things to do”) but these arguments are important to resolve upfront because
the cost of resolution later on is far higher.

In my experience, the owner of this process has to sit in the web team. The web team has responsibility for the quality of the website,
therefore it must take ownership of the data management process. 

A few pointers:

  • Nominate one person in the web team
    to be the guardian angel of product data.
  • Make sure they are fully trained on
    what is required and why so they can educate others in the business.
  • Train other departments involved in
    the process to understand the impact of poor quality (e.g. if you’re using product titles to auto-populate page titles for
    SEO, explain how this data supports search engine visibility).
  • Weave product data quality targets
    into people’s objectives and team goals (this can really sharpen focus if bonus
    payments are related to objectives and targets).

This isn’t meant to sound overly
authoritarian. In my experience you’ve got to get people to focus on the
implications of not taking this seriously because most people, left to their
own devices, don’t really understand the full impact of poor product data,
especially if they don’t have a digital background.

Step 2. Defining quality control criteria

This probably sounds grander that it
is. It involves defining what requirements your product data has to satisfy
before it’s allowed anywhere near the website. If you don’t have this in place,
how do you know that every product has the highest quality data? You don’t, or
at best it’s anecdotal and prone to assumption.

 A few pointers:

  • Clearly define what data elements
    are mandatory for new products e.g.
    Supplier code, ProductID, Product Title, Product description etc.
  • Define how the data needs to be
    provided, when and by whom.
  • If there are system imposed
    restrictions on data formats, make sure these are clearly communicated e.g. Product ID has to be alphanumeric and
    between eight and ten characters.
  • Where there are restrictions, look
    to use data validation to prevent errors getting on to the website e.g. if creating an Excel file and Product
    Title has to be 70 characters or less, add validation to data cells to flag an
    incorrect entry.
  • Be clear on the style and tone of
    the product copy required including the purpose of the product title and what
    information it must contain, this helps with consistency across the website.
  • For images, define the minimum
    requirement e.g. if you have product
    zoom, the minimum is the main web ready image + high resolution image for the
    zoom.

Below is an example of what I
consider poor quality product data. The product title is keyword poor and doesn’t
include sufficient information about the product contents. For example, the
product contains Vitamin B3 but you wouldn’t know this from the title.

This also reduces the accuracy of
site search results. A search for “food supplement” doesn’t return this product
even though the label quite clearly states “food supplement”.

Step 3. Making use of the QA environment

A common mistake, to save time, is to push products to the live website
without first checking how they look on a testing environment.

I’m not a fan of
this approach, for obvious reasons: once live, it’s too late to spot an error
because it’s likely other visitors have already seen it.

Hopefully, you will have invested in
a QA environment in which you can review all product uploads. You should use QA
to review new products and major changes to existing products (e.g. when the catalogue structure is changed
and the products are being re-categorised).

What are you looking for?

  • Has the product uploaded ok and is
    visible on the website?
  • If you run a search for the product
    name/ID, does the site search find it?
  • Is the product showing in the
    correct categories and under the relevant attribute refinements?
  • Does the product data display
    correctly in the product list pages?
  • On the product page itself, is all
    the data present and is it displaying correctly?
  • Does the product copy read well and
    is it clear what the product is/does?

There’s always an exception…

The exception to this is when you
make simple changes to existing product data to react to a short-term
requirement. In this situation, it’s acceptable to make the change without
first validating in QA.

A good example is a short-term price promotion for a
product to support a marketing campaign.

Step 4. Managing changes and amends

If a customer sends an enquiry about
a product that shows there is an error in the data, how is this managed? This
enquiry could come through an on-site Q&A or via Customer Services from
inbound emails and calls.

All teams involved should know who
to send these requests to and they need to be controlled to enable audit of
progress. Relying on emails is not great, a cluttered inbox can often lead to
urgent requests being missed.

A simple solution is a spreadsheet
on a shared network folder that uses a new tab for each month. Each new request
is added as a new row in the relevant tab, with details on who raised it, what
is required, the level of urgency and a deadline date if critical.

A nominated
person from the web team polices the spreadsheet and updates the website
according to the agreed process.

Step 5. Final sense check

Just because you did the QA work,
don’t assume the live deployment has been 100% accurate. Assumption is a
dangerous game with scripted deployments and database syncs.

Make sure somebody in the web team
is checking the products on the live website once the upload has happened.

Get
them to validate:

  • The correct images are showing and
    the zoom version works.
  • The product displays correctly in
    site search results and on product list pages.
  • The product title is correct.
  • The product short and long
    descriptions are displayed correctly.
  • The product is appearing in the
    right places on the website e.g. in the relevant categories and attribute
    refinements.
  • The products stock status is
    correct.

How do you handle product data?

I’d be interested to understand how you manage product data, so please drop by and add to the
discussion. If you don’t agree with something I’ve written, please let me know
why as I’m always open to suggestions and advice.

It’s now that with fevered brow I
frantically re-read this blog to make sure I’ve not left any glaring copy
errors that would enable pedants and ironists to goad and chastise me…