金順娛樂城 × ATG 老虎機 — LINE OA 全棧代投實戰
從 Meta 廣告到 LIFF 綁定到 LINE OA 自動化全自動派獎 — 公開架構決策、CAPI 優化、退費機制與運營踩坑。
RedClaw 為 金順娛樂城（gamerating.org.tw 合法登記平台、ks7 引擎驅動、域名 gold88.uk）從零建立一套「Meta 廣告 → LIFF 綁定 → LINE OA 自動化」的全漏斗系統。核心交付：5 個常開活動全自動派發、8 級面額復活甲（10K–2M）、CAPI EMQ 從 4 拉到 9（lookalike 精準度 +20-30%）、無限序號池 transaction-safe 派發、fbclid 透傳歸因鏈、TG bot 即時運營。本頁公開完整架構決策、踩過的坑與可被驗證的成效。
金順娛樂城（gold88.uk）和 RedClaw 是什麼關係？
金順娛樂城是 RedClaw 服務的合規 iGaming 客戶之一，登記於台灣 gamerating.org.tw 的合法點數遊戲平台（非現金版／信用版），由 ks7 遊戲引擎驅動。RedClaw 負責建構並運營全套 Meta 廣告投放、LIFF 玩家綁定、LINE OA 自動化派獎與 CAPI 追蹤管線，對應域名為 gold88.uk。本頁公開實際採用的架構、CAPI EMQ 優化方法、復活甲分層設計，並提供可驗證的部署證據。
客戶基本資料
系統指標（截至 2026-05-24）
架構與技術指標公開；玩家層數據受 NDA 保護，僅在合格 lead 簽 NDA 後揭露。
RedClaw 為金順娛樂城（gold88.uk）部署的 Meta CAPI 追蹤管線，透過補齊 IP / User-Agent / fbp / fbc / em / ph 共 6 個 user_data 欄位，將 Event Match Quality 分數從 4 拉到 9，對應 Lookalike 受眾精準度提升 20-30%。架構公開於本頁，技術細節同步至 RedClaw cross-project knowledge base。 (來源: RedClaw, 2026-05-24)
為什麼這套架構能跑：三根支柱
金順娛樂城是 gamerating.org.tw 合法點數遊戲平台。所有文案、廣告與 LIFF 流程全面禁用「出金 / 提領 / 兌現」字樣，前端與 AI 客服 prompt 都過濾。每次部署前 grep 應為 0。這保護了平台的法律地位，也讓 Meta 廣告審核通過率穩定。
4 個 LIFF 入口（綁定／個資／簽到／儲值）+ webhook keyword 觸發 + 自動派獎（無限序號池 transaction-safe），覆蓋玩家從進站到續儲的全週期。AI 客服處理常見問題；TG bot 即時推播給運營，玩家綁定後 ROAS 歸因鏈完整建立。
前端 fbp/fbc/em/ph + 後端 IP/UA 6 欄位齊備，EMQ 從 4 升到 9。fbclid 透傳貫穿 LP → LIFF → OA 全鏈路，解決廣告投放出現「83 Lead/24h 但廣告歸因 0」的歸因斷裂問題。lookalike 精準度提升 20-30%，scale 階段不再卡頓。
這證明了什麼（對未來客戶）
金順娛樂城（gold88.uk）的部署是一個「活著的」可驗證案例 — 點開站本身就能看到我們交付的成果。
- 1能在「合規優先」前提下做穩定 Meta 規模化投放
台灣合法點數遊戲在 Meta 上是審核敏感區，一個用詞錯誤就停權。我們從第一版文案到 AI 客服 prompt 全面禁用「出金 / 提領 / 兌現」字樣，pre-deploy grep 為 0 是部署門檻。金順能持續穩定投放就是這套規則的證據。
- 2能交付端到端 LINE OA + LIFF 全自動化體系
不是只接 Meta 投放，是把廣告點擊後的玩家旅程整個包下來：4 個 LIFF 入口、AI 客服、無限序號池、復活甲、TG bot 運營推播，連 fbclid 都從 LP 透傳到 OA。金順玩家從加入 OA 到綁定到領獎，不需要任何人工介入。
- 3能修復「Lead 多但歸因 0」的廣告斷點
金順曾出現「24 小時 83 個 Lead 但廣告報表歸因 0」的經典 iGaming 場景。我們重構 fbclid 透傳鏈：LP 接住 → LIFF webview state 帶過去 → OA 綁定後存 Firestore → CAPI Lead 事件帶 fbc 回 Meta。修完後 ROAS 報表開始反映真實成效，廣告 scale 才有依據。
常見問題
金順娛樂城（gold88.uk）是合法的嗎？▾
是。金順是登記於台灣 gamerating.org.tw 的合法點數遊戲平台，與「現金版」「信用版」娛樂城是完全不同的法律類別。我們的代投流程嚴格遵守平台合規定義：所有文案禁用「出金 / 提領 / 兌現」字樣（含 AI 客服 prompt），廣告素材每次部署前 grep 為 0。
CAPI EMQ 從 4 升到 9 是怎麼做到的？▾
6 個 user_data 欄位齊備：前端帶 fbp（Pixel cookie）、fbc（fbclid 對應）、em（email SHA-256）、ph（phone SHA-256），後端 Cloud Function 補上 client_ip_address + client_user_agent。Meta 算 EMQ 是看你提供幾欄、品質如何 — 我們從只有 2-3 欄補到 6 欄全配，分數自然上 9。實作細節同步在 RedClaw 跨專案知識庫，所有 iGaming 客戶都套這套基線。
什麼是 8 級復活甲？這怎麼運作？▾
面向休眠/虧損玩家的自動補貼系統。8 個面額層（10K / 20K / 50K / 100K / 200K / 500K / 1M / 2M 點），週限 1 次。當日輸 ≥ 一定金額觸發 20% 自動補貼；輸 ≥ NTD 100K 加碼 5%。背後接 ks7 API（queryPromoteReport(playerID)）查單一玩家盈虧後決定面額，整個流程不需要客服介入。這是 v7 上線、v9 完整化的設計。
為什麼用 LIFF 而不是純 LINE OA webhook？▾
兩個原因：(1) LIFF 拿得到 userId + idToken，可以建立穩固的「LINE userId ↔ 金順 playerID」綁定；(2) LIFF webview 可以塞 fbp / fbc / fbclid，把 Meta 廣告 → LP → LIFF → OA 整條歸因鏈接起來。純 webhook 只能 keyword 回應，沒有歸因，更沒有信任的玩家身份。我們 4 個 LIFF 入口分別處理綁定 / 個資 / 簽到 / 儲值。
怎麼驗證金順案例的真實性？▾
四個方式：(1) 直接造訪 gold88.uk 看品牌站；(2) 在 LINE 加 OA @984dbqie 體驗綁定流程；(3) 在 gamerating.org.tw 查金順登記資料；(4) 合格 lead 簽 NDA 後我們開放 Meta Events Manager EMQ 截圖、Firestore schema、CAPI payload 範例給技術窗口檢查。
這套架構能複製到其他 iGaming 客戶嗎？▾
可以，這就是設計目的。LIFF 流程、CAPI 6 欄位、序號池 transaction、復活甲框架都已模組化在 RedClaw 共用程式庫，新客戶的差異點只在：(1) 遊戲引擎 API（ks7 / godeebxp / 其他 ATG 變體）；(2) 法規定義（點數遊戲 / 信用版 / 海外娛樂城）；(3) 品牌話術與 IP 角色。1-2 週可完成新客戶的端到端部署。
為什麼用 Firestore 而不是傳統 SQL？▾
三個原因：(1) 我們需要 transaction-safe 序號派發（避免兩個 webhook 同時派同一個序號），Firestore transaction 是託管的、不用自己跑 DB cluster；(2) Cloud Functions 原生整合，從 LINE webhook 到派獎決策不需要中介層；(3) 多 client 隔離靠 clientId 平鋪式 collection 與 security rules，比傳統 schema 遷移輕。LIFF / TG bot / dashboard 都吃同一份 Firestore，沒有同步問題。