內容目錄引擎

目錄引擎是遊戲展示櫃和促銷收藏品的核心：它收集和規範提供商（RGS）的元數據，提供搜索/過濾器/排名，跨轄區和品牌應用可用性規則，調節個性化和促銷程序，然後通過具有可預測SLO的API提供快速響應。

1）目標和原則

快速讀取：p95 ≤ 100-150毫秒的目錄/搜索請求。
真實與新鮮：保證關鍵屬性（可用性、頭獎、提供商狀態）的相關性。
靈活性：編輯收藏和非發行促銷插槽。
合規性：地理/年齡/內容規則,許可證,負責任遊戲的限制。
多特南特/地區：品牌隔離和數據駐留合規性。
可觀察性：發射質量指標，A/B，轉換為遊戲/投註。

2）域模型（最小值）

• 遊戲是提供商的遊戲/產品。
• Provider-RGS/工作室。
• 變體-單個遊戲選項（波動，線路，限制，服務器）。
• Collection是編輯/自動選擇（例如，「Novinki」，「Jackpots」）。
• Placement-頁面/插槽中的固定位置/橫幅/標記。
• 能力/功能-遊戲屬性（免費旋轉、購買功能、大獎）。
• JurisdictionRule-可用性/限制規則。
• 信號-行為/操作信號（受歡迎，CTR，revenue）。
• Asset-具有設備/密度選項的媒體（圖標，海報，演示視頻）。

鍵：「game_id」（穩定的內部，不等於provider_game_id)，「tenant_id」，「region」，「locale」。

3）Ingest和正常化

1.源適配器（pullers）：與RGS/工作室集成（目錄、fici、RTP、標簽）。

2.Sanitize＆Map：將外部字段映射到單個字典（ACL），驗證和重復數據消除。

3.Enrich：本地化，類別，語義標簽，年齡限制等級。

4.Moderate：跨市場內容標誌（NSFW/宗教符號/敏感主題）。

5.Publish： 「GameUpserted/ProviderStatusChanged」事件→目錄投影。

相似性：所有帶有「source_id」+「version_ts」的消息；重復處理沒有副作用。
演變方案：適配器+mapper遷移中的「schema_version」。

4）歸一化方案（簡化）

json
{
"game_id": "g_3f92",
"tenant_id": "brand_eu",
"provider": { "id": "pr_evolution", "name": "Evolution" },
"title": { "en": "Lightning Roulette", "de": "Lightning Roulette" },
"capabilities": ["live","roulette","multiplier","bonus"],
"rtp": 97.3,
"volatility": "high",
"limits": { "min": 0.1, "max": 1000.0, "currency": "EUR" },
"jurisdiction": {
"allowed": ["MT","EE","DE"],
"blocked": ["NL","BE"],
"age_rating": 21
},
"assets": {
"tile": { "1x":"...", "2x":"..." },
"poster": { "web":"...", "mobile":"..." }
},
"tags": ["new","jackpot"],
"release_date": "2025-09-12",
"status": "active",
"variants": [{ "id":"v1","server":"eu-central-1","rtp":97.3 }]
}

5）搜索,過濾器,面板

索引：標題/同義詞的全文，「provider」，「capabilities」，「volatility」，「rtp_bucket」和「tags」。
過濾器：管轄權/地區/語言/設備/年齡,只有主動/認證。
同義詞/stemming：用戶術語地圖（「書」，「水果」，「球」）。
錯字：具有長度限制的tolerant搜索（編輯距離≤1 -2）。

6）排名： 信號和公式

• Freshness（發布時間）。
• 人口（發射/小時，獨特的玩家）。
• 質量（從目錄到遊戲的CTR，保持1/7天）。
• 商業（營銷助推器，交易，促銷插槽）。
• 法規遵從性（如果需要，敏感內容的軟降級）。
• Player-fit（配置文件/首選項兼容性）。

score = w1freshness + w2popularity + w3ctr + w4player_fit + w5boost

權重由配置/實驗控制；所有信號均標準化為［0；1].

7）個性化

短內存：最新推出和流派，RYW-用戶立即看到新的動作。
長期記憶：遊戲和玩家配置文件（遊戲類型/波動/會話）。
安全：個性化永遠不會違反管轄權/年齡規則。
Fallback：如果信號很少-中性排名+編輯收藏。

8）收藏品和促銷播放器

• Auto：規則/查詢（例如，"capabilities contains" jackpot "AND release_date>=NOW（）-30d'）。
• 編輯：有順序和時限的手動列表。
• 播放：頁面的固定位置（hero, row-1-slot-3）, A/B,按部分/轄區定位。
• 時間和優先級：「starts_at/ends_at」，沖突優先級，預覽優先於發布。

9）合規性和無障礙政策

地理/管轄權：白色/黑色國家/地區列表，許可證/證書驗證。
年齡評級：最低年齡，警告，不兼容市場的隱藏。
主題/符號：按國家/地區劃分的敏感內容的旗幟（宗教，酒精等）。
負責任的遊戲：對於限制/超時玩家的隱藏/降級。
審計：具有原因的不可變可用性更改日誌。

10）多特南特和多區域

所有數據均標有「tenant_id」和「region」。
隔離：按區域分列的法定人數/倉庫；跨區域投影-僅聚合。
Fairness： ingest/per tenant出版物的配額,以便「嘈雜」的品牌不會延遲其他品牌。

11）建築輪廓

寫入目錄內核（CP）：規範化+事務性事件輸出。
投影/閱讀模型（EC）：搜索索引，實例化集合，人氣計數器。

• Edge/CDN用於「冷」頁面/圖像。
• 熱請求的內存緩存（key=過濾器+頁面+tenant+region）。
• Ficheflagi：滾動排名/收藏規則,不發布。

12） API （REST/GraphQL,示例）

REST

GET /v1/catalog?tenant=brand_eu&region=EE&locale=ru
&filter=jackpot,true&sort=score_desc&page=1&size=24
→ 200 { items:[...], facets:{...}, as_of:"2025-10-31T12:10:02Z" }

GraphQL（片段）

graphql query Catalog($tenant:String!,$region:String!,$q:String,$filters:Filters){
catalog(tenant:$tenant, region:$region, q:$q, filters:$filters){
items { gameId title provider { name } score badges assets { tile } }
facets { providers { key,count } capabilities { key,count } }
freshnessMs
}
}

• 始終返回'as_of/freshnessMs', paging, fasts。
• 個性化是沒有PII的會話標記（RYW）。

13）信號和數據流

受歡迎：遊戲啟動時的註釋→微小的垃圾桶→投影中的集合。
CTR/轉換：在劇本/集合上點擊/啟動計數器。
操作狀態：健康提供者（RGS），頭獎/限制（事件流）。
市場推廣：遊戲/類別/供應商的時間系數。

14）可觀察性和SLO

• `catalog_p95_ms`, `catalog_p99_ms`, `error_rate`.
• 「index_freshness_ms」（項目延遲），「ingest_lag_ms」。
• 「ctr」，「click-to-launch」，「collection_coverage」（從收藏中提取的百分比）。

• `lift_ctr`, `lift_conversion`, «explore vs exploit» доля.

• 正確適用的地理/年齡規則的百分比，塊數/小時。

Alerts： 「ingest_lag_ms」的增長、關鍵收藏的CTR的下降、提供商的退化（發行中的標簽）。

15）性能和緩存

策略：熱請求-帶過濾器密鑰的30-120緩存；個人單元-短的TTL （10-30 c）或無緩存。
殘疾：通過「GameUpserted/可用性更改/PlacementUpdated」事件。
分割：穩定的光標，以便在更新信號時不會「跳躍」卡片。

16）與媒體合作

渲染配置文件：web/mobile/TV的尺寸/密度。
優化：WebP/AVIF, lazy-load, sprite/atlas用於瓷磚。
內容安全：掃描,水印,inline-PII禁令。

17）測試

適配器和API的合同/計劃測試。
救濟測試：黃金查詢集→預期結果/順序。
個性化：離線AUC/NDCG+online A/B with guardrail度量（遊戲時間、存款、RG信號）。
混亂：提供商降級，激增，索引延遲。

18）花花公子（runbooks）

1.索引差>SLO：停止次要集合,提高優先級,暫時簡化排名。
2.提供商「紅色」：降級/隱藏其遊戲，提升其他收藏。
3.API錯誤跳躍：檢查緩存/後端,啟用安全時間表,減小頁面大小。
4.不正確的可用性：回滾最新規則，包括關鍵市場的「白名單」，並審核更改。
5.排名發布：Canary rollout （5% → 25% → 50% → 100%）, CTR/轉換回滾。

19）典型錯誤

將外部提供商方案與內部模型混合（沒有ACL）。
缺乏「as_of/freshness」 →關於「過時」目錄的爭論。
違反管轄規則的個性化。
唯一不分解信號和A/B的「魔術」排名公式。
沒有緩存的大頁面和光標→ p99「射擊」。
將雙寫入索引和OLTP而不是事件+投影。

20）售前支票清單

• 所有提供商的歸一化字段和ACL字典。
• Idempotent ingest、outbox/inbox、DLQ和redrive。
• 帶有新鮮度SLO的目錄投影和搜索索引。
• 受控權重排名，信號分解和A/B。
• 合規規則（地理/年齡/主題）和變更審核。
• multi-tenant/region：數據隔離,公平,居住。
• 具有「as_of」，面板，遊標的API；緩存和事件致殘。
• p95/p99度量標準，ingest/索引，CTR/轉換；Alertes。
• 事件花花公子；金絲雀發行和ficheflagi。
• 相關性、合同、混亂和個性化測試。

二.結論

目錄引擎是遊戲內容上的「搜索引擎+規則系統+展示櫃」。強大的ACL、規範化的數據、快速閱讀的投影、透明的排名信號、帶有guardrail度量的個性化和嚴格的合規性將目錄變成一個可持續和可衡量的產品增長杠桿--在生產中沒有驚喜，也沒有與監管機構妥協。