Throne Creator, Wishlist & Brand Intelligence

Turns public Throne creator pages into structured commerce data: profiles, complete wishlists, normalized prices and merchants, brand and category classification, brand affinity, creator niches, sponsorship fit, and wishlist change monitoring.

Built for brands and influencer agencies who need to answer "which creators already want what we sell, and what would it cost to send it?" — with the reasoning visible, not just a score.

What you get

Creator profile	Username, display name, bio, main platform, social links the creator published themselves, account age
Full wishlist	Every publicly visible item, with prices in whole currency units, merchant, product URL, image, availability, collections
Normalization	Brand and category per item with a confidence and a source; stable product keys for matching the same product across creators
Statistics	Min / median / mean / trimmed mean / p25 / p75 / p90 / stdDev / price buckets — per currency, never summed across currencies
Intelligence	Brand affinity (0–100, formula published below), creator niches, commercial readiness signals, duplicate-product detection, sponsorship fit with reasons and blockers
Cross-creator popularity	Which products and brands the most creators want — counted per creator, not per item
Monitoring	New items, price drops and rises, availability flips, collection moves, crowdfunding progress, removals

Quick start

{
  "mode": "profile",
  "creatorUrls": ["https://throne.com/cirely"],
  "outputLevel": "intelligence"
}

Usernames work too, in any shape you happen to copy: cirely, @cirely, throne.com/cirely, https://throne.com/cirely?utm_source=x.

Modes

Mode	What it does	Browser
profile	One creator in full detail. The cheapest way to try the Actor.	no
batch	Many creators. One failing creator never stops the run.	no
discover	Lists creators from Throne's public directory, newest accounts first. Metadata only — feed the result into batch.	no
search	Same work as batch, but only writes items matching your filters.	no
monitor	Compares against the previous run and reports what changed.	no

Output levels

basic — profile, social links, price statistics, top brands and categories. No item list. Use it to screen hundreds of creators.

full — everything in basic, plus the complete wishlist and collections.

intelligence — everything in full, plus brand affinity, niches, commercial signals, duplicate products and sponsorship fit.

Measured performance

Real numbers from a run over 30 creators discovered from the sitemaps:

Creators	30
Wishlist items	511
HTTP requests	61 (2.03 per creator)
Downloaded	2.1 MB (70 kB per creator)
Runtime	13.8 s at concurrency 3
Peak memory	197 MB
Browser	never launched — no mode needs one
Proxy	not used

Extrapolated to 1 000 creators: roughly 2 030 requests, 70 MB, and about 8 minutes at the default concurrency. Raise maxConcurrency to trade politeness for speed.

Discovery is cheaper still: 40 creators with public wishlists came back in a single request, scanning 300 profiles.

How the numbers are made

Everything below is deterministic. There is no language model anywhere in this Actor — the same input always produces the same output, and the cost of a run does not depend on how chatty a wishlist is.

Prices

Throne stores money in minor units — 2403 means $24.03. This Actor converts once, in one module, using ISO 4217 exponents, so zero-decimal currencies (JPY, KRW) and three-decimal ones (KWD, BHD) come out right too.

Shipping, tax and fees are separate fields and are never added to the item price. If you want what a gifter actually pays, use totalContribution — that value comes from Throne, it is not our sum.

The original pre-discount price is the one field Throne sends inconsistently — sometimes in cents, sometimes in whole dollars. It is only returned when one of those readings is actually plausible as a higher former price; otherwise it is null. A missing field beats an invented discount.

No currency conversion happens anywhere. Statistics are computed per currency. A wishlist mixing USD and EUR gets two statistics blocks, never one meaningless total.

Brands

Resolved in order: the explicit brand field from Throne → merchant domain → a brand dictionary → parsing the product title. Each result carries a confidence and a source.

Names are unified so affinity does not split in half: Jackbox Games, Inc. and Jackbox Games become one brand, SQUISHMALLOW becomes Squishmallows, Pokemon and Pokémon converge — while deliberate capitalization like LEGO, NVIDIA and HyperX is left alone.

Ambiguous words are only accepted as brands when the title confirms them. Apple iPhone 16 Pro Case is Apple; Apple Pie Silicone Baking Mold is not. When in doubt the brand is null — an invented brand is worse than a missing one, because brand affinity is built on top of it.

Brand affinity (0–100)

Component	Weight	Measures
countShare	40	share of wishlist items from that brand
valueShare	30	share of wishlist value
featured	15	the creator pinned an item of that brand
recency	15	an item of that brand was added in the last 90 days

The result is multiplied by evidenceFactor = min(1, itemCount / 3). Affinity means repeated preference, and one item is one data point. Without this, a single $3 539 sword — 78 % of one real wishlist's value — outranked a brand with five items.

Shares are absolute, relative to the whole wishlist. On a wishlist spread across 18 brands the strongest brand scores around 7 out of 100, and that is intentional: the score is meant to be comparable across creators, which is what you need when screening five hundred profiles. For "does this creator fit my brand?" use the sponsorship fit output, which works with shares directly.

Sponsorship fit

Only the criteria you fill in are scored; the rest are excluded from the formula rather than counted as zero. budget, minimum wishlist size and max days inactive are hard gates — fail one and the creator is reported as not a match whatever the score.

Every result carries reasons and blockers in plain language, plus up to ten concrete matchingItems — an actual answer to "what should I send?".

Monitoring

One snapshot per creator lives in a named key-value store (default throne-monitor-state), so it survives between runs. Item identity never includes price or position, so a discount is reported as a price drop rather than as a new item — verified by running twice over an unchanged wishlist and getting zero changes.

A removed item never implies a purchase. People delete items they changed their mind about, got elsewhere, or are simply tidying up. Throne does not publish the reason, so neither does this Actor: the event is ITEM_REMOVED and its description says the reason is not knowable from public data.

When a run hits maxItemsPerCreator, removal detection is switched off for that creator and the reason is stated in the output — a missing item might just be beyond the cap.

Limits, stated plainly

• Wishlist caps. Rows hit by maxItemsPerCreator are flagged wishlistTruncated. Nothing is ever silently shortened.
• Popularity is dataset-scoped. "Wanted by 7 creators" means 7 of the creators in your run. Every popularity report repeats this in a scope field.
• No currency conversion. Price ranges and cross-currency totals are deliberately absent rather than approximated.
• search costs the same as batch. Throne cannot be queried by brand or category — those categories are produced by this Actor's own normalization, so filtering happens after fetching.
• discover cannot filter server-side. Combining a public-wishlist filter with ordering needs a database index Throne does not have, so the filter is applied after fetching. Discovery still returns roughly 40–100 usable creators per request.
• Category taxonomy is rule-based. Items it cannot place land in Other with a low confidence. Three figures are reported so you can tell why: uncategorizedShare, unnamedItemShare (items named with a single emoji or similar, which nothing can classify) and uncategorizedShareOfNamed — the last is the one that actually measures taxonomy quality. On five real wishlists it currently sits between 0 % and 13 %.
• Private and missing profiles produce an error row, not a crash — and are not charged for.

What this Actor does not collect

• Nothing behind a login, and nothing private. Only what an anonymous visitor sees. Where Throne's access rules deny anonymous access, the run reports it and moves on — no attempt is made to work around it.
• No gifter or supporter data. Those are third parties and are irrelevant to commerce intelligence.
• No guessed contact details. Only the links a creator published on their own public profile. No email guessing, no enrichment from third-party databases.
• No sensitive profiling. Race, ethnicity, religion, politics, sexual orientation, health and financial status are never inferred or classified. Niches describe the goods in a wishlist, never the person.
• No payment or shipping information.
• No redirect following. Throne's robots.txt disallows /redirect; those URLs are recorded and flagged but never requested.

Credentials, tokens, cookies and proxy passwords are never logged at any level, including debug.

Outputs

• Dataset — one row per creator (or per change in monitor with onlyChanges), with the views Creators & wishlists, Wishlist changes and Discovered creators.
• POPULARITY_REPORT in the key-value store — products and brands wanted by the most creators in the run.
• RUN_SUMMARY in the key-value store — counts, requests and bytes per creator, truncated wishlists, error codes and what was charged. Written even when the run fails.

Not affiliated with Throne

This is an independent tool. It is not built, endorsed, or supported by Throne, and it uses no official Throne API, partnership, or private access — it reads the same public pages and public data any visitor's browser receives. "Throne" is used only to say which public website the data comes from.

Support

Found a field that is wrong, or a brand that should be unified? Open an issue on the Actor page. Include the creator username and what you expected — the normalization rules are data, and adding a rule is a one-line change.