dotdigital（前身為 Dotmailer）：Purple AI 用戶的整合指南、最佳實踐與疑難排解

執行摘要

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 為每個同意的訪客傳輸八個數據欄位到 dotdigital。這些欄位直接對應到 dotdigital 的標準聯絡人數據模型，基本部署不需自訂欄位設定。

數據傳輸在平台層級受到同意控管。除非訪客已透過 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 通訊錄中。確認歡迎自動化計劃正確觸發。記錄測試結果，然後繼續進行生產部署。

最佳實踐

同意架構

您選擇加入資料庫的品質直接取決於您的同意架構。投資於清晰、誠實的同意文字的組織——即使這會稍微降低選擇加入率——能建立更具參與度、更高價值的聯絡人清單。透明同意機制帶來的 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 設定指引。

風險緩解框架

ROI 與業務影響

衡量成功

Purple-dotdigital 整合在兩個不同的維度上提供價值：資料庫成長與營收歸因。資料庫成長的衡量標準包括：每月新增的選擇加入聯絡人數、選擇加入率佔總 WiFi 驗證次數的百分比，以及聯絡人數據完整性比率（所有八個欄位皆已填寫的聯絡人百分比）。營收歸因則透過追蹤購買、忠誠計劃註冊或其他可連結至透過 WiFi 登入進入資料庫之聯絡人的轉換事件來衡量。

dotdigital 的報表套件提供活動層級的分析——開啟率、點擊率、轉換率——可用於計算每個自動化計劃的營收貢獻。Purple 的分析儀表板則提供計算每位獲得聯絡人成本所需的人流和驗證數據。

基準與預期成果

根據 Purple 場地中已記錄的部署：

成本效益考量

相較於營收潛力，Purple 內 dotdigital 連接器的邊際成本偏低。主要的投資在於計劃設計和內容創建——自動化旅程、電子郵件範本和區隔邏輯，這些決定了聯絡人資料庫的貨幣化效率。將此整合視為設定後即可置之不理的數據管道的組織，將獲得有限的回報。那些投資於持續計劃優化——A/B 測試主旨行、優化區隔、擴展自動化深度——的組織，將獲得與上述 Harrods 和 AGS Airports 基準一致的成果。

一個實用的經驗法則：每透過 WiFi 獲得 10,000 個選擇加入的聯絡人，一個設定良好的 dotdigital 計劃應能在部署後 90 天內產生可衡量的增量營收，假設歡迎系列的開啟率至少達 20%、點擊率達 2%。