寫在前面：追蹤廣告成效，真的一定要像Facebook所述都是 Apple 的問題、這麼麻煩嗎？
事實上，netiCRM.tw原本就有內建追蹤功能，想要追蹤廣告成效，根本不用取得消費者個資，不用通過網域驗證，不需要捲入兩大企業的爭執。
Facebook將之塑造成沒有個資，不使用企業管理平台就無法有效投放廣告，就沒辦法追蹤成效，其實這完全是兩回事。至於為何Facebook要這樣做，這只能問問他們了。
netiCRM的內建追蹤展示
＊ ＊ ＊
去年、今年鬧的沸沸揚揚的Facebook槓上Apple，近來也影響到我們了。
我們的產品 netiCRM.tw 是個小型SaaS服務，允許NPO客戶直接租用、啟用站台，並且不用申請註冊網址，即可用 ooooo.neticrm.tw 這種網域開立他們各種線上功能。其中，包含跟Facebook廣告推播最相關的「廣告=>捐款=>成效追蹤」的功能。
然而 Facebook 面臨到追蹤消費者個資的難題，看來他們並沒有仔細思考為網路世界的各個廠商都在努力反追蹤，反而是鐵了心還是想繼續追蹤各種個資，所以直接把企業管理平台的後台改版了，他改了什麼呢？
- 首先，企業平台原本不需要網域註冊驗證，現在變成強制了。
- 再來，Facebook 沒有跟廣告投放主說清楚的是：就算成功驗證了網域，卻無法追蹤轉換，因為「一個網域僅能允許8個事件」的限制。
如果NPO或是小型電商，你租用的是別人家的服務，不是自己擁有的網域，Facebook的企業管理平台改版後，你不大可能追蹤的到自己的轉換。 - 將來，無論是 ooo1.neticrm.tw，還是ooo2.neticrm.tw，還是 https://neticrm.tw 我們的官網，只要這些網域都是同一家廠商註冊的，Facebook「總共」只能追蹤8個成效，無法分開。
相反的，不把自己的產品變更交代清楚，Facebook卻是把所有這種改版的責任都推給iOS和Apple。可是，Facebook 大可選擇產品不要這樣設計，說清楚無法正確追蹤iOS的流量，因為使用者退出追蹤即可。現在卻是因為這樣的產品改版設計，拖著全世界的SaaS服務商下海，這樣是對的嗎...
＊ ＊ ＊
以上是一般人可能看的懂，卻不大明白為什麼，但以下就是SaaS服務商在這幾個月中，陷入兩大廠商吵架的掙扎脈絡。
首先介紹一下 Public Suffix List ，這是全世界瀏覽器共用的一個簡易解決方案，這個清單上的網域，將會變成根網域，讓瀏覽器可以將Cookie站站分離。因此，ooo1.org.tw 跟 ooo2.org.tw 為什麼在瀏覽器中可以辨識為不同的網站，以及兩個站可以有不同的Cookie登入標記，其實都仰賴這個Public Suffix List（清單）。說到底，他就只是一個清單，而且頂層網域來使用，所以一打開清單，會看到上面有 org.tw, gov.tw, edu.tw, .tw... 等，這些列在清單中的名稱，就表示頂層，瀏覽器不再允許這種頂層的cookie存在了。
然而，因為Facebook在他「責任都推給Apple的說明」中，說要讓 ooo1.neticrm.tw 、ooo2.neticrm.tw 這兩個網站被Facebook視為不同網站，不再受到「同網域只能追蹤8個事件」的限制時，說明你可以把自己域名加入到 Public Suffix List 清單中，就不再受此影響了，這是個很不負責任的指引！
這種公開給非技術人員的說明，公開給廣告投放商「企業管理平台」的說明，導致一群志工工程師管理的清單，湧入各地來的請求。他們不厭其煩的回覆、提醒、說服來退回這些請求，請這些廠商仔細思考，不要輕易把自己的域名放到清單中，不然會有嚴重的後果。畢竟，neticrm.tw 跟 .tw ，本來 neticrm.tw 就不會是頂層網域吧？這清單不是給 Facebook 這樣使用的。
結果因為太多人還是說不聽，PSL他們只好凍結所有的修改請求，在 Facebook 跟 Apple 討論出正確的解決方案之前，他們不會允許這類型的請求。
短期來看，有很多子網域的，像是 Typeform、我們netiCRM這種廠商，目前沒有好解，雖然可能可以用 Public Suffix List，但是不能用現有域名，得用新的域名，還得等待兩大廠商討（吵）論（架）完看看有沒有其他方案。而想要投放追蹤廣告的小型商家想要追蹤成效，只能用別的方案，不要用Facebook的報表來處置。
長期來看，這個網路推向大家擁有自己的域名前進，所以可能還是申請自己的域名、好好管理為妥。而網路世界值得花時間在更有創造力的事情上面...
一些延伸閱讀參考：
- Hacker News： https://news.ycombinator.com/item?id=26726722
- Apple 和 Facebook 的討論： https://github.com/privacycg/private-click-measurement/issues/78
- Public Suffix List 的討論： https://github.com/publicsuffix/list/issues/1245
