Ask Naver for dentists in 역삼동. It reports 638 matches. It serves 300 results. One hundred and sixty-two of them are in 역삼동. The rest are neighbouring areas, and nothing in the response says so.
The finding
Naver Place pads its search responses with businesses located outside the area requested. The padding arrives with HTTP 200, no flag, no separate section — it is indistinguishable from a real result unless you check the address yourself.
| Query | Reported | Served | In area |
|---|---|---|---|
역삼동 치과 | 638 | 300 | 162 |
율현동 치과 | 52 | 52 | 2 |
How it was measured
Ten queries, across districts of different sizes. For each one: what Naver reported as the match count, how many results it actually served, and how many of those carried an address inside the requested area. The last number is the only one that describes the district.
Small districts are almost all padding
This is the part that should change how you plan a run. In 역삼동 — a dense commercial district — 54% of served results were local. In 율현동, a small residential one, 2 of 52 were. Naver served a full page because it had a page to fill, and 96% of it was elsewhere.
So the padding ratio is not a constant you can correct for. It is a function of how much inventory the district actually has, which is the thing you were trying to measure.
Why Naver does it
Because for its actual user it is the right behaviour. Somebody looking for a dentist in a small neighbourhood wants the one two stops away rather than an empty page, and Naver is a consumer product, not a data API.
The same logic produces Nextdoor's distance-ordered directory, which serves the requested city and then keeps going. In both cases the behaviour is defensible and the silence about it is the problem.
What it does to a dataset
Three failures, in increasing order of how long they go unnoticed:
- Wrong geography. “Dentists in 역삼동” that is 46% not in 역삼동.
- Inflated market size. Quote the reported 638 and you have overstated a district's dentist count by a factor of four.
- Double counting. Sweep ten adjacent districts and the same businesses appear in several result sets, so a naive union over-counts the region while under-covering it.
The filter, and what it reports
The Actor compares each business's own address against the requested region and drops the rest — which is why the region has to be named in the input. Then it says what it did:
"역삼동": 162 of 300 results are actually located in this area.
138 were padding from neighbouring areas and were dropped.
Naver reports 638 matches for this query, but that count includes
out-of-area padding and is not an inventory figure.Dropped rows are not charged, because they were never delivered. The reason the count is printed rather than silently applied is that how much was padding is itself the interesting number: it tells you whether the district is dense or nearly empty.
Working with the corrected numbers
- Report the in-area count, never Naver's match count, and say which you used.
- Treat a high padding ratio as a finding. 96% padding means that district has almost no supply in that category — which is a market gap, stated in data.
- Deduplicate by
place_idwhen sweeping adjacent districts, since the same business legitimately appears in several searches. - If a query returns 300 in-area results, split it. You hit the ceiling, not the end of the market.
