This is the field reference for a Naver Place record, with coverage measured on 3,295 businesses across 8 verticals and 8 regions. The unusual part of this dataset is not the fill rates but the fields that do not exist at all for certain verticals — which is a different thing from a field being empty.
How to read this reference
A percentage is a measured fill rate. “At least 90%” means the field cleared that bar in every vertical measured, which is a stronger statement than a single average. The key is always present in the row with an explicit null, so a parser never has to distinguish absent from empty.
Identity and category
| Field | Filled | Notes |
|---|---|---|
place_id | 100% | Naver's identifier. The join key across runs and entity types. |
name | ≥90% | Business name in Korean. |
category | ≥90% | Translated, with the Korean original kept alongside. |
region | ≥90% | The region the business is actually in — what the padding filter acts on. |
place_url | 100% | Public Naver Place URL. |
The category is translated because a category is a description, and the Korean original is kept because a translation is an interpretation. Same rule as the `*_raw` fields on coches.net.
Contact, and the relay number
phone averages 88% across verticals and falls to 37% in the worst measured — pharmacies. So a call list built on this field is vertical-dependent in a way that a single headline number would hide.
More importantly, phone_is_virtual says whether the number is Naver's 0507 relay rather than the business's own line. Between 37% and 87% of businesses publish only the relay — what that means in practice.
Location, and two address systems
Korea runs two addressing systems side by side: the newer road-name system and the older lot-based jibun system. Naver publishes both, so both are returned — road_address and full_address — along with latitude and longitude.
Reputation aggregates
With includeReputation on, each business carries Naver's own aggregates: average rating, the distribution across ten star bands, review and reviewer counts, image-review count, and Naver's theme analysis with counts. It costs one detail request per business, billed at $0.0008.
Why these are cheaper than deriving the same thing from reviews.
Review rows
A review row carries review_id, rating, body, visited_at, is_receipt_verified, photos and videos. It carries no reviewer identity — no nickname, no account id, no history link — and a build-time test enforces that at any depth of the row. The reasoning.
is_receipt_verified is the quality signal worth filtering on: Naver checked that the reviewer actually transacted.
Fields that depend on the vertical
| Field | Where it appears |
|---|---|
visitor_review_score | Absent for clinics, academies and pharmacies — Naver computes none. |
micro_review | Restaurants and cafés only. |
save_count | Restaurants and cafés only. |
price, currency | Menu items, so restaurants and cafés in practice. |
This is the distinction that matters most in this dataset: a null rating on a dentist is not missing data, it is data that does not exist. Treating it as zero produces a table where every clinic in Korea is rated 0.0 — technically a null-handling bug, practically a libel of an entire vertical.
Freshness metadata, and what it says today
Every row carries from_cache, fetched_at and data_age_hours. Today they read false, null and null: every row is fetched fresh, because shared caching is designed and not switched on.
The fields exist now so that when caching is enabled, a cached row can never be presented as a fresh one — the general argument. Shipping the fields before the feature is the cheap half of that decision.
