I wrote this one myself, which makes it the first post on this blog not written entirely by ScribeGap's own engine. And while the banner at the bottom of this page is going to tell you that about this post too, it simply meant that i was a tad lazy and, decided I would rather get the update out than spend my evening editing a template.

What the feature used to do

Up until this week, the Write About My Own Ideas tab worked the way more or less every keyword tool works. You type a keyword in, ScribeGap checks it against live search data, and you get a row back with the monthly searches, a difficulty score, and the questions people ask around it. It is a perfectly reasonable feature if you already know which keyword you want. The trouble is that most of the people we built this for do not know, and would not especially want to spend an afternoon finding out.

The part that bothered me

Our homepage has been telling people they can type an idea in their own words. I wrote that line, and it was not true.

If you typed an actual sentence into the box, the kind of thing you would say out loud if a friend asked what you were working on, you got a blank back. Not an error, just nothing, because a sentence is not something people type into Google and there was nothing for us to measure it against. Which meant we were asking you to do the keyword research before you were allowed to use the keyword research tool. That is obviously backwards, and it had been live for months.

The first thing I tried, which was wrong

My first attempt was to ask our language model to suggest some real search phrases based on what you had written. It seemed like the obvious move. It is also a bad one, for a reason I probably should have seen sooner.

Models are genuinely good at working out what you meant. They are not databases. Asking one which phrases people type into Google is asking it to recall something it never stored in the first place, and what you get back instead is a set of phrases that sound completely plausible and do not exist. On one of our test runs it handed me eight suggestions and not a single one of them had any search volume behind it at all.

What happens now

So the job got split down the middle. The model does the understanding and Google does the remembering.

ScribeGap reads your description, pulls out a handful of candidate starting points, and then, before using any of them, checks each one against live search data to see which ones people are really searching. The ones with actual demand behind them get used to pull Google's own related searches, and that list is what you see on screen. Everything in it is a phrase real people type, because there is nowhere else it could have come from.

The difference on our own test cases was larger than I expected. A Bulgarian search for a folk dance club used to return two usable rows and now returns 97. A twenty six word sentence describing an article somebody wanted to write used to return nothing whatsoever, and now returns 197.

The one that actually made me sit up was Bulgarian. The word хора means both "people" and a kind of folk dance, and which one it is depends entirely on the sentence around it. The list came back full of dancing rather than demographics. No keyword matching rule was ever going to get that right, and that is precisely the part models are good at, which is why there is still a model in here at all.

One tidy-up we decided against

There is an obvious clean-up available that we deliberately did not do, and I want to explain it, because otherwise it reads as something we missed.

The list often holds phrases that are nearly identical. A singular and a plural. The same three words in a different order. The neat move is to fold those together so the list looks cleaner and every row feels distinct.

We do not, and the reason is that Google treats the two halves of this differently. Search volume gets grouped across close variants, so a singular and its plural will usually show you the same number. Difficulty does not get grouped at all. It is worked out against that exact phrase and whatever is actually sitting on its first page of results. In our own testing, "sourdough bread recipes" came back Medium, and the singular, "sourdough bread recipe", came back Hard. Same monthly searches. A meaningfully different amount of work to rank for.

Fold those two into one row and you have thrown away the only number that told them apart, and you have quietly picked one on the user's behalf without saying so. So near duplicates get grouped rather than merged. The list stays short enough to read, and you can open any row and see every wording underneath it with its own numbers.

What is still not right

There is one thing in here that is still wrong and I would rather say it than wait for somebody to find it.

I typed in a request for the best hiking trails in Sofia. There is almost no English language search demand for that, so what came back was a list about things to do in Sofia. Which is a truthful answer, in the sense that it accurately reflects what the data holds. It is also not what I asked for, and ScribeGap says nothing at all about the gap between the two. Somebody who asks about hiking ought to be told that the hiking half of their request had nothing behind it, rather than being handed the other half and left to work it out.

That is what I am fixing next.

Every number above came from our own test runs rather than a benchmark, and the sample is small. If you use this and something comes back looking wrong, tell me. Most of what got fixed this week was found exactly that way.