IOSOR

IOSOR 知識庫

10DLC 的 opt-in 證據：審核前稽核人員需要什麼

10DLC 活動註冊的合規檢查清單——稽核人員實際查核什麼、哪些同意蒐集方式禁得起檢視，以及如何讓證據幾分鐘內可調閱，而不是翻箱倒櫃。

10DLC 活動審核不會相信「使用者已同意」這種行銷式說法——它要的是證據:確切的畫面、確切的措辭、確切的時間戳記,以及半年後陌生人也能循線查證的留存鏈。把 opt-in 當成投影片上一個勾選框的團隊,會在上線途中被限速、被拒或被暫停。本文適合經營白牌預付費訊息計畫的合規與產品負責人,他們需要活動核准經得起真正的稽核,而不只是第一次送審。

IOSOR 期望 opt-in 證據與支出處於同一個預付費控管平面——方案「就緒」不是因為某處存在一張表單,而是因為證據幾分鐘內就能調出,不必翻箱倒櫃。當每月平台用量接近 USD 1,000+ 時,活動註冊審核人員預設你已具備生產等級紀律,而不是通話前五分鐘才找到的截圖。

「證據」到底代表什麼

說法 它在說什麼 稽核人員要的證據
「使用者在我們網站上同意了」 相信我們 蒐集當下確切表單與文案的存檔截圖
「同意記錄在 CRM 裡」 相信我們 與號碼、訊息綁定的時間戳記錄
「我們遵守規則」 相信我們 書面政策加上與之對應、可調閱的日誌

稽核人員逐行核對什麼

  1. 展示給使用者的確切 opt-in 措辭,而非轉述
  2. 蒐集到的號碼是否與實際發送號碼一致
  3. 蒐集方式(網頁表單、關鍵字加入、口頭/紙本、結帳勾選)依來源逐一記錄
  4. 時間戳記與方式於同意當下即記錄,而非事後重建
  5. 範圍:交易類與行銷類同意分開留存,絕不事後合併

禁得起檢視的蒐集方式

  • 網頁表單預設不勾選,清楚顯示發送頻率與 HELP-STOP 文案
  • 關鍵字加入(如回覆 START)連同準確的 inbound/reply 一併記錄
  • 口頭或紙本同意依腳本執行,在活動註冊用途範圍內可儲存、可調閱
  • 結帳頁面的 opt-in 於購買當下展示,不埋在一般條款裡

同意當下要記錄什麼

欄位 為何重要
時間戳記(UTC) 證明同意早於首則訊息
展示的確切文案 證明措辭與活動承諾一致
蒐集渠道 把證據綁定到註冊用途
IP / 裝置或來源參考 支援爭議處理

投訴之後才補的截圖不是證據,而是事後重建,稽核人員看得出差別。

存了但稽核期間內調不出來的證據,等於沒有。依號碼和活動為 opt-in 記錄建索引,依主管機關或審核方期望的期限留存,並能由指定負責人調閱,而不必翻找舊系統——一份在時間壓力下誰都查不動的表格,和根本沒有記錄一樣,都過不了這個測試。

如果 STOP 沒有立即生效、HELP 得不到真正的回應,opt-in 證據只講了一半故事。把封鎖狀態與 opt-in 證據放在一起,讓一個儀表板一次查詢就能回答「這個號碼是否曾經同意,現在是否仍符合資格」——而不是兩套互相矛盾的系統。

  • 「等活動被標記了再去湊證據」
  • 截圖沒有時間戳記或來源不明
  • 一條證據鏈涵蓋企業跑的所有活動
  • 同意文案寫在文件裡,卻從未在真實產品中展示過
  • opt-in 證據請求沒有指定負責人

常見導致拒絕或限速的證據缺口

  • 同意文案與註冊樣本訊息不一致
  • 一筆 opt-in 記錄涵蓋多個不相關活動
  • 儲存前沒有號碼格式標準化的記錄
  • 行銷同意被悄悄挪用於交易情境
  • 證據只存在客服人員的記憶裡

從 IOSOR 開始

請在將 10DLC 廣告活動提交審核之前，直接將封存的加入同意截屏與同意記錄上傳至 IOSOR 主控台。設定你的網路鉤子，讓每筆訂戶資料都能傳遞準確的 UTC 時間戳記、IP 記錄以及擷取的加入同意文字。在合規閘道驗證你的佐證資料包之前，請先暫停你的訊息佇列。

IOSOR 要點

通過 10DLC 加入同意稽核需要可驗證且帶有時間戳記的證明，這些證明必須在使用者同意的確切當下記錄，而不是在電信商標記後才做追溯性的聲明。記錄準確的表單文案、明確未勾選的同意方塊以及擷取管道，能確保你的品牌從第一天起就隨時準備好接受稽核。

請務必為每個電話號碼記錄 UTC 時間戳記、擷取來源以及完整的加入同意語言，然後才發送第一則訊息。切勿依賴籠統的隱私權政策、未經驗證的客戶關係管理記錄，或多個不同廣告活動共用的同意足跡。

這篇指南有幫助嗎？

相關指南