K-Pop Photocard Price Index 📊🎴

The first K-pop photocard price index built on Korean-origin market data. This actor samples live listings from Pocamarket (포카마켓) — the global marketplace where K-pop fans buy and resell photocards — and aggregates them into one clean index row per (artist, member): listing count, median / min / max USD asking price, a confidence interval on that median, the sampling basis the statistics were computed over, average wish count (demand signal), and sample listing URLs.

Sellers and buyers on eBay, Mercari, or Depop usually price photocards by guessing from scattered listings. This index lets you price against the origin market instead.

Try it free. Apify's free plan includes $5 of monthly platform credit — roughly 1,600 results from this actor, and one run emits only ~20–150 index rows, so that's months of daily index snapshots, no credit card required. Set your input, click Start, and export JSON/CSV/Excel.

---

🚀 What it does

1. Samples up to maxListings photocard listings from Pocamarket's public catalog API (each listing already carries the lowest current USD asking price across sellers), drawing pages spread across the full result depth — see Methodology.
2. Groups them by the catalog's own artist / member labels.
3. Aggregates each group into one index row: listing_count, median_price_usd with its confidence interval, min_price_usd, max_price_usd, avg_wish_count, the sampling basis, and up to 3 sample_urls.

Give it a list of artists to build a focused per-member index, or leave artists empty to index a spread across the whole catalog. Naming your artists is strongly recommended — a per-artist query spends the whole listing budget on that artist, so its medians are far tighter than the same budget spread catalog-wide.

Privacy first: this is an aggregate index — card + price statistics only. The catalog API carries no seller nicknames, IDs, or profiles, and no seller identity exists anywhere in this actor's pipeline or output.

---

🔬 Methodology (how the median is computed)

A median is only worth as much as the slice it was taken over, so this actor states that slice on every row instead of leaving you to guess.

Pages are spread across the full result depth, never taken off the head. Pocamarket orders every query newest-offer-first, and the head of a result list is not a random slice of the market — fresh drops skew expensive. A full 288-page census of q=BTS (5,742 listings) shows the price gradient plainly:

Catalog pages	Median asking price
1–24 (head)	$4.80
73–96	$9.50
145–168	$11.90
193–216 (deep tail)	$29.20

Walking pages 1, 2, 3… would therefore make the published median a function of your maxListings setting rather than of the market. Instead the sampler walks a rotated van der Corput (bit-reversal) sequence over the query's full page depth — mid, ¼, ¾, ⅛, ⅝, … — so any prefix of the sample is already spread evenly, whatever page the budget runs out on. Pages past the point where listings stop carrying live offers (sold-out tail) are detected and excluded rather than wasting the budget.

Verified against that census: the true BTS / JUNGKOOK median is $14.90 over 582 priced listings, and the sampler's median is centred on it at every budget — $14.3 at maxListings=400, $14.3 at 800, $14.9 at 2000 (median of 300 simulated runs each). What changes with the budget is precision, not level.

Every row therefore carries its own precision and sampling basis:

• median_price_ci_low_usd / median_price_ci_high_usd — a distribution-free confidence interval on that row's median, from the Binomial(n, ½) order-statistic bounds over the group's own listing_count prices. Nominally 95%; replaying the actual page-cluster sampler against a full census measures ~90–98% real coverage (prices correlate within a sampled page), so treat it as approximately nominal rather than conservative — at the default maxListings the weakest members read ~90%. null below 8 listings, where no such interval exists — a median over 5 listings has no publishable precision and the actor says so rather than implying one.
• sampling_method, pages_sampled, sample_size, total_listings, coverage_pct — what the query drew from, so you can see the population behind the number.

Read the interval, not just the point. Measured on BTS, a busy member's interval is roughly ±50% of the median at maxListings=400, ±30% at 800, and ±14% at 2000. If you are diffing daily snapshots to spot market movement, a change that stays inside the interval is sampling noise, not a price move.

---

📥 Input

Field	Type	Default	Description
artists	array	[]	Artist/group names to index (e.g. SEVENTEEN, ATEEZ, NewJeans). Empty = a spread across the whole catalog. Naming artists gives far tighter medians.
maxListings	integer	400	How many listings to sample and aggregate (cap 2,000, split evenly across artists). Buys precision, not a different price level — it narrows median_price_ci_*, it does not shift median_price_usd.
minListingsPerGroup	integer	3	Drop (artist, member) groups backed by fewer priced listings — thin groups make noisy medians. Set to 8+ if you only want rows with a computable confidence interval.
proxyConfiguration	object	off	Optional Apify proxy. Not required — enable one if you hit rate limits at scale.

Input example — per-member price index for two groups:

{
  "artists": ["SEVENTEEN", "ATEEZ"],
  "maxListings": 400,
  "minListingsPerGroup": 3
}

You are billed per INDEX ROW emitted (typically 20–150 per run), not per listing sampled.

---

📤 Output

Each (artist, member) group is one dataset record in this shape (real sample from a live run):

{
  "source": "pocamarket_index",
  "artist": "BTS",
  "member": "Jin",
  "listing_count": 161,
  "median_price_usd": 8.3,
  "median_price_ci_low_usd": 7.1,
  "median_price_ci_high_usd": 10.1,
  "min_price_usd": 3,
  "max_price_usd": 419.5,
  "avg_wish_count": 138,
  "sampling_method": "stratified_pages",
  "pages_sampled": 40,
  "sample_size": 800,
  "total_listings": 5742,
  "coverage_pct": 13.93,
  "sample_urls": [
    "https://pocamarket.com/search?photo_card_id=8771",
    "https://pocamarket.com/search?photo_card_id=8777",
    "https://pocamarket.com/search?photo_card_id=7392"
  ],
  "scraped_at": "2026-08-18T08:43:26.631+09:00"
}

Field notes

• listing_count — number of distinct priced photocards sampled for this group. This is the n behind the median, and it is what governs the interval below — not sample_size, which counts the whole query.
• median_price_usd / min_price_usd / max_price_usd — statistics over each card's lowest current asking price (after any active discount), in USD (Pocamarket's global marketplace prices in USD).
• median_price_ci_low_usd / median_price_ci_high_usd — confidence interval on this row's median (see Methodology). null when listing_count < 8 — treat those medians as indicative only.
• sampling_method — stratified_pages when pages were spread across the query's full depth (the normal case), head_pages in the rare fallback where the catalog API returned no total count and the depth was unknown, mixed when a group was fed by both.
• pages_sampled / sample_size — catalog pages fetched and listings drawn for the query/queries that fed this row (not for this group alone).
• total_listings — total catalog matches for those queries; coverage_pct is sample_size / total_listings. Low coverage is expected and fine — the sample is spread across the full depth, so it is representative rather than exhaustive.
• avg_wish_count — mean wishlist count across the group's cards, a demand signal.
• sample_urls — up to 3 example catalog listings from the group, most-wished first.
• artist / member — the catalog's own labels (e.g. Seventeen, SEUNGKWAN). Unit and full-group cards carry member labels like Unit / Group and form their own rows.
• A 20-row real sample lives in samples/sample-output.json.

---

💡 Use cases

• Resale pricing — price your photocards on eBay / Mercari / Depop against the Korean-origin market median instead of guessing from three stale listings.
• Arbitrage spotting — compare origin-market medians to Western marketplace prices and find the spread per artist/member.
• Collectible market analytics — track which members command price premiums, and how demand (avg_wish_count) maps to price.
• Trend monitoring — schedule daily runs and chart median movement per member around comebacks, tours, and enlistments.
• AI agents & LLM pipelines — a compact, numeric index table is far cheaper to feed an agent than thousands of raw listings.

---

🌐 Data source

This actor reads Pocamarket's public catalog JSON API — the same one that powers pocamarket.com — and aggregates in one pass. No login, no private API, no HTML scraping. The endpoint returns card-level data with the lowest asking price already consolidated across sellers, so no proxy is required in most runs; enable an Apify proxy for IP diversity at scale.

Want the underlying card-level rows instead of the index? Use the companion pocamarket-scraper actor.

---

⚠️ Known limitations (honest notes)

• Asking-price index, not sold-price index. Statistics are computed over current (lowest) asking prices, not completed transactions.
• Sample-based medians. Each run samples up to maxListings listings spread across the full result depth, so medians describe the current market surface, not the full historical order book. The sample is representative but not exhaustive — always read median_price_ci_* alongside median_price_usd, and raise maxListings to narrow it.
• Thin groups are dropped below minListingsPerGroup (default 3). If no group reaches the threshold (tiny maxListings), the actor emits all observed groups rather than failing, and logs a warning. Groups under 8 listings publish a median with a null confidence interval — real, but not precise enough to price against on its own.
• Catalog-wide runs are thin per member. With artists empty, the budget is spread over ~488,000 listings, so a given member may land only a handful of listings and its interval will be null. Name your artists for actionable per-member numbers.
• artists is a keyword search. Results are grouped by the catalog's own labels (e.g. Seventeen, not SEVENTEEN), and a keyword can occasionally match cards of other artists; such stray groups are usually removed by minListingsPerGroup.
• No card_type / album-era breakdown in v0.1. Grouping is per (artist, member) only.

---

⚖️ Rate & legality note

• Only public, non-personal catalog data is read — the same listings anyone sees on Pocamarket without logging in — and only aggregated statistics are emitted. No personal data: the catalog API carries no seller nicknames, IDs, or profiles, and this actor's output contains no seller identity of any kind. artist/member are public commercial attribution (like an author name on a book).
• Requests are rate-limited (sequential pages, ≥500 ms delay) to stay light on the site.
• You are responsible for complying with Pocamarket's Terms of Service and applicable law in your jurisdiction. Use the data for research, pricing, and analytics — not to replicate the platform.

---

❓ FAQ

Is it legal to scrape this data? This actor reads only public, non-personal catalog data and outputs aggregated statistics per artist/member. No seller data is collected at any stage. You are responsible for how you use the data; see the rate & legality note above.

What does it cost in practice? $3.00 per 1,000 results (launch pricing) + a few cents of platform usage. One run emits roughly 20–150 index rows, so a daily snapshot costs well under $0.50/day. Apify's free $5 monthly credit covers ~1,600 results.

Do I need to configure proxies? No — the default settings work out of the box. Optionally, enable an Apify proxy for IP diversity when running at scale.

How fresh is the data? Every run samples the live Pocamarket catalog at run time. Schedule the actor for recurring index snapshots and diff the medians.

Why do median and min sometimes match? Popular cards often have many listings at the same lowest asking price, so the median can sit at the minimum. That's the real market shape, not a bug.

Why did a member's median change between two runs on the same day? Sampling noise, almost always. The sampler is unbiased (see Methodology), but a median over a small listing_count is imprecise. Compare median_price_ci_low_usd / median_price_ci_high_usd between the two runs: if the intervals overlap, nothing moved in the market — raise maxListings if you need to resolve changes that small.

What is NOT included? Sold/transaction prices (asking prices only), card_type / album-era breakdowns (grouping is artist + member), raw card-level rows (use pocamarket-scraper for those), and any seller identity (by design, never).

---

🤖 Use with AI agents (MCP)

Call this Actor as a tool from Claude or any MCP-compatible AI agent — no glue code. Point your MCP client at Apify's server, scoped to this Actor:

{
  "mcpServers": {
    "apify": {
      "url": "https://mcp.apify.com?tools=kdatafactory/kpop-photocard-index",
      "headers": { "Authorization": "Bearer <YOUR_APIFY_TOKEN>" }
    }
  }
}

Your agent can then pull K-pop photocard median prices by member on demand — no scraping code in your app. Grab a free token from Apify → Integrations.

🇰🇷 More Korean data actors

This actor is part of a suite of Korean-platform scrapers by the same maintainer:

• pocamarket-scraper — the raw card-level listings behind this index: per-card prices, stock, wishes.
• ktown4u-scraper — K-pop albums & official merch prices from a global K-pop shop.
• bunjang-scraper — Korea's top secondhand marketplace, resale listings & prices.

Browse all: apify.com/kdatafactory

---

🏃 Run it

On Apify: set your input and click Start. Locally:

npm install
# put your input in storage/key_value_stores/default/INPUT.json
npm start

Results land in the default dataset (Apify) or ./storage/datasets/default (local).

---

If this actor saves you time, a rating on the Store page helps a solo maintainer a lot. Found an issue? Open it in the Issues tab — I respond fast.