資料與報表
名單先去重，再上傳平台
同一個客戶，四行紀錄：一張市集平台訂單、一次 WhatsApp 查詢、一份表單、還有某位同事自己保存的試算表。把它們併成一行，是普通不過的資料工作——正規化、比對、保留一行。不普通的是之後那一步。名單一旦上傳到廣告平台，它就構成一次個人資料轉移；而各平台自己的文件都寫明，法律依據在你身上，不在工具身上。這條流程不會為你建立同意。它能做的，只是拒絕帶走一行沒有同意的資料。
- 觸發
- 兩個
- 執行頻率
- 每週一次，加寫入時
- 工具
- 4 件
- 需要 durable execution
- 不需要
流程
上面那條在紀錄進來時維持「一個人一行」。下面那條每週醒一次，逐行判斷它是否可以離開；只有獲准的部分才會被雜湊和送出。
客戶資料新增或更改
Sheets · Airtable
比對之前先正規化
n8n · Make
一個人一行
Sheets · Airtable
每週一次
n8n 排程
取出仍在範圍之內的行
n8n · Make
此用途是否有同意紀錄？
n8n IF
先雜湊，再上傳
Meta · Google Ads
移除，然後說明原因
Google Ads · Meta
逐步拆解
- 01
客戶資料新增或更改
Sheets · Airtable可以是一張訂單、一次查詢、一份表單。在同一次寫入裡，一併記下收集的目的和日期。幾個月之後再回頭推斷，只是猜測，而猜測不能當作法律依據。
- 02
比對之前先正規化
n8n · Make轉小寫、去除前後空白、電話統一成國際格式；Gmail 地址還要移除句點和加號後綴。重複紀錄大多是格式問題，不是不同的人——兩行看似不同的資料，要經過這一步才會合成一行。
- 03
一個人一行
Sheets · Airtable以正規化之後的識別碼合併，保留最早的同意紀錄和最新的聯絡方式。目的和日期要留在該行之上，讓下一步可以直接讀取，而不是靠假設。
- 04
每週一次
n8n 排程選每週是有意的。平台受眾和來源名單會向兩個方向脫節——有人新加入，也有人撤回同意——而兩個方向各自需要一項操作，因為上傳只會新增，不會移除任何人。只在開始時同步過一次的名單，到第二個月就已經是錯的。
- 05
取出仍在範圍之內的行
n8n · Make剔除超過你自己保留期限的行，以及收集目的並不涵蓋廣告用途的行。這一步會令名單變短，而它本來就應該如此。
- 06
此用途是否有同意紀錄？
n8n IF從該行讀取，絕不推斷。買過東西不等於同意接收推廣，欄位空白就當作否。什麼算是同意、同意如何取得，由營運者決定；流程只負責執行一個早已被記錄下來的決定。
- 07
先雜湊，再上傳
Meta · Google Ads正規化之後才做 SHA-256，平台收到的是雜湊值，永遠不是地址本身。次序調轉會得出另一個雜湊值，而它表現出來的樣子是配對率偏低，不是一個錯誤訊息。
- 08
移除，然後說明原因
Google Ads · Meta把一行扣起不上傳，並不會把那個人從平台上已有的受眾中拿走——在成員資格到期之前，他仍然可以被投放。移除是另一項作業，而在 Google Ads，移除操作不能與新增操作放在同一項作業裡。之後才把數量和原因送到指定負責人：超過保留期、目的不符、同意已撤回。一行被靜靜剔走，和一行從來不存在，外觀完全一樣。
平台和法例不容許的事
頭三項是平台自己的規則，界定資料可以怎樣送出、名單要有多大。最後兩項是香港的法例，位置在所有平台規則的上游——一份完全符合 Meta 和 Google 要求的名單，仍然可能在建立之初已經違法。
上傳只會新增，所以撤回同意需要另一項操作。在 Google Ads，移除操作不能與新增操作放在同一項作業裡，而 remove_all 必須是該項作業的第一個操作，否則執行會失敗。在那項作業跑完之前，撤回同意的人仍然是受眾的可投放成員。
Google Ads API — Customer Match: get startedMeta 要求上傳的資料必須經過雜湊，並且指明演算法：「To create audiences, you must share your data in a hashed format to maintain privacy」，以及「You must hash data as SHA256; we don't support other hashing mechanisms.」Meta 亦把責任講得很白——「As the owner of your business's data, you are responsible for creating and managing this data.」
Meta Marketing API — Customer list custom audiencesGoogle Ads 的要求相同：「email addresses, first names, last names, and phone numbers must be hashed using the SHA-256 algorithm before being uploaded」；Gmail 地址的使用者名稱部分，必須先移除句點和加號後綴。這一步正規化同時也是去重能夠成立的原因，所以它應該放在上游，而不是放在上傳那一刻。
Google Ads API — Customer Match: get startedCustomer Match 對名單本身同時設有下限和上限：「Upload at least 5,000 members to increase the chance of having enough matched, active users for targeting」，而 membership_life_span「must be no more than 540」日。所以一份小而乾淨的名單，有可能小到根本不足以投放——這是把資料整理做好之後的真實結果。
Google Ads API — Customer Match: get startedGoogle 把資料來源寫成政策，不是建議：「Per policy, you can only upload data that you acquired yourself (first-party). You cannot buy email lists from third parties and upload them.」上傳時必須填寫同意欄位；未取得同意的歐洲經濟區用戶資料，不會被用於廣告個人化處理。
Google Ads API — Customer Match: get started根據香港《個人資料（私隱）條例》，保障資料第 3 原則「prohibits the use of personal data for any new purpose which is not or is unrelated to the original purpose when collecting the data, unless with the data subject's express and voluntary consent」；第 2 原則則要求個人資料「is not kept longer than is necessary for the fulfilment of the purpose for which the data is used」。為完成一張訂單而收集的電郵地址，本身並不等於一個你可以向其投放廣告的地址。
PCPD — The Personal Data (Privacy) Ordinance at a glance專就直銷而言，條例第 6A 部要求在使用個人資料作直銷、或把資料轉移予第三方作直銷之前，先取得知情同意。同意必須是「an explicit indication by the data subject」，而且「silence cannot constitute consent」——所以一個沒有勾選的方格，或者一行完全沒有紀錄的資料，都當作否。
PCPD — The Personal Data (Privacy) Ordinance at a glance
什麼情況不值得做
以下三種情況，維護成本會高於重複紀錄的代價；其中一種更是應該完全停手的理由。
你講不出每一行資料當初是為什麼而收集。這不是靠一個每週排程去解決的時間問題，而是在紀錄補齊之前根本不應該上傳名單的理由——流程只能執行一個早已有人作出並寫下的同意決定。
名單小到一個人一眼就認得出哪些是重複。他合併的速度會比每週排程更快，而這個排程只會變成另一個複製了個人資料、卻沒有帶來好處的地方。
那些平台受眾其實沒有用來投放。把客戶名單和一個從來沒有花費的受眾保持同步，等於在廣告平台上無端存放著個人資料，那是有風險而沒有相應好處。