dotdigital（前身為 Dotmailer）：Purple AI 用戶的整合指南、最佳實踐與疑難排解
本指南為 Purple AI 用戶 - 尤其是飯店、零售連鎖、體育場館和會議中心的 IT 經理、網路架構師和技術長 - 提供了部署和優化 dotdigital（前身為 Dotmailer）連接器的權威技術參考。涵蓋端到端整合架構、逐步設定、符合 GDPR 的數據處理、自動化計劃設計，以及結構化的疑難排解框架。正確實施此整合的組織，能將訪客的 WiFi 登入轉化為高價值、受同意控管的行銷資料庫，從而創造可衡量的營收成果。
收聽此指南
查看播客逐字稿
核心系列的一部分：WiFi Marketing Guide →
執行摘要
Purple AI 平台能在酒店、零售場所、體育場館和公共部門場地的 WiFi 認證點擷取第一方顧客數據。dotdigital 連接器 - 前身為 Dotmailer - 將該原始數據擷取轉化為生產級的行銷自動化管道。當顧客連接到您的 WiFi 並同意接收行銷通訊時，Purple 會即時將其個人檔案推送到指定的 dotdigital 通訊錄。從那一刻起，dotdigital 的自動化引擎便能觸發歡迎旅程、忠誠計劃邀請、再參與活動，以及跨電子郵件、SMS 和推播的全通路通訊。
商業案例已有充分記錄。Harrods 透過 WiFi 驅動的數據擷取建立了 360 萬聯絡人的資料庫，並在一年內從 Purple 投資中獲得 54 倍的回報。AGS Airports 實現了 842% 的 ROI。Brussels South Charleroi Airport 使用 Purple 的 MicroSurveys 結合下游行銷自動化，創下了 10,630% 的 ROI。這些成果並非異常 - 它們是經過精心設計的整合部署所預期的結果。
本指南提供在企業規模部署、優化和疑難排解 Purple-dotdigital 整合所需的技術深度。它專為需要在本季度實施解決方案、而非明年評估的 IT 專業人士而設計。
技術深入探討
整合架構
Purple-dotdigital 連接器以伺服器對伺服器 REST API 整合運作。Purple 作為數據生產者，dotdigital 作為消費者。連線使用 dotdigital 的基本驗證機制進行驗證：在 dotdigital 平台內建立一個專用的 API 使用者帳戶（電子郵件地址和密碼），並搭配區域特定的 API 端點 URL。
此架構預設為單向 - Purple 在 WiFi 認證點將聯絡人記錄推送到 dotdigital。對於需要雙向同步的組織（例如，將取消訂閱或封鎖名單的更新反映回 Purple），則需透過 dotdigital 的 webhook 框架進行額外設定。
| 組件 | 角色 | 備註 |
|---|---|---|
| Purple Captive Portal | 訪客驗證與同意擷取 | 在 WiFi 登入時呈現的 Splash 頁面 |
| Purple Connector Engine | 數據轉換與 API 派送 | 在「管理」>「連接器」下設定 |
| dotdigital REST API | 聯絡人匯入與通訊錄管理 | 需要區域特定端點 |
| dotdigital Address Book | 聯絡人儲存與分層 | 每個場地/物業一個或多個通訊錄 |
| dotdigital Program Builder | 自動化計劃執行 | 聯絡人加入通訊錄時觸發 |
數據負載與欄位對應
Purple 為每個同意的訪客傳輸八個數據欄位到 dotdigital。這些欄位直接對應到 dotdigital 的標準聯絡人數據模型，基本部署不需自訂欄位設定。
| 欄位名稱 | 數據類型 | 描述 |
|---|---|---|
firstName |
String | 訪客的名字 |
lastName |
String | 訪客的姓氏 |
userID |
Integer | Purple 的內部使用者識別碼 |
email |
String | 主要聯絡地址；用作去重鍵值 |
mobile |
String | 手機電話號碼（建議採用 E.164 格式） |
gender |
String | 從 splash 頁面自行宣告的性別 |
postcode |
String | 郵遞區號；可進行地理區隔 |
dateOfBirth |
String | 格式：YYYY-MM-DD；可進行年齡層區隔與生日觸發 |
數據傳輸在平台層級受到同意控管。除非訪客已透過 splash 頁面的同意核取方塊明確選擇加入行銷通訊，否則 Purple 不會將聯絡人記錄發送到 dotdigital。這是一項硬性強制要求 - 非可設定選項 - 也是此整合維持符合 UK GDPR、歐盟一般資料保護規則（EU General Data Protection Regulation）和 CCPA 的主要機制。
驗證與端點設定
dotdigital 為其 REST API 使用 HTTP 基本驗證。憑證包含一個 API 使用者電子郵件地址和密碼，必須在 dotdigital 帳戶內建立為專用使用者 - 而非主要帳戶登入。API 端點 URL 是帳戶特定的，且依區域而定。可從 dotdigital 平台內的「帳戶設定」>「存取」中擷取。典型的端點形式為 https://r1-api.dotdigital.com（區域一的帳戶）。
此端點特異性是連接器驗證失敗最常見的原因。嘗試使用通用或文件範例 URL 的團隊會遇到驗證錯誤。務必直接從正在使用的 dotdigital 帳戶中擷取端點值。
連接器部署層級
Purple 支援兩種 dotdigital 連接器的部署層級：
客戶層級 將連接器設定套用至整個 Purple 帳戶，將所有場地中所有同意的訪客路由到單一的 dotdigital 通訊錄。這適用於單一場地營運者或場地同質性高的組織。
場地層級 允許每個個別場地對應到不同的 dotdigital 通訊錄。這是多物業營運者 - 酒店集團、零售連鎖、體育場館營運商 - 的建議設定，此類組織需要場地層級的分層以進行目標行銷、本地化優惠或獨立的品牌識別。
實施指南
步驟 1：準備您的 dotdigital 帳戶
在設定 Purple 連接器之前，請在您的 dotdigital 帳戶中完成以下事項。前往「帳戶設定」，建立一個新的 API 使用者，使用專用電子郵件地址和強密碼。記錄「存取」頁面頂部顯示的 API 端點 URL。建立將接收 Purple 聯絡人的通訊錄 - 對於多物業部署，建議每個場地一個。如果您打算擷取八個標準 Purple 欄位以外的其他屬性，可選擇在 dotdigital 中建立自訂數據欄位。
步驟 2：設定 Purple 連接器
在 Purple 平台內，前往「管理」>「連接器」。找到 dotdigital 連接器並選取「新增」。填寫四個必填欄位：連接器名稱（您參考用的描述性標籤）、dotdigital API 電子郵件、dotdigital API 密碼，以及 dotdigital API 端點 URL。選取「驗證」。驗證成功後，會出現一個下拉清單，列出您 dotdigital 帳戶中可用的通訊錄。選取目標通訊錄並儲存設定。
對於多場地部署，請在場地層級為每個物業重複此程序，將每個物業指派給其指定的通訊錄。
步驟 3：設定 Splash 頁面同意機制
Purple splash 頁面上的行銷同意核取方塊是整個整合的入口。前往您的 splash 頁面設定，確保行銷選擇加入核取方塊已啟用並清楚標示。同意文字必須根據 UK GDPR 第 7 條的規定，明確、具體且不含糊。一個合規的例子：「我同意接收來自 [組織名稱] 關於優惠、活動和新聞的行銷通訊。您可以隨時取消訂閱。」 請勿預先勾選此核取方塊。
如果您的行銷計劃包含 SMS，請確保同意文字明確涵蓋 SMS 通訊。只要文字清楚，單一核取方塊同時涵蓋電子郵件和 SMS 是允許的。
步驟 4：建立您的 dotdigital 自動化計劃
在連接器上線前，於 dotdigital 中部署自動化計劃。至少設定一個由聯絡人加入通訊錄觸發的歡迎計劃。一個建議的三階段歡迎旅程：
- 立即（0 分鐘）： 確認 WiFi 存取的歡迎電子郵件，附帶品牌化的場地或服務簡介。
- 第 2 天（48 小時）： 後續電子郵件，提供相關優惠、場地指南或根據訪客情境量身打造的內容。
- 第 30 天（再參與）： 針對未回訪聯絡人的自動化再參與電子郵件，附帶回訪獎勵。
對於忠誠計劃整合，使用 dotdigital 的 Program Builder 將符合特定條件的聯絡人加入 - 例如，在自訂 splash 頁面問題中對忠誠計劃興趣回答肯定的聯絡人。
步驟 5：設定雙向封鎖同步
設定 dotdigital webhook，在聯絡人取消訂閱時通知 Purple。這可確保已封鎖的聯絡人在下次 WiFi 登入時不會被重新新增到 dotdigital。若未執行此步驟，從 GDPR 合規角度來看，此整合在技術上是不完整的。
步驟 6：驗證並上線
執行端對端測試：在 WiFi 上驗證測試裝置，使用測試電子郵件地址和行銷同意填寫 splash 頁面，並確認聯絡人在兩到三分鐘內出現在正確的 dotdigital 通訊錄中。確認歡迎自動化計劃正確觸發。記錄測試結果，然後繼續進行生產部署。
對於您的特定設置有任何疑問嗎？
我們的團隊與超過 80,000 個場域的場域營運商、IT 經理和網路工程師合作。立即預約 20 分鐘的通話，我們將向您展示其他與您相似的用戶是如何解決此問題的。
最佳實踐
同意架構
您選擇加入資料庫的品質直接取決於您的同意架構。投資於清晰、誠實的同意文字的組織 - 即使這會稍微降低選擇加入率 - 能建立更具參與度、更高價值的聯絡人清單。透明同意機制帶來的 30% 選擇加入率，將持續優於模糊或誤導性機制帶來的 60% 選擇加入率，因為前者的群體真心想收到您的訊息。Harrods 從 581,000 名 WiFi 用戶中實現了 38% 的選擇加入率 - 此比率與透明、價值交換的同意文字相符。
通訊錄分類法
在連接 Purple 之前，先設計您的 dotdigital 通訊錄結構。對於經營 20 個物業的酒店集團，這可能意味著 20 個場地特定的通訊錄，再加上一個用於跨物業活動的總合併通訊錄。對於零售連鎖，則可能是按區域或商店型態劃分的通訊錄。關鍵原則是：通訊錄結構決定了您下游的區隔能力 - 在收集數據後再進行改造，成本高昂且具破壞性。
自動化計劃深度
最有效的 Purple-dotdigital 部署會使用 dotdigital 的完整計劃功能：歡迎旅程、由 dateOfBirth 欄位觸發的生日活動、針對失效聯絡人的再參與序列，以及造訪後調查。postcode 欄位可實現本地化優惠的地理定位。gender 欄位可實現人口統計個人化。dateOfBirth 欄位可實現年齡層區隔和生日觸發。使用所有八個欄位 - 它們代表了一個豐富的區隔基礎，而大多數組織並未充分利用。
送達率管理
在部署的前 90 天內，每週監控 dotdigital 的送達率儀表板。關鍵基準：開啟率高於 20%、點擊率高於 2%、退信率低於 2%、取消訂閱率低於 0.5%。如果退信率偏高，請實施 dotdigital 的雙重選擇加入工作流程，在電子郵件地址進入您的活躍資料庫前進行驗證。這對於高流動人流的場地 - 機場、火車站、會議中心 - 尤其重要，因為訪客可能會輸入臨時或錯誤的電子郵件地址。
GDPR 與 PECR 合規
此整合在設計上預設即為合規，但合規是一項共同責任。Purple 在數據擷取層強制執行同意；dotdigital 在通訊層強制執行。您的組織需負責 splash 頁面上的同意文字、行銷通訊的內容，以及封鎖名單的維護。在 UK GDPR 或 EU GDPR 管轄範圍內部署此整合前，應進行資料保護影響評估（Data Protection Impact Assessment），特別是對於根據《2018 年資料保護法》承擔額外義務的公共部門組織。
疑難排解與風險緩解
連接器驗證失敗
最常見的部署問題。大多數情況是由於 API 端點 URL 不正確所導致。解決方案：登入 dotdigital，前往「帳戶設定」>「存取」，並完全複製顯示的端點 URL。確保不包含結尾斜線或空白。確認 API 使用者憑證是用於專用 API 使用者帳戶，而非主要帳戶登入。如果驗證仍然失敗，請確認 dotdigital 帳戶已啟用 API 存取權限 - 某些帳戶層級可能需要由 dotdigital 支援團隊啟用此功能。
聯絡人未出現在 dotdigital 中
如果連接器驗證成功，但聯絡人未出現在目標通訊錄中，主要原因是 splash 頁面上的行銷同意核取方塊未啟用。Purple 不會在沒有明確同意的情況下傳輸數據。次要原因包括連接器設定在錯誤的層級（客戶 vs. 場地），或自儲存連接器以來通訊錄 ID 已變更。解決方案：驗證 splash 頁面同意設定、確認連接器層級，並重新驗證連接器以重新整理通訊錄選擇。
重複的聯絡人記錄
當相同的電子郵件地址在多個 WiFi 連線階段中被提交時發生，通常出現在高人流的場地。解決方案：確保 dotdigital 的通訊錄設定為在電子郵件地址匹配時更新現有聯絡人，而非建立新記錄。這可在 dotdigital 的聯絡人匯入設定中控制。此外，檢查 Purple 連接器是否同時在客戶層級和場地層級為同一場地進行設定 - 雙重設定會導致重複推送。
缺失的數據欄位
如果聯絡人出現在 dotdigital 中但某些欄位為空，最可能的原因是訪客沒有在 splash 頁面上填寫這些欄位。Purple 只會傳輸在驗證期間提供的欄位。對於手機號碼或出生日期等選填欄位，部分訪客會拒絕提供。如果特定欄位的完整性對您的區隔策略至關重要，請考慮在 splash 頁面將這些欄位設為必填 - 但請注意，每個增加的必填欄位都會降低您的整體選擇加入轉換率。
GDPR 封鎖未被遵守
如果已取消訂閱的聯絡人在後續 WiFi 登入時被重新新增到 dotdigital，表示雙向封鎖 webhook 尚未設定。這是一項合規風險。解決方案：設定一個 dotdigital webhook，在取消訂閱事件發生時觸發，並更新 Purple 中對應的聯絡人記錄。請參考 dotdigital 開發者文件以取得 webhook 設定指引。
風險緩解框架
| 風險 | 可能性 | 影響 | 緩解措施 |
|---|---|---|---|
| 不正確的 API 端點 | 高 | 中 | 直接從 dotdigital 帳戶擷取端點 |
| 同意核取方塊已停用 | 中 | 高 | 納入上線前檢查清單；使用真實裝置測試 |
| 重複聯絡人 | 中 | 低 | 在 dotdigital 中設定基於電子郵件的去重複 |
| 封鎖未同步 | 低 | 高 | 在上線前實作取消訂閱 webhook |
| 數據欄位完整性 | 高 | 低 | 根據區隔需求設定欄位要求 |
| API 憑證外洩 | 低 | 高 | 使用專用 API 使用者；每季輪換憑證 |
ROI 與業務影響
衡量成功
Purple-dotdigital 整合在兩個不同的維度上提供價值：資料庫成長與營收歸因。資料庫成長的衡量標準包括：每月新增的選擇加入聯絡人數、選擇加入率佔總 WiFi 驗證次數的百分比，以及聯絡人數據完整性比率（所有八個欄位皆已填寫的聯絡人百分比）。營收歸因則透過追蹤購買、忠誠計劃註冊或其他可連結至透過 WiFi 登入進入資料庫之聯絡人的轉換事件來衡量。
dotdigital 的報表套件提供活動層級的分析 - 開啟率、點擊率、轉換率 - 可用於計算每個自動化計劃的營收貢獻。Purple 的分析儀表板則提供計算每位獲得聯絡人成本所需的人流和驗證數據。
基準與預期成果
根據 Purple 場地中已記錄的部署：
| 場地類型 | 典型選擇加入率 | 預期 ROI 時程 | 關鍵營收驅動因素 |
|---|---|---|---|
| 精品零售 | 35–45% | 6–12 個月 | 忠誠計劃轉換 |
| 飯店（中階市場） | 25–35% | 12–18 個月 | 直接預訂再參與 |
| 機場／交通樞紐 | 15–25% | 18–24 個月 | 零售與餐飲向上銷售 |
| 體育場館／活動場地 | 20–30% | 12–18 個月 | 周邊商品與門票向上銷售 |
| 會議中心 | 30–40% | 6–12 個月 | 活動再預訂與贊助 |
成本效益考量
相較於營收潛力，Purple 內 dotdigital 連接器的邊際成本偏低。主要的投資在於計劃設計和內容創建 - 自動化旅程、電子郵件範本和區隔邏輯，這些決定了聯絡人資料庫的貨幣化效率。將此整合視為設定後即可置之不理的數據管道的組織，將獲得有限的回報。那些投資於持續計劃優化 - A/B 測試主旨行、優化區隔、擴展自動化深度 - 的組織，將獲得與上述 Harrods 和 AGS Airports 基準一致的成果。
一個實用的經驗法則：每透過 WiFi 獲得 10,000 個選擇加入的聯絡人，一個設定良好的 dotdigital 計劃應能在部署後 90 天內產生可衡量的增量營收，假設歡迎系列的開啟率至少達 20%、點擊率達 2%。
關鍵定義
Captive Portal
在授予訪客 WiFi 網路存取權限之前呈現給他們的網頁。Purple 的 captive portal - 也稱為 splash 頁面 - 是訪客進行驗證、提供個人檔案數據和給予行銷同意的介面。它是所有流入 dotdigital 整合之數據的入口點。
IT 團隊在網路設定和 splash 頁面設計中會遇到此概念。Captive Portal 的同意核取方塊是通往整個行銷自動化管道的法律與技術閘道。
Address Book (dotdigital)
dotdigital 中已命名的聯絡人清單，類似於郵寄清單或 CRM 區隔。通訊錄是 dotdigital 中的主要組織單位，並作為 Purple 數據推送的目標。自動化計劃由聯絡人新增至特定通訊錄所觸發。
通訊錄分類法 - 通訊錄的數量、命名方式、設定層級 - 是多場地部署中最具影響力的架構決策。它決定了所有下游行銷活動的區隔能力。
Automation Programme (dotdigital)
dotdigital 中已設定的一系列自動化動作，由定義的事件觸發，例如聯絡人新增至通訊錄。計劃可包含電子郵件發送、SMS 訊息、等待期間、條件分支和聯絡人評分更新。它們是將 Purple 的數據擷取轉化為行銷通訊的機制。
IT 團隊負責確保連接器正確觸發計劃註冊。行銷團隊設計計劃內容。「包含透過 API 新增的聯絡人」設定是常見的設定疏失，會阻止計劃觸發。
API Endpoint (dotdigital)
dotdigital REST API 的基礎 URL，特定於每個帳戶所指派的區域數據中心。其形式為 `https://r{n}-api.dotdigital.com`，其中 `{n}` 是區域編號。可從 dotdigital 平台內的「帳戶設定」>「存取」中擷取。
這是連接器驗證失敗最常見的單一原因。必須直接從 dotdigital 帳戶中擷取 - 無法猜測或從通用文件中複製。
Consent-Gated Data Push
一種數據傳輸機制，僅在記錄到明確的使用者同意時才會啟動。在 Purple-dotdigital 整合中，只有當訪客在 splash 頁面上勾選了行銷同意核取方塊時，Purple 才會將聯絡人記錄推送到 dotdigital。這是一項平台層級的強制執行，而非可設定選項。
此機制是整合中主要的 GDPR 合規控制。它確保只有真正選擇加入的聯絡人才能進入行銷資料庫，保護組織免受監管風險，並保護送達率免受低參與度聯絡人的影響。
Double Opt-In
一種兩階段的同意驗證流程，聯絡人在初次選擇加入後，會收到一封確認電子郵件，必須點擊連結以驗證其電子郵件地址並確認訂閱。dotdigital 原生支援雙重選擇加入。它會將聯絡人從「待確認」狀態轉換為「已訂閱」狀態，並提供額外的同意記錄層。
建議用於高流動人流的場地 - 機場、會議中心、火車站 - 訪客可能會輸入不正確或臨時的電子郵件地址。雙重選擇加入可降低退信率並改善送達率，但代價是較低的初始轉換率。
Suppression List
一份不得接收行銷通訊的電子郵件地址或聯絡人名單，通常是因為他們已取消訂閱、提出申訴或被認定為無效。dotdigital 會自動維護封鎖名單。Purple-dotdigital 整合需要一個 webhook 將封鎖狀態同步回 Purple，以防止在後續 WiFi 登入時重新新增已封鎖的聯絡人。
未能實施雙向封鎖同步是一項 GDPR 合規風險和送達率風險。在任何生產部署中，這都是一個必要的設定步驟。
Venue-Level Connector
一種 Purple 連接器設定，範圍限於單一場地，與套用至整個 Purple 帳戶的客戶層級設定相反。場地層級連接器允許將不同場地路由到不同的 dotdigital 通訊錄，從而實現場地特定的區隔和個人化。
對多物業營運者至關重要。酒店集團、零售連鎖和體育場館營運商應始終使用場地層級設定，以在整個場地中維持乾淨的數據區隔。
First-Party Data
由將用於行銷的組織直接向個人收集的數據，且是在個人知情和同意下進行。透過 Purple 的 captive portal 擷取的 WiFi 登入數據，即為第一方數據。它有別於第三方數據（購買的清單）和第二方數據（合作夥伴共享的數據）。在後 cookie、後 GDPR 的環境中，第一方數據是最有價值且最合規的行銷數據形式。
Purple-dotdigital 整合的策略價值在於，它從實體場地造訪中大規模產生高品質的第一方數據。此數據無法透過任何數位行銷管道取得，對場地營運商而言是一項真正的競爭優勢。
PECR (Privacy and Electronic Communications Regulations)
英國的法規，管理透過電子方式（包括電子郵件和 SMS）進行的直接行銷。PECR 要求向個人（而非企業）發送行銷電子郵件需事先取得同意。它與 UK GDPR 共同作用，為 Purple-dotdigital 整合所觸發的行銷通訊定義法律依據。
IT 和行銷團隊必須確保 splash 頁面的同意文字涵蓋用於行銷的所有管道 - 電子郵件、SMS 和推播 - 且同意在必要時針對每個管道具體說明。
範例
一家在英國擁有 12 間物業、共 450 間客房的市中心酒店集團，希望使用 Purple 的 dotdigital 連接器來建立直接預訂再參與計劃。每個物業都有自己的 Purple 場地設定。行銷團隊希望向曾入住特定酒店的賓客發送該物業專屬的優惠，同時也能執行集團範圍的活動。此整合應如何架構？
正確的架構是在 Purple 中使用場地層級的連接器設定，將 12 個物業分別對應到專屬的 dotdigital 通訊錄。這能為行銷團隊提供乾淨、場地特定的聯絡人清單，以進行物業層級的目標定位。同時，建立一個 dotdigital 區隔，彙總所有 12 個通訊錄中的聯絡人 - 此區隔用於集團範圍的活動，而不會重複發送給出現在多個物業通訊錄中的聯絡人。
步驟 1：在 dotdigital 中，建立 12 個以物業命名的通訊錄（例如：「Purple - 曼徹斯特市中心」、「Purple - 愛丁堡皇家大道」）。使用「聯絡人存在於這些通訊錄中的任一個」條件建立一個主要區隔，涵蓋所有 12 個通訊錄。
步驟 2：在 Purple 中，前往「管理」>「場地」下的每個場地設定。為每個場地在場地層級新增一個 dotdigital 連接器，使用相同的 API 憑證，但選擇該物業特定的通訊錄。
步驟 3：在 dotdigital 中建立一個歡迎自動化計劃，由聯絡人新增至 12 個通訊錄中的任一個所觸發。在電子郵件範本中使用動態內容區塊，根據聯絡人被新增至的通訊錄（物業）來個人化訊息 - 例如，突顯該特定酒店的設施和直接預訂連結。
步驟 4：建立一個在最後一次 WiFi 登入 30 天後觸發的再參與計劃，提供物業特定的優惠。使用 dotdigital 的聯絡人評分來識別高價值賓客（多次造訪、高數據完整性），以進行進階的再參與活動。
步驟 5：對於集團範圍的活動 - 季節性促銷、忠誠計劃推出 - 使用主要區隔來觸及完整的選擇加入資料庫，而不會重複發送給出現在多個物業通訊錄中的聯絡人。
一家擁有 85 家門市的全國零售連鎖店已在其所有據點部署 Purple WiFi。六個月後，行銷團隊回報聯絡人出現在 dotdigital 中，但約有 15% 的新聯絡人未觸發歡迎自動化計劃。IT 團隊已確認連接器驗證成功，且聯絡人正被新增到正確的通訊錄。最可能的原因是什麼，以及應如何解決？
最可能的原因是在 dotdigital 中聯絡人建立與計劃註冊之間的競爭條件，再加上聯絡人是透過 API 而非 dotdigital 的原生匯入功能新增。當聯絡人透過 API（如 Purple 的做法）新增到通訊錄時，如果計劃設定為在「聯絡人透過匯入新增至通訊錄」時觸發，而非「聯絡人透過 API 新增」，則 dotdigital 的計劃觸發邏輯可能不會啟動。
解決步驟 1：在 dotdigital 的 Program Builder 中，開啟歡迎計劃並檢查註冊觸發條件。確認觸發條件設為「聯絡人新增至通訊錄」，且已啟用「包含透過 API 新增的聯絡人」選項。此選項並非在所有 dotdigital 帳戶設定中預設啟用。
解決步驟 2：如果觸發條件正確，請檢查受影響的聯絡人在 dotdigital 中的選擇加入狀態是否為「未知」而非「已訂閱」。狀態為「未知」的聯絡人可能會根據計劃設定被排除在計劃註冊之外。解決方案：設定計劃以包含選擇加入狀態為「未知」的聯絡人，或實施 dotdigital 的雙重選擇加入工作流程，在確認後將聯絡人轉換為「已訂閱」狀態。
解決步驟 3：檢視計劃的註冊頻率設定。如果設為「僅註冊一次」，則先前已註冊的聯絡人 - 例如，來自不同門市的先前 WiFi 連線階段 - 將不會被重新註冊。對於訪客可能造訪多個門市的零售連鎖店，請考慮在每次新門市造訪時重新註冊是否適當，並據此進行設定。
解決步驟 4：檢查計劃註冊限制。某些 dotdigital 帳戶設定會施加每日最大註冊率。如果零售連鎖店的 WiFi 在交易高峰日產生大量新聯絡人，此限制可能導致 15% 的落差。
練習題
Q1. 一家會議中心營運商擁有一個涵蓋三個場地（主禮堂、分組討論室和展覽廳）的單一 Purple 帳戶。他們希望使用 dotdigital 向與會者發送會後追蹤電子郵件，內容根據他們所造訪的空間而異。他們目前的連接器設定在客戶層級，將三個場地都路由到同一個 dotdigital 通訊錄。他們應進行何種變更，以及有何影響？
提示：考慮場地層級設定如何改變通訊錄結構，以及在 dotdigital 中需要哪些額外步驟來支援場地特定內容。
查看標準答案
營運商應在場地層級重新設定連接器，建立三個獨立的 dotdigital 通訊錄 - 每個場地一個。這讓 dotdigital 能夠識別聯絡人是從哪個場地新增的，從而實現自動化計劃中的場地特定內容。影響如下：(1) 現有在單一客戶層級通訊錄中的聯絡人將需要遷移或重新區隔；(2) 需要建立三個獨立的自動化計劃，或設定一個包含動態內容區塊的單一計劃；(3) 對於集團通訊，應建立一個彙總所有三個通訊錄的 dotdigital 區隔。現有聯絡人的遷移是營運上最複雜的步驟 - 需要識別每個現有聯絡人與哪個場地相關聯，這可能需要將 Purple 的分析數據與 dotdigital 聯絡人記錄進行交叉參考。
Q2. 一家酒店集團的 IT 團隊已在 8 個物業部署 Purple-dotdigital 連接器。上線三個月後，行銷團隊回報歡迎電子郵件的開啟率為 12% - 顯著低於酒店業歡迎電子郵件 25% 的基準。退信率為 4.2%。最可能的原因是什麼，IT 團隊應建議哪些補救步驟？
提示：4.2% 的退信率是關於收集點數據品質的強烈訊號。考慮當退信率升高時，電子郵件送達率會如何，以及同意機制可能有何影響。
查看標準答案
4.2% 的退信率是主要問題，且幾乎可以肯定是導致低開啟率的原因。當退信率超過 2% 時，收件匣提供者會開始將發送網域視為低品質電子郵件的來源，降低整個資料庫（包括有效、參與度高的聯絡人）的收件匣投遞率。退信率高的根本原因很可能是訪客在 splash 頁面輸入不正確或臨時的電子郵件地址，這在暫態的酒店環境中很常見。補救措施：實施 dotdigital 的雙重選擇加入工作流程，在電子郵件地址進入活躍資料庫前進行驗證。這會減少新聯絡人的數量，但會顯著提高數據品質。此外，檢視 splash 頁面是否需要電子郵件地址確認（輸入兩次地址） - 這個簡單的 UX 變更可減少因打字錯誤導致的退信。對於開啟率，檢視歡迎電子郵件的發送時間 - 如果電子郵件是在辦理入住後數小時才發送，而非在 WiFi 連線後幾分鐘內，則情境關聯性會降低。同時檢視主旨行和寄件人名稱的相關性與信任訊號。
Q3. 一家大型零售連鎖的資料保護長提出疑慮，認為 Purple-dotdigital 整合可能會在先前已取消訂閱的聯絡人造訪門市並連接 WiFi 時，將其重新新增到行銷資料庫。IT 團隊需要確認是否發生此情況，若然，實施修復。他們應採取哪些步驟？
提示：這不僅是技術問題，更是 GDPR 合規問題。考慮雙向數據流，以及需要哪些設定來防止重新新增已封鎖的聯絡人。
查看標準答案
這是真實的 GDPR 風險。此情況發生於：(1) 聯絡人從 dotdigital 行銷取消訂閱；(2) 取消訂閱未同步回 Purple；(3) 聯絡人隨後造訪門市並連接 WiFi；(4) Purple 不知已封鎖，再次將聯絡人記錄推送到 dotdigital；(5) dotdigital 將聯絡人重新新增到通訊錄。要確認是否發生此情況，請將 dotdigital 的封鎖名單與最近的通訊錄新增進行交叉比對 - 任何同時出現在兩個清單中的電子郵件地址，即表示問題正在發生。修復需要兩個步驟：(1) 設定一個 dotdigital webhook，在取消訂閱事件觸發時，更新 Purple 中對應的聯絡人記錄，將其標記為已封鎖；(2) 在連接器設定中實施推送前檢查，以在傳輸前驗證聯絡人的電子郵件地址不在 dotdigital 封鎖名單上。鑑於涉及跨系統的個人數據處理，也應建議資料保護長進行資料保護影響評估（若尚未針對此整合完成）。
Q4. 一家體育場館營運商希望使用 Purple-dotdigital 整合，向在活動期間連接體育場 WiFi 的球迷發送個人化的賽後電子郵件。他們希望包含比賽結果、精彩片段連結，以及根據球迷隊伍歸屬提供的個人化商品優惠。目前的整合僅擷取八個標準的 Purple 數據欄位。需要哪些額外的設定來支援此使用案例？
提示：考慮如何將活動特定數據（比賽日期、隊伍、結果）與 dotdigital 中的聯絡人相關聯，以及如何在 splash 頁面層級擷取隊伍歸屬。
查看標準答案
此使用案例需要在標準整合之外進行兩項加強。首先，必須使用 Purple splash 頁面上的自訂問題功能，在 splash 頁面層級擷取隊伍歸屬。一個下拉式選單或單選按鈕問題 - 「您今天支持哪一隊？」 - 在驗證時擷取歸屬。此數據可作為自訂聯絡人數據欄位傳遞到 dotdigital，該欄位必須在設定連接器之前於 dotdigital 的帳戶設定中建立。其次，活動特定數據（比賽日期、對手、結果）需要與聯絡人的連線階段相關聯。這可以透過為每個活動建立一個獨立的 dotdigital 通訊錄（以比賽詳情命名），並設定 Purple 連接器將該活動的 WiFi 登入路由到該活動特定的通訊錄來實現。然後，賽後自動化計劃由新增至該通訊錄觸發，並在電子郵件範本中嵌入比賽詳情。對於商品優惠，dotdigital 的動態內容功能可根據隊伍歸屬自訂數據欄位提供不同的產品推薦。這是一個較複雜的部署，在初始設定期間受益於 Purple 專業服務團隊的參與。
繼續閱讀本系列
如何利用簡訊行銷提高回訪率
本技術參考指南概述了企業級場域如何將 WiFi 分析與簡訊行銷引擎整合，以推動重複造訪。指南詳細介紹了擷取即時實體存在數據、根據實際行為觸發自動化簡訊活動，以及衡量對回訪率直接影響所需的架構。透過將網路基礎設施與行銷自動化相結合，IT 與營運團隊可以建立一個高收益的客戶留存管道。
客戶數據管理平台：企業全面指南
本指南說明場所營運商如何部署客戶數據管理平台以統一分散的訪客數據。內容涵蓋技術架構、整合策略，以及 Guest WiFi 在建立第一方數據個人檔案中的關鍵角色。
如何利用 WiFi 提升飯店顧客體驗
本指南為 IT 主管和場地營運商提供了將飯店 WiFi 從基本便利設施轉變為主動互動管道的技術藍圖。涵蓋了傳遞個人化訪客體驗、推動客房升級和提高忠誠度計畫獲取所需的架構、PMS 整合和部署策略。從 captive portal 設計和 GDPR 遵循到存在分析與離店後問卷自動化，這是飯店業 IT 團隊的權威營運參考。
對於您的特定設置有任何疑問嗎？
我們的團隊與超過 80,000 個場域的場域營運商、IT 經理和網路工程師合作。立即預約 20 分鐘的通話，我們將向您展示其他與您相似的用戶是如何解決此問題的。