# Naver Brand Store Reviews Scraper & Monitor (`huggable_quote/naver-brand-store-review-monitor`) Actor

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.

- **URL**: https://apify.com/huggable\_quote/naver-brand-store-review-monitor.md
- **Developed by:** [OrbitData Labs](https://apify.com/huggable_quote) (community)
- **Categories:** E-commerce, Automation, Developer tools
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $1.50 / 1,000 product checkeds

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

Actors are web data automations that power AI and operations. They run on the Apify platform to scrape websites, process data, connect APIs, and automate workflows.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.
Actors are written with capital "A".

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.
The best way to integrate Actors is as follows.

- **AI agents and MCP clients** — the [Apify MCP server](https://docs.apify.com/integrations/mcp.md) at `https://mcp.apify.com` (remote, streamable HTTP, OAuth on first use).
- **Agentic workflows and local Actor development** — [Agent Skills](https://apify.com/.well-known/agent-skills/index.json) with the [Apify CLI](https://docs.apify.com/cli/docs.md): `npm install -g apify-cli`, then `apify login`.
- **JavaScript/TypeScript projects** — the official [JS/TS client](https://docs.apify.com/api/client/js/docs.md): `npm install apify-client`.
- **Python projects** — the official [Python client](https://docs.apify.com/api/client/python/docs.md): `pip install apify-client`.
- **Any other language** — the [REST API](https://docs.apify.com/api/v2.md).

For usage examples, see the [API](#api) section below.

For more details, see Apify documentation as [Markdown index](https://docs.apify.com/llms.txt) and [Markdown full-text](https://docs.apify.com/llms-full.txt).

# README

## Naver Brand Store Reviews Scraper & Monitor

> **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.

```json
{
  "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:

```json
{
  "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:

1. Finds every product in the store.
2. Collects up to `maxReviewsPerProduct` of the newest reviews for each product.
3. 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:

1. Finds the products again, so products added to the store are included.
2. For each product, reads the newest reviews until it reaches a review it has already
   returned.
3. 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):

```json
{
  "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

1. Open the Actor, enter your store URLs, tick **Enable incremental monitoring**, and click
   **Save as a new task**.
2. Run the Task once to build the baseline.
3. Add a **Schedule** for the Task: daily is typical for competitor review monitoring,
   weekly for slower stores.
4. 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.

# Actor input Schema

## `storeUrls` (type: `array`):

Paste one or more Naver Brand Store URLs. Product URLs are discovered automatically. SmartStore URLs are not supported.<br><br>Example: <code>https://brand.naver.com/dalba</code>. Up to 5 stores per run. The limit counts the URLs you submit, before duplicates are removed. A SmartStore URL (<code>smartstore.naver.com</code>) makes the run fail with an explanation instead of being skipped silently.

## `monitoringEnabled` (type: `boolean`):

OFF: each run returns a fresh review snapshot and does not use saved monitoring state. ON: the first run creates a baseline and later runs return only reviews added since the previous monitoring run.

## `maxReviewsPerProduct` (type: `integer`):

Controls the first baseline only. Later runs collect all new reviews until the previous review boundary is reached.<br><br>Use it to control the cost of the first run: the first run returns up to this many of the newest reviews for every product. Later runs ignore it. Naver serves at most the newest 30000 reviews per product, so a product above that cannot be fully backfilled.

## Actor input object example

```json
{
  "storeUrls": [
    "https://brand.naver.com/burberrybeauty"
  ],
  "monitoringEnabled": true,
  "maxReviewsPerProduct": 100
}
```

# Actor output Schema

## `reviews` (type: `string`):

All reviews returned by this run, with their product and store context.

## `runSummary` (type: `string`):

Products checked, reviews returned, failed products, historical-limit and cost-limit warnings for this run.

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "storeUrls": [
        "https://brand.naver.com/burberrybeauty"
    ],
    "monitoringEnabled": false
};

// Run the Actor and wait for it to finish
const run = await client.actor("huggable_quote/naver-brand-store-review-monitor").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = {
    "storeUrls": ["https://brand.naver.com/burberrybeauty"],
    "monitoringEnabled": False,
}

# Run the Actor and wait for it to finish
run = client.actor("huggable_quote/naver-brand-store-review-monitor").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "storeUrls": [
    "https://brand.naver.com/burberrybeauty"
  ],
  "monitoringEnabled": false
}' |
apify call huggable_quote/naver-brand-store-review-monitor --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,huggable_quote/naver-brand-store-review-monitor"
        }
    }
}
```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/pHAW91mBhhNbhegd1/builds/P0CuKBiJOrjaHQLaP/openapi.json