Enter a search term such as “mobile analytics” or browse our content using the filters above.
Check your spelling or try broadening your search.
Sorry about this, there is a problem with our search at the moment.
Please try again later.
Whether 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...