Naver Brand Store Reviews Scraper & Monitor
Pricing
from $1.50 / 1,000 product checkeds
Naver Brand Store Reviews Scraper & Monitor
Monitor reviews across an entire Naver Brand Store from one URL. Discover every product automatically, build a baseline, and return only new reviews on later runs.
Pricing
from $1.50 / 1,000 product checkeds
Rating
0.0
(0)
Developer
OrbitData Labs
Maintained by CommunityActor stats
0
Bookmarked
2
Total users
1
Monthly active users
3 days ago
Last modified
Categories
Share
Unofficial tool. Not affiliated with, endorsed by, or sponsored by Naver.
Scrape and continuously monitor reviews across an entire Naver Brand Store from one store URL. No product URL lists and no manual dataset comparison.
Paste a store address such as https://brand.naver.com/dalba. The first run finds every
product in the store and collects a baseline of recent reviews. Every later run of the same
Task returns only the reviews that are new since the last run — ready for VOC analysis,
competitor review monitoring, sentiment pipelines, or a spreadsheet.
One Brand Store URL → every product → baseline reviews → only new reviews on later runs
The input form starts in snapshot mode, which returns a fresh snapshot of the latest reviews on every run. Snapshot mode is ideal for one-time scraping. Enable incremental monitoring for recurring runs that should return only newly added reviews.
What it does
- Finds every product in a Naver Brand Store from the store URL alone, including out-of-stock products and listings that the store page folds under another product.
- Collects Naver Brand Store reviews for each product with rating, text, option, date, photos, and seller replies, linked to the product and store they belong to.
- Builds a baseline on the first run. You choose how many recent reviews per product the baseline holds.
- Returns only new reviews on later runs. The Actor remembers where it stopped for each product, reads the newest reviews until it reaches a review it has already returned, and stops there.
- Keeps the state for you. You never pass a dataset ID, a date, or a list of known reviews. Run the same Task again and it continues.
Two modes: one-time scraping or continuous monitoring
One checkbox, Enable incremental monitoring (monitoringEnabled), picks the mode.
One-time review scraping — monitoring OFF
Brand Store URL → latest review snapshot
Every run discovers every product and returns up to maxReviewsPerProduct of the newest
reviews per product. Nothing is remembered between runs, so running it again returns a fresh
snapshot, not an empty dataset.
Good for one-off data collection, AI and sentiment datasets, competitor research, and review exports.
{"storeUrls": ["https://brand.naver.com/example"],"monitoringEnabled": false,"maxReviewsPerProduct": 100}
Continuous review monitoring — monitoring ON
Brand Store URL → baseline → later runs return NEW_REVIEW only
The first run builds a baseline. Every later run of the same Task returns only the reviews added since the previous monitoring run.
Good for scheduled competitor monitoring, VOC pipelines, new-review alerts, and recurring analytics.
Snapshot runs never read or change the monitoring state. If you switch a Task to snapshot for a run and back to monitoring later, the next monitoring run continues from the last monitoring run and returns every review added since then, including the ones your snapshot run already showed you.
Why this Actor is different
The usual way to monitor reviews on Naver takes several tools and manual steps:
Store → collect product URLs → paste them into a review scraper → save the dataset→ compare with the previous dataset → work out which reviews are new
A product review scraper needs a product URL list that you build and keep up to date. A catalog scraper lists products but does not collect reviews. Neither one remembers what you already have, so finding the new reviews stays your job.
With this Naver review monitor it is:
Store URL → Run → NEW_REVIEW records only, from the second run on
| Manual pipeline | This Actor | |
|---|---|---|
| Product list | You collect and update product URLs | Discovered automatically on every run |
| New products in the store | You notice and add them | Picked up automatically |
| Finding new reviews | You diff two datasets | Only new reviews are returned |
| State between runs | You store it | Kept per Task and store |
Input
| Field | Required | Default | Description |
|---|---|---|---|
storeUrls | yes | — | One or more Naver Brand Store URLs, e.g. https://brand.naver.com/dalba. Up to 5 stores per run. |
monitoringEnabled | no | true | ON: baseline first, then only new reviews. OFF: a fresh snapshot on every run. |
maxReviewsPerProduct | no | 100 | Reviews per product on the first run only in monitoring mode, or on every run in snapshot mode. From 1 to 30000. |
The input form on this page starts with monitoring unchecked, so trying the Actor gives you a snapshot straight away. API calls and saved Tasks that leave the field out keep monitoring on. Tick the box when you set up a recurring monitor.
Sample input for a monitoring Task:
{"storeUrls": ["https://brand.naver.com/example"],"monitoringEnabled": true,"maxReviewsPerProduct": 100}
You do not configure proxies, cookies, or a login. The Actor uses Apify Proxy on its own and reads only public store pages.
First run
This section and the next describe monitoring mode. In snapshot mode every run works like a first run and saves nothing.
The first run for a store builds the baseline:
- Finds every product in the store.
- Collects up to
maxReviewsPerProductof the newest reviews for each product. - Saves where it stopped for each product.
Records from the first run have collectionType: "BASELINE". Snapshot runs also use
BASELINE, because every snapshot is a fresh baseline.
The first run is usually the most expensive one, because it returns the baseline reviews.
maxReviewsPerProduct is how you control that cost. A store with 500 products returns up to
50,000 reviews at the default of 100, or up to 5,000 reviews at 10. If you only care about
reviews written from now on, set it low: later runs are not limited by it.
Later runs / monitoring
Every later run of the same Task and store:
- Finds the products again, so products added to the store are included.
- For each product, reads the newest reviews until it reaches a review it has already returned.
- Returns every review above that point, with
collectionType: "NEW_REVIEW".
maxReviewsPerProduct does not apply here. If a product received 250 new reviews since the
last run, you get all 250 even with maxReviewsPerProduct set to 100.
A product that appears in the store after your first run is monitored from the last
successful run onwards: its reviews written since then are returned as NEW_REVIEW, and its
older reviews are not backfilled. A product with no reviews at baseline is handled the same
way once its first reviews arrive.
A run with no new reviews still checks every product. The run summary tells you how many products were checked, so "0 new reviews" means "checked, nothing new", not "did nothing".
Output
The dataset holds one record per review. Each record carries the store and product it came from, so you can group, filter, or join without extra lookups. Review text is returned as written on Naver, usually in Korean.
Sample output (synthetic data, not a real store or review):
{"collectionType": "NEW_REVIEW","dedupeKey": "example:9000000001:5000000123","collectedAt": "2026-09-11T00:00:05.123456+00:00","store": {"storeName": "Example Beauty","storeSlug": "example","storeUrl": "https://brand.naver.com/example"},"product": {"channelProductId": "1000000001","originProductNo": "9000000001","productName": "예시 수분 세럼 50ml","productUrl": "https://brand.naver.com/example/products/1000000001","productStatus": "SALE","outOfStock": false,"storeVisible": true,"groupedListing": false,"modelName": "EXAMPLE-SERUM-50","currentReviewCount": 1284},"review": {"reviewId": 5000000123,"originProductNo": "9000000001","channelProductId": "1000000001","reviewScore": 5,"reviewContent": "촉촉하고 향이 은은해요. 다음에는 대용량으로 살게요.","createDate": "2026-09-10T09:15:00.000+00:00","modifyDate": null,"maskedWriterId": "exa***","productOptionContent": "용량: 50ml","repurchase": true,"reviewType": "NORMAL","parentReviewId": null,"helpCount": 2,"reviewAttaches": [{"attachmentId": 7000000001,"type": "IMAGE","url": "https://example.com/review-photo-1.jpg","width": 1080,"height": 1440}],"sellerReplies": [{"replyId": 8000000001,"content": "소중한 후기 감사합니다.","createDate": "2026-09-10T11:02:00.000+00:00","status": "NORMAL"}]}}
| Field | Meaning |
|---|---|
collectionType | BASELINE on a store's first run, NEW_REVIEW on every later run |
dedupeKey | storeSlug:originProductNo:reviewId. The same review always has the same key |
review.reviewScore | Star rating, 1–5 |
review.productOptionContent | The option the reviewer bought, as Naver shows it |
review.reviewAttaches | Attachments on the review, such as photos |
review.sellerReplies | Seller replies present when the review was collected |
product.storeVisible | true if the store page lists this product directly |
product.groupedListing | true if the store page folds this listing under another product of the same model |
The Reviews table view shows the fields most people read first: type, store, product, rating, text, date, option, repurchase, helpful votes, product link. All fields shows every column. Exports and the API return the full nested JSON shown above.
Each run also writes a RUN_SUMMARY record to its key-value store with the number of
products discovered, checked, and failed, the number of reviews returned, any warnings, and
runMode: MONITOR or SNAPSHOT.
Pricing
This Actor uses pay-per-event pricing. You pay for two things:
| Event | Price | When it is charged |
|---|---|---|
product_checked | $1.50 per 1,000 products | A product was checked completely (and, in monitoring mode, its position was saved) |
review_collected | $1.00 per 1,000 reviews | A review was returned in the dataset |
There is no custom start fee. Apify's standard synthetic actor-start event may apply. Platform compute and proxy usage are included in the event prices. The Pricing tab on this page always shows the current prices.
| Scenario | Calculation | Cost per run |
|---|---|---|
| Quiet monitoring: 500 products, 0 new reviews | 500 × $0.0015 | $0.75 |
| Active monitoring: 500 products, 100 new reviews | $0.75 + 100 × $0.001 | $0.85 |
| Small store: 100 products, 20 new reviews | $0.15 + $0.02 | $0.17 |
The first run also pays for its baseline reviews, so it costs more than the runs after it.
Lower maxReviewsPerProduct to make it cheaper.
Snapshot mode re-collects the selected baseline reviews on every run. Enable monitoring for recurring jobs if you only want to pay for newly added reviews after the first baseline.
A few details that keep the bill predictable:
- A product that could not be checked completely is not charged, and neither is a review that was not written to the dataset.
- A review is charged once, through
review_collected. The platform's generic per-item event (apify-default-dataset-item) is not used by this Actor, so a review is never charged twice. - Set a maximum cost per run on your Task. When the limit is reached, the Actor stops cleanly, keeps everything it already saved, and reports the stop in the run summary. The next run checks the store again and finishes the products that were left.
Scheduled usage
- Open the Actor, enter your store URLs, tick Enable incremental monitoring, and click Save as a new task.
- Run the Task once to build the baseline.
- Add a Schedule for the Task: daily is typical for competitor review monitoring, weekly for slower stores.
- Connect the Task's dataset to your destination (Google Sheets, a webhook, Slack, a database) with Apify integrations, or read it through the API.
Keep one Task per monitor. The state is tied to the Task, so a schedule that runs the same Task keeps continuing where the last run stopped.
Run time grows with the number of products: roughly 1.5 to 2 seconds per product, so about 15 minutes for a 500-product store and about an hour for 2,000 products. Set the Task timeout above that, and schedule runs further apart than one run takes.
Historical 30,000 review limit
Naver serves at most the newest 30,000 reviews for a single product. Older reviews on a product above that are not reachable through Naver's review pages, by this Actor or otherwise.
- For a product with more than 30,000 reviews, the first-run baseline may not be complete.
The baseline covers at most the newest 30,000 reviews, and never more than
maxReviewsPerProduct. - The Actor names every affected product in the run summary warnings, with its total review count.
- Monitoring of new reviews continues normally for those products. Later runs only read reviews newer than the previous run, which stays far below the limit.
If a single product somehow receives more new reviews between two runs than Naver serves, the Actor does not pretend it caught up. That product is reported as incomplete, its saved position is left unchanged, and it is not charged.
SmartStore unsupported
This Actor supports Naver Brand Store (brand.naver.com) only. SmartStore URLs
(smartstore.naver.com) are rejected with an explanation instead of being skipped silently.
In our testing, SmartStore review pages required a Naver login. This Actor never uses a login, cookies, or a personal account, so it does not support SmartStore.
Review update/delete unsupported
The Actor detects new reviews. It does not detect later changes to a review it already returned:
- an edited review is not returned again,
- a deleted review is not reported,
- a seller reply, helpful vote, or photo added later is not reported.
Your dataset keeps each review as it was when it was first collected. A snapshot run shows each review as it is at that moment, but it does not compare it with earlier runs.
Deduplication / at-least-once
In monitoring mode, runs that finish normally return each review once. Across completed
runs of the same Task and store, the same reviewId is not returned twice.
Snapshot runs return the same reviews again by design: each one is a full snapshot. Use
dedupeKey if you merge several snapshots.
If a run stops unexpectedly (a manual abort, a timeout, a platform failure) after writing
reviews but before saving its position, the next run can return some of those reviews
again. Delivery is at-least-once: zero duplicates in normal operation, possible repeats
after an interrupted run. Drop them by dedupeKey, which never changes for a given review.
When a product or store does not complete, the run is marked as failed and the run summary says which product and why. Products that completed keep their results. The next run retries the rest.
Concurrent same-Task warning
Do not run the same Task for the same Store concurrently. Two overlapping runs of the same Task and store race on the same saved state and can corrupt it. Wait for one run to finish before the next one starts, and keep schedules further apart than a run takes.
This applies to monitoring runs. Snapshot runs never touch the saved state, so a snapshot can run while a monitoring run of the same Task is in progress.
Different Tasks are independent, even for the same store URL. Monitoring runs started directly from the Actor page, without a Task, share one separate state per store URL.
FAQ
Do I need a list of product URLs? No. The store URL is enough. Products are discovered on every run.
Why did my second run return the same reviews again? Monitoring was off, so each run was a fresh snapshot. Tick Enable incremental monitoring to get only new reviews after the first run.
Why did my run return nothing new? Monitoring was on and no reviews were added since the previous monitoring run. The run summary still shows how many products were checked.
I created my Task before the monitoring option existed. Did anything change? No. A Task without the field keeps monitoring on and continues from its saved position. If you edit and save the Task input, make sure Enable incremental monitoring is ticked.
How do I start the baseline over? Create a new Task. Each Task keeps its own state, so a new Task starts with a new first run.
How far back can the first run go?
Up to Naver's limit: set maxReviewsPerProduct as high as 30000. Products with more than
30,000 reviews are named in the run summary warnings.
What happens when a product is removed from the store? It is simply no longer checked or charged. There is no removal event. If it comes back, monitoring continues from where it stopped.
Why did a run show as failed when most reviews arrived?
A run is marked failed when any store or product could not be completed, so that a partial
result never looks like a full one. Everything that completed is in the dataset, and
RUN_SUMMARY lists what did not.
Are out-of-stock products included?
Yes. product.outOfStock and product.productStatus tell you their state.
How many stores can one run handle? Up to 5 store URLs per run. For more, create more Tasks.
Does it use my Naver account? No. It reads public store pages only and never logs in.