尚未偵測到更新。GitHub 發布版本後會顯示在這裡。
個人 GitHub 帳號下公開儲存庫的擁有者可以登入並驗證所有權,自行管理介紹,無需管理員核准。
登入並產生驗證檔案,在 30 分鐘內將其提交至此儲存庫的預設分支。其他分支或分叉儲存庫中的檔案無效。然後在下方檢查檔案,即可無需管理員核准直接管理專案。請保留檔案以維持管理權限。
如需登入,將前往登入頁面。登入後請回到此處,再次點擊所選的驗證按鈕。
在專案資料夾中執行 /nomorevibe verify,即可驗證所有權並自行管理介紹。
一分鐘完成驗證Agent that finds the podcasts, creators, neighbourhoods and collab brands a small brand's customers love, ranked by value. Built on Qloo taste data.
翻譯準備中
取自儲存庫 README
正在載入完整 README。
檢視完整 README ↗Live: https://sponsor-scout.vercel.app · Demo video (2:54): https://youtu.be/YR31NnS1aGg
Small direct-to-consumer brands spend money every month on podcast ads, creator deals, pop-ups and collabs, and they choose where by guessing or by copying bigger brands. Sponsor Scout is an agent that works out who your customers are by taste, using Qloo, and then gives you a media plan:
If your brand isn't in Qloo yet (likely for a small brand), pick 2–4 "brands like us" and a few vibe tags instead.
Ask an LLM which podcasts a coffee roaster should sponsor and you get the famous shows every brand already names, with no evidence and no geography. Qloo supplies cross-domain affinity (a coffee brand's audience → podcasts, artists, places), popularity percentiles, location heatmaps and demographics. The report has a Without Qloo panel that asks the LLM the same question with no tools, next to the Qloo-grounded answer.
The value score. Famous sponsorships are overpriced for small brands. Each pick gets
value = affinity × (1 − popularity)^k, with k set by budget (bootstrapped 1.0, growing 0.5, funded 0), and bootstrapped and growing budgets also cap filter.popularity.max. The UI shows both the value ranking and the raw affinity ranking.
Browser ──POST /api/run (SSE)──▶ Agent loop (Gemini function calling, or scripted plan)
▲ live step trace │ calls tools
│ ▼
│ Tools (src/lib/agent/tools.ts)
│ │ │
│ Qloo client (src/lib/qloo.ts) Scoring (src/lib/score.ts, deterministic)
│ │ cache (Redis, 24h) Nominatim reverse geocoding (cached)
│ ▼
│ hackathon.api.qloo.com
│
└── /r/[id] permalink ◀── report saved to Redis
GEMINI_API_KEY the same tools run as a fixed plan.| Endpoint | Used for |
|---|---|
GET /search | Resolve the brand and lookalike brands to entity IDs |
GET /v2/tags | Vibe tags for brands Qloo doesn't know |
GET /v2/insights filter.type=urn:entity:{podcast,person,artist} | Sponsor shortlists, with filter.popularity.max per budget |
GET /v2/insights filter.type=urn:entity:{artist,podcast,tv_show,brand,destination} | Audience taste profile |
GET /v2/insights filter.type=urn:demographics | Age and gender affinity of the audience and of each pick |
GET /v2/insights filter.type=urn:heatmap + filter.location.query | Neighbourhoods that over-index on the audience |
GET /v2/insights filter.type=urn:entity:place + filter.location.query | Local partner places |
GET /v2/insights filter.type=urn:entity:brand + filter.exclude.tags / filter.exclude.entities | Non-competing collab brands |
GET /v2/analysis/compare | Audience overlap between the brand and a pick, for the pitch |
npm install
cp .env.example .env.local # all keys optional
npm run dev
With no keys it runs on synthetic data (src/lib/mock.ts, all names invented) and a scripted agent. Add QLOO_API_KEY for live data and GEMINI_API_KEY for the Gemini agent, pitch emails and the Without Qloo panel.
npm test # scoring unit tests
npx tsx scripts/probe.mts "Brand A" "Brand B" # Qloo coverage probe (writes git-ignored probe-output/)
npx tsx scripts/warm.mts https://your-app.vercel.app # precompute the landing-page examples
Vercel, with QLOO_API_KEY, GEMINI_API_KEY and an Upstash Redis store (UPSTASH_REDIS_REST_URL, UPSTASH_REDIS_REST_TOKEN, or the Vercel KV equivalents). Without Redis, permalinks don't survive across serverless instances. New runs are rate-limited per IP (RUNS_PER_HOUR); repeated inputs within 24h replay the cached report.
Qloo responses are cached server-side only. No Qloo response data is committed to this repo; the fixtures are generated synthetically.
MIT