統計和分析API:事件,聚合,重組
文章全文
1)為什麼外部API分析
合作夥伴/提供商:監視SLA內容、RTP、參與。
營銷/CRM:基於指標的觸發活動(DAU,存款漏鬥)。
運營/財務:近實時GGR/NGR、支付成功、webhook瀉湖。
產品:應用內統計小部件,A/B面板。
目標是安全和可預測地以清晰的語義和SLA提供事件和集合。
2)手指上的建築
Producers (PAM/Wallet/RGS/Payments/Kafka/CDC)
│
Ingestion API ──Stream (Kafka/Pulsar) ──Lakehouse (Delta/Iceberg)
│                 └─OLAP (ClickHouse/BigQuery/Trino)
└────────────────────────────────────Aggregation/Query API
(cache, RBAC/RLS, rate limits)事件:on-least-once,「event_id/idempotency_key」的去世。
聚合物:賽前滾動(1m/5m/1h/1d)+上飛。
Retenchen:在Gold Marts之上的cohort引擎。
Кэш: CDN/edge + ETag/`Cache-Control`, server-side TTL.
3)事件模型: 最低標準
3.1常見字段
json
{
"event_id":"uuid",  "event_type":"bet.settled",  "occurred_at":"2025-10-23T16:21:05Z",  "ingested_at":"2025-10-23T16:21:06Z",  "tenant_id":"brand-7",  "region":"EU",  "player_id":"p_19f3",   // псевдо-ID
"trace_id":"tr_a1b2c3",  "schema_version":"1.3.0",  "payload":{...}
}規則:UTC timestamps,「player_id」是別名,貨幣在小單位中。
3.2個關鍵類型
4) Ingestion API(適用於第三方來源)
發送事件包
POST /v1/events:batch
Headers: X-Idempotency-Key: ev_20251023_001
[
{"event_id":"...","event_type":"bet.placed",...},  {"event_id":"...","event_type":"bet.settled",...}
]
→ 202 { "accepted":2, "duplicates":0, "trace_id":"tr_a1b2" }保障措施:在保障之下;通過「event_id」在Silver中過濾重復。
5) Aggregation API: 時間系列和切片
5.1時間表(時間度量)
GET /v1/analytics/timeseries
?metric=ggr    // ggr, ngr, dau, deposits_success, rtp
&granularity=5m  // 1m/5m/1h/1d
&from=2025-10-22T00:00:00Z&to=2025-10-23T00:00:00Z
&filters=region:EU,brand_id:brand-7,provider_id:studio_x
&group_by=brand_id
→ 200 {
"metric":"ggr",  "granularity":"5m",  "series":[
{"ts":"2025-10-22T00:00:00Z","brand_id":"brand-7","value_minor":120030},   {"ts":"2025-10-22T00:05:00Z","brand_id":"brand-7","value_minor":98020}
],  "next_cursor":null
}5.2切片/上衣(按組)
GET /v1/analytics/slice
?metric=rtp &dim=game_id &from=2025-10-22&to=2025-10-23
&limit=50&order=-value
→ 200 { "items":[{"game_id":"g_01","value":0.956},...] }5.3漏鬥(funnel)
POST /v1/analytics/funnel
{
"steps":[
{"event":"payment.intent"},   {"event":"payment.authorized"},   {"event":"payment.captured"},   {"event":"wallet.credit", "reason":"deposit"}
],  "window_sec": 3600,  "filters":{"region":"EU","brand_id":"brand-7"}
}
→ 200 {
"total": 12450,  "steps": [
{"name":"intent", "count":12450, "rate":1.0},   {"name":"authorized", "count":11020, "rate":0.885},   {"name":"captured", "count":10110, "rate":0.811},   {"name":"credited", "count":10050, "rate":0.807}
]
}5.4限制和緩存
Rate limit per token/brand/region.
「ETag」的回應;支持「If-None-Match」。
TTL緩存取決於「granularity」(例如5m → TTL 60-120 s)。
6)重生和隊列: 規則和API
6.1定義(公約)
DAU/WAU/MAU:如果是'bet,則處於活動狀態。placed'或'wallet。credit (deposit)` или `session.started '≥ N分鐘。
Cohort by first deposit(通常用於LTV)或registration(用於參與)。
Retention D1/D7/D30:隊列中的份額又回到了白天窗口+/-品牌超時區的入場券。
根據窗口中唯一的「player_id」來重新訪問。
6.2個API隊列
POST /v1/analytics/retention
{
"cohort":"first_deposit",  "start_date":"2025-09-01",  "end_date":"2025-09-30",  "return_event":"bet.placed",  "days":[1,7,14,30],  "filters":{"region":"EU","brand_id":"brand-7"}
}
→ 200 {
"cohort":"first_deposit",  "rows":[
{"cohort_date":"2025-09-01","size":1820,"d1":0.36,"d7":0.22,"d14":0.18,"d30":0.12},   {"cohort_date":"2025-09-02","size":1714,"d1":0.35,"d7":0.23,"d14":0.19,"d30":0.13}
]
}6.3 LTV/累積量
GET /v1/analytics/ltv?cohort=first_deposit¤cy=EUR&horizon=90d
→ 200 { "cohorts":[{"date":"2025-09-01","ltv_minor":[0,150,230,280,...]}] }7)語義指標(不爭論)
所有內容均在UTC中,指定貨幣和次要單位;通過將固定的FX轉換為Data Lake來解決多元貨幣性。
8)驗證、過濾和兼容性
路徑:'/v1/……';新度量/字段-選擇性。
Фильтры: `brand_id, region, provider_id, game_id, method, currency, device, geo`.
分離:基於cursor(「next_cursor」)。
Breaking只→ '/v2'+Deprecation/Sunset頭條新聞和changelog。
9)安全和準入
OAuth2 Client Credentials(短壽命令牌),用於B2B的mTLS。
RBAC/ABAC:度量/切片權限;通過「品牌/地區」的RLS過濾器。
PII:API不提供PII,僅在需要時提供聚合/偽ID。
駐地:將請求路由到區域;跨區域數據-禁止。
利率極限和配額,反赤字;WORM可用性審核。
10)SLO和可觀察性
SLO地標:- 'GET/timeseries gran=5 m'p95 ≤ 500-800毫秒,'GET/slice' p95 ≤ 1-2 s(最高可達50-100個位置),'POST/retention'(隊列月份)p95 ≤ 3-5 s,rollup的新鮮度:p95 ≤ 2-5分鐘來自'occurred_at'。
- 度量標準:latency p50/p95/p99,error-rate(4xx/5xx),cache-hit,查詢/掃描字節(OLAP),每個滾動的「freshness lag」。
- Logs:結構化的'trace_id'、查詢過濾器(沒有PII),掃描計數。
11)現金,初步計算,成本
滾動表:1m/5m/1h/1d按關鍵指標→快速「時間序列」。
重型切片/cohort的材料化視圖。
ETag + max-age;後期事件中的殘疾是增量發生的。
「熱/冷」策略:在OLAP-warehouse中進行熱門查詢;檔案在湖裏。
對查詢的「掃描字節」限制;給調度員的提示。
12)嵌入(嵌入)和導出
通過帶有RLS令牌的簽名URL/iFrame內置小部件。
按任務(job API)導出CSV/Parquet(具有大小限制和時間參考)。
Webhook上載就緒通知。
13)支票單
體系結構
- 單一事件圖,semver, registry;「event_id」的祖先。
- Rollup's和materialized views為頂級案例。
- RLS/RBAC/ABAC,居住權,令牌壽命短。
- Cash (ETag/TTL), rate limits,配額。
語義學
- GGR/NGR/RTP/DAU/retention定義已記錄在案。
- 貨幣-小單位;FX是在事件發生時捕獲的。
- UTC Retention,考慮到顯示中的品牌時間段。
業務活動
- SLO/dashbords新鮮和潛伏。
- WORM可用性/出口審核。
- DR/xaoc演習:積壓的滾動,一連串的查詢,遲到的事件。
14)反模式(紅旗)
「原始」OLTP表直接放入API中。
命令之間的度量定義不一致。
沒有重復數據消除和水廠→雙/丟失事件。
沒有緩存/配額的無限制飛行聚合→昂貴且緩慢的請求。
沒有居住策略的跨區域聚合。
將PII/玩家的詳細信息返回到公共響應中。
沒有「/v2」和Deprecation的安靜突破變化。
15)Mini-Spec(TL;DR)
事件:'/v1/事件:batch'(在least-once上,在'event_id'上刪除)。
時間: '/v1/analytics/timeseries?metric=...&granularity=...` (rollup + кэш).
切片: '/v1/analytics/slice?metric=...&dim=...`.
漏鬥:'/v1/analytics/funnel'(窗口、步驟、過濾器)。
再生/再生:'/v1/analytics/retion'(+LTV)。
安全性:OAuth2+mTLS,RLS,按品牌/區域代幣,WORM審核。
SLO: p95 ≤ 0.5-2 c;新鮮度≤ 2-5分鐘。
統計和分析的API不是"SELECT FROM big_table",而是合同度量:穩定事件,預讀和可緩存單元,嚴格定義的重構和隊列,安全性(RLS/RBAC)和居住性,SLO可以理解。因此,您可以快速、廉價和可預測地將數據提供給合作夥伴,產品和BI,而無需有爭議的解釋,並且不會泄漏或存儲過載的風險。
