Home About Experience Projects Case studies Resources Articles Briefs Playbook Tools FAQ How we start Security Get in touch

Research

Read the Picture, Not the Page

Product pages describe products badly. When a price study needs the size, the count and the package format, the package photo is the primary source and the page text is the fallback. When a fact is printed on the thing itself, look at the thing.

This sounds obvious. It was not obvious to me until a sheet full of "not shown" cells and a few wrong ones taught it. The fix took one rule and a column, and it is the same rule I now apply to any fact that lives on a physical object.

The moment: dozens of blanks, a few wrong answers

I was building a shelf-price snapshot: one row per product per store, with the regular price, any sale, the size, the piece count and the package format. The invented example I use on this site is trail mix, so picture rows like "Brand E Snack Packs, Store 1" and "Brand C Fruit Mix, Store 3."

The first pass filled size, count and format from the product page text. It read the title, the description and the little spec table, and copied what it found. The result looked tidy. It was not.

Dozens of cells came back as "not shown," because the page never said how many packs were inside or what kind of package it was. A few cells were simply wrong. One page described a pouch as a box. The package photo on that same page showed a stand-up pouch with a zip top, plainly. The front of the pack also printed the net weight and the pack count in large type. Every answer the text missed was sitting in the picture.

The first pass had only read text. Nobody had told it to look at the image, so it did not.

Why page text is a weak source

Product page text is written to sell, and it is often written once and reused. That creates a few predictable problems:

The package photo has none of these problems in the same way. The front of the pack is printed for the shelf. It has to state the net weight, and a multi-pack usually prints its count on the front because that is what a shopper scans for. The shape of the package is visible in the image: a pouch stands on a gusset and has soft edges, a box has flat panels and corners.

PACKAGE FRONT: THE SOURCEBRAND ESnack Packs6 PACKSNET WT 12 OZFormat: pouchgusset, soft edges, zip topCount: 6 packsprinted on the front badgeSize: 12 ozread from the net weight linePRODUCT PAGE TEXT: THE FALLBACKBrand E Snack PacksPackage: BoxWrong: the photo shows a pouchSize: 12 ozMatches the photoCount: not shownPhoto shows 6On the row: pouch, 12 oz, 6 packs.Source column says photo. Text only fills gaps.
Figure 1: size, count and format read from the package front. The page text called the pouch a box and left the count blank, so it only fills gaps the photo cannot.

What changed: the photo is the source

Every row was re-checked by opening the package image and reading the front of the pack. Size, count and format came from there. Page text became the fallback, used only when the photo did not show the fact.

I also added one column: the source of each of those three fields, written as "photo" or "text." It costs a few seconds per row. It means anyone reviewing the sheet can see at a glance which facts came from the thing itself and which came from a description of it.

The rules, written at the top of the sheet:

  1. Read size, count and format from the package photo first.
  2. Use the page text only when the photo does not show the fact.
  3. If the photo and the text disagree, the photo wins, and the disagreement goes in a note.
  4. If neither shows the fact, write "not shown." That is a valid answer, and it stays visible.
  5. Record the source of each field: photo or text.

Rule four matters. A blank that is honestly labeled is better than a guess. A guess looks exactly like a real value, and nobody will check it again.

How to read a package front

A few habits make the photo reading fast and reliable:

When the photo and the text disagree

Most disagreements are simple: the text is stale or generic, and the photo is right. Some are not. A photo can be older than the product. If the page text says 9 ounces and the photo on that page shows 10, the pack may have changed size and the image was never updated.

That is not something to settle quietly in a cell. Write what you see and ask the person who owns the study whether it is expected, with the page link attached. I wrote about that habit in A Flag Should Be a Question, Not a Decision. A checker that reads only text should never overwrite a value that came from the photo. That is exactly how a correct "pouch" becomes a wrong "box."

Why it matters for the price

Size, count and format are not side details in a price study. They are what make two rows comparable.

Price per ounce is the regular price divided by the size. Get the size wrong and every unit price on that row is wrong, and so is every average it feeds. Get the count wrong on a multi-pack and you compare a box of six to a single bag. Get the format wrong and you may put a product on the wrong part of the shelf in your summary.

So a fix to a size cell is not cosmetic. On a small sample it can move a store category's average enough to change what a reader concludes.

What goes wrong

The free shelf price normalizer takes rows like these, applies the regular and sale rules, and flags any row with no size so it cannot slip into an average. The full method, with the row template and the checklist, is in The Price Check Playbook (PDF).

The takeaway

When a fact is printed on the thing itself, look at the thing. For a price study, that means size, count and format come from the package photo, every row, every time.

Use the page text to fill gaps, never to overrule the picture. Label "not shown" honestly instead of guessing. Add a source column so anyone can see where each fact came from.

Read the picture, not the page. The package front is the source for size, count and format. Text is the fallback.

Paul Prado Pacardo is a Senior Executive Assistant and Operations professional with over ten years supporting C-level leaders, and the solo founder of a multi-product software studio. Available for remote Chief of Staff, Operations, Senior Executive Assistant and Project Manager roles.