Naver Shopping Product Insight

Apify Actor for collecting enriched Naver Shopping product rows with a simple commercial input surface.

The default user flow is intentionally small: enter product keywords, optionally choose the number of products per keyword, and run. The Actor owner configures Naver OpenAPI credentials as Apify environment secrets, so end users do not need to understand sources, proxies, browser fallback, page sizes, or diagnostics.

What It Collects

• Product name, ID, page URL, and image URL
• Seller name, discounted price, keyword, rank, page, and crawl timestamp
• OpenAPI metadata when available: brand, maker, category path, and product type
• Enhanced diagnostics: source type, source URL, crawl status, and missing-field signals
• Compatible legacy fields when outputMode=compatible is used through advanced JSON input

Simple Input

Most users only need this:

{
  "keywords": ["running shoes"]
}

The default collects 100 products per keyword. To request a different count:

{
  "keywords": ["running shoes", "wireless earbuds"],
  "itemsPerKeyword": 250
}

Optional sort:

{
  "keywords": ["running shoes"],
  "itemsPerKeyword": 100,
  "sort": "review"
}

The Apify form intentionally exposes only:

• keywords
• itemsPerKeyword
• sort

All commercial defaults are supplied automatically:

• sourceMode=openapi
• outputMode=enhanced
• openApiDisplaySize=100
• maxCrawlPages=ceil(itemsPerKeyword / 100)
• maxItems=keywords.length * itemsPerKeyword
• failIfBelowMaxItems=true
• maxConcurrency=1
• requestDelayMs=100
• Apify run options: 1024 MB memory, 600 second timeout
• browser fallback disabled
• raw product payload disabled

This keeps the first run easy while preserving strict failure behavior when the requested count cannot be collected.

1000 Result Run

Use examples/openapi-1000-input.json:

{
  "keywords": ["running shoes"],
  "itemsPerKeyword": 1000
}

Commercial release note, 2026-07-06: Apify Cloud source probes on build 1.0.15 still showed Naver Shopping web/API sources blocked through both default Apify Proxy and Residential KR. Do not market the pure-web path as a reliable 1000-result product until a source probe shows Shopping sources with blocked=false and uniqueProductCount>0 on pages 1-3.

Verified commercial path: sourceMode=openapi with Actor-owned Naver OpenAPI credentials.

OpenAPI commercial proof: build 1.0.18, run h2GIa87P2xr5yfFcV, dataset 2dbh2E5EPZwGc2HdX, wrote 1000/1000 rows with RUN-SUMMARY.status=passed.

OpenAPI output quality proof: the same dataset has 100% coverage for product name, ID, page URL, image URL, seller name, discounted price, keyword, rank, page, source URL, source type, category path, product type, crawl status, and crawl timestamp. Brand coverage is 99.7% and maker coverage is 85.6%. OpenAPI does not provide web-only fields such as seller ID, shipping fee, reviews, stock, and product flags, so outputMode=enhanced omits unsupported null-only fields.

Advanced Operator Inputs

The runtime still accepts advanced JSON inputs for troubleshooting and controlled experiments. These fields are intentionally hidden from the default Apify form:

• runMode
• sourceMode
• maxCrawlPages
• probeMaxPages
• openApiDisplaySize
• maxItems
• failIfBelowMaxItems
• maxConcurrency
• requestDelayMs
• useBrowserFallback
• browserFallbackMaxPages
• browserSessionReuse
• browserWarmupEnabled
• browserMaxBlockedPagesBeforeReset
• integratedFallbackMaxPages
• stopAfterEmptyPages
• stopAfterBlockedPages
• saveDebugArtifacts
• includeRaw
• externalHttpProxyUrl
• externalBrowserProxyUrl
• proxyConfiguration
• outputMode

Keep these options in examples and API inputs for operator use, not as the default end-user experience.

Web And Proxy Diagnostics

Pure web scraping remains diagnostic only. If Naver Shopping web pages return NAVER_SHOPPING_ACCESS_RESTRICTED, the Actor fails fast after repeated blocked pages and writes useful counters instead of spending indefinitely.

Before investing in web scraping or proxy experiments, run:

• examples/source-probe-input.json
• examples/residential-source-probe-input.json
• examples/external-proxy-source-probe-input.json

Probe mode writes one diagnostic row per source/page candidate:

• shopping-search-page
• shopping-api-search-all
• shopping-api-products
• mshopping-api-search-all
• integrated-nexearch
• integrated-where-shopping

Each row reports statusCode, blocked, productCount, uniqueProductCount, sampleProductIds, sampleProductNames, and durationMs. A web source is only worth using for scale-up if it returns unblocked pages with meaningfully changing unique products across pages.

For external proxy scale-up, use the staged examples only after a passing source probe:

• examples/web-100-external-proxy-input.json
• examples/web-500-external-proxy-input.json
• examples/web-1000-external-proxy-input.json

Do not combine useApifyProxy, groups, or countryCode with proxyUrls in the same proxyConfiguration.

Output Compatibility

Enhanced mode is the default and omits unsupported null-only fields. Compatible mode can still be requested by advanced JSON input when a legacy integration needs the broader field set.

Compatible records include fields such as:

{
  "isAd": "Not Ad",
  "productName": "Sample product",
  "productId": "11152911412",
  "productPageUrl": "https://smartstore.naver.com/main/products/11152911412",
  "productImageUrl": "https://shopping-phinf.pstatic.net/main_8869742/88697421733.1.jpg",
  "sellerName": "Sample seller",
  "sellerPageUrl": null,
  "sellerId": "ncp_1nrc1k_01",
  "discountedPrice": 169900,
  "searchKeyword": "running shoes",
  "crawledAt": "2026-07-04 17:00:00"
}

See docs/OUTPUT_SCHEMA.md for the full dataset contract.

Reliability Strategy

The commercial path uses Naver OpenAPI first to reduce Apify compute cost and avoid the known Cloud web-blocking path. Records with missing fields are not silently discarded; enhanced mode exposes crawlStatus and missingFields so schema drift is easier to debug.

Run logs include openApiPages, httpPages, integratedSearchPages, browserPages, blockedPages, emptyPages, foundProducts, writtenProducts, dedupedProducts, and durationMs.

Every scrape run writes RUN-SUMMARY to the default key-value store. Inspect it before raw debug artifacts. It includes:

• status: passed, attention, or failed
• shouldFail: true when the strict item target was missed
• issues: concrete failure or quality signals
• recommendations: next operational step for Cloud validation
• counters: final run counters

Local Development

npm install
npm run check
npm test
npm run build

Run locally with Apify storage:

npm run build
apify run

Release Checklist

1. Run npm run build:release.
2. Run git diff --check.
3. Build on Apify Cloud.
4. Verify commercial OpenAPI collection with examples/openapi-1000-input.json.
5. Inspect the default dataset and RUN-SUMMARY before calling a run successful.
6. Only run source probes or pure-web scale-up when specifically validating web/proxy strategy.

Release builds validate every JSON file under examples/. To run that check directly:

$npm run validate:examples