Naver Place Review Monitor — New Reviews to CSV

Monitor public Naver Place pages (restaurants, cafés, salons, shops) across up to 10 locations. The first run emits a baseline of each place's recent visitor reviews; later runs emit only newly observed reviews for the same monitor key, so you can export a spreadsheet of just the new reviews instead of the whole review list again.

Built for people who already check Naver Place reviews regularly — e.g. agencies or operators consolidating reviews for several stores into one report.

How it works

1. You provide up to 10 public Naver Place URLs and a monitor key (any name you choose, e.g. client-a-weekly).
2. Run 1 observes each place's recent reviews and writes rows labelled baseline.
3. Run 2+ compares against the reviews this monitor key has already observed and writes only rows labelled newly_observed.
4. Review rows go to the run's dataset (exportable as CSV/JSON/Excel). A per-place run summary is written to the key-value store under OUTPUT.

newly_observed means not seen before by this monitor key — it does not guarantee the review was written recently. A bounded scan can miss reviews; see limits below.

Input

Field	Type	Description
placeUrls	string array	1–10 public Naver Place URLs: m.place.naver.com/<type>/<id>/..., pcmap.place.naver.com/..., map.naver.com/.../place/<id>, or a bare numeric Place ID. Unsupported entries are reported per place (status invalid_url) without failing the run.
monitorKey	string	Stable identifier for this monitored collection (letters, digits, ., -, _; max 100 chars). State is kept separately per key and per user account.
maxReviewsPerPlace	integer	How many of each place's most recent reviews to scan per run (1–200, default 50). Keep it comfortably above the number of reviews that can accumulate between runs, or older missed reviews fall out of the window.
resetBaseline	boolean	Opt-in: forget retained history for the places in this run and emit a fresh baseline.

Output

Dataset fields (one row per review)

Field	Meaning
placeId	Stable Naver Place identifier
businessName	Business name when exposed by the source; otherwise null
reviewId	Stable Naver review identifier
text	Original review text; null for rating-only reviews
publishedAt	Publication date as exposed by Naver, kept raw — often a yearless display string like 10.13.화; otherwise null
visitedAt	Visit date (ISO) when exposed, kept separate from publication date; otherwise null
sourceUrl	Public review page URL for the place
observedAt	Collection timestamp (UTC)
recordType	baseline or newly_observed

Nothing is fabricated: when Naver does not expose a value, the field stays null.

Run summary (key-value store, key OUTPUT)

Per place: status, scanned, emittedBaseline, emittedNew, duplicatesPreviousRuns, duplicatesInRun, capReached, totalAvailable, requests, elapsedMs, and an error message when something went wrong. Statuses are distinct:

• ok — worked (with capReached: true if the scan cap ended the run before the window did)
• empty — genuinely no reviews returned
• blocked — Naver rate-limited or refused (HTTP 401/403/429)
• failed — network error, error response, or malformed body
• invalid_url — URL not recognized as a Naver Place URL
• busy — another run currently holds the lock for this monitor key

Example outputs

See sample-outputs/ for a real (live, 2026-10-14) baseline summary, the identical second run (0 new rows), and a 3-row sample of the review dataset.

Deduplication state and limits

• State lives in a named key-value store (naver-place-review-monitor-state), retained across runs and kept per user account.
• Per place, the monitor retains the most recent 500 observed review IDs. Deduplication only covers that retained history.
• Rows are pushed to the dataset before their IDs are recorded; state only advances for rows that were saved. If a run dies between the two, those rows can be re-emitted on the next run (at-least-once), but unexported reviews are never falsely marked as seen.
• Concurrent runs of the same monitor key are serialized with a lock record; the later run exits with busy rather than racing. The KV store has no compare-and-set, so the lock is best-effort (documented residual race).
• Review edits and deletions are not tracked. Historical backfill beyond maxReviewsPerPlace is not provided.

Honest limitations

• Collects only what public Naver Place pages expose; no login-only data, and no attempt to bypass access controls. If Naver changes or blocks the endpoint, runs report blocked/failed honestly.
• Polling costs apply on every run, including runs with zero new reviews — keep schedules modest.
• Review counts and windows are Naver's; totalAvailable may exceed what your cap scans.
• Naver Place review pages are public but rates are not infinite: requests are paced (~1/second) and retried with backoff.

Local development

cd actor
uv venv .venv --python 3.14 && source .venv/bin/activate
uv pip install -r requirements.txt

# deterministic offline verification (59 checks, no network)
python tests/verify_actor.py

# local live run (writes to ./storage)
apify run -i '{"placeUrls":["https://m.place.naver.com/restaurant/832363546/review/visitor"],"monitorKey":"my-monitor","maxReviewsPerPlace":10}'

On the Apify platform, review rows appear in the run's Output → dataset tab (any run of this Actor has its own dataset — export CSV there), and the run summary appears in the key-value store under OUTPUT.

Support

Questions, bug reports, and feature requests go through the Issues tab on this Actor's page on Apify Store. When reporting a collection problem, include the run ID and the run summary (key-value store OUTPUT) — it lists each place's exact status and error, which makes problems diagnosable without extra back-and-forth.

Pricing

Not yet set. See the project plan — pricing will be based on measured polling costs (including no-new-review runs), with any minimum charge or platform usage fee made explicit in the listing.