如何處理推送流量及其細分

推送是一個快速、低成本的觀眾回歸頻道。在iGaming中，它也是高級責任區（YMYL）：嚴格按照協議，沒有點擊位和「結果承諾」，具有可見的頻率設置和對Responsible Gaming的引用。下面是系統方法：從基礎架構和同意到細分，頻率和測量。

💡 Disklamer：遵守您的司法管轄區要求、年齡限制（18歲以上）、場地/平臺規則以及負責任的遊戲原則。

1）推送類型以及何時使用

Web Push（瀏覽器）-快速批量警報，會話轉發。即使沒有開放的網站（同意後）也可以工作。

App Push （FCM/APNs）-高傳送，深層深層腳本，定制「安靜時鐘」。

In-App-應用程序/Mobile內的橫幅/調制解調器：用於貼紙、狀態、提示。

OS/平臺限制-尊重「quiet小時」，「不打擾」模式，頻率限制。

2）同意,首選中心和基礎設施

同意（opt-in）

本機查詢-在預覽屏幕之後，其中解釋了收益和主題（boarding prompt → native prompt）。

僅是自願的；沒有「站立」（「未經同意就不允許」）。

Preference center

主題：付款/狀態，新聞/演示，響應/支持。

頻率：「很少」，「每周一次」，「立即發生重要變化」。

從通知中輕松退貨。

基礎設施

代幣的可靠存儲及其重復數據消除（多設備）。

Deeplink/Universal Links + deferred deep link, UTM-метки.

Failover：重新發送未交付的令牌（帶有後綴）。

分離觸發/質量線程並編寫事件。

3）細分： 如何建立受眾

生命周期

新（D0-D7），活躍（最近7-30天），瀕臨流出（7-14天無訪問），非活動（30/60+）。

行為行為

打開演示/閱讀海達，完成/退出KYC，進行存款/要求退出，提問支持。

上下文

GEO/語言/貨幣，設備，最喜歡的垂直/提供商，「夜間/白天」活動插槽。

狀態和風險

KYC: waiting/approved/rejected;支付狀況；RG狀態（限制，暫停，自我體驗）。

規則：如果用戶有限制/自我體驗-僅信息/支持消息，無需促銷。

4）內容和腳本（道德和有用）

什麼是合適的

狀態：「KYC已確認」，「輸出/隊列處理」，「可用本地方法」。

培訓和演示：「新版本是未經註冊的演示」，「海德：如何閱讀獎金條款」。

響應/支持：「如何設置限制」，「在哪裏獲得幫助」。

規則/條件更新：頁面上的條件表，沒有「立即向所有人」的承諾。

避免什麼

按下，點擊門，「保證獲勝」，偽緊急計時器，規避限制/GEO。

推的微結構

標題≤ 40-45個符號，文字≤ 90-120，一個CTA，表情符號-在最小化和情況下。

Deeplink到特定的屏幕（演示/條件/狀態）,活動標簽。

5）頻率，靜音窗口和旋轉

通道限制：每個用戶每天不超過1-2，觸發器優先於質量。

Quiet hours：通過GEO/時區在本地指定,尊重系統DND。

Fatigue信號：在穩定的覆蓋範圍內,open/CTR下降≥30%-降低頻率/改變主題。

渠道協調：電子郵件/推入/應用不得同時射擊；具有優先級的編排器。

6） A/B測試和個性化

假設：標題（信息vs澄清），卡中字段的順序，更新日期的存在，deeplink路線（push→demo vs push→LP）。

目標：按生命周期和GEO分段。

規則：一次一個因素；持續時間-全周周期；至少400-600次點擊/首次發現的選項。

7）度量與分析

推漏鬥

1.Opt-in rate（接受許可）

2.交貨率/未交貨（取回代幣）

3.Open rate （web/app）, Direct Open vs「強制」開放

4.CTR（在目標deeplink上）

5.點擊後： 啟動時間,目標動作（KYC/demo/FAQ/聊天請求）

6.投訴/退房、更改訪問頻率、影響D1/D7/D30

達什伯德

按部分（生命周期，GEO，設備），按主題（狀態/學習/響應）。

時間卡（每周小時/每天），fatigue顯示器。

8）安全、合規和隱私

明確同意，易於更改/禁用；單一點擊的隱私政策。

相關場景中的年齡標記和響應。

將令牌存儲為個人數據（加密、壽命、召回）。

對於具有自我體驗的用戶，沒有促銷活動；只提供服務和幫助。

使用中性語言和範圍（例如，「通常在KYC之後15分鐘-24小時」）。

9）反模式（打破可交付性和信任）

在第一個屏幕上請求權限,無需解釋。

大規模的大炮「為了覆蓋」所有部分。

許多主題在一個通知和2-3 CTA。

不可讀的預覽（長標題/表情符號-垃圾郵件）。

重新使用過時的令牌，沒有從浮標中退貨。

在「安靜的時間」，clickbate和「承諾」中傳達的信息。

10）模板（安全措辭）

培訓/演示

標題： 「新版本-無註冊演示」

文字： 「關於內部力學和規則的簡短海德」

CTA： 「打開演示」

條件/規則

標題： 「所有獎金條款都在同一頁面上」

文字： 「Vager，時機，遊戲貢獻-表格和示例」

CTA： 「觀看條款」

付款/狀態

標題： 「處理中的輸出-狀態已更新」

文字： "通常在KYC之後15分鐘-24小時。方法詳細資料"

CTA： 「檢查狀態」

響應能力/支持

標題： 「設置限制-負責任地玩」

文字： "在配置文件中點擊一對。任何問題全天候聊天"

CTA： 「打開設置」

11）發布前技術支票清單

Onboarding-prompt → native prompt，可理解的訂閱主題
Preference Center：主題/頻率,1點擊退款
令牌：重復數據消除、到期、重新註冊
Deeplink/UTM, deperred deep link,深屏
GEO/時區安靜的時鐘，頻道編排

[] Логи: send/delivered/open/click/error;域報告

A/B框架，點擊後目標，重發保護
RG/KYC/自我排斥政策（活動過濾器）

12）30/60/90天實施計劃

0-30天-基礎

引入opt-in的預選,收集首選中心。

設置令牌，deeplink，quiet小時。

運行3個基本腳本：KYC狀態、條件更新、演示新穎性。

Dashbords： opt-in, delivery, open, CTR,投訴/退房。

31-60天-深入

按生命周期和行為進行細分；RG例外。

A/B：標題，路線（演示vs LP），發送時間。

電子郵件/push/in-app協調和頻率帽。

Fatigue邏輯和主題旋轉。

61-90天-規模和質量

通過GEO和貨幣進行本地化；興趣個性化（無壓力）。

增量測試：控股組，D7/D30影響評估。

自動變量：投訴激增，開放/CTR下降，劣勢上升。

13）迷你常見問題

何時申請Web push權限?

在短暫的預覽解釋了好處和選擇主題之後-高於選擇性和較少的投訴。

更重要的是：開放或CR？

兩者。但是，通過點擊後決定（有用的行動）和投訴。

每個人都需要泄露同樣的消息嗎？

沒有。相關性>覆蓋範圍。GEO/興趣/狀態段和頻率帽。

推送通道是有效的，因為它是自願的，相關的和道德的：可理解的主題和頻率，對「安靜時鐘」的尊重，深刻的deeplink腳本，生命周期和行為的細分，不僅是開放/CTR的測量，而且是有用的行動。在iGaming中,添加Responsible和透明的條件-推送將成為返回和流量質量的穩定驅動因素,而不是投訴和鎖定的來源。