加密賭場

Torrent Gear

事件和獎項自動化：規則和網絡指南

遊戲化取決於兩個「摩托車運動員」：事件（用戶所做的事情）和規則（這取決於什麼）。為了使它大規模且無誤地工作，您需要可靠的事件總線，規則引擎，交付/頒獎機制以及嚴格的防偽保護。下面是實用體系結構，模板和支票單。

1）流式架構「事件→規則→獎勵」

1.Ingest（事件輸入）：SDK/Web，來自付費遊戲/遊戲提供商的服務器網絡手冊→ Gateway API →隊列/總線（Kafka/Rabbit/Cloud Pub/Sub）。

2.Normalizer：驗證，富集（geo，device，payer_flag)，電路版本。

3.規則引擎：得分/CV，任務/任務檢查，獎勵/通知觸發器。

4.Reward Orchestrator：計算獎項，預算支票，RG/KYC門，創建「發行任務」，寫入日誌。

5.Payout/Bonus Service：緩存/獎金緩存/飛盤/優惠券，外部webhooks（錢包，提供商）。

6.Notifier： push/in-app/email/messenger帶頻率限制。

7.Storage/Analytics：原始事件、店面、A/B、Alerta。

8.Anti-Fraud/RG：帽子，啟發式/ML，大獎的保留和審查。

2）事件模型（最小集）

json
{
"event_id": "d9e8-...-5c2",  "event_name": "bet",  "version": "1.2.0",  "ts": "2025-10-24T11:37:21Z",  "user": {
"id": "u_123",   "geo": "TR",   "platform": "android",   "payer_flag": true,   "risk_flags": ["vp_nightly"]
},  "context": {
"session_id": "s_789",   "device_fp": "fp_...",   "ip": "203.0.113.24"
},  "payload": {
"game_id": "slot_wolf",   "bet": 0.5,   "win": 1.25,   "currency": "EUR",   "provider": "GameCo"
}
}

Базовые типы: `login`, `session_start/end`, `bet/spin`, `win`, `deposit`, `withdraw_request`, `kyc_status_changed`, `mission_view/join/progress/complete`, `tournament_join/score/update/reward`, `reward_issued`, `rg_event`.

3）規則引擎： 如何描述邏輯

概念：規則（if/then），細分，時間窗口，帽子，優先級，轉化。

聲明規則示例（YAML樣式）：

yaml rule_id: r_points_winmult_v2 when:
event_name: bet filters:
- payload.bet >= 0.2
- user.geo in ["TR","BR","PE"]
- now between "2025-11-01" and "2025-11-30"
score:
formula: "floor((payload.win / payload.bet) 3)"
caps:
per_bet: 50 per_minute: 200 per_day: 1500 reward_trigger:
on_progress:
threshold: [100, 300, 800]
reward: [{type: "fs", value: 10}, {type: "bonus_cash", value: 2}, {type: "loot", rarity: "rare"}]
guardrails:
kyc_min_level: 2 rg_limits_ok: true budget_pool: "nov_season"
budget_soft_cap: 80000 meta:
version: "2.0"
experiment: "scoring_ab_2025w45"

4） Webhooks： 集成服務器

4.1.出站webhooks（從您到提供商/錢包）

方法： 'POST https：//合作夥伴。example/payouts`

Подпись: `X-Signature: HMAC-SHA256(secret, body)` + `X-Request-Id` (idempotency).

Retrai：指數後端，「max_retries=8」，jitter，DLQ。

Idempotency：重播相同的「X-Request-Id」 →合作夥伴必須回答相同的「payout_id/status」。

payload示例：

json
{
"request_id": "rid_7f5...",  "user_id": "u_123",  "reward": {"type":"cash","amount":10.00,"currency":"EUR"},  "reason": "milestone_300_points",  "kyc_level": 2,  "constraints": {"wagering": 0, "expiry_at": "2025-12-01T00:00:00Z"}
}

4.2.傳入的webhooks（給你）

僅允許IP/MTLS列表，檢查HMAC和簽名壽命（「X-Timestamp」，± 5分鐘）。

將「原始」body+標題保存到審計存儲（WORM）中。

任何雙打/重播→檢查相對於日誌的idempotency鍵。

5）可靠性： 「水平」流動沒有雙重支付

ingest+idempotent上的at-least-once處理程序→金本位制。

Idempotency key：「hash（event_id+user_id+rule_id）」用於計分；頒發「reward_task_id」獎勵的單獨密鑰。

Exactly-once語義僅在邏輯上（通過冪等）是現實的，而不是運輸。

事件順序：存儲「event_ts」和「ingest_ts」；從「user_id」鍵的隊列中應用reordering窗口（例如60秒）和replay。

Dead Letter Queue (DLQ):

我們在那裏寫信時存在永久錯誤（臨時計劃未通過，簽名不合格，預算已關閉）。

使用reprocess/drop/fix計劃按鈕的「咆哮DLQ」服務。

6）預算和保證金保護

預算池：「nov_season」，「daily_sprint」，「vip_weekend」。

配額：軟/硬帽，「巡回賽決勝局」-當預算達到90％時，將大獎轉為保留狀態。

單一成本：「Prize&Bonus Cost per Active/Payor」，Net Uplift。

優先事項：RG和合規性比促銷更重要-在沖突中，獎勵被推遲。

預算檢查示例（SQL草圖）：

sql
SELECT pool_id,    SUM(amount) AS spent,    budget AS limit,    SUM(amount)/budget AS fill
FROM reward_ledger
WHERE pool_id =:pool AND date(ts) = current_date
GROUP BY pool_id, budget;

7）RG/KYC/Geo門（玩家安全和合規性）

KYC：緩存/大獎的最低L2；L1允許飛旋。

RG：在取消限制之前，檢查存款限額、自我排除、「冷靜」→獎勵「凍結」。

Geo：每個規則/獎項池的授權國家列表。

閾值變量：個別帳戶「幾乎達到」的急劇增長=保持和評論的理由。

8）反親屬規則和遙測

每天/分鐘/小時/小時的積分帽，最低費率方差，禁止「完美」模式。

Tehsignals：無頭，重復device_fp，代理子網。

異常：「眼鏡/投註」和「眼鏡/分鐘」是99 percentile上的長「尾巴」。

為頂級獎牌獲得者保留和審查：KYC自動支票+手動查看。

9）監視，度量標準和Alerta

SLO/SLA:

Ingest p95 ≤ 250毫秒；處理p95 ≤ 150毫秒規則；領導層更新≤ 2 c；頒發獎項≤ 60秒。

Error budget < 0.每天1％的事件。

Alerts：

實驗中的SRM（流量偏斜），DLQ的增長，HMAC驗證簽名下降，預算超支，單倍激增。

Dashbord（每天）：

事件/s，脫落，容錯性；
漏鬥：事件→規則→ reward_task → reward_issued；
費用：Prize/Bonus per Active, Net Uplift；
質量：指紋標誌，KYC塊，RG觸發。

10）驗證和遷移

每個規則都是versioned（'rules。version`).

如果沒有新版本，則無法編輯活動規則；使用ficheflag和「平穩加熱」（10% → 50% → 100%）。

通過計劃註冊的事件模式；不兼容的更改-僅主要版本。

11） A/B自動化測試（簡短）

單位-用戶；sticky-assignment;分層（payer/geo/platform）。

分開的排行榜或積分正常化以消除幹擾。

Primary: participation_net, completion, Net ARPPU;Guardrails：投訴/1k, frod-flags, RG觸發。

CUPED和協變量以減少方差。

12）示例： 從規則到引渡

12.1.觸發器「微觀進步獎」

json
{
"type": "reward_task.created",  "reward_task_id": "rt_456",  "user_id": "u_123",  "origin": {"rule_id":"r_points_winmult_v2","threshold":300},  "reward": {"type": "bonus_cash", "amount": 2, "currency":"EUR", "wagering": 15},  "pool_id": "nov_season",  "status": "pending",  "created_at": "2025-10-24T11:38:30Z"
}

12.2.外出webhook到錢包


POST /wallet/credit
X-Request-Id: rid_7f5...
X-Timestamp: 1730061700
X-Signature: sha256=7b9a...

{ "user_id":"u_123", "amount":2.00, "currency":"EUR", "reason":"rule:r_points_winmult_v2" }

成功→ 「reward_task」=「succeeded」並寫入「reward_ledger」。

失敗（5 x/taymaut）→具有相同「X-Request-Id」的後退。

失敗（4xx） → DLQ+手動解析。

13）存儲和表格（草圖）

sql
-獎項雜誌
CREATE TABLE reward_ledger (
id BIGSERIAL PRIMARY KEY,  reward_task_id TEXT UNIQUE,  user_id TEXT,  pool_id TEXT,  type TEXT,  value NUMERIC(18,2),  currency TEXT,  cost NUMERIC(18,2) DEFAULT 0, -- реальная стоимость для P&L status TEXT, -- succeeded/failed/held created_at TIMESTAMPTZ,  updated_at TIMESTAMPTZ
);

-不可持續性
CREATE UNIQUE INDEX uniq_reward_task ON reward_ledger (reward_task_id);

-預算
CREATE TABLE reward_budget (
pool_id TEXT PRIMARY KEY,  budget NUMERIC(18,2),  spent NUMERIC(18,2),  period DATE
);

14）安全和隱私

HMAC簽名，MTLS，allow-list IP。

過境/靜止加密，按鍵旋轉，保管箱中的秘密。

最小化付費中的數據（單獨使用PII，通過引用令牌，TTL）。

審核日誌不可變（WORM）。

保留和處置策略（遺忘、重復數據消除安全）。

15）發射支票清單

事件圖和註冊表，webhook合同（簽名，TTL）。
隊列、轉發、DLQ、等效處理程序。
KYC/RG門規則中的帽子/警員。
預算池，電路斷路器，溢出變量。
Dashboard SLO+漏鬥恢復。
A/B-ficheflagi和SRM監測。
事件運行手冊（重播、凍結、手動發行）。

16）迷你案例（合成）

遊戲和錢包提供商的活動已連接；包括帶有帽子的「win/bet」得分。

Webhooks由HMAC簽名，最多可進行8次嘗試，DLQ每2小時進行一次咆哮。

在4周內： p95 180毫秒的處理時間；DLQ < 0,06%;付款0；前旗− 0.4個百分點；ΔParticipation_net +6,3 п.п.;ΔARPPU (net) +€2,1 при Prize&Bonus/Active +€0,7.

結論：將規則擴展到具有本地預算池的新地理位置。

頒獎自動化不是「隨心所欲地發送」。這是一個工程系統：可靠的事件交付，嚴格的規則驗證，idempotency和簽名，預算私人，KYC/RG門，防凍和監視。有一天建造這個框架-任何任務，錦標賽和「戰利品時刻」都可以預見，及時且具有積極的凈效果。