DEV Community: Sami

Synthesio charges $36K+/year for Chinese platform coverage. I built one for $0.045/mention.

Sami — Wed, 20 May 2026 01:46:55 +0000

Synthesio sells Chinese platform coverage for $36K+/year. Brandwatch and Meltwater sit in roughly the same $24K-80K/year band. I built an Apify Actor that does the equivalent core job — Weibo, RedNote, Bilibili, Douban, Xueqiu — for $0.045 per deduplicated mention, billed pay-as-you-go.

If you've ever tried to DIY this, you know the math. Five Chinese platforms means five different parsers, five different rate-limit dances, five different schema-drift surprises every couple of weeks, and zero deduplication when a KOL reposts the same content across all of them. By the time you've normalized author identity, follower counts, and timestamps into a usable cross-platform record, you've built a small distributed system that breaks every other Tuesday.

The pitch for zhorex/chinese-brand-monitor is simple: one API call, one normalized schema, one PPE event per canonical mention. You pass a brand keyword (Chinese or English), get back deduplicated records with sentiment scores and reach signals across all five platforms. You don't write per-platform code. You don't run five cron jobs. You don't pay an enterprise floor.

This post walks through six concrete workflows with runnable Python — brand health, crisis monitoring, KOL discovery, hedge fund alt-data, AI training corpora, and a cross-tool finance signal — so you can decide if this fits your stack.

What it does

The Actor takes a single brand keyword (or a list of keywords) and returns deduplicated, sentiment-scored mentions from five Chinese platforms:

Weibo — China's largest microblog; broad consumer chatter
RedNote / Xiaohongshu (小红书) — lifestyle and product discovery; heavy DTC signal
Bilibili — long-form video community; strong Gen-Z signal
Douban — long-form reviews, especially media and lifestyle
Xueqiu (雪球) — retail investor chatter, cashtag-tracked stock sentiment

The Actor handles:

Single keyword input — Chinese 护肤 or English Estée Lauder both work
Normalized cross-platform schema — same fields on every record, no per-platform parsing in your downstream code
Lexicon-based Chinese sentiment scoring per mention (polarity + score)
Cross-platform deduplication — when the same KOL reposts identical content on Weibo and RedNote, you get one canonical record with crossPlatformReposts listing the other appearances
Author identity normalization with follower count for reach-weighted analysis

Engineering choices worth knowing: a browser-grade HTTP client, polite rate limiting, session warming, and a public-data scope that respects each platform's accessible surface. The point is that you don't have to think about any of that — you call the Actor, you get records.

Six concrete workflows

a) Brand health dashboard (~$135/mo)

Daily 8am cron, single brand, 7-day rolling lookback. Push to Looker, Metabase, or a Notion database. Compare this to a $4K/mo Synthesio seat for the same functional coverage.

from apify_client import ApifyClient
import pandas as pd

client = ApifyClient("YOUR_APIFY_TOKEN")

run_input = {
    "brandKeyword": "Estée Lauder",
    "platforms": ["weibo", "rednote", "bilibili", "douban", "xueqiu"],
    "lookbackDays": 7,
    "maxMentionsPerPlatform": 600,
    "sentimentAnalysis": True,
    "deduplication": True,
}

run = client.actor("zhorex/chinese-brand-monitor").call(run_input=run_input)
items = list(client.dataset(run["defaultDatasetId"]).iterate_items())

df = pd.DataFrame(items)
df["polarity"] = df["sentiment"].apply(lambda s: s["polarity"])
summary = (
    df.groupby(["platform", "polarity"])
      .agg(mentions=("mentionId", "count"),
           reach=("authorFollowerCount", "sum"))
      .reset_index()
)
print(summary)

The grouped DataFrame is what you push to your BI tool. ~3,000 deduplicated mentions/month at this cadence lands around $135 in PPE charges.

b) Crisis monitoring (~$270/mo)

Hourly cron, 1-day lookback, filter for negative polarity from accounts above 10K followers. Slack webhook fires on match. This is the workflow that justifies the spend during a product recall, a CEO quote going viral, or a competitor smear campaign.

import requests
from apify_client import ApifyClient

client = ApifyClient("YOUR_APIFY_TOKEN")
SLACK_WEBHOOK = "https://hooks.slack.com/services/XXX/YYY/ZZZ"

run = client.actor("zhorex/chinese-brand-monitor").call(run_input={
    "brandKeyword": "Estée Lauder",
    "platforms": ["weibo", "rednote", "bilibili", "douban", "xueqiu"],
    "lookbackDays": 1,
    "maxMentionsPerPlatform": 200,
    "sentimentAnalysis": True,
})

for m in client.dataset(run["defaultDatasetId"]).iterate_items():
    if m["sentiment"]["polarity"] == "negative" and m["authorFollowerCount"] >= 10000:
        requests.post(SLACK_WEBHOOK, json={
            "text": (
                f"[{m['platform']}] {m['authorName']} "
                f"({m['authorFollowerCount']:,} followers) — "
                f"sentiment {m['sentiment']['score']:.2f}\n"
                f"{m['contentSnippet']}\n{m['url']}"
            )
        })

Hourly × 24 × 30 ≈ ~6,000 deduplicated mentions/month if the brand has steady chatter — roughly $270/mo. Cheap insurance for a comms team.

c) KOL identification (~$90/mo)

Weekly category-keyword run. Skincare = 护肤, sneakers = 球鞋, supplements = 保健品. Filter verified authors above 50K followers, sort by engagement.

from apify_client import ApifyClient
import pandas as pd

client = ApifyClient("YOUR_APIFY_TOKEN")

run = client.actor("zhorex/chinese-brand-monitor").call(run_input={
    "brandKeyword": "护肤",
    "platforms": ["weibo", "rednote", "bilibili", "douban"],
    "lookbackDays": 14,
    "maxMentionsPerPlatform": 500,
})

df = pd.DataFrame(list(client.dataset(run["defaultDatasetId"]).iterate_items()))
df["engagement"] = df["engagementMetrics"].apply(
    lambda e: e.get("likes", 0) + e.get("comments", 0) * 3 + e.get("shares", 0) * 5
)

candidates = (
    df[(df["authorVerified"]) & (df["authorFollowerCount"] >= 50000)]
      .sort_values("engagement", ascending=False)
      .drop_duplicates("authorId")
      .head(50)
)
candidates[
    ["authorName", "platform", "authorFollowerCount", "engagement", "url"]
].to_csv("kol_candidates.csv", index=False)

Weekly cadence on 1-2 category keywords ≈ ~2,000 mentions/month — roughly $90/mo. The output is a ranked candidate list your social team can outreach directly.

d) Hedge fund alt-data (~$990/mo)

Daily run across 20 portfolio tickers on Xueqiu + Weibo + RedNote. Build a sentiment-velocity feature: 7-day mention-count delta paired with polarity shift. Join two consecutive runs to compute the velocity.

from apify_client import ApifyClient
import pandas as pd

client = ApifyClient("YOUR_APIFY_TOKEN")

tickers = [
    "BABA", "PDD", "JD", "BIDU", "NIO", "XPEV", "LI", "MEITUAN",
    "TENCENT", "BYD", "LKNCY", "TME", "BILI", "VIPS", "TAL", "YMM",
    "DIDI", "ZH", "NTES", "FUTU",
]

def pull(lookback_days):
    rows = []
    for ticker in tickers:
        run = client.actor("zhorex/chinese-brand-monitor").call(run_input={
            "brandKeyword": ticker,
            "platforms": ["xueqiu", "weibo", "rednote"],
            "lookbackDays": lookback_days,
            "sentimentAnalysis": True,
        })
        for item in client.dataset(run["defaultDatasetId"]).iterate_items():
            rows.append(item)
    return pd.DataFrame(rows)

today = pull(1)
week = pull(7)

def agg(df):
    df = df.copy()
    df["score"] = df["sentiment"].apply(lambda s: s["score"])
    return df.groupby("brandKeyword").agg(
        count=("mentionId", "count"),
        avg_polarity=("score", "mean"),
    )

today_agg = agg(today)
week_agg = agg(week)
features = today_agg.join(week_agg, lsuffix="_1d", rsuffix="_7d")
features["velocity"] = features["count_1d"] - (features["count_7d"] / 7)
features["polarity_shift"] = features["avg_polarity_1d"] - features["avg_polarity_7d"]
print(features.sort_values("velocity", ascending=False))

20 tickers × daily × 3 platforms ≈ ~22K mentions/month — roughly $990/mo. Compare to a single Bloomberg terminal at ~$28K/year for one analyst.

e) AI training corpus (~$2,250 one-shot)

50 brand keywords × 1,000 mentions each = 50K Chinese-language labeled records for SFT or RLHF corpora. Every record has an explicit sentiment polarity, author follower bracket, and platform. Compare to $15-50K academic licensing fees for comparable annotated Chinese sentiment corpora.

from apify_client import ApifyClient
import json

client = ApifyClient("YOUR_APIFY_TOKEN")

brands = [
    "华为", "小米", "比亚迪", "蔚来", "理想汽车", "拼多多", "美团",
    "完美日记", "花西子", "钟薛高", "元气森林", "瑞幸咖啡", "海底捞",
    # ... 50 total
]

with open("china_sft_corpus.jsonl", "w", encoding="utf-8") as f:
    for brand in brands:
        run = client.actor("zhorex/chinese-brand-monitor").call(run_input={
            "brandKeyword": brand,
            "platforms": ["weibo", "rednote", "bilibili", "douban", "xueqiu"],
            "lookbackDays": 30,
            "maxMentionsPerPlatform": 200,
            "sentimentAnalysis": True,
        })
        for m in client.dataset(run["defaultDatasetId"]).iterate_items():
            f.write(json.dumps({
                "text": m["content"],
                "label": m["sentiment"]["polarity"],
                "score": m["sentiment"]["score"],
                "platform": m["platform"],
                "brand": m["brandKeyword"],
            }, ensure_ascii=False) + "\n")

50K records × $0.045 = $2,250. One-shot. No annotator contracts, no FTE-month spent labeling.

f) Cross-tool finance signal: Xueqiu sentiment × TradingView price

Pair the Chinese Brand Monitor with the TradingView Scraper for a sentiment-vs-price divergence signal. When Xueqiu retail sentiment turns sharply positive while the price stays flat or drifts down, you have a setup worth a closer look.

from apify_client import ApifyClient
import pandas as pd

client = ApifyClient("YOUR_APIFY_TOKEN")

sent_run = client.actor("zhorex/chinese-brand-monitor").call(run_input={
    "brandKeyword": "BABA",
    "platforms": ["xueqiu"],
    "lookbackDays": 7,
    "sentimentAnalysis": True,
})
sent = pd.DataFrame(list(client.dataset(sent_run["defaultDatasetId"]).iterate_items()))
sent_score_7d = sent["sentiment"].apply(lambda s: s["score"]).mean()

price_run = client.actor("zhorex/tradingview-scraper").call(run_input={
    "mode": "technical_analysis",
    "symbols": ["NYSE:BABA"],
    "includeIndicators": True,
})
price = next(iter(client.dataset(price_run["defaultDatasetId"]).iterate_items()))
perf_week_pct = (price.get("perfWeek") or 0) / 100

# Positive Xueqiu sentiment minus weekly price return: large positive = retail
# is loud-bullish but the tape hasn't caught up yet.
divergence = sent_score_7d - perf_week_pct
print({
    "ticker": "BABA",
    "xueqiu_sentiment_7d": round(sent_score_7d, 3),
    "tradingview_perfWeek_pct": price.get("perfWeek"),
    "divergence": round(divergence, 3),
})

A positive divergence row is "sentiment positive, price not yet moved." That's the setup quants pay alt-data brokers tens of thousands a year to surface.

Normalized output schema

Every record across every platform has this shape:

{
  "mentionId": "rednote_8b3c2f91a4",
  "platform": "rednote",
  "brandKeyword": "Estée Lauder",
  "brandMatchType": "exact",
  "content": "雅诗兰黛小棕瓶用了三个月，肌肤紧致很多...",
  "contentSnippet": "雅诗兰黛小棕瓶用了三个月...",
  "language": "zh-CN",
  "authorId": "rednote_user_4429871",
  "authorName": "小琳护肤日记",
  "authorFollowerCount": 184230,
  "authorVerified": true,
  "publishedAt": "2026-05-18T14:23:11Z",
  "engagementMetrics": {
    "likes": 2104,
    "comments": 187,
    "shares": 56,
    "views": 18430
  },
  "url": "https://www.xiaohongshu.com/explore/...",
  "mediaUrls": ["https://sns-img-...jpg"],
  "sentiment": { "polarity": "positive", "score": 0.78, "method": "lexicon" },
  "crossPlatformReposts": [
    {
      "platform": "weibo",
      "url": "https://weibo.com/...",
      "publishedAt": "2026-05-18T15:02:00Z"
    }
  ],
  "scrapedAt": "2026-05-20T08:00:01Z"
}

Your downstream code stays platform-agnostic. Pandas, BigQuery, Snowflake, ClickHouse — pick your warehouse and the records load directly.

Pricing

$0.045 per canonical mention, billed only after deduplication. If a KOL reposts the same content across Weibo + RedNote + Bilibili, that's one billable mention with the reposts attached, not three.

Use case	Volume	Monthly cost	Enterprise alternative
Single brand, daily, 7-day lookback	~3K/mo	~$135	$4K/mo Synthesio seat
5-brand agency, daily, sentiment + dedup	~15K/mo	~$675	$24K-80K/year
20-ticker hedge fund	~22K/mo	~$990	$28K/year Bloomberg seat
AI training corpus one-shot	50K	~$2,250	$15K-50K academic license

What this Actor does NOT do

Honest scoping matters more than pitch volume:

Not real-time push streaming. Cron-based polling, 5-minute minimum interval. If you need sub-second push, this isn't it.
Not a historical archive. Maximum 30-day lookback. For multi-year backfill, you need a different tool.
Not authentication-walled content. No Zhihu authenticated answers, no private WeChat groups, no closed Weibo Super Topic posts.
Not a CRM or BI tool. This is the data layer. You bring the dashboard.

If those constraints are dealbreakers for your use case, save the credit and don't run it.

The broader China stack

The main Actor here is zhorex/chinese-brand-monitor, but the rest of the stack exists for cases when you need single-platform depth or a different angle:

For deeper single-platform RedNote dives — full creator profiles, comment threads, hashtag networks — reach for the standalone RedNote/Xiaohongshu Scraper.
For Weibo-only bulk pulls — historical hashtag sweeps, single-account timelines, Super Topic posts — the Weibo Scraper is the dedicated tool.
For Bilibili-only deep pulls — video metadata, danmaku, UP主 channel coverage — use the Bilibili Scraper.
For finance-only sentiment with cashtag granularity and reply trees, the Xueqiu Scraper goes deeper than the brand-monitor surface.
For long-form review extraction, especially books, films, and lifestyle, the Douban Scraper handles the review-thread structure.
For the cross-tool finance workflow above, the TradingView Scraper provides the price half of the sentiment-vs-price divergence signal.
If you're tracking brand mentions, you usually also want competitor pricing — the JD Scraper covers the e-commerce price side of the China stack.

Try it

$5 of Apify free credits cover roughly 100 mentions — enough to run a single brand for a week and see whether the output shape fits your downstream code. Start here: zhorex/chinese-brand-monitor.

If you build something on top of this — a Looker dashboard, a Slack bot, a Streamlit explorer, a sentiment ETF screen — drop a comment, or open an Issue on the Actor page. Schema customization, missing platforms, follower-bracket additions, new sentiment lexicons — those are the kinds of changes that get prioritized when users ask for them.

Pinnacle odds for $0.01 a snapshot: the OddsJam / Odds API replacement sharp bettors are using in 2026

Sami — Tue, 19 May 2026 13:54:32 +0000

If you bet sharp lines, the only book that genuinely matters for fair-value is Pinnacle. Every EV model, every CLV report, every "did I beat the close?" check eventually compresses down to one question: what was Pinnacle showing on this market at T-1?

For years the standard way to get that feed was The Odds API ($249/mo for 15M credits) or OddsJam Gold ($249/mo, $499+ for Pro). For a tipster shop polling 100 fixtures a day that math is tolerable. For a solo bettor running CLV on 20 fixtures it's overspend. For a specials trader it's worse — OddsJam gates futures and yes/no markets behind their highest tier and The Odds API doesn't surface most of them at all.

There's now an Apify Actor that does the same job pay-per-snapshot:

zhorex/sports-odds-aggregator — Pinnacle h2h + spreads + totals + 5,000+ specials per sport, from $0.01 a snapshot. Datacenter-proxy friendly. No login, no monthly minimum.

This post is the playbook: four recipes that show exactly how to run it, what each costs, and where the savings show up vs. the SaaS-incumbent pricing.

Quick note on naming: the Actor's title still references Bet365 because Bet365 is the second-book slot, but Bet365's public mobile-web path is under repair as of May 2026. Pinnacle is shipping today, and the moment Bet365 returns the cross-book best-price flag (isBestPriceAcrossBooks) and fuzzy event-matching activate automatically — no input change on your side.

Pricing in plain English

Four event types, billed pay-per-event (PPE):

Event	Price	When it fires
`odds-snapshot-pre-match`	$0.01 / snapshot	One market-outcome from a scheduled (not in-play) fixture
`odds-snapshot-live`	$0.02 / snapshot	One market-outcome from a live (in-play) match
`odds-snapshot-player-prop`	$0.04 / snapshot	One special / future / yes-no / team prop / exact-totals row
`scheduled-run`	$0.05 / run	Once per cron tick — often fully offset by the dedup window

A typical pre-match fixture with ["h2h", "spreads", "totals"] emits ~7 snapshots (3 h2h outcomes + 2 spreads + 2 totals). Add "specials" and you get an extra 30–80 rows per fixture — yes/no markets, exact totals, first-team-to-score, winning margin per scoreline, team props.

The bit that turns this from "interesting" to "actually cheap": the deduplicationWindowSeconds setting suppresses snapshots when the line hasn't moved. On stable mid-week Premier League pre-match polls you typically charge for 5–15% of "naïve" volume. A 60-second cron on a stable line is essentially free.

Recipe 1 — Pinnacle closing-line value (CLV) tracker

The recipe that pays for the Actor in its first weekend.

Setup:

mode: "pre_match_only"
Trigger at T-30 minutes and T-1 minute per fixture
Bet your soft book at T-30, log Pinnacle's T-1 close, compute CLV per ticket

Pinnacle's closing line is the canonical sharp benchmark. If you're consistently beating Pinnacle's close, your edge is real. If you aren't, you can stop pretending — CLV is the ground truth of whether you're a winning bettor or a noise-trader.

Cost for 200 fixtures/week (h2h+spreads+totals, ~7 snapshots × 2 polls each): ~$65/month.

The Odds API doesn't expose "Pinnacle close at T-1" as a first-class field, so you're paying $249/mo for the feed and still rolling your own snapshot scheduler. Here the snapshot scheduler (Apify cron) and the snapshot itself together come in at ~25% of the price.

Recipe 2 — EV-model live edge harvester

The model-on-top use case. If you have a fair-value model and you harvest the moments where book_price × your_fair_value > 1.03, you want a polling firehose during in-play, not an hourly dump.

Setup:

{
  "books": ["pinnacle"],
  "sports": ["basketball", "tennis", "soccer"],
  "marketTypes": ["h2h", "spreads", "totals"],
  "mode": "live_only",
  "deduplicationWindowSeconds": 0
}

Schedule: 60-second cron during target match windows.

Volume: ~50K live snapshots/month × $0.02 + orchestration ≈ ~$1,080 / month.

That looks pricey until you put it next to OddsJam Pro at $499+/mo for a SaaS API you don't control and that throttles by tier. The trade is: you pay more per request, but you pay only for what you actually consume, you set the cadence, and a stable line costs you nothing.

The other thing the SaaS won't sell you: every snapshot includes isLive, matchClock, and matchScore. Your model doesn't have to join against a separate scoreboard feed during a live NBA fourth quarter.

Recipe 3 — Specials sniper (the OddsJam gating trick)

For value bettors and exact-totals modellers. This is the recipe where the pricing gap gets embarrassing.

Pinnacle's withSpecials=true matchups call returns ~5,000 markets per major sport:

First Team To Score (3-way)
Win to Nil 1st Half (yes/no)
Exact Total Goals 1st Half (multi-way)
Winning Margin per scoreline
A long tail of team props and player-related markets

These are the markets soft books are slowest to sharpen up on — which is where the actual edge lives. OddsJam gates futures and props behind their highest tier. The Odds API doesn't surface most of them.

Setup:

{
  "books": ["pinnacle"],
  "sports": ["soccer"],
  "marketTypes": ["specials"],
  "mode": "pre_match_only",
  "deduplicationWindowSeconds": 60
}

Schedule: 4-hour cron during the season.

Volume: ~6K specials snapshots + 180 runs ≈ ~$250 / month for the segment that powers the largest EV pockets in retail sports betting.

A pattern that works: filter the dataset to marketType == "specials" && impliedProbability < 0.10. Pinnacle longshots above 10× implied with sharp money backing are where the soft-book mispricings concentrate.

Recipe 4 — Tipster Discord auto-poster

The cheapest one and the easiest to sell to a small operation.

Setup:

sports: ["soccer"]
leagueFilter: ["UEFA", "EPL", "La Liga"]
mode: "pre_match_only"
Every 6 hours, webhook → Discord

Cost: ~$30/month for a daily top-10 spreads + totals digest piped straight into the channel. If you currently screenshot OddsJam into Discord by hand, this is the upgrade.

The pay-per-event math in one table

Workflow	Volume	Monthly cost	Replaces
Casual bettor — daily 9am pre-match dump, 30 fixtures	~900 snapshots	~$11	$59/mo Odds API tier
CLV tracker — T-30 + T-1, 80 fixtures/wk	~3.2K snapshots	~$65	$249/mo OddsJam Gold
Tipster shop — 100 fixtures × 7 outcomes, hourly	~21K snapshots	~$245	$249/mo OddsJam Gold (parity)
Specials trader — daily soccer sweep	~6K snapshots	~$250	Highest-tier gate (not available below)
EV model — live NBA + tennis + soccer, 90s cron	~50K live snapshots	~$1,200	OddsJam Pro $499+ + you control cadence

Flat-rate SaaS wins only once you cross ~150K snapshots/month of stable workload. Below that — which is most solo sharps, most tipster operations, and every specials trader — PPE is just cheaper, and the cost curve is linear in actual usage rather than tier-jumpy.

The other PPE advantage that quietly compounds: there's no annual contract. Off-season for a sport? Cron stops, billing stops. You don't pay for unused capacity in August when soccer is dead.

Three steps to a running cron

Step 1 — Pick your sports and markets.
Defaults are ["soccer", "tennis"] — the two highest-liquidity sharp markets year-round. For CLV add "spreads", "totals". For specials sniping add "specials". The full sport list is 11 deep (soccer, tennis, basketball, MMA, baseball, hockey, esports, AFL, NFL/college, golf, rugby).

Step 2 — Run once with default input and verify Pinnacle returns data for your sport+league pick. Output lands in your Apify dataset.

Step 3 — Save as Task → Schedules → New Schedule with the cron string you want:

*/5 * * * *    pre-match every 5 minutes
* * * * *      live every minute during target windows
0 9 * * *      daily 9am pre-match dump
0 */6 * * *    every 6 hours
0 10 * * 6     Saturday morning weekly audit

Attach a webhook to the schedule and ship the dataset into your EV pipeline, Discord/Slack bot, Sheets workbook, or wherever your model lives.

Python in 12 lines

from apify_client import ApifyClient

client = ApifyClient("YOUR_APIFY_TOKEN")
run = client.actor("zhorex/sports-odds-aggregator").call(run_input={
    "books": ["pinnacle"],
    "sports": ["soccer", "tennis"],
    "marketTypes": ["h2h", "spreads", "totals", "specials"],
    "mode": "pre_match_only",
    "maxEventsPerSport": 50,
    "deduplicationWindowSeconds": 30,
})

for snapshot in client.dataset(run["defaultDatasetId"]).iterate_items():
    if snapshot["marketType"] == "specials" and snapshot["impliedProbability"] < 0.10:
        evaluate_for_bet(snapshot)

That's the whole integration. Every snapshot arrives in a flat per-market-outcome shape with priceAmerican, priceFractional, price (decimal), impliedProbability, and isBestPriceAcrossBooks on every row — your model doesn't have to do format gymnastics or join against a separate American-odds conversion table.

What a snapshot looks like

{
  "snapshotId": "a1b2c3d4e5f6789012345678",
  "book": "pinnacle",
  "sport": "soccer",
  "league": "Premier League",
  "homeTeam": "Manchester City",
  "awayTeam": "Liverpool",
  "commenceTime": "2026-05-22T19:00:00Z",
  "isLive": false,
  "marketType": "h2h",
  "outcomeKey": "home",
  "outcomeLabel": "Home",
  "price": 1.91,
  "priceAmerican": -110,
  "priceFractional": "10/11",
  "impliedProbability": 0.52356,
  "isBestPriceAcrossBooks": true,
  "scrapedAt": "2026-05-18T14:32:00Z"
}

snapshotId is a stable sha1 derived from book+event+market+outcome+timestamp, so it makes a clean primary key if you're persisting into Postgres / DuckDB.

For high-volume operations

If your monthly burn is past 50K snapshots and you need a dedicated polling cadence, custom market types (Asian handicap quarter-lines, derivative props, fancy bets), or a schema SLA for a downstream production pipeline, the Actor page has an "Enterprise inquiry" pointer. Webhook integrations, dedicated proxy pools, and custom dataset views ship in roughly a week. Sustained seven-figure-action operations can talk dedicated-instance posture.

For everyone else the default Apify Proxy works on Pinnacle's guest API — Pinnacle's public surface tolerates datacenter IPs by design (which is why it's on the supported-books list to begin with). If your plan includes datacenter, override apifyProxyGroups: ["DATACENTER"] and your proxy cost drops to roughly 5% of a residential-default scraper.

Things worth knowing before you run it

Not US bookmakers. DraftKings / FanDuel / BetMGM / Caesars / ESPN BET are geo-gated behind Akamai and need US residential proxy, which kills the per-snapshot economics. Other Apify Actors target those — this one stays out.
Personal-analysis use only. Pinnacle's TOS forbids commercial redistribution of raw odds. The architecture is per-buyer-execution — you run it in your own Apify account against your own polling cadence. Don't resell the feed.
Not a streaming WebSocket feed. Poll-based, fastest meaningful cadence ~60s.
Bet365 returns when Bet365 returns. Cross-book best-price flag and fuzzy event-matching are already in the codebase; the day a second book ships, arb infra activates without an input change.

Where to start

If you currently pay The Odds API or OddsJam Gold $249/mo for the Pinnacle column, the cheapest experiment is:

Spin up the Actor with the default input.
Run it on five of your usual fixtures.
Compare the snapshots against whatever your incumbent feed gave you for the same fixtures.

The break-even comes faster than you'd expect — most workflows under 150K snapshots/month earn back the SaaS subscription inside the first month, and the dedup window keeps marginal cost near zero on stable lines.

Actor link: apify.com/zhorex/sports-odds-aggregator

If the Actor saves you a month of OddsJam Gold, the single highest-leverage thing you can do back is a 30-second review on the Actor page — it directly funds the next defensive patch when the books shift their schemas.

Roadmap is public: Smarkets adapter (v0.4) reactivates cross-book arb infra, Pinnacle alternate-lines / period markets (v0.5) opens half/quarter handicap decomposition, Betfair Exchange BYO-credentials (v0.6), WebSocket mode (v0.7), automatic arb finder (v0.8).

$0.005 per Weibo post — the Chinese social data layer Western teams keep skipping

Sami — Sun, 17 May 2026 16:54:46 +0000

I shipped a Weibo scraper on Apify eight months ago. Fifteen customers pay me on it now, another thirty-four use the free tier, and in the last sixteen days they pulled 136,400 posts through it. I built it because every Western social-listening tool I evaluated — Synthesio, Brandwatch, Meltwater — quoted four to five figures a year for China coverage that was thinner than what you get from one tuned Apify run.

The whole pitch is one number: $0.005 per post. Pay only for items you actually take. The Apify free plan covers your first ~1,000 mentions before you spend a cent.

Weibo Scraper on Apify Store →

What's actually in the box

Four modes. All return normalized JSON. No Weibo login. No API key from Weibo. No VPN.

hot_search — the live hot-topics list, i.e. what 580M+ monthly active users are looking at right now. The single most-watched signal in Chinese social.
search — keyword search across public posts. Brand names, ticker symbols, product launches, Chinese or English.
post_comments — every public comment on a given post. Sentiment grenades and viral crises live here.
user_posts — full posting history of any public account. KOL vetting, executive watch, competitor monitoring.

Output is flat JSON — post text, author handle, timestamp, repost / comment / like counts, media URLs. Push it straight into a warehouse, a Pandas DataFrame, or a Slack alert with a 30-line script.

What people actually pay for

I see what runs every day on this actor. The patterns paying customers settle into:

1. Equity / sentiment signal on China-listed names — ~$25/day, ~$750/month

A small fund or research desk covering BABA, NIO, PDD, BILI, JD, BEKE, LI, XPEV, KWEB constituents, or any China-exposed Western name. Scheduled search over 30-50 tickers and brand names, ~5,000 posts a day, fed into a sentiment model. Sentiment shifts on Weibo lead the Hong Kong open by hours. Dedicated enterprise social-listening contracts that even attempt China coverage start near $30K/year, and most don't index Weibo deeply.

2. Brand monitoring for Western brands in China — ~$15/day, ~$450/month

A consumer brand with China exposure — Apple, Tesla, Nike, Starbucks, LVMH, Lululemon, any DTC brand on Tmall — needs ~3,000 mentions/day on brand and product-line keywords. Comments mode catches crisis posts before they trend. Synthesio / Brandwatch / Talkwalker contracts that include China typically run $30K-$100K/year. The same daily mention stream costs you less than a streaming subscription.

3. KOL / influencer due diligence — ~$1 per KOL

Before you wire 50,000-200,000 RMB to a Weibo influencer for a sponsorship, run user_posts against the handle. Look at posting cadence, real engagement (not vanity follower counts), brand affinity history, controversy flags. One avoided bad deal pays for years of usage.

4. AI / LLM training data — ~1M posts = $5,000

Real-world, conversational, dialect-rich Mandarin from public posts. Filtered Weibo subsets sell on data marketplaces for $20K-$50K and ship stale by months. Pull fresh data on the topics and time windows you care about, own the pipeline, and the per-post cost is a small fraction of either marketplace data or annotator-collected datasets.

5. M&A and pre-deal diligence on Chinese targets — $200-$500 one-off

A pre-LOI sentiment pull on a Chinese target — employee chatter, customer complaints, founder reputation, glass-door-equivalent venting. Boutique diligence firms bill $25K-$75K for the equivalent exercise. As a banker or consultant, even a "$500 in cost, $30K invoice" framing is a 60x markup the client is happy to pay for.

6. Crisis monitoring / hourly brand watch — ~$50/month

Schedule a six-times-a-day run on brand keywords. hot_search catches a viral crisis the moment it crosses into the public consciousness — typically a 4-12 hour head start on Western media coverage. For a brand worth eight figures, that gap is the difference between "managed" and "case study."

7. Macro / consumer-trend reading from the hot list — ~$5/day

The hot search list is the cheapest macro signal in Chinese markets. Tariff reactions, regulatory rumblings, viral consumer products, celebrity scandals that wreck brand deals — all surface here first. Hedge fund quants, geopolitical analysts, and morning-brief writers all bake this in.

The number that matters: $0.005 per item

You pay per item returned. No subscription, no surprise overage.

1,000 mentions: $5
10,000 mentions: $50
100,000 mentions: $500

The Apify free plan gives you ~$5/month in platform credit, which covers your first ~1,000 mentions on this actor. You validate the data fits your use case before you spend a cent.

Start on the free plan →

Quick start

from apify_client import ApifyClient

client = ApifyClient("<YOUR_APIFY_TOKEN>")

# Pull 1,000 posts mentioning Tesla. $5 flat.
run = client.actor("zhorex/weibo-scraper").call(run_input={
    "mode": "search",
    "searchQuery": "特斯拉",
    "maxResults": 1000,
})

# Stream the results
for post in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(post["createdAt"], post["repostsCount"], post["text"][:120])

Same shape works for hot_search, post_comments, user_posts. Swap the mode and the input keys to whatever the run takes. The exact input schema lives on the actor page.

Where the real money lives: recurring runs

One-shot pulls are fine for a diligence assignment. The customers who actually extract serious value from this are the ones running it on a schedule. Apify Schedules takes a cron expression and a saved input — the actor runs forever, the dataset accumulates, and you download it as JSON, CSV, or Excel.

The math gets compelling fast. Below is what my heaviest recurring customers actually run:

Use case	Cron expression	Approx. monthly cost	What it replaces
Morning hot-search dump for the daily brief	`0 9 * * 1-5` (Asia/Shanghai)	~$15	A junior analyst's 30-min daily task
Brand mentions, every two hours	`0 /2 * *`	~$450	$30K/yr Brandwatch contract for China only
Equity tickers, hourly (the highest-ROI cron on this list)	`0 * * * *`	~$750	A $120K/yr China sentiment analyst, half-replicated
Crisis watch, every 30 minutes	`/30 * * *`	~$1,500	A 24/7 PR monitoring agency contract
Overnight KOL sweep on 200 handles	`0 2 * * *`	~$60	$5K/mo influencer-vetting subscription

Set the cron once, walk away, get paid in compounded insight. The customers running hourly equity cron jobs have been doing it for months without touching the config — the actor runs, the data lands, the alpha shows up in their dashboards. That's the only mode of use that actually justifies the time you invested learning the schema.

If you take one thing from this post: don't run it manually twice — wire the second run into a cron. The actor was built for that, the pricing was designed for that, and that's where every customer who renewed went.

Reliability and what happens when things break

You pay per item. If the actor returns nothing on a run, you pay nothing. If it returns 327 items, you pay for 327. That alignment is the whole reason I picked per-event pricing instead of a monthly subscription — my incentive to keep the thing working is exactly your incentive that it works.

I monitor the actor daily. When something upstream changes, I ship a fix within hours, not weeks. The Apify Store rating and issue history on the actor page are public.

Why I priced it like this

I shipped this eight months ago. By month two it was profitable. The most recent sixteen-day window: fifteen paying customers, 136,400 items returned, $697 revenue, $675 profit, 96.79% margin. The margin isn't there because the work is trivial — it's there because per-event pricing means I only earn when the data is actually delivered.

If you're evaluating Chinese social tools and the lowest quote you can get is $20K+, run a 1,000-mention probe through this actor first. You'll know inside ten minutes whether the data covers your use case. Worst case, you spend $5. Then wire it into a cron and forget about it.

Try it on the free plan →

Other Chinese-platform actors I run

Weibo is the macro signal layer for China. These cover the rest of the surface area:

Xiaohongshu / RED scraper — lifestyle, beauty, female-skewing audience. The #1 platform for DTC brand launches in China.
Bilibili scraper — long-form video, Gen Z, gaming / anime / tech vertical signal.
Douban scraper — books, films, music, niche communities. The most "honest" review platform in China.
Xueqiu scraper — retail-trader-heavy financial discussion. Equity-desk supplement to Weibo.
Chinese Brand Monitor — composite brand signal across the platforms above.

All same pricing model. Pay per item. Schedule freely.

Compliance posture

Only public Weibo posts. No private accounts, no DMs, no content behind a login wall.
No login bypass. The actor does not log into Weibo on your behalf, and does not need an account to function.
Optional cookies are user-supplied and only raise your personal rate limit. They are never required for the actor to work.

If your use case requires private data, this actor isn't it — and frankly nothing on the Apify Store will be.

If you actually run something interesting with it, leave a comment or open an issue on the actor page — I read all of them.

apify.com/zhorex/weibo-scraper

Track brand mentions across China's top 5 social platforms in one API call — $0.045 per mention

Sami — Sat, 16 May 2026 10:36:57 +0000

If your brand competes for Chinese consumers and you're not actively monitoring conversations on Weibo, RedNote, Bilibili, Douban, and Xueqiu, you're flying blind in the world's second-largest consumer market.

The problem is that the "enterprise" way to do this — Synthesio, Brandwatch, Talkwalker — starts at $50,000 per year for Chinese platform coverage, with annual contracts, locked-in seats, and a sales cycle measured in weeks. So most mid-market teams just… don't. They monitor English-language Twitter for their global brand, see a sentiment dip in APAC revenue a quarter later, and have no leading signal explaining why.

Chinese Brand Monitor launches today on the Apify Store to fix that. One API call, five platforms, normalized output, $0.045 per mention. No subscription. No annual contract. No minimum spend. Run it once, run it daily, run it hourly — you only pay for the mentions you actually pull.

The 5 platforms in one call

Platform	What it captures	Why it matters for brand monitoring
Weibo (微博)	Public microblog mentions, KOL posts, hot search trending	China's Twitter. 580M+ users. Where consumer crises break first and where KOL endorsements reach hundreds of millions in hours.
RedNote / Xiaohongshu (小红书)	Lifestyle and consumer brand notes, first-person product reviews	300M+ users. The single highest-trust channel for Chinese consumer purchase decisions in beauty, skincare, fashion, food, travel.
Bilibili (B站)	Video titles, descriptions, and creator mentions	China's YouTube. 300M+ users. Where Gen Z consumer brand affinity is built and where unboxing / review culture lives.
Douban (豆瓣)	Movie / book / music subject mentions, brand tie-ins, soundtracks, branded titles	200M+ users. Long-form opinion-rich content — the densest source of detailed consumer attitude data outside Zhihu.
Xueqiu (雪球)	Stock cashtag and corporate mentions for listed brands	20M+ users, financial-grade signal. Critical if your brand is publicly listed (NYSE:BABA, NASDAQ:JD, HK:00700, A-share tickers) — finance KOLs move retail sentiment fast.

These five platforms cover the full spectrum: broad public opinion (Weibo), high-trust consumer reviews (RedNote), Gen-Z video sentiment (Bilibili), long-form opinion (Douban), and investor sentiment (Xueqiu). For most consumer brands, monitoring any 3 of these in real time is a leading indicator that beats your CRM dashboards by 2-6 weeks.

Why each mention is worth $0.045

It's tempting to look at $0.045 and compare it to "free" Twitter mentions. That's the wrong comparison. The right comparison is: what would it cost you to get one Chinese consumer mention, normalized, sentiment-tagged, and cross-platform-deduplicated, any other way?

Synthesio / Brandwatch / Talkwalker enterprise seat: $50K+/year minimum. Cost per mention at typical 100K mentions/year volume: $0.50. 11× the cost of this Actor.
Hire a Chinese-speaking VA to manually check 5 platforms: ~$15/hour, ~30 mentions/hour effective. Cost per mention: $0.50. Same 11× cost, plus 24-48 hour latency.
Build it yourself: 5 separate scrapers, 5 different output schemas to parse, dedup logic, sentiment classifier, ongoing maintenance every time a platform changes their frontend. Conservatively 60-100 engineering hours upfront and 10-20 hours/month ongoing. At $150/hr loaded engineer cost, that's $9K-$15K to build + $1.5K-$3K/month to maintain. Break-even vs this Actor: never, unless you're pulling >100K mentions/month.

Every mention you pull at $0.045 buys you: the raw text, the author identity (handle, follower count, verified flag), the engagement metrics (likes, comments, shares), the timestamp, the URL, media URLs, language detection, lexicon-based sentiment scoring, and — if dedup is enabled — a crossPlatformReposts array showing exactly which other platforms amplified the same content. That's a record your competitive intelligence analyst would gladly take and immediately put into a deck.

The more you run it, the more leverage you get from each run. A single weekly snapshot tells you nothing about velocity. A daily run shows you trends. An hourly run during a crisis or product launch shows you the inflection point in real time — which is when one mention is worth $4.50 to your PR team, not $0.045.

8 concrete use cases (run it like this)

1. Daily brand health dashboard

Workflow: Cron daily at 8am local time, single brand keyword, 7-day lookback, sentiment + dedup enabled. Push the canonical mentions to your BI tool (Looker / Metabase / Hex / Sigma) for a stacked-by-platform sentiment chart, follower-weighted reach total, and top-10 highest-engagement mention list. Run for 30 days, you have a baseline. Run for 90 days, you have a leading-indicator dashboard your CMO will check daily.
Volume: 100 mentions/day × 30 days = 3,000/mo. Cost: ~$135/mo per brand.
Compare to: $4,000/mo for a Synthesio seat covering the same platforms.

2. Crisis monitoring (hourly polling with Slack alerts)

Workflow: Cron every hour, 1-day lookback, sentiment-enabled, filter for sentiment.polarity == "negative" AND authorFollowerCount > 10000. Pipe matching records to a Slack webhook that pings #pr-alerts. The moment a verified KOL posts a negative mention, your PR team knows within 60 minutes — versus 24-72 hours via Google Alerts or "someone forwarded it to me."
Volume: Most hours return 0-5 mentions. ~200 mentions/day amortized = 6,000/mo. Cost: ~$270/mo per brand. Single prevented PR crisis pays for the entire year.

3. Pre-launch competitor intelligence (one-off pull)

Workflow: Before launching a new SKU in China, pull 30 days of mentions on each competitor brand keyword across all 5 platforms. Look at: which platforms each competitor over-indexes on, which KOLs are talking about them, what sentiment dominates, what product attributes get the most positive vs negative mentions. Run this once a quarter on 5 competitors and you have the best competitive intel deck in the room.
Volume: 5 competitors × 500 mentions each = 2,500 mentions one-time. Cost: ~$112 one-time per quarter.

4. KOL identification and vetting

Workflow: Weekly run on your category keyword (e.g. "护肤" for skincare, "球鞋" for sneakers). Pull 500 mentions/week. Filter the output for authorVerified == true AND authorFollowerCount > 50000. Sort by engagementMetrics.likes descending. Top 20 results = your candidate KOL list for the week, scored by actual cultural reach not by paid impressions. Compare against your influencer agency's recommendations.
Volume: 500 mentions/week × 4 weeks = 2,000 mentions/mo. Cost: ~$90/mo per category.

5. China-watcher hedge fund alt-data signal

Workflow: Daily run on each portfolio ticker that has Chinese consumer exposure (BABA, JD, PDD, BIDU, NIO, BYD, ANTA, Yum China, POP MART, etc.). Pull mentions from Xueqiu (financial sentiment) + Weibo (consumer sentiment) + RedNote (brand affinity for consumer brands). Build a sentiment-velocity feature: 7-day mention count delta + sentiment polarity shift. Backtest against earnings surprises and brand event days — Chinese consumer sentiment leads Western analyst consensus by 2-6 weeks for most consumer-facing names.
Volume: 20 tickers × 50 mentions/day = 1,000/day × 22 trading days = 22,000/mo. Cost: ~$990/mo. Compare to: a single Bloomberg China consumer alt-data feed subscription, $80K-$200K/year minimum.

6. AI / LLM training data corpus

Workflow: One-time bulk pull on a diverse set of brand keywords across consumer categories. 50 brands × 1,000 mentions each = 50K labeled Chinese-language consumer text records with explicit sentiment labels. Drop into your SFT or RLHF pipeline for Chinese-language consumer-domain fine-tuning. This is the densest source of brand-grounded labeled Chinese text outside of paid academic corpora.
Volume: 50,000 mentions one-time. Cost: ~$2,250 one-time. Compare to: licensing a comparable academic corpus from Trinity College Dublin or Tsinghua, $15K-$50K per corpus, single-use license, 6-month delivery.

7. Cross-platform virality discovery (run it weekly, look at the dedup array)

Workflow: Weekly run, dedup ENABLED, scan the output for canonical records where crossPlatformReposts.length >= 2. Those are mentions that spread across multiple platforms within 24 hours — the closest thing to a "viral" signal you can extract from raw mention data. Use it to identify breakout moments before they hit mainstream Chinese media.
Volume: 500 mentions/week × 4 weeks = 2,000/mo. Cost: ~$90/mo per brand. Most viral moments cost $50K-$200K in PR services to capitalize on; this is how you find them 48-72 hours earlier than the agency.

8. Multi-brand portfolio monitoring (agency workflow)

Workflow: One Actor run per client brand, scheduled daily via Apify Schedules. 10 clients × 500 mentions/brand/day = 5,000 mentions/day. Each client gets their own dataset and dashboard. The agency bills $2K-$5K/client/month for "China monitoring," delivers a custom dashboard, and the underlying data cost is ~$675/client/month — leaving healthy 70%+ gross margin per client.
Volume: 5,000 mentions/day × 30 days = 150,000/mo. Cost: ~$6,750/mo for 10 brands. Revenue at $3K/client × 10 = $30K/mo. Gross margin: 77.5%.

What the output looks like

Every mention is normalized to the same schema regardless of platform. Here's a real Weibo mention from a test run on the Chinese sportswear brand 李宁 (Li-Ning):

{
    "mentionId": "weibo_4923475823745",
    "platform": "weibo",
    "brandKeyword": "李宁",
    "brandMatchType": "exact",
    "content": "李宁的新款跑鞋质量真不错，比之前的耐克舒服多了！",
    "language": "zh-CN",
    "authorName": "运动达人",
    "authorFollowerCount": 12500,
    "authorVerified": true,
    "publishedAt": "2026-05-15T14:32:11+00:00",
    "engagementMetrics": { "likes": 234, "comments": 18, "shares": 42 },
    "url": "https://weibo.com/1234567890/4923475823745",
    "sentiment": { "polarity": "positive", "score": 0.72 },
    "crossPlatformReposts": [
        { "platform": "rednote", "url": "https://www.xiaohongshu.com/explore/abc123" }
    ]
}

Three fields buyers tell me they care about most:

sentiment — lexicon-based Chinese sentiment scoring on every mention. Polarity (positive / neutral / negative) plus a numeric score. Disable it if you have your own pipeline; enabled by default.
crossPlatformReposts — the same viral post often appears across Weibo and RedNote within hours. The aggregator detects this with SimHash similarity and merges duplicates into the canonical record, with the repost paths preserved. You don't pay twice for the same mention, and you get a free virality signal.
authorFollowerCount / authorVerified — the difference between a 200-follower throwaway account and a 1.2M-follower verified KOL is the difference between "ignore this" and "alert the C-suite." Follower-weighting your dashboard is the first thing every serious buyer does with the data.

Quick start

The input is brutally simple. This is a complete config:

{
    "brandKeyword": "李宁",
    "platforms": ["weibo", "bilibili", "rednote", "douban", "xueqiu"],
    "maxMentionsPerPlatform": 200,
    "lookbackDays": 7,
    "sentimentAnalysis": true,
    "deduplication": true
}

One brand keyword, one call, get back a normalized stream of mentions across all five platforms. The lookbackDays filter applies per platform so you only get fresh content; deduplication collapses cross-platform reposts; sentimentAnalysis tags every record.

To run it on a schedule (which is where the real value compounds): use Apify Schedules and set a cron expression. 0 8 * * * for daily 8am runs, 0 * * * * for hourly, */15 * * * * for every 15 minutes during a launch or crisis. Each run hits the same Actor with your saved input config, pushes to the same dataset, and bills only on the new canonical mentions. The Actor is built to be run thousands of times — that's how you go from "snapshot" to "monitoring system."

If you have cookies for any of the platforms (logged-in browser session) you can pass them under cookieStrings to unlock higher recall and rate limits. Cookies are optional — the actor degrades gracefully without them.

For deeper single-platform scraping (full comment trees, infinite scroll, profile enrichment), use the dedicated single-platform actors directly:

Weibo Scraper — posts, hot search, comments, profiles
RedNote (Xiaohongshu) Scraper — notes, comments, profiles, video
Douban Scraper — long-form reviews and group discussions
Xueqiu Scraper — ticker-tagged posts, KOL tracking
JD.com Scraper — product detail extraction

The aggregator is for recurring cross-platform brand monitoring with normalized output. The single-platform scrapers are for one-off deep extraction inside one platform.

What this is NOT

Being honest about scope is more useful than vague promises:

Not real-time streaming. Poll-based — 5-15 minute effective refresh is realistic. If you need millisecond latency, this isn't it.
Not WeChat coverage. WeChat has no public scraping interface; trying is a fast way to get accounts banned.
Not Douyin (TikTok China). Out of scope for v0.1 — under evaluation for the roadmap.
Not a Synthesio replacement at the largest enterprise scale. Synthesio also covers TV, podcasts, news, and provides a managed-service layer. This Actor is the data layer; bring your own BI / dashboard / alerting stack. Most teams who pick this over Synthesio are choosing it because they already own their BI stack and just need the raw normalized feed at a sane price.

Compliance posture

Only public mentions — no private accounts, no DMs, no follower lists.
No login bypass; cookies are user-supplied for higher rate limits only, and they're stored as a secret in the Apify input schema (encrypted at rest).
Reviewer / commenter nicknames are partially redacted by the source platforms; this Actor passes through what the platforms display. No additional PII enrichment.

Try it free, then scale it

The Apify free plan includes monthly platform credit that covers a meaningful first batch of mentions — enough to validate the data quality on your own brand keyword before any commitment.

Try Chinese Brand Monitor on Apify →

The flow most teams follow:

Week 1: Run it once manually on your main brand keyword. Verify the output quality on a brand you know well — every mention should be one you'd recognize. (~$2-5 spend.)
Week 2: Wire it into a daily Apify Schedule. Stream the dataset to your BI tool. Watch one week of trend data. (~$25-50 spend.)
Week 3: Add a second brand keyword (competitor, partner, or category term). Add a Slack webhook for negative-sentiment alerts above a follower threshold. (~$50-100 spend.)
Month 2 onward: Production. Daily monitoring on your core brand portfolio, hourly during launches and crises, monthly competitive intel pulls. (Typical mid-market team: $200-1,500/mo.)

Pricing is transparent at every step: $0.045 per canonical mention, billed only on the deduplicated records. No subscription, no minimum spend, no annual contract. Pause it for a month, scale it up 10x next week, switch brand keywords mid-run — it all just works.

The teams getting the most out of this are running it on a schedule, daily or hourly, across multiple brand keywords, piping the normalized output into their existing BI / Slack / dashboard stack. Each run pays for itself in the first time it surfaces a mention you would have missed.

Open an issue on the Actor page if you hit any edge case. Typical turnaround on fixes is 48 hours.

JD.com's isJdSelfRun Flag Is the Best Gray-Market Detection Signal in Chinese E-Commerce (Python Scraper Inside)

Sami — Fri, 15 May 2026 22:08:41 +0000

If your brand sells on JD.com (China's #2 e-commerce platform, ~600M annual active users) — or competes against one that does — there's a gray-market problem you can't see without one specific field in JD's data.

That field is isJdSelfRun. It tells you whether a given product listing is fulfilled by JD itself (their warehouses, their warranty, their return logistics) or by a third-party merchant on JD's marketplace. Combined with the seller's sellerType (flagship / franchise / specialty / self-run), it's the single cleanest signal for detecting unauthorized resellers on Chinese e-commerce — and almost no generic scraper surfaces it.

This post walks through:

Why JD's hybrid retail model creates the gray-market detection opportunity
The exact field signatures (isJdSelfRun, sellerType) and what they mean
Three concrete workflows: brand authorization audit, competitive pricing, gray-market detection
A 50-line Python integration with the Apify Actor I built around this
Honest cost math at indie scale and at hedge-fund scale

If you don't want to read the whole thing: the Actor is at zhorex/jd-scraper, and pricing is $0.008 per product detail + $0.02 per seller store record (pay-per-event, no subscription).

The hybrid retail model that creates the signal

JD.com is structurally different from Tmall and Pinduoduo. Tmall is a marketplace — every SKU is sold by a third-party merchant; Alibaba just runs the platform. JD operates a hybrid: a meaningful chunk of its catalog is sold and shipped by JD itself (JD Logistics, JD Plus warranty, JD's own returns), with the rest fulfilled by marketplace merchants.

That hybrid creates an information asymmetry buyers can exploit. When a consumer searches a brand's SKU on JD, they see all listings — but the trust signal comes from whether it's JD-self-run or a third-party. For a brand monitoring team, the question becomes: of the third-party listings of my SKU, which are authorized resellers and which are gray-market?

The data answers it in two fields:

{
    "productId": "100009082476",
    "sellerName": "Apple产品京东自营旗舰店",
    "isJdSelfRun": true,
    "sellerId": "1000003566",
    ...
}

isJdSelfRun: true means JD is the seller. The other listings — those with isJdSelfRun: false — are where the gray-market questions live, and where you need the seller's type to decide.

The seller type enum

A separate scrape against the seller store endpoint resolves to one of four values:

{
    "sellerId": "1000003566",
    "sellerType": "flagship_store",
    "serviceScore": 4.9,
    "logisticsScore": 4.8,
    "descriptionAccuracyScore": 4.9,
    ...
}

flagship_store (官方旗舰店) — the brand's own JD store. There should be exactly one per brand. If you see multiple, you have a counterfeit-or-impersonator problem.
franchise_store (品牌专营店) — authorized franchise of the brand. Brands typically maintain a list of these.
specialty_store (专卖店) — third-party that specializes in selling the brand. Often authorized via distribution agreement; sometimes gray-market.
jd_self_run (京东自营) — JD's direct retail. Always legitimate.

The canonical gray-market signature: a flagship_store listing alongside three specialty_store listings priced 20-40% lower on the same SKU. Those specialty stores are usually moving inventory acquired outside the authorized channel (parallel imports, diverted product, refurbished-as-new). They're flagged the moment your monitoring sees the price gap.

Three workflows the data unlocks

Workflow 1 — Brand authorization audit

Submit your SKU IDs. Get back a record per listing with sellerType resolved. Filter to entries where isJdSelfRun: false AND sellerType is not in your authorized list. That's your unauthorized reseller list, refreshed on whatever cadence you want.

A small brand watching 50 SKUs across 200 listings (4 average sellers per SKU) costs about $2 per refresh: 200 seller records × $0.02 + 50 product details × $0.008 = $4.40 ($2.20 if you skip product detail and only check sellers).

Workflow 2 — Competitive pricing intelligence

The product detail mode returns a realtimePrice field that is fetched fresh at scrape time, not parsed from cached HTML. JD runs flash discounts that move prices within hours; cached scrapers miss them entirely.

Tracking 200 competitor SKUs hourly = 200 × 24 × 30 = 144,000 detail records per month, $1,152 in raw event cost. At hedge-fund-grade refresh rates this is real money, but it's the right order of magnitude for the buyer cohort that already pays $3K-15K/month for alt-data feeds.

Tracking 200 SKUs daily (more realistic for a brand team) = 6,000 records × $0.008 = $48/month. Cheap enough to run as a cron.

Workflow 3 — Gray-market detection at scale

The canonical pattern in code:

for product in products:
    listings = [l for l in product["allListings"] if not l["isJdSelfRun"]]
    cheap_specialty = [
        l for l in listings
        if l["sellerType"] == "specialty_store"
        and l["price"] < product["msrp"] * 0.80
    ]
    if len(cheap_specialty) >= 3 and any(l["sellerType"] == "flagship_store" for l in listings):
        alert(product, cheap_specialty)

That's the brand-monitoring signal: a real flagship store coexisting with three or more sub-MSRP specialty stores on the same SKU. Brand teams pay agencies five-figure annual contracts to surface exactly this kind of alert; running it yourself on this data feed costs cents per check.

The 50-line Python integration

Here's the working integration end-to-end. Replace YOUR_TOKEN with your Apify API token:

from apify_client import ApifyClient

client = ApifyClient("YOUR_TOKEN")

# Scrape product details for your SKU list
run = client.actor("zhorex/jd-scraper").call(run_input={
    "mode": "product_detail",
    "productUrls": [
        "https://item.jd.com/100009082476.html",
        "https://item.jd.com/100012345678.html",
    ],
})

unauthorized_sellers = set()
for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    if not item["isJdSelfRun"]:
        unauthorized_sellers.add(item["sellerId"])
        print(
            f"Non-self-run listing: {item['productTitle']}\n"
            f"  Seller: {item['sellerName']} (id {item['sellerId']})\n"
            f"  Price: {item['realtimePrice']}\n"
        )

# Now drill into those sellers to classify them
if unauthorized_sellers:
    seller_run = client.actor("zhorex/jd-scraper").call(run_input={
        "mode": "seller_store",
        "sellerUrls": [f"https://mall.jd.com/index-{sid}.html" for sid in unauthorized_sellers],
    })
    for seller in client.dataset(seller_run["defaultDatasetId"]).iterate_items():
        flag = "⚠️ AUDIT" if seller["sellerType"] == "specialty_store" else "✅"
        print(f"{flag} {seller['sellerName']} → {seller['sellerType']} (service: {seller['serviceScore']})")

That's the whole audit. Two API calls, classified output, ready to feed into Slack alerts / spreadsheet exports / BI dashboards.

Honest pricing — what does this cost in production?

Workflow	Volume / month	Cost / month
Brand watchlist — 50 SKUs daily	1,500 product details	~$12
Brand authorization audit	500 sellers, monthly	~$10
Competitive pricing — 200 SKUs daily	6,000 product details	~$48
Competitive pricing — 200 SKUs hourly	144,000 product details	~$1,152
Gray-market sweep — 200 SKUs + 50 sellers	200 details + 50 sellers	~$2.60

Indie brand teams typically run the daily/monthly workflows ($10-60/month). Hedge-fund alt-data and agency-scale customers run hourly or 15-minute refreshes (low four figures monthly). Both work on the same Actor with the same event-priced billing.

What this Actor doesn't do

Two honesty disclosures:

No search discovery. You bring the SKU list. Discovery requires a different scraping pattern that doesn't survive shared residential proxy pools the way product detail and seller store do.
No review scraping. Same reason — JD's WAF gates the review API at the IP-reputation level on shared pools. If you need review sentiment, the Apify Store has other scrapers, or contact me for a premium-proxy integration.

The README on the Actor page documents this in a "Known limitations" section. If your workflow needs either, this Actor isn't the right tool.

Why I built this

I run a portfolio of six Chinese-platform scrapers on Apify Store (zhorex). Five of them cover sentiment and content: Weibo for trending, RedNote (Xiaohongshu) for lifestyle, Bilibili for video, Douban for long-form reviews, Xueqiu for stock-cashtag discussion. The JD scraper extends the suite into commerce — the missing layer for buyers who already use the social ones for brand monitoring.

The six together are a stack. A consumer-electronics brand can track sentiment on Weibo, video reviews on Bilibili, lifestyle unboxings on RedNote, and gray-market resellers on JD — all on the same vendor, same billing, same API surface.

Try it

The Actor is live: zhorex/jd-scraper. Pay-per-event billing — no subscription, no setup fee. Run a small evaluation batch (the Apify Free plan includes monthly platform credit you can apply to the run) to confirm output quality on your SKU list before scaling up.

The rest of the Chinese Digital Intelligence Suite:

Weibo Scraper — pair with JD to catch when a SKU trends socially before stock-outs hit
RedNote Scraper — Chinese lifestyle unboxings; useful for fashion, beauty, baby, home brands
Bilibili Scraper — video reviews; especially valuable for tech and consumer electronics SKUs
Xueqiu Scraper — Chinese retail-investor sentiment; pair if you trade JD stock (NASDAQ:JD) alongside operational metrics
Douban Scraper — long-form film / book / music reviews; less relevant for commerce but useful for IP / entertainment teams

If you ship a brand-monitoring workflow on top of any of these, drop a comment with what you're tracking. If this saved you the time of building an integration from scratch, a heart on the post or a follow keeps these writeups coming.

Scraping Chinese Social Platforms for LLM Training Data: A Practical Multi-Source Pipeline (Python, 2026)

Sami — Tue, 12 May 2026 20:02:05 +0000

If you're training Chinese-language models — or multilingual models that need real Chinese coverage, not just translated English — the data problem is the bottleneck. Common Crawl gives you the open web. HuggingFace gives you the curated stuff. But the linguistic patterns that matter most for cultural alignment — slang, memes, code-mixed English-Chinese, regional variations, real-time discourse — those live in places Common Crawl barely touches.

Three platforms that matter most for Chinese training corpora in 2026:

Weibo (微博) — 580M+ MAU, microblogging, real-time discourse, similar role to X/Twitter
Bilibili (哔哩哔哩) — 300M+ MAU, video platform, comments + danmaku give you code-mixed natural language at volume
Xiaohongshu / RedNote (小红书) — 300M+ MAU, lifestyle posts with longer-form content, female-skewed register

This post walks through how to build a multi-source pipeline that pulls clean structured data from all three, normalize across platforms, and ship it into your training datasets. With code, schema, and economics.

A note on legal posture: this entire pipeline accesses only publicly visible data — no auth bypass, no captcha solving, no scraping behind login. That matches the standard most AI training teams operate under in 2026, post-NYT-vs-OpenAI. Always consult your legal team for your specific use case and jurisdiction.

Why these three (and not, say, Douyin or Zhihu)

Each platform contributes a different linguistic register:

Weibo posts are short, high-frequency, conversational. Best for:

Everyday Mandarin patterns
Trending slang and memes (热搜 reflects what's actually viral right now)
Public sentiment on news and policy
Brand-mention contexts

Bilibili comments and danmaku are unique:

Heavy code-mixing English ↔ Chinese (gaming, tech, anime communities)
Real-time chat-style language
Subculture vocabulary (gaming, fandom, two-dimensional culture / 二次元)
Longer thread discussions on long-form videos

RedNote posts lean longer and more curated:

Beauty / lifestyle / travel / food vocabulary
Product-attribute language (skincare ingredients, fashion descriptors)
Female-skewed register and topics
Aspirational / descriptive framing

Douyin (Chinese TikTok) and Kuaishou are dominantly video — text data is sparse. Zhihu (Q&A) is great for long-form but dominated by single-author voice. The triad above gives you the best balance of volume, diversity, and accessibility.

Pipeline architecture

The cleanest architecture for an AI training data pipeline:

[Weibo Scraper]    →
[Bilibili Scraper] →  [Normalize]  →  [Dedup + Filter]  →  [JSONL]
[RedNote Scraper]  →

Each scraper outputs platform-native JSON. A normalization layer flattens to a common schema. Deduplication on text hash + filtering by min-length / language detection ships clean data into your training format.

Below: I use Apify-hosted scrapers for the extraction layer (they handle anti-bot, rate limiting, and schema stability so you don't have to). The normalization + dedup is your code — straight Python.

Step 1 — Pulling from Weibo

For training data, the high-value combination is:

Hot search topics (real-time trending — what people are talking about right now)
Posts under those topics (organic conversation about real issues)

from apify_client import ApifyClient

client = ApifyClient("YOUR_APIFY_TOKEN")

def collect_weibo_corpus(target_topics: int = 50, posts_per_topic: int = 100):
    # 1a. Pull current trending topics
    topics_run = client.actor("zhorex/weibo-scraper").call(run_input={
        "mode": "hot_search",
        "maxResults": target_topics,
    })
    topics = list(client.dataset(topics_run["defaultDatasetId"]).iterate_items())

    # 1b. For each topic, pull underlying posts
    corpus = []
    for topic in topics:
        posts_run = client.actor("zhorex/weibo-scraper").call(run_input={
            "mode": "search",
            "searchQuery": topic["title"],
            "maxResults": posts_per_topic,
        })
        for post in client.dataset(posts_run["defaultDatasetId"]).iterate_items():
            corpus.append({
                "platform": "weibo",
                "topic": topic["title"],
                "category": topic.get("category"),
                "text": post.get("text", ""),
                "author": post.get("authorName"),
                "engagement": (post.get("attitudesCount", 0) +
                               post.get("commentsCount", 0) +
                               post.get("repostsCount", 0)),
                "post_url": post.get("postUrl"),
                "scraped_at": post.get("scrapedAt"),
            })
    return corpus

Volume math: 50 topics × 100 posts = 5,000 items per snapshot. At $0.005/item that's $25 per pull. Run daily for a year ≈ $9,125.

Step 2 — Pulling from Bilibili

Bilibili gives you something the others don't: comments on long-form videos. That's where heavy code-mixing happens (tech tutorials, gaming streams, study-with-me content, drama analysis). For training data, comments are higher-value than video metadata.

def collect_bilibili_comments(category: str = "knowledge",
                               videos: int = 50,
                               comments_per: int = 100):
    # Get popular videos in the category
    popular_run = client.actor("zhorex/bilibili-scraper").call(run_input={
        "mode": "popular",
        "category": category,
        "maxResults": videos,
    })
    items = list(client.dataset(popular_run["defaultDatasetId"]).iterate_items())
    bvids = [v["bvid"] for v in items if v.get("bvid")]

    # Pull comments on each
    corpus = []
    for bvid in bvids:
        comments_run = client.actor("zhorex/bilibili-scraper").call(run_input={
            "mode": "video_comments",
            "videoUrls": [f"https://www.bilibili.com/video/{bvid}"],
            "maxComments": comments_per,
            "sortComments": "hot",
        })
        for c in client.dataset(comments_run["defaultDatasetId"]).iterate_items():
            if c.get("type") != "comment":
                continue
            corpus.append({
                "platform": "bilibili",
                "category": category,
                "text": c.get("text", ""),
                "author": c.get("authorName"),
                "engagement": c.get("likeCount", 0),
                "video_bvid": bvid,
                "scraped_at": c.get("scrapedAt"),
            })
    return corpus

Note: Bilibili throttles comment depth on cloud IPs — top ~3 per video without residential proxies. For training-data scale you don't need every comment, just enough diversity, so the top-N approach is fine and cheaper.

Categories worth pulling for diverse coverage: knowledge, tech, game, life, food, fashion, cars, entertainment.

Step 3 — Pulling from RedNote

RedNote gives you longer, more curated content — good for training models on aspirational and descriptive Chinese. The seed-query approach lets you control topical distribution, important for avoiding bias toward whatever's trending the day you scrape.

def collect_rednote_corpus(seed_queries: list, posts_per_query: int = 50):
    corpus = []
    for query in seed_queries:
        run = client.actor("zhorex/rednote-xiaohongshu-scraper").call(run_input={
            "mode": "search",
            "searchQuery": query,
            "maxResults": posts_per_query,
        })
        for post in client.dataset(run["defaultDatasetId"]).iterate_items():
            corpus.append({
                "platform": "rednote",
                "topic": query,
                "text": post.get("title", ""),
                "author": (post.get("author") or {}).get("nickname"),
                "engagement": post.get("likes", 0),
                "post_url": post.get("postUrl"),
                "scraped_at": post.get("scrapedAt"),
            })
    return corpus

# Diverse seed queries spread coverage across topics
seeds = [
    "护肤心得",      # skincare experience
    "穿搭",          # outfits
    "美食推荐",      # food recommendations
    "旅行攻略",      # travel guides
    "健身打卡",      # fitness check-in
    "读书笔记",      # reading notes
    "育儿日记",      # parenting diary
    "职场感悟",      # work reflections
]
rednote_data = collect_rednote_corpus(seeds, posts_per_query=100)

For richer body content per post (beyond title), pivot to mode: post_details with the post URLs you want to deep-dive on.

Step 4 — Normalization and dedup

All three scrapers produce platform-specific schemas; the per-step code above already brings them to a common shape:

{
    "platform": "weibo" | "bilibili" | "rednote",
    "topic": str,
    "text": str,
    "author": str,
    "engagement": int,
    "scraped_at": ISO8601,
}

Enough to ship into a JSONL training format. For higher quality, layer in filtering:

import hashlib

def filter_corpus(corpus, min_chars: int = 10, max_chars: int = 5000):
    seen = set()
    out = []
    for item in corpus:
        text = (item.get("text") or "").strip()
        if not (min_chars <= len(text) <= max_chars):
            continue
        h = hashlib.md5(text.encode("utf-8")).hexdigest()
        if h in seen:
            continue
        seen.add(h)
        out.append(item)
    return out

For pretraining-grade quality, also add fastText / langdetect to filter non-Chinese content, and a profanity / PII pass appropriate to your training context.

Economics at training-corpus scale

A reasonable Chinese-language pretraining contribution might be 10M items across platforms:

Platform	Items	Cost @ $0.005
Weibo	5M	$25,000
Bilibili	3M	$15,000
RedNote	2M	$10,000
Total	10M items	$50,000

Apify free tier ($5/month credit) covers ~1,000 items per actor for prototyping.

For comparison, hiring 2 senior engineers to build and maintain DIY Chinese-platform extraction for 6 months: $150K-300K — and you don't even get the data, just the tooling.

For 100M+ items (real pretraining scale), volume pricing or a custom enterprise contract makes sense. See enterprise section below.

When to build vs buy

Build it yourself if:

You're scraping 100M+ items per month and have a dedicated team
You need real-time streaming below 1-second latency (this pipeline is batch)
Your legal team requires you to own the entire data path

Use the hosted scrapers if:

You're under 50M items per month per platform
You want time-to-data measured in hours, not months
You don't want to maintain three platform-specific scrapers as APIs evolve

The actors

Weibo Scraper — hot_search, search, post_comments, user_posts
Bilibili Scraper — search, popular, video_detail, video_comments, user_videos
RedNote (Xiaohongshu) Scraper — six modes covering posts, profiles, comments, video

All three at $0.005/result. Pure HTTP — no browser, no proxy required for moderate volumes.

Enterprise / training-scale

If you're building actual training corpora (not prototyping), DM me on any actor page or open an Issue with subject "Training data inquiry":

Custom output schemas matched to your training pipeline (Parquet / Arrow / your dialect of JSONL)
Volume pricing above 1M items/month per platform
Dedicated proxy infrastructure for sustained throughput
Schema stability SLA so your training runs don't break mid-epoch

Issues typically get a response within 48 hours.

FAQ

Is this legal? Each Actor accesses only publicly visible data — no auth, no captcha bypass, no login walls. The same data any anonymous browser user can see. Standard ToS-compliant scraping posture as of 2026. Consult your legal team for jurisdiction-specific guidance.

What about rate limits? The hosted Actors handle rate-limit responses with exponential backoff. For 1M+ items/day per platform, talk to me about dedicated infrastructure.

Can I get historical data? The Actors return what's currently public. For longitudinal datasets, schedule them via Apify Schedules at the cadence you need (hourly / daily / weekly) and version-control your dataset snapshots.

Do you offer streaming / real-time? Not currently. The Actors are pull-based. If you need streaming, that's a custom integration.

Other platforms? I also maintain a RedNote Shop Scraper for Xiaohongshu e-commerce listings — useful if your model needs to reason about products, pricing, or commerce vocabulary.

Other relevant work

If you're building Chinese intelligence at scale, the full suite:

RedNote Scraper — lifestyle social
RedNote Shop Scraper — Xiaohongshu e-commerce (product metadata, pricing, vendor info)
Weibo Scraper — microblogging, hot search, sentiment
Bilibili Scraper — video creator analytics

If this saved you a quarter of dev time, a 30-second review on any of the Actor pages helps a lot. ⭐

Found a bug or have a feature request? Open an Issue — I usually ship fixes within 48 hours.

Influencer Vetting at Scale on Xiaohongshu (RedNote): A Practical Python Guide for Brand Teams 2026

Sami — Mon, 11 May 2026 16:14:10 +0000

RedNote — known internationally as Xiaohongshu (小红书) or Little Red Book — has become the single most consequential platform for influencer marketing in China. With 300M+ monthly active users skewed female and Gen Z, it's where beauty, fashion, lifestyle, and travel brands first place a campaign before going wider. After the TikTok-uncertainty migrations of 2024–2025, RedNote also became the de facto Western fallback for many creators.

If you're a brand team, agency, or media buyer working in or with China, you need a way to vet RedNote influencers at scale. Manual scrolling doesn't cut it past five creators. Here's the structured approach.

What "vetting at scale" actually means

For a single influencer partnership, you typically want answers to:

Reach: how many followers, but more importantly how many people actually see their content (median impressions / followers)?
Engagement quality: average likes/comments/saves per post — and the distribution. A creator with 100K followers and 50 posts averaging 500 likes is very different from one with 100K and a few viral 10K posts.
Niche fit: do their tags and topics align with your category?
Audience hints: from bio, location, profile signals — who follows them?
Authenticity: posting cadence, sponsored-content ratio, content reuse from other platforms.

The data lives in two places on RedNote: profile metadata (followers, bio, location, verified status, total likes received) and recent posts (titles, like counts, content type, publish dates).

What you can extract per creator

{
    "userId": "5d7439b40000000001009f54",
    "nickname": "BeautyBlogger123",
    "avatar": "https://sns-avatar-qc.xhscdn.com/...",
    "redId": "100123456",
    "description": "Skincare reviews, K-beauty translations. Seoul-based.",
    "followers": 184500,
    "following": 320,
    "totalLikes": 1240000,
    "gender": 1,
    "location": "Seoul, South Korea",
    "isVerified": true,
    "tags": ["Beauty Blogger", "K-Beauty", "Skincare"]
}

Per recent post:

{
    "postId": "64be395b0000000010030b56",
    "type": "video",
    "title": "Morning skincare routine for dry skin",
    "likes": 15234,
    "scrapedAt": "2026-05-06T12:00:00Z"
}

Combined, you can compute:

Median likes / post (use median, not mean — viral outliers skew means)
Engagement rate = median likes / followers (RedNote benchmark for healthy: 2–5%, viral creators 8%+)
Post frequency (posts per week — burnout warning if dropping)
Content-type ratio (video vs image — videos get higher reach in 2026)
Niche concentration (% of recent posts matching your category keywords)

Practical Python: building a vetting batch

from apify_client import ApifyClient
import statistics

client = ApifyClient("YOUR_APIFY_TOKEN")

def vet_creator(profile_url: str) -> dict:
    # Profile data
    profile_run = client.actor("zhorex/rednote-xiaohongshu-scraper").call(run_input={
        "mode": "profile",
        "userUrl": profile_url,
    })
    profile = next(client.dataset(profile_run["defaultDatasetId"]).iterate_items())

    # Recent posts
    posts_run = client.actor("zhorex/rednote-xiaohongshu-scraper").call(run_input={
        "mode": "user_posts",
        "userUrl": profile_url,
        "maxResults": 50,
    })
    posts = list(client.dataset(posts_run["defaultDatasetId"]).iterate_items())

    likes = [p.get("likes", 0) for p in posts if p.get("likes")]
    median_likes = statistics.median(likes) if likes else 0
    er = (median_likes / profile["followers"]) * 100 if profile.get("followers") else 0

    return {
        "nickname": profile.get("nickname"),
        "followers": profile.get("followers"),
        "verified": profile.get("isVerified"),
        "tags": profile.get("tags"),
        "post_count_recent": len(posts),
        "median_likes": median_likes,
        "engagement_rate_pct": round(er, 2),
        "video_ratio": sum(1 for p in posts if p.get("type") == "video") / max(len(posts), 1),
    }

# Vet a list
candidates = [
    "https://www.xiaohongshu.com/user/profile/USER_ID_1",
    "https://www.xiaohongshu.com/user/profile/USER_ID_2",
]

results = [vet_creator(u) for u in candidates]
results.sort(key=lambda r: r["engagement_rate_pct"], reverse=True)

for r in results:
    print(f"{r['nickname']:25s}  followers={r['followers']:>7,}  ER={r['engagement_rate_pct']}%")

That gives you a sortable spreadsheet of candidates ranked by genuine engagement, not vanity follower counts.

Red flags to look for

Engagement rate < 0.5% with > 100K followers → likely bought or stale
Only image posts when category is video-heavy → low reach in 2026's algorithm
Posts in the last 30 days < 4 → low retainer reliability
No tags or generic tags → low discoverability inside RedNote search
Median likes within 10x of mean → relatively consistent (good); 50x+ means single-viral-driven (risky)

When to skip the DIY approach

RedNote's public surface requires sustained anti-bot engineering to extract reliably at scale. The schema also evolves regularly, so a scraper that worked last month can quietly start returning empty arrays this month without raising any error you'd notice in your pipeline.

That's why I maintain the RedNote Scraper on Apify — six modes (search, user posts, profiles, post details, comments, video) with consistent output schemas across them. The infrastructure work (session handling, rate limiting, schema stability) is already done.

Pricing is pay-per-event: $0.005 per result. A typical influencer batch (50 candidates, profile + 50 posts each) costs about $13. The Apify free tier ($5 monthly) covers ~1,000 items.

FAQ

Is the data from open profiles only? Yes — public-facing profile and post data. Private/locked accounts are not accessible. Same content any anonymous browser user can see.

Does it work on xhslink.com short links? Yes, those resolve automatically.

Can I get post-level comments? Use mode: comments on individual post URLs.

What about RedNote vs Xiaohongshu vs Little Red Book? All the same platform — the Actor handles all three name conventions and URL formats.

Is scraping Xiaohongshu legal? This Actor accesses publicly visible content only. No authentication is bypassed. Always consult your local laws.

Full Chinese intelligence stack

Brand teams running campaigns across Chinese platforms typically pair this with:

RedNote Scraper — (this one, social side)
RedNote Shop Scraper — Xiaohongshu e-commerce (products, vendors, prices)
Weibo Scraper — microblogging, brand mentions, hot search
Bilibili Scraper — video creator analytics

Vetting more than 100 creators per month? I offer custom output schemas, dedicated proxy pools, SLA support, and volume discounts. DM me on Apify or open an Issue titled "Enterprise inquiry".

Bug? Issues are typically fixed within 48 hours.

If this saved you time, a 30-second review on the Apify Store helps a lot. ⭐

Weibo's Hot Search Is the Best Real-Time Feed of Chinese Public Sentiment in 2026

Sami — Fri, 08 May 2026 17:33:19 +0000

Weibo's "hot search" (热搜) is the closest thing China has to a real-time barometer of public attention. It updates every few minutes, ranks topics by an opaque heat score, and is where every news cycle, celebrity scandal, and viral product launch lands first. For brands, agencies, and researchers covering China, this feed is gold — and unlike most of Weibo, it's accessible without a single cookie.

This post is for anyone building a brand-monitoring, sentiment-tracking, or trend-discovery pipeline aimed at China.

Why hot search matters

Weibo (微博) is China's microblogging giant — 580M+ monthly active users. The hot search ranking is curated by Weibo's own engagement signals: a topic earns a spot when search volume, post creation, and engagement spike together within a short window.

That makes hot search a leading indicator for:

PR crises: a brand mention reaches the top 50 within minutes of a viral video
Product launches: launches by Apple, Tesla, Xiaomi, etc. typically hit the top 20 within an hour
Cultural shifts: holiday spikes, generational slang, viral memes
Geopolitics: state-affiliated topics surface predictably; their ranking velocity tells a story

If you're tracking China for any of these use cases, polling hot search every 5–15 minutes gives you sub-news-cycle response time.

What you actually get

Each hot search row exposes:

rank (1–50)
title (the search term itself, in Chinese)
hotValue — an integer that approximates topical heat
category (科技 = tech, 娱乐 = entertainment, 时尚 = fashion, etc.)
labelName — content-moderation labels: 热 (hot), 新 (new), 沸 (boiling), 爆 (exploding)
isHot flag
url to the search results page on weibo.com

Sample row:

{
    "rank": 1,
    "title": "人工智能最新突破",
    "category": "科技",
    "hotValue": 2847562,
    "labelName": "热",
    "isHot": true,
    "url": "https://s.weibo.com/weibo?q=%23..."
}

A minimal Python pipeline

import time
from datetime import datetime
from apify_client import ApifyClient

client = ApifyClient("YOUR_APIFY_TOKEN")

def snapshot_hot_search():
    run = client.actor("zhorex/weibo-scraper").call(run_input={
        "mode": "hot_search",
        "maxResults": 50,
    })
    return list(client.dataset(run["defaultDatasetId"]).iterate_items())

# Poll every 10 minutes and dedupe by title
seen = {}
while True:
    snap = snapshot_hot_search()
    ts = datetime.utcnow().isoformat()
    for row in snap:
        title = row["title"]
        if title not in seen or seen[title]["rank"] != row["rank"]:
            seen[title] = {"rank": row["rank"], "first_seen": ts}
            print(f"[{ts}] rank={row['rank']:>2}  {title}  heat={row['hotValue']}")
    time.sleep(600)

A small loop and you've built a brand-mention monitor.

Common patterns I see customers run

1. Brand watch. Match new hot-search titles against a list of brand keywords. Trigger alerts when a brand name enters top 50.

2. Velocity tracking. Compute the rank-change velocity per topic. Topics that jump from rank 40 → 5 in under 30 minutes are early-warning signals for going viral.

3. Category drift. Track which categories dominate hot search hour-by-hour. Useful for media planning and ad targeting timing.

4. Cross-platform correlation. Pair Weibo hot search with Bilibili trending and RedNote search to detect cross-platform memes early. The platforms are surprisingly correlated 1–6 hours apart.

Going deeper: posts and comments

Hot search gives you topics. To go deeper into actual conversation, pivot from a hot title to its underlying posts:

# After identifying a hot topic, search posts about it
posts_run = client.actor("zhorex/weibo-scraper").call(run_input={
    "mode": "search",
    "searchQuery": "人工智能最新突破",
    "maxResults": 100,
})

That returns post-level data: text, author, like/repost/comment counts, embedded images, and post URLs. Pair with mode: post_comments to harvest reactions.

Why a hosted scraper, not raw scraping

Weibo's public web endpoints work without login for most read paths, but they require a visitor session token (Sina Visitor System) and exponential backoff on throttling responses. A naive requests script will either get throttled within 100 calls or pull empty arrays without realizing.

The Weibo Scraper on Apify handles session bootstrap, throttling, retries, and consistent schema across modes (hot_search, post_comments, search, user_posts). Pure HTTP — no browser, no proxy required.

Pricing is pay-per-event: $0.005 per item. 1,000 items = $5. The free Apify tier covers 1,000 items/month.

FAQ

Is hot search censored? Some topics are rate-limited or removed by Weibo's moderation. The labelName field hints at moderation state. You'll see topics appear and disappear.

Can I get historical hot search? Not via Weibo directly — they don't expose archives. You build your own archive by snapshotting at intervals.

What about session tokens? They expire periodically. Hosted scrapers refresh them automatically; if you DIY, plan for re-auth.

Is scraping Weibo legal? This accesses publicly visible data. No authentication is bypassed. Always check your local laws and Weibo's ToS.

Building a Chinese intelligence stack?

I maintain the full suite for production pipelines:

Weibo Scraper — (this one)
Bilibili Scraper — China's YouTube, 300M MAU
RedNote (Xiaohongshu) Scraper — lifestyle social
RedNote Shop Scraper — Xiaohongshu e-commerce

Running 50K+ items per month? I offer custom output schemas, dedicated proxy pools, SLA, and volume pricing. DM me on Apify or open an Issue titled "Enterprise inquiry".

Found a bug? Open an Issue and I usually ship fixes within 48 hours.

A 30-second review on the Apify Store helps other users find this tool. ⭐

Building a Xiaohongshu (RedNote) E-commerce Scraper for RedShop Product Data

Sami — Wed, 06 May 2026 01:56:00 +0000

When Xiaohongshu (RedNote / Little Red Book / 小红书) launched RedShop — its US-facing e-commerce platform — in April 2026, I noticed every existing scraper on Apify only covered the social side: posts, profiles, comments, videos. None of them touched product listings, vendor catalogs, or pricing data.

So I built one.

Why a dedicated shop scraper?

Xiaohongshu is unusual among Chinese platforms because product listings live in a separate URL space from social posts. The all-in-one social scrapers handle the /explore/ posts surface. RedShop products live behind /goods-detail/ with completely different structure.

Trying to extract product data from a "social" scraper means hacky workarounds. A dedicated commerce-focused tool gives you:

Structured product fields (price, sold count, SKU variants, vendor metadata)
Native support for vendor/store browsing
Cross-border vs domestic flagging
Cleaner pricing model: charge per product, not per "result"

What it extracts

For each product:

itemId, title, productUrl
salePrice, originalPrice, discountPct, currency (CNY for domestic, USD for cross-border)
soldCount, wantCount (popularity signals)
cover, images
vendor (sellerId, name, rating)
category path
skus (variants with prices and stock)
crossBorder flag and shippingOrigin

Three modes

Mode	What it does
`product_search`	Search products by keyword, sort by price/sales, filter by price range
`vendor_products`	Full catalog from a specific seller
`product_detail`	Deep dive on specific product URLs (full SKU breakdown)

Real-world use cases

DTC brands: monitor your own listings and competitor pricing on China's #1 social commerce platform
Dropshippers and resellers: discover trending Chinese products before they hit Amazon or Etsy
Cross-border arbitrage: identify SKUs popular in China that haven't reached Western markets yet
Investment analysts: track e-commerce activity for Chinese consumer brands
Sourcing agents: scout Chinese products at scale for clients in cosmetics, fashion, or home goods

Combined with the RedNote All-in-One Scraper (social side), you can map products to the influencers tagging them — extremely valuable for influencer-product correlation studies.

How to use it

from apify_client import ApifyClient

client = ApifyClient("YOUR_APIFY_TOKEN")

run = client.actor("zhorex/rednote-shop-scraper").call(run_input={
    "mode": "product_search",
    "searchQuery": "skincare",
    "maxResults": 100,
    "sortBy": "sales",
    "minPrice": 50,
    "maxPrice": 500,
})

for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(f"{item['title']} — ¥{item['salePrice']} (sold {item['soldCount']})")

Output sample

{
    "itemId": "642a1b3c0000000023019f7e",
    "title": "Skincare Set - Hydrating Toner + Serum + Moisturizer",
    "salePrice": 199.00,
    "originalPrice": 299.00,
    "discountPct": 33.4,
    "currency": "CNY",
    "soldCount": 12500,
    "wantCount": 5400,
    "vendor": {"sellerId": "...", "name": "BeautyBrand Official", "rating": 4.8},
    "category": "Beauty / Skincare / Sets",
    "skus": [{"spec": "Normal Skin", "price": 199.00, "stock": 1200}],
    "crossBorder": false,
    "shippingOrigin": "China"
}

Pricing

Pay-per-event:

$0.0075 per product scraped
$0.025 per vendor info record

Typical costs:

Search 100 products: ~$0.75
Full vendor catalog (200 products): ~$1.53
5 competitor vendors with 100 products each: ~$3.88

FAQ

Does it work for cross-border products?
Yes — products are explicitly flagged in the output (crossBorder: true/false) so you can filter domestic vs international listings.

Can I track price changes over time?
Schedule the actor to run daily/weekly via Apify Schedules. The dataset versioning gives you a price history for any product or vendor.

Does it need a proxy?
Residential proxies are recommended for reliable results. The default config uses Apify's residential pool.

Is there an official Xiaohongshu shop API?
No — Xiaohongshu doesn't offer a commerce API for international developers. This actor is the practical alternative.

Try it

RedNote Shop Scraper on Apify — works with Apify's free plan ($5/month credits cover hundreds of products at no cost).

If you build something useful with it, drop a comment — always interested in seeing how people use commerce data.

Google Ads can spend up to 2x your daily budget. I built a Chrome extension that catches it before it happens.

Sami — Thu, 30 Apr 2026 15:17:28 +0000

If you've ever opened Google Ads and noticed your campaign spent way more than the daily budget you set, you're not imagining it. Google's documentation explicitly says they may spend up to twice your daily budget on any given day, evening it out across the month. That's not a bug — it's how their pacing engine has always worked.

What changed in March 2026: Google now aggressively targets 100% of your monthly limit — which is 30.4× your daily budget. Even with ad scheduling. So if your campaigns only run 22 days a month (weekdays only, for example), Google can push up to 38% more spend per active day than you'd expect from your daily budget setting.

Most PPC managers don't notice until the damage is done. The Campaigns tab in Google Ads doesn't tell you whether you're on pace or headed for overspend. You'd need a spreadsheet, a calendar, and a calculator open in another window — or a SaaS tool that costs $49 to $749 per month.

I got tired of the spreadsheet route. So I built a Chrome extension that does it inside Google Ads, in real time, for free up to 3 campaigns. Walking through the build because the technical approach is interesting and the pricing math vs SaaS tools is genuinely lopsided.

What budget pacing actually requires

The math is simple. For each campaign:

expected_spend_today = daily_budget × (days_elapsed_in_month / total_days_in_month)
pacing_ratio = actual_spend_today / expected_spend_today

# pacing_ratio < 1.10 → on pace
# pacing_ratio 1.10–1.20 → slight overspend
# pacing_ratio > 1.20 → overspend risk

That's the whole core logic. SaaS tools wrap this in dashboards, alerts, multi-account aggregation, and reporting. But the underlying calculation is six lines of code.

The reason SaaS tools charge $49+/month isn't the math — it's the data plumbing. They connect to the Google Ads API (OAuth, refresh tokens, quota management), run server-side jobs to pull your accounts on a schedule, store results in a database, render charts. Real infrastructure cost.

But here's the thing: your campaign data is already visible on your Google Ads screen. Names, budgets, costs, statuses — the information is sitting in the DOM right there. If you're already looking at Google Ads, why does anyone need to call an API to tell you what you're already looking at?

The Chrome extension approach

I built AdPacer as a Manifest V3 Chrome extension that reads the campaign data from the Google Ads page DOM and overlays three pacing indicators directly on the interface you're already using. Architecture:

Content script runs on ads.google.com URLs
MutationObserver detects when the campaigns table renders or updates (Google Ads is a heavy SPA so this matters)
DOM parsing extracts campaign name, daily budget, current spend per row
Pacing math runs locally on the extracted values
DOM injection adds the colored pacing bars and projected-spend badges next to each campaign row
Notifications API for the periodic overspend checks

Zero API calls. Zero authentication flows. Zero backend. Zero data leaves the user's browser. Everything runs in the page's content-script context.

The privacy implication is meaningful: AdPacer cannot exfiltrate your Google Ads data even if it wanted to. There's no network request to anywhere. SaaS tools, however privacy-conscious their privacy policies are, send your campaign data to their servers as a fundamental part of how they work.

What you actually see in Google Ads after install

Three additions to the standard Campaigns tab:

1. Pacing bars — a color-coded bar next to each campaign:

Green: on pace, within 10% of expected spend
Yellow: ahead of pace, 10–20% over expected
Red: overspend risk, 20%+ over expected

2. Projected end-of-month spend — a badge showing what your monthly spend will be if you continue at the current daily run rate. Updates as the page data updates. No spreadsheet required.

3. Browser notifications — when any campaign crosses your threshold (configurable from 10% to 25%). Checks automatically every 30 minutes. Catch problems early instead of at month-end reconciliation.

That's it. Install, open Google Ads, see your pacing.

Pricing — and why this is structured the way it is

I deliberately wanted to make this accessible to freelancers and small teams, not enterprise-priced.

Tier	Price	Limit
Free	$0	Up to 3 campaigns. All core features. No credit card, no trial expiration.
Pro	$14/mo	Unlimited campaigns, custom thresholds, priority support.
Agency	$29/mo	Multi-account support, PDF pacing reports, team sharing.

The free tier covers most freelancers managing 1-3 client accounts at a time, or small e-commerce teams running a couple of brand/generic/shopping campaigns. Pro is for in-house PPC managers running 5-50 campaigns. Agency is for teams managing multiple clients.

For comparison with the SaaS landscape:

Tool	Lowest tier	Notes
TrueClicks	$49/mo	Broader PPC management
Optmyzr	$129/mo	Optimization suite
WordStream	$299/mo+	Enterprise tier
AdPacer	$0–$14/mo	Pacing only

If you need full PPC management — bid optimization, A/B testing, audience suggestions, the whole stack — the SaaS tools are doing a lot more than pacing. But if all you actually need is "tell me when a campaign is going to overspend," paying $49-299/month for that single feature is overkill.

Who I built this for

PPC managers running Google Ads daily who want instant budget visibility without context-switching to another tool. Freelancers managing 1-5 client accounts where SaaS pricing eats too much of the margin. Agency teams who need quick pacing checks across multiple campaigns. E-commerce advertisers watching ROAS and budget efficiency in real time.

If you're an enterprise team running 200+ campaigns with complex bid strategies, this isn't for you — you probably already have an Optmyzr-class tool. If you're somewhere between "spreadsheet" and "expensive SaaS," this fills the gap.

What it doesn't do (yet)

Being honest about scope:

No Microsoft Ads / Bing Ads support yet (Google Ads only)
No Meta / TikTok Ads (different DOMs, different challenges, would be a separate extension)
No historical pacing trends beyond current month
No bid suggestions or campaign optimization (that's a different problem space)

Pacing is a single, focused use case. The extension does that one thing well rather than trying to be a half-decent everything tool.

Install link

AdPacer on the Chrome Web Store

Free tier covers up to 3 campaigns with no credit card and no trial expiration — install and see if it solves your problem before paying anything.

If you're a PPC manager and the spending pattern Google introduced in March 2026 has been causing you headaches, this is the lowest-friction way to catch overspend before it happens. If you're a developer reading this for the technical approach: yes, the entire thing runs client-side via DOM parsing — no API key, no backend, no data leaves the browser.

Happy to answer questions about either side.

How to scrape Weibo (微博) data with Python in 2026 — the Sina Visitor System and how to handle it

Sami — Thu, 30 Apr 2026 14:58:19 +0000

Weibo is China's Twitter — the platform where Chinese public opinion forms, brand crises break first, and government statements land. 580M+ monthly active users, mostly mainstream demographics. If you're doing China market intelligence, brand monitoring, or PR analytics, Weibo is one of the platforms you can't skip.

The challenge: Weibo's developer API requires a Chinese business license, has severe rate limits, and exposes very limited data. For Western teams, web scraping is the practical option. The interesting twist is Weibo's Sina Visitor System — an auth flow that makes anonymous access possible for some endpoints but not others. Understanding which is which matters for what you can actually scrape.

This article covers the technical landscape (with real Python code) and points to a hosted scraper if you'd rather skip the maintenance.

What Weibo serves

A Weibo post is structured similarly to a tweet but with longer character limits and more structured engagement signals:

Post text (140 to 2,000 characters depending on user level)
Repost chain — Weibo's quote-tweet equivalent, central to virality tracking
Engagement metrics — attitudes_count (likes), comments_count, reposts_count
Hashtags and mentions
Geolocation if disclosed by user
Author profile — follower count, verification status, verified reason (e.g., "新浪科技 official Weibo")
Media — images, videos

A Weibo user profile gives you:

User ID (numeric)
Screen name (display name)
Description / bio
Followers / friends counts
Statuses count (total posts)
Verification status with reason text — this is gold for identifying official accounts vs personal vs corporate

For monitoring use cases, the metric that matters most depends on your goal:

Crisis monitoring: track comments_count and repost velocity. A spike in either signals viral attention.
Brand presence: track post frequency from verified accounts in your category.
KOL identification: filter by verified=true + follower count above a threshold.

The Sina Visitor System

This is the key technical concept for scraping Weibo without a Chinese business license.

When you visit Weibo without logging in, Sina automatically issues you a "visitor cookie" via what they call the Sina Visitor System (SVS). This cookie lets you access limited public data — specifically:

Hot search / trending topics: full access
Post comments: full access for any public post
Post viewing: limited

For these endpoints, scraping is straightforward — get a visitor cookie, hit the AJAX endpoint, parse JSON.

What the visitor cookie does NOT give you:

Search by keyword (returns hot timeline as a fallback instead of true search results)
User posts beyond profile basics (you get the profile, not the user's post history)

For those, you need a real logged-in cookie — specifically the SUB cookie value from a logged-in browser session. We'll get to that.

Approach 1: Build it yourself

The Sina Visitor System flow looks roughly like this:

import httpx

# Step 1: Hit the visitor system to get a tid (temporary ID)
visitor_url = "https://passport.weibo.com/visitor/genvisitor"
resp = httpx.post(visitor_url, data={
    "cb": "gen_callback",
    "fp": '{"os":"1","browser":"Chrome","fonts":"undefined","screenInfo":"1920*1080*24","plugins":""}',
})
# The response is a JSONP-wrapped JSON. Strip the wrapper, parse, extract tid.

# Step 2: Use tid to get the SUB visitor cookie
incarnate_url = "https://passport.weibo.com/visitor/visitor"
resp = httpx.get(incarnate_url, params={
    "a": "incarnate",
    "t": tid,
    "w": "2",
    "c": "100",
})
# Response sets cookies. Extract SUB and SUBP from response.cookies.

# Step 3: Use those cookies to call AJAX endpoints
hot_search_url = "https://weibo.com/ajax/side/hotSearch"
resp = httpx.get(hot_search_url, cookies={"SUB": sub, "SUBP": subp})
data = resp.json()
# data["data"]["realtime"] is the hot search list

That's the rough shape. In practice you'll handle:

Rate limit responses (HTTP 418, 429) with exponential backoff
Cookie expiration (visitor cookies last hours, not days)
AJAX endpoint changes (Weibo periodically reshuffles paths)
Anti-scraping fingerprint checks (less aggressive than RedNote, but still present)

For the keyword-search and user-posts endpoints, you'll need a real SUB cookie from a logged-in account:

# Get SUB from your browser DevTools → Application → Cookies → weibo.com
# Look for the cookie named "SUB"
sub_cookie = "SUB=_2A25Fxxxxxx..."

resp = httpx.get(
    "https://weibo.com/ajax/side/searchAll",
    params={"q": "人工智能"},
    cookies={"SUB": sub_cookie.split("=", 1)[1]},
)

Cookies typically last several days before expiring, depending on Weibo's session policies.

DIY cost breakdown

Cost	Estimate
Initial setup (visitor system, hot search, comments)	4-8 hours
User session cookie management	1-2 hours/week
Maintenance when Weibo changes endpoints	2-4 hours, every 2-3 months
No proxy needed for most endpoints	$0

Weibo is genuinely the easiest of the major Chinese platforms to scrape if you stay within visitor-system endpoints. RedNote and Bilibili both have more complex auth.

Approach 2: Use a hosted scraper

If you don't want to maintain visitor-system handling and cookie management, the zhorex/weibo-scraper Apify actor handles it.

from apify_client import ApifyClient

client = ApifyClient("YOUR_APIFY_API_TOKEN")

# Hot search (no cookie needed)
run = client.actor("zhorex/weibo-scraper").call(run_input={
    "mode": "hot_search",
    "maxResults": 50,
})

for topic in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(f"#{topic['rank']}: {topic['title']} (heat: {topic['hotValue']:,})")

Output format:

{
  "rank": 1,
  "title": "人工智能最新突破",
  "category": "科技",
  "hotValue": 2847562,
  "labelName": "热",
  "isHot": true,
  "url": "https://s.weibo.com/weibo?q=...",
  "scrapedAt": "2026-04-25T12:00:00Z"
}

For brand monitoring, search mode is what you want — though note the search-vs-cookie tradeoff:

# Without cookie: returns hot timeline as fallback
run = client.actor("zhorex/weibo-scraper").call(run_input={
    "mode": "search",
    "searchQuery": "CeraVe",
    "maxResults": 50,
})

# With cookie: returns true keyword-matched results
run = client.actor("zhorex/weibo-scraper").call(run_input={
    "mode": "search",
    "searchQuery": "CeraVe",
    "maxResults": 50,
    "cookieString": "SUB=your_logged_in_cookie",
})

The hosted actor handles the visitor system, exponential backoff, and rate limit recovery internally. Pricing: $5 per 1,000 results.

Honest stats on the actor right now: 4 paying users, 11 free-tier users, 92.5% success rate, 3,768 result extractions to date. Average issue response time when something breaks: under a few hours.

When DIY vs hosted

DIY makes sense when:

You're processing > 1M posts/month (per-result cost adds up)
You have ops capacity to refresh SUB cookies regularly
You need to scrape behind login at scale
You have specific endpoints not covered by hosted scrapers

Hosted makes sense when:

You don't have a dedicated scraper engineer
Volume is moderate (< 500k posts/month)
You want the visitor-system handling to be someone else's problem
You're prototyping and want to validate the use case before committing

What you do with the data downstream

Sentiment analysis on Chinese text is the obvious next layer. Off-the-shelf Chinese BERT models work reasonably for Weibo's discourse style — Weibo posts tend to be more formal than RedNote slang, so general Chinese sentiment models accuracy is higher (typical 75-85% on neutral/positive/negative classification).

For brand crisis detection, the signal you usually want is *velocity

Coin-per-view: the Bilibili metric that beats subscriber count for creator vetting

Sami — Wed, 29 Apr 2026 17:48:32 +0000

If you've ever sponsored a YouTube creator and been disappointed by the ROI, you've already lived through what subscriber count actually measures: not engagement, not influence, not purchase intent. Just historical clicks on a follow button. Many of those followers stopped opening videos two years ago. Some are inactive accounts. Some followed for a single piece of content that has nothing to do with your brand.

This is universally true on creator platforms, but it's especially true on Bilibili — China's YouTube. With 300M+ monthly active users skewed Gen Z and millennials, Bilibili is where Chinese creator marketing happens. And Bilibili exposes three engagement signals that YouTube doesn't, which together let you cut through the noise of follower counts and identify creators whose audiences actually engage.

The single most useful one is coin-per-view ratio. This post explains what it is, why it matters, what threshold to use, and how to compute it for any Chinese creator in a few lines of code.

Why follower count is a lying signal

Three reasons follower counts mislead in creator marketing:

1. Followers are a lagging indicator. Someone followed a creator in 2023 because they liked one video. That doesn't tell you whether they still watch in 2026, whether they engage, or whether they trust the creator's recommendations enough to buy.

2. Followers are gameable. Not everyone games them, but enough creators do that you can't trust raw counts without other signals. Bot followers, follow-for-follow campaigns, paid follower services. China specifically has a robust market for these.

3. The follower-to-engagement ratio varies wildly. A creator with 100k followers and 1M average views per video has fundamentally different audience economics than another creator with 100k followers and 5k average views per video. Both have the same "follower count" — the engagement quality is the actual signal.

This is why every serious creator marketing tool talks about "engagement rate" — which on YouTube is usually computed as (likes + comments) / views. It's better than raw follower count, but on Bilibili you can do meaningfully better.

The three Bilibili-native metrics

Bilibili was designed by anime fans for anime fans, and the engagement system reflects values around quality and creator support that YouTube's flat "like" button never captured. Three metrics that come back from any Bilibili video scrape:

Danmaku (弹幕) — real-time scrolling comments overlaid on the video as users watch. Think livestream chat, but for pre-recorded video. The danmaku count tells you how many people were engaged enough mid-watch to type something. It's a leading indicator of viewing time and attention.

Favorites (收藏) — equivalent to "save for later" or YouTube's bookmark. Strong long-term value signal: high favorites relative to views means people return to this video. Tutorials, references, and definitive content score high here.

Coins (投币) — Bilibili's tipping system. This is the interesting one. Each user gets a small daily allocation of coins (typically 5 per day for active users), and they can "throw" them at videos they want to support. Because coins are scarce by design — you only have a few to spend, ever — coin counts are a strong genuine-appreciation signal.

A user gives a coin to a video they love. They give a coin to a creator they want to keep making content. They don't give a coin to a video they passively watched and forgot. The cost is real (relative to the user's daily allocation), so the signal is real.

Coin-per-view ratio: the single best signal

If I had to pick one metric to evaluate a Bilibili creator, it would be median coin-per-view ratio across their last 20-30 videos.

The math is simple:

coin_per_view = coin_count / view_count * 100  # express as percentage

What I've found from looking at hundreds of Bilibili creators across categories:

Coin/View %	Audience quality
< 0.5%	Passive viewers. Casual scrolling traffic, not engaged.
0.5% – 1%	Average. Normal Bilibili content, decent audience.
1% – 2%	Strong. Genuinely engaged audience. Worth sponsoring.
> 2%	Exceptional. Users actively spending limited resources on this content.

Above 2% is rare. It typically indicates either: (a) genuinely high-quality educational/tutorial content that people return to, (b) a creator with a deeply loyal niche audience, or (c) content that struck a strong emotional/cultural nerve.

For creator vetting, my heuristic is: if median coin-per-view is below 1%, the audience is more passive than the follower count suggests; sponsorship ROI will probably disappoint.

How to compute this for any creator

The data you need: a creator's recent videos with their view and coin counts. Bilibili exposes this through their public API — no auth required. You can use the open-source bilibili-api Python library, or call their /x/space/wbi/arc/search endpoint directly.

If you'd rather skip the API integration entirely, I built a hosted scraper on Apify Store: zhorex/bilibili-scraper. $5 per 1,000 results, free tier covers ~1,000 results.

from apify_client import ApifyClient
from statistics import median

client = ApifyClient("YOUR_APIFY_API_TOKEN")

# Get a creator's last 30 videos
# user_id (mid) is the number in their profile URL: space.bilibili.com/{mid}
run = client.actor("zhorex/bilibili-scraper").call(run_input={
    "mode": "user_videos",
    "userIds": ["546195"],   # 老番茄 (a well-known Bilibili gamer)
    "maxResults": 30,
})

videos = []
for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    if item.get("type") == "video":
        videos.append(item)

# Compute coin-per-view ratio per video
ratios = []
for v in videos:
    views = v.get("viewCount", 0)
    if views < 1000:  # skip videos with too few views to be meaningful
        continue
    coins = v.get("coinCount", 0)
    ratios.append(coins / views * 100)

print(f"Videos analyzed: {len(ratios)}")
print(f"Median coin-per-view: {median(ratios):.2f}%")
print(f"Best video coin-per-view: {max(ratios):.2f}%")

# Categorize
median_ratio = median(ratios)
if median_ratio >= 2.0:
    label = "EXCEPTIONAL"
elif median_ratio >= 1.0:
    label = "STRONG"
elif median_ratio >= 0.5:
    label = "AVERAGE"
else:
    label = "PASSIVE"

print(f"Audience quality: {label}")

Run this against any Bilibili creator's user ID and you have a concrete answer about audience engagement quality.

A workflow for vetting creators at scale

If you're building a creator marketing program for the Chinese market, the workflow that works for the teams I've seen using this:

Gather candidates. From competitor sponsorship lists, from category trending, or from agency recommendations. Aim for 30-50 candidates per round.
Pull their recent video portfolios. Use user_videos mode to get the last 20-30 videos per creator.
Compute aggregate metrics. For each creator: median coin-per-view, median favorite-per-view, median danmaku-per-view, view consistency (standard deviation).
Filter on quality threshold. Drop anyone with median coin-per-view below 1%. This usually cuts the candidate list by 40-60%.
Manual review of the survivors. Watch a sample of their videos. Check for content fit. Evaluate sponsorship history (do their sponsored posts feel native or forced?).
Negotiate from the qualified shortlist.

Total cost using a hosted scraper: ~$5-10 in scraping for a 50-creator vetting round. Compared to agency rates for the same work ($500-2000 per round), the math is obvious once you do it.

Cross-platform creator vetting

Bilibili is not the whole story. If you're vetting creators for a comprehensive China presence:

Bilibili for video content (gaming, tech, anime, education)
RedNote (Xiaohongshu) for product-discovery content (beauty, fashion, lifestyle, food)
Weibo for public discourse and broad reach campaigns

Each platform has different engagement signals. Bilibili has coins; RedNote has saves (similarly scarce intent-to-buy signal); Weibo has reposts and verified-account hierarchy. A creator strong on one isn't necessarily strong on others.

I maintain scrapers for all three on Apify Store under the zhorex profile, with consistent output schemas across the suite. Same pricing model ($5/1000 results), same Apify infrastructure. If you're doing cross-platform creator analytics, the consistency saves integration time.

When this approach fails

Two cases where coin-per-view ratio is a misleading signal:

1. Brand-new creators with very few videos. If a creator has uploaded 3 videos and one went viral with high coins, the ratio looks artificial. Wait until you have 15-20 videos to compute median.

2. Live-stream-focused creators. Bilibili lets creators upload archived live streams. Coin economics are different in livestream context (gifts replace coins). For livestream-heavy creators, you need different analysis.

For everyone else, coin-per-view ratio is the single best signal I've found for vetting Bilibili creator quality at scale.

What this won't tell you

Whether the audience is geographically right for your campaign (need follower demographics, which require auth)
Whether the creator has done sponsorships before that flopped (need to scrape their content for promo patterns)
Whether their audience overlaps with your target customer profile (need cross-reference with other platforms)

Treat coin-per-view as the engagement-quality filter. Everything else still requires manual review or additional data sources.

If you're working on creator marketing for the Chinese market and want to compare notes on what works — drop a comment. I write about Chinese platform analytics (Bilibili, RedNote, Weibo) and the build-vs-buy tradeoffs around them.

Hosted Bilibili scraper: apify.com/zhorex/bilibili-scraper
Other Chinese platform scrapers in the same suite: RedNote for product-discovery content, Weibo for public discourse.