Singular vs Plural: The Mistake That Ruins Datasets

Full transcript

981 words · script draft, under review.

Intro

You build a keyword list from a template. One phrase, a thousand city names. Say, espresso machine repair shop in, and then the city. You pull the volumes, and almost everything comes back as zero. Conclusion: there's no demand. Project dead.

Except you picked the wrong form. Change one letter, singular to plural, and the same list shows clear demand in hundreds of cities.

I've seen this happen on a real dataset of my own. One letter can decide whether a project looks promising or worthless. In this episode: why it happens, how to catch it before it costs you, and the one small test I now run before every big pull.

Two forms, two possible outcomes

Here are two pairs from our fictional coffee equipment shop, with made-up numbers for illustration. When you ask for both forms of a keyword, one of two things happens.

Outcome one: both come back with exactly the same number. That's Google telling you it treats them as one synonym group. Same searches, reported twice. Which form you use doesn't matter for volume. But you must never add them together. Two times thirteen hundred is not twenty-six hundred. It's thirteen hundred, shown twice.

Outcome two: the numbers differ, sometimes by a factor of five or ten. Now Google sees them as separate keywords, and one form clearly carries the demand. If your dataset is built on the weak form, every row is understated, and the whole picture is wrong.

The tricky part is that you can't guess which outcome you'll get. It changes from phrase to phrase.

It changes with the location too

It gets worse. The winning form can change with the geographic level.

At national level, people might search mostly in the plural: "espresso machine repair shops", looking for options. At state or city level, the singular might win, or the two might be grouped. I've seen the winning form flip between national and state level in my own data.

So don't validate on one level and assume it holds on another. If your dataset is a template across many locations, validate at the level you're actually going to build for.

Why this ruins whole datasets

A single keyword in the wrong form is a small error. A template in the wrong form is a systematic error. Every row inherits it.

And systematic errors are hard to see. Random errors look like noise. A systematic error looks like a fact. A thousand rows of low volumes don't look broken. They look like a weak market.

There are warning signs, though. Almost every row lands on the lowest buckets. Volumes barely change between a small town and a big city. Or the head term has healthy volume while every templated variant is near zero. When you see that pattern, suspect the form before you suspect the market.

There's a second way it ruins datasets: summing. If you pull both forms to be safe, and then add them per city, every grouped pair is double counted. Now your market looks twice as big as it is. Either way, the decision you make from the data is wrong.

The validation task

The fix is cheap. Before any big pull, run a validation task.

Take a random sample from your list. Thirty to fifty rows is enough. Spread them across small and large locations. For each row, create both forms. Send them all in one Google Ads search volume task. That's one task, about nine cents.

Then compare row by row. Count three things. How often the two forms are identical, meaning grouped. How often singular wins. How often plural wins.

If one form wins clearly, use it for the whole run. If most pairs are grouped, either form works, and you pull only one. If it's mixed, you need both forms in the big pull, and a rule for combining them.

Running it in code

In code it's a short script. Read your template, draw a random sample of locations, build both forms for each, send one task, and write a comparison table to your database.

Two practical traps here. First, location names. Templates often produce things like a city name, a comma, then a state code. The Google Ads endpoint rejects any keyword with a comma, and one bad keyword fails the whole task. So clean the names first: drop the comma, or drop the state part if your location setting already covers it.

Second, keep the sample random. If you only test the big cities, you're testing the rows that are most likely to have volume in both forms. The small places are where the measurement floor bites, and where the wrong form turns real demand into zeros.

Save the raw response in your cache folder. When you make the decision, you want to be able to show what it was based on.

The combining rule

Here's the rule I use when I have both forms.

If the volumes are equal, it's one group. Take the value once.

If they differ, take the higher one as the keyword's volume, and store the other form as a variant of the same row. Don't add them. Even when they're reported separately, there's usually overlap in who's searching, and the data can't tell you how much. Taking the maximum is conservative and honest.

Store the form you chose in its own column. Six months later, when someone asks why a number looks low, you'll know exactly what was measured.

Other near-twins to test

Singular and plural is the most common case, but the same logic applies to other near-twins. With or without "near me". Different word order. With or without a hyphen. An abbreviation versus the full name.

The method is the same for all of them. Small sample, both versions, one task, compare. Then decide, and write the decision down.

Wrap-up

Validate the form before the big pull, and never sum equal volumes. The validation script and decision sheet are linked in the description. Next episode: classifying search intent for thousands of keywords, fast. See you there.