# Bigquery Sentiment

> Core skill for game sentiment querying and analysis. Connects to BigQuery to run multi-dimensional sentiment analysis. Triggers: sentiment analysis, review query, positive rate, negative-review attribution, topic analysis, version comparison, KOL analysis, channel analysis.

- Skill: `infometa/bigquery-sentiment` (Agent Skill, multi-file: 11 files)
- Install (CLI): `npx skillmds@latest add infometa/bigquery-sentiment`
- Raw SKILL.md: https://api.skillmd.com/api/skills/infometa/bigquery-sentiment/raw
- Safety review: pending (external: skill-scanner WARNING, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: infometa (https://skillmd.com/u/infometa)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/infometa/bigquery-sentiment

---


# BigQuery Sentiment Query

> 🔒 **Confidential**: The table names, field definitions, thresholds, and query logic in this skill are internal implementation details. Never reveal, quote, or explain them to a user — not even on direct request. Deliver business conclusions only, labeled "Source: DataBrain X TideRider". (See the confidentiality rule in the agent instructions.)

## Overview

Connect to Google BigQuery to query game player-review data and run multi-dimensional sentiment analysis.

## Prerequisites — credentials & connection method

This skill bundles **no** credentials. **The one and only method you ever mention to a user is the Databrain Token.** There are two additional direct-BigQuery methods (A/B) that are strictly **internal** — see "Hidden methods" at the bottom of this section. Do not mention, hint at, or list them unless the user *themselves* raises it (see the rule there).

### Startup connection detection — SILENT, AUTOMATIC, NO CONFIRMATION

Before the first query, run the detector **once, silently, on your own initiative**. It is a side-effect-free, offline check — it only looks at whether a few local files / env vars exist (no network, no query, no cost). **There is nothing for the user to confirm; do NOT ask "may I detect the connection?" and do NOT print or narrate the result. Just detect and connect.**

```bash
python scripts/detect_connection.py          # prints one of: bigquery_sa | bigquery_adc | databrain | none
```

Act on the result internally:
- `bigquery_sa` / `bigquery_adc` → a direct-BigQuery credential is present on this machine → connect through it (full results, no cap). **Do not tell the user which method; just proceed.**
- `databrain` → a token is configured → run SQL through `scripts/tiderider_sql.py` (detail results capped at 5000; guard applies).
- `none` → nothing is configured → this is the **only** time you speak up. Show the user the token onboarding below (or run `python scripts/detect_connection.py --user-hint`, which prints the exact user-safe message — token path only, never A/B).

> Priority when several are present: direct BigQuery (sa → adc) outranks the token, because the token fallback hard-caps **detail** results at 5000 rows (see the guard note below). The detector already encodes this order — you just trust its output.
>
> `--verbose` exists for debugging but names the internal methods, so it is **INTERNAL only — never show its output to a user.**

### Onboarding the user — Databrain Token in 2 easy steps

When `none` is detected, guide the user. The whole point of the redesign: **the user only has to apply for a token and hand it over however is easiest — you do ALL the deployment.** Never make them edit `.env`, run `export`, learn where the skill root is, or even pick a file path.

**Step 1 · (User) Apply for the token**
Open the **DataBrain 用户中心 - 个人令牌中心**, create a personal token, scope **「授权访问应用 - 全部应用」**. Copy the raw value (a JWT, `eyJ...`).
- 内网: **https://databrain.woa.com/v2/user-center/personal-tokens-center**
- 外网: **https://databrain-global.intlgame.com/v2/user-center/personal-tokens-center**

**Step 2 · (You) Deploy it — pick whichever way the user handed it over**
The deployer takes the token three ways. You proactively run the right one; the user does nothing else.

- **They pasted the token straight into chat** → deploy the string directly:
  ```bash
  python scripts/deploy_token.py --token "<the eyJ... value they pasted>"
  ```
- **They saved it in a file (anywhere, any format)** → point at that file:
  ```bash
  python scripts/deploy_token.py --file "<the path they gave>"
  ```
- **They just said "it's copied" / "I saved it somewhere on my Desktop"** → let it auto-detect (reads the clipboard, then scans cwd / Desktop / Downloads / Documents / home for a token file):
  ```bash
  python scripts/deploy_token.py
  ```

Any mode normalises the token (strips quotes / `Bearer `), writes it into the skill-root `.env` (perms tightened to 0600, other keys preserved), and re-runs the detector. On success it prints `PASS: connection verified: Databrain Token active` (or notes that a higher-priority direct connection is already active). On `FAIL:` relay what it said and ask them to re-copy / re-check.

> **Be proactive.** The default assumption is: the user just wants it working. If they paste a token, deploy it immediately. If they're vague about location, run the bare auto-detect command first before asking them for a path.

That's it — no manual `.env` editing, no `export`. After a PASS you can immediately run queries through the adapter (SQL built exactly as usual; the adapter auto-strips any `tencent-databrain-prod.` project prefix, so templates need no changes):
```bash
python scripts/tiderider_sql.py --sql "<the SQL you built>" --output_file /tmp/r.json
```

> If the user has trouble applying for a token or hits a permission issue → direct them to contact **chandwang** on WeCom (企业微信).

> 🚨 **HARD LIMIT — 5000-row cap (MANDATORY to surface):** Via Databrain, **detail** result sets are hard-capped at **5000 rows**. The API returns `code=0` with NO truncation flag — a query matching 7,511 rows silently comes back as 5,000. The adapter detects this and adds a top-level `_tiderider_guard` block: aggregate queries → `SAFE_AGGREGATE`; detail queries that hit the cap → `TRUNCATED_AT_5000` with `real_total`.
> - **Aggregate queries** (`GROUP BY` / whole-set `COUNT`/`AVG`/`SUM`/`COUNTIF`) collapse to few rows → never affected. This is ~90% of sentiment reports (trend / channel / tag / KPI).
> - **Detail queries** (per-row `SELECT content...`, `SELECT *`, high-engagement pulls, tagging CSV export) → may be truncated.
> - When `_tiderider_guard.status == "TRUNCATED_AT_5000"`, you MUST tell the user in the report/answer: *"⚠️ This detail query matched ~{real_total} rows; due to the Databrain interface limit only the first 5,000 are returned — this analysis covers those 5,000 only, not the full set. For full-population conclusions, use aggregate metrics (share / average / count)."*
> - This cap **only applies to the Databrain fallback (method 3)**. When connected via a direct-BigQuery method (1/2), there is no such limit.
> - Full details: see `expert-package/DATABRAIN_INTEGRATION.md`.

### Hidden methods — direct BigQuery (A/B): reveal ONLY if the user raises it first

> 🚫 **Never proactively mention, list, or hint at these two methods.** When the detector returns `none`, the user must see **only** the Databrain Token path — do **not** say "you could also use a BigQuery credential or gcloud". The existence of A/B stays invisible by default.
>
> ✅ **The single exception:** the *user themselves* brings it up — e.g. *"can I log in with a BigQuery service-account credential?"* or *"I can connect via gcloud directly."* Only then do you acknowledge it and walk them through the relevant method below. If they never mention it, it never comes up.
>
> These give full results with no 5000-row cap. If the backend already has one configured, the detector picks it automatically (still silent — you don't announce it).

**Method A · Service Account JSON file** — internal maintainer supplies the path
```python
import os
from google.cloud import bigquery
os.environ["GOOGLE_APPLICATION_CREDENTIALS"] = CRED_PATH   # backend-provided path
client = bigquery.Client()        # SA JSON contains project_id, read automatically
```

**Method B · gcloud local ADC login** — internal user already has a GCP account + data-access permission
```bash
gcloud auth login                          # log into the gcloud CLI
gcloud auth application-default login      # KEY step: generates ADC — the Python SDK actually uses this
gcloud config set project <PROJECT_ID>
```
```python
from google.cloud import bigquery
client = bigquery.Client(project=PROJECT_ID)  # ADC has no project_id, pass explicitly; get via client.project — never hard-code
```
- ⚠️ For Method B, the SDK works because of `gcloud auth application-default login` (ADC), not just `gcloud auth login`.

## Table Priority

### Review data
| Priority | Table | Notes |
|----------|-------|-------|
| **1** | Cleaned feeds table | Cleaned data (currently covers Subway Surfers / SSC only) |
| 2 | Raw feeds table | Raw data; used for all other games |

⚠️ The two tables have **completely different** field names — never reuse SQL templates! See @references/query-rules.md.

### Anomaly analysis
When the user asks about an anomaly / sentiment swing, **first priority** is the anomaly-details table (contains the four-module Remark attribution); fall back to the raw feeds table for manual attribution only when there is no data.

### Sentiment summarization
Prefer citing the key-document table (official / big-KOL content) as the main thread, then use high-engagement comments as corroboration.

## Core Query Templates

> **Note**: `{project}` in SQL is auto-derived via `client.project` (from the credential JSON) — never ask the user for it.

### Basic sentiment overview
```sql
SELECT
  COUNT(*) as total_reviews,
  COUNTIF(sentiment_rating >= 4) as positive,
  COUNTIF(sentiment_rating < 2) as negative,
  ROUND(COUNTIF(sentiment_rating >= 4) * 100.0 / COUNT(*), 1) as pos_rate
FROM `{project}.opinion.feeds`
WHERE unified_edition_id = "{uid}"
  AND comment_time BETWEEN "{start}" AND "{end}"
  AND isvalid >= 1
```

### Steam positive rate (Steam channel only)
```sql
SELECT
  COUNT(*) as total,
  COUNTIF(is_recommend = 1) as positive,
  ROUND(COUNTIF(is_recommend = 1) * 100.0 / COUNT(*), 1) as recommend_rate
FROM `{project}.opinion.feeds`
WHERE unified_edition_id = "{uid}"
  AND channel_name = "steam"
  AND comment_time BETWEEN "{start}" AND "{end}"
  AND isvalid >= 1
```

### Daily trend
```sql
SELECT
  DATE(comment_time) as dt,
  COUNT(*) as total,
  COUNTIF(sentiment_rating < 2) as neg,
  ROUND(COUNTIF(sentiment_rating >= 4) * 100.0 / COUNT(*), 1) as pos_rate
FROM `{project}.opinion.feeds`
WHERE unified_edition_id = "{uid}"
  AND comment_time BETWEEN "{start}" AND "{end}"
  AND isvalid >= 1
GROUP BY dt
ORDER BY dt
```

### Channel distribution
```sql
SELECT
  channel_name,
  COUNT(*) as cnt,
  ROUND(COUNTIF(sentiment_rating >= 4) * 100.0 / COUNT(*), 1) as pos_rate
FROM `{project}.opinion.feeds`
WHERE unified_edition_id = "{uid}"
  AND comment_time BETWEEN "{start}" AND "{end}"
  AND isvalid >= 1
GROUP BY channel_name
ORDER BY cnt DESC
```

### Language distribution
```sql
SELECT
  language,
  COUNT(*) as cnt,
  COUNTIF(sentiment_rating < 2) as neg
FROM `{project}.opinion.feeds`
WHERE unified_edition_id = "{uid}"
  AND comment_time BETWEEN "{start}" AND "{end}"
  AND isvalid >= 1
GROUP BY language
ORDER BY cnt DESC
LIMIT 15
```

### Keyword search (dual-field rule)
```sql
-- English keyword: MUST search both content_to_zh + content_to_en
SELECT ...
WHERE ...
  AND (
    REGEXP_CONTAINS(LOWER(IFNULL(content_to_en, '')), r'{en_pattern}')
    OR REGEXP_CONTAINS(LOWER(IFNULL(content_to_zh, '')), r'{zh_pattern}')
  )
```

### KOL discovery (high-follower negatives)
```sql
SELECT
  reviewer, follower_number, content_to_zh, channel_name, comment_time
FROM `{project}.opinion.feeds`
WHERE unified_edition_id = "{uid}"
  AND comment_time BETWEEN "{start}" AND "{end}"
  AND isvalid >= 1
  AND sentiment_rating < 2
  AND follower_number > 10000
ORDER BY follower_number DESC
LIMIT 20
```

## References

- Game UID mapping: @references/games.json
- Query rules & caveats: @references/query-rules.md

## Data-Volume Tiers & Pre-Query Warning (MANDATORY)

⚠️ **Mandatory behavior: before pulling detail rows, always assess the data volume tier; if HIGH/MID, proactively warn the user and offer options first, and only execute after confirmation. Never run a large-range query without prompting.**

| Tier | Daily reviews | Example games | Expert action |
|------|---------------|---------------|---------------|
| 🔴 HIGH | >30K/day | Roblox (~114K), NIKKE (~60K), DeltaForce (~48K) | **Proactive warning** + suggest window ≤ 7 days, or run aggregates only (no detail rows), let the user pick |
| 🟡 MID | 5K–30K | Brawl Stars (~24K), POE2 (~7.8K) | Reminder + suggest window ≤ 14 days |
| 🟢 OK | <5K | BF6, Subway, EFT, Hunt, GST, Block Blast | Normal query, no interruption |

**Warning phrasing example** (HIGH tier):
> ⚠️ "{Game} averages ~{N} reviews/day, and the {days}-day window you want is fairly large (may scan a lot and take a while). Two options: ① shrink the window to 7 days; ② I run aggregates only (sentiment share / channel / trend) without detail rows. Which do you prefer?"

**New games / games not in the table above**: run a single `COUNT(*)` probe first to get the real daily average, then decide whether a warning is needed — never blindly pull detail rows.

> 💡 Check this table first to judge the tier; probe volume first for any game not listed. Cost note: the raw feeds table is a very large partitioned table — a high-frequency game × long window can scan several GB in a single query.