GH GambleHub

テレメトリーとイベントコレクション

1)目的と原則

目的:
  • アナリティクス、不正防止、RG、コンプライアンス、およびMLのための単一で予測可能なイベントフロー。
  • エンドツーエンドのトレース(ユーザー/セッション/リクエスト/トレース)と再現性。
  • PIIの最小化とプライバシーの遵守。

Принципы: schema-first、 privacy-by-design、 idempotency-by-default、 observability-by-default、 cost-aware。

2)イベントの分類

支払: '支払。デポジット'、'支払い。出金'、'支払い。「チャージバック」

ゲーム:'ゲーム。session_start/stop'、ゲーム。ベット'、'ゲーム。支払い'、'ボーナス。適用されました。
カスタム:'auth。 login'、 'profile。'、'kycを更新します。status_changed'、 RG。 。 。
手術室:'api。リクエスト'、'エラー。例外'、'release。deploy'、'feature。 。 。
コンプライアンス:'aml。alert_opened'、制裁。スクリーニングされた'、'dsar。要求されました。

各タイプには、ドメイン所有者、スキーマ、および新鮮さSLOがあります。

3)スキームと契約

必須フィールド(最小):
  • 'event_time' (UTC)、 'event_type'、 'schema_version'、 'event_id' (UUID/ULID)、
  • 'trace_id'/'span_id'、 'request_id'、 'user。pseudo_id'、 'session_id'、
'source'(クライアントサーバプロバイダ)、'market'(管轄)、'labels'。
例(JSON):
json
{
"event_id": "01HFY1S93R8X",
"event_time": "2025-11-01T18:45:12. 387Z",
"event_type": "game. bet",
"schema_version": "1. 4. 0",
"user": {"pseudo_id": "p-7a2e", "age_band": "25-34", "country": "EE"},
"session": {"id": "s-2233", "device_id": "d-9af0"},
"game": {"id": "G-BookOfX", "provider": "StudioA", "stake": {"value": 2. 00, "currency": "EUR"}},
"ctx": {"ip": "198. 51. 100. 10", "trace_id": "f4c2...", "request_id": "req-7f91"},
"labels": {"market": "EE", "affiliate": "A-77"}
}

スキームの進化:セマンティックバージョン;後方互換性-nullableフィールドを追加します。breaking-新しいバージョン('/v2')でのみ、録音期間が2倍になります。

4)器械使用: どこでそしていかに

4.1クライアント(Web/モバイル/デスクトップ)

ローカルバッファテレメトリーSDK、バッチ送信、指数関数リトレイ。
自動イベント:訪問、クリック、ブロックの可視性、Webバイタル(TTFB、 LCP、 CLS)、 JSエラー。
識別子:'device_id' (stable、 but private)、 'session_id' (updated)、 'user。 。 。
「ノイズ」に対する保護:'event_id'、スロットリング、クライアント側サンプリングによるデッドアップ。

4.2サーバ/バックエンド

ロガー/トレーサラッパー(OpenTelemetry)→ドメインイベントemit。
edge/gatewayからdownstreamのすべてのサービスに'trace_id'を強制的に投げます。
ドメインイベントのトランザクション公開のためのアウトボックスパターン。

4.3プロバイダー/第三者

ホスト回路への正規化のコネクター(PSP/KYC/studios);バージョンアダプタ。
署名/ペイロード整合性チェック、境界ロギング(インジェスト監査)。

5) OpenTelemetry (OTel)

トレース:各リクエストは'trace_id'を受け取ります。'trace_id'/'span_id'を介してログ/イベントを関連付けます。
ログ:OTelログ/コンバータを使用します。環境ラベルのサービス。name'、'deployment。env'。
メトリクス:サービス別RPS/レイテンシ/エラーレート、ビジネスメトリクス(GGR、変換)。
コレクター:Kafka/HTTP/graphicへのレシート/バッファ/エクスポートの単一点。スタック。

6)識別子と相関関係

'event_id'-一意性と偶像性。
'user。pseudo_id'-安定したエイリアス(個別にマッピングし、制限)。
エンドツーエンドの分析には'session_id'、 'request_id'、 'trace_id'、 'device_id'が必要です。
APIゲートウェイおよびSDKレベルのID整合性。

7)サンプリングとボリュームコントロール

ルール:イベントタイプごと、市場ごと、負荷による動的(アダプティブ)。
正確にキャプチャされたイベント:支払い/コンプライアンス/インシデント-サンプリングされていません。
分析イベント:10-50%ディスプレイケースの補正重量で許可されています。
サーバー側のダウンサンプリング:高周波メトリックに有効です。

8)プライバシーとコンプライアンス

PIIの最小化:PAN/IBAN/emailのトークン化;IP→geo codes/ASNをingestする。
地域化:地域のインジェストエンドポイント(EEA/UK/BR)に送信します。
DSAR/RTBF:選択的な投影非表示のサポート。法的取引ログ。
保持ポリシー:タイプ別のタイミング(アナリティクスが短く、規制が長い)リーガルホールド。

9)輸送および緩衝

→エッジクライアント:HTTPS (HTTP/2/3)、 'POST/telemetry/batch'(最大100イベント)。
エッジ→タイヤ:Kafka/Redpandaによって分割'user。 。 。
フォーマット:JSON (ingest)、 Avro/Protobuf(バス)、寄木細工(湖)。
信頼性:ジッタ、DLQ、毒薬分離とレトライ。

バッチ指定(簡略化):
json
{
"sdk": {"name":"igsdk-js","version":"2. 7. 1"},
"sent_at": "2025-11-01T18:45:12. 500Z",
"events": [ {... }, {... } ]
}

10)信頼性およびidempotency

クライアントによって生成された'event_id'+'(event_id、 source)'によるサーバ祖父。
サービス上のOutbox、スレッド内の正確に一度の意味(キー付き状態+重複除外)。
キー内での注文:'user/session'によって分割されます。
タイムコントロール:NTP/PTP、許可されたドリフト(例:≤ 200 ms)、サーバー上の'received_at'。

11)テレメトリー品質(TQ)とSLO

完全性: ≥ 99。1 Tあたりクリティカル型イベントの5%

鮮度:p95シルバーへの納期遅延≤ 15分。

正当性: 有効なスキーム≥ 99。9%、ドロップレート<0。1%.

トレースカバレッジ:'trace_id'のリクエストの割合≥ 98%です。
コスト/GB:ドメインごとのインジェスト/ストレージのターゲット予算。

12)可視性とダッシュボード

最小ウィジェット:
  • ソースとリージョンによるラグインジェスト(p50/p95)。
  • イベントタイプとマーケットによる完全性。
  • /oversized-payloadsスキームの検証エラー。
  • SDKバージョンマップとレガシークライアントの割合。
  • Webバイタルの相関関係↔変換/失敗。

13)クライアントSDKの要件

ライトフットプリント、オフラインバッファ、遅延初期化。
設定:サンプリング、最大バッチサイズ、最大キュー年齢、プライバシーファッション(no-PII)。
保護:パッケージの署名/反タンパー、キーの難読化。
更新:ノイズの多いイベントを無効にするfeature-flags。

14)端の層および保護

レート制限、WAF、スキーマ検証、圧縮(gzip/br)。
クライアントごとのトークンバケット;アンチリプレイ('request_id'、 TTL)。
「未加工」ペイロードの外のIPおよびUAの取り外し→normalization/enrichment。

15)データパイプラインとの統合

ブロンズ:不可逆的に(法医学のために)生のペイロードを追加しました。
シルバー:重複排除/濃縮を伴う正規化テーブル。
金:BI/AML/RG/プロダクトのための陳列ケース。
イベントとレポート間のリンク;変形のバージョン。

16)顧客品質分析

静かな顧客比率(N時間にイベントはありません)。
「嵐」の異常(重複/バースト)。
バージョンとプラットフォームによる「レガシーSDK」の共有。

17)プロセスとRACI

R: Data Platform (ingest/bus/validators)、 App Teams (SDKインストルメンテーション)。
A:データ・アーキテクチャ担当。
C: コンプライアンス/DPO (PII/保持)、 SRE (SLO/インシデント)。
I: BI/マーケティング/リスク/製品。

18)実装ロードマップ

MVP (2-4週):

1.6〜8種類のイベントタクソノミv 1+JSONスキーマ。

2.SDK (Web/Android/iOS)-バッチPCサンプリング;エッジ'/テレメトリー/バッチ'。

3.カフカ+ブロンズ層;基本的なバリデータとデッドアップ。

4.ダッシュボードは、Drop/Validatorへのアラート、Lag/Completenessを取り込みます。

フェーズ2(4-8週間):
  • OTelコレクター、トレース相関;銀の正規化とDQルール。
  • 地域エンドポイント(EEA/UK)、プライバシーファッション、DSAR/RTBF手続き。
  • SDKバージョンマップ、リングによる自動ロールアウト更新。
フェーズ3(8-12週間):
  • 正確に一度ストリーム、機能ストア接続、不正防止オンラインフィード。
  • スキームとバリデータのルールとしてコード、影響分析。
  • 価値の最適化:適応的なサンプリング、湖のZ順序/クラスタリング。

19)リリース前の品質チェックリスト

  • 必要なスキーマフィールドと正しいタイプが入力されます。
  • 'trace_id'/'request_id'/'session_id'が存在します。
  • SDKはバッチ、再試行、サンプリングをサポートします。
  • Edgeはスキームを検証し、ペイロードサイズを制限します。
  • プライバシーフィルタと機密フィールドのトークン化が有効になります。
  • SLO/アラートとダッシュボードを設定しました。
  • ドメインのドキュメント(イベント、所有者、SLAなど)。

20)頻繁なミスとそれらを回避する方法

スキームのないRawイベント:レジストリとCI検証を入力します。
idempotency: 'event_id'を要求し、重複除外ウィンドウを格納します。
PIIとアナリティクスミックス:個別のマッピング、マスクフィールド。
トレースなし:ルート'trace_id'ゲートウェイ→サービス→イベント。
管理されていないボリューム-サンプリング/トロトリングおよび予算クォータを使用します。
リージョンのないグローバルエンドポイント-地域化とデータ常駐を使用します。

21)用語集(短い)

OpenTelemetry (OTel)は、トレイル/メトリック/ログのオープンスタンダードです。
Outbox-ドメインイベントのトランザクション発行。
DLQ-「壊れた」メッセージのキュー。
サンプリング-ボリューム削減のためのイベントの一部を選択します。
Data Residency-データを所望の管轄区域に保存します。

22)ボトムライン

厳密なスキーム、合意された識別子、デフォルトのプライバシー、信頼性の高いトランスポート、観測性、コスト削減など、単なる「ログの送信」ではなく、適切に設計されたテレメトリーは手配に関するものです。この記事に従うことで、予測可能なSLOを使用して、分析、コンプライアンス、機械学習の準備が整いました。

Contact

お問い合わせ

ご質問やサポートが必要な場合はお気軽にご連絡ください。いつでもお手伝いします!

統合を開始

Email は 必須。Telegram または WhatsApp は 任意

お名前 任意
Email 任意
件名 任意
メッセージ 任意
Telegram 任意
@
Telegram を入力いただいた場合、Email に加えてそちらにもご連絡します。
WhatsApp 任意
形式:+国番号と電話番号(例:+81XXXXXXXXX)。

ボタンを押すことで、データ処理に同意したものとみなされます。