我們正在見證網際網路發展中的一個分水嶺——在蘋果推出內容攔截器後，我們看待和理解我們網上的使用者的方式將發生深刻的改變。
這看上去並沒有多麼重要。雖然廣告攔截器在桌面瀏覽器上存在了很多年，但類似谷歌分析的產品仍然成為了測量和監測網站的行業標準。但這些都即將改變——個人產品和分類將因為移動版 Safari 上的一個小小的技術轉變而受到很大影響，有自己的網站的機構也將必須適應這一轉變，否則就會在競爭中處於劣勢。
為什麼改變會在現在發生呢？簡單地說，這是因為網站跟蹤的遺留系統已經無法工作了。由於現有的廣告攔截器，它已經不能準確地捕捉使用者在網站上的活動了，移動端內容攔截器的加入會進一步影響它收集到的資料的準確性。它無法在單頁面網站應用程式上工作，是因為它是基於頁面載入而構建的。出於相同的原因，它更無法捕捉移動應用上的活動，因為移動應用中 90%的動作都不是頁面載入，而且移動應用的多堆疊資料通常整合化較低。不過，遺留系統最大的缺陷是把資料藏起來，即把關於你的客戶的關鍵資料放在一個無法訪問的地方，只有使用費用高昂且脆弱的 API 整合才能整合資料及進行自動操作。
移動內容攔截器是對遺留系統的致命一擊。相比桌面廣告攔截器，它對使用者更有吸引力——節省網路頻寬和更快的頁面載入對移動端非常重要。防止收集隱私資訊只不過是一個附帶的功能。當用智慧手機使用網際網路的趨勢已經無法阻擋時，如果很難收集 iOS 使用者的資訊——這些使用者在網上花的錢和時間最多，將影響資料的準確性，讓資料變得不可靠。
這些變化不是一蹴而就的。但是，安卓也會步 iOS 的後塵，採用類似的技術，而且，當使用者熟悉這種技術後，他們將更有可能使用桌面攔截器。甚至連瀏覽器也有可能內建這種技術。
受影響的 不只是釋出者
這種技術將深刻影響數字廣告和歸因，進而會影響釋出者和其他依靠廣告盈利的公司。但這僅僅是開始。
讓我們檢查一下任何電商或 B2B 網站，看看它們所有的 cookie 和請求（通常是通過谷歌跟蹤程式碼管理器發出的）。這些網站（以及各種跟蹤程式碼管理器），連同所有與它們合作的創意機構和市場營銷人員，將受到巨大影響。而那些在這種平臺上進行銷售的公司將受到更大的影響——那麼，電商公司將如何可靠地重新定位使用者呢？
在移動端減少網路頻寬佔用以及清理大量繁瑣的東西是值得追求的目標。
想觸及那些最精通科技的使用者將變得更加困難；對廣告網路的逆向選擇實際上會越來越頻繁。衰落的歸因模式將降低對投資回報率的信心，讓廣告專案——甚至是任何營銷專案都更難有把握地進行量化，也更缺乏具體的合理性。
除數字廣告和歸因之外，Optimizely 之類的前端的網站測試框架也將受到影響，這是因為 Optimizely 是載入測試偏差和以非同步方式傳送資料的 JavaScript 片段。如果你的 A/B 測試只考慮了較少使用移動端、不那麼精通科技的人群，結果會怎樣？測試結果仍然有效、可操作嗎？
從最基本的層面看，理解網上的使用者行為將變得更加困難。試圖將谷歌分析中的資料與內部系統中的資料相結合的分析人員已經知道兩者間幾乎總存在明顯的分歧，而第三方系統扣留的資料越多，分歧就越嚴重。沒有合適的資料對很多產品和營銷團隊來說就像雙目失明一樣——他們不知道在他們的使用者那裡究竟發生了什麼，也無法對其採取明智的應對措施。
接下來該怎麼做？負擔將會轉移
網站追蹤的未來很好理解，但要承認它卻很難；我們不能再依賴第三方 cookie 和 JavaScript 片段了。負擔從使用者的瀏覽器上轉移回了我們自己的網站伺服器上，而且這個轉移會讓網站的堆疊變得更復雜。但是，這個轉移中卻暗含著一個絕佳的機會，能讓我們統一我們的資料，改進我們理解使用者的方式；那些最有遠見的團隊將從轉移的努力中收穫成果。
新的內容攔截器將時常阻止使用者的瀏覽器向谷歌或 Optimizely 傳送請求，但不可能阻止傳送給來源的請求（正如我們所知道的，如果阻止，則會破壞任何類似 AJAX 的東西，並會破壞網頁）。因此，合理的解決方案是，依賴向第三方域名傳送非同步請求的解決方案應該釋出服務端庫。你將把 PHP 或 Ruby 庫連同你的 JavaScript 片段一起貼上到你的伺服器上；JavaScript 會把請求發回你自己的伺服器上，然後你的伺服器會以 REST 形式與這些第三方服務進行通訊。
就像移動應用的生態系統產生了更多工作量以及混亂和變化一樣，網站分析上的轉變不會那麼容易。
但這麼做有一些根本性的問題。第一，只有精通技術的開發者能有把握地調整伺服器端程式碼。對大多數網站管理者而言，他們會依賴他們的主機或 WordPress 外掛來替他們完成這項工作。最終，在部署這些解決方案時，這將產生更多的衝突和延遲，降低它們的吸引力。精通技術的開發者會產生這樣的疑問：“如果我已經在部署客戶端和服務端的程式碼，為什麼還要使用第三方系統？”開源的分析解決方案將得到推動，而且更多機構將選擇把更多分析和資訊工作交給其內部完成。
另一個問題是可擴充套件性。現在大部分的網頁屬性都被優化為提供頁面，而不是處理分析資料流。新的服務端解決方案必須簡單、可靠、有內聚力。如果我們不考慮效能就增加大量請求和畫素，就像現在的情況一樣，那麼我們最終將沖垮我們自己的伺服器，增加成本和潛在的延遲。成功的解決方案會把前端資料與服務端處理器在一個單一、精心設計的管道上結合起來，然後把資料從伺服器匯出到資料倉儲（和第三方服務）中，可以是批量匯出。
在這種轉變中，很多機構將不會採取行動，並將依靠越來越糟糕的有缺陷的資料。資料是無濟於事的，而偏見會導致糟糕的資訊和決策。對開發人員、分析人員和營銷人員來說，這將是一段混亂的時期，而複雜的團隊中則可能產生分歧，出現一部分人採用新工具、另一部分人依然固守舊工具的情況。
是時候進行革新了
雖然混亂，但如果能超越內容攔截的問題，解決與網站追蹤有關的更深層次的問題——把前端資料與多堆疊內部資料相結合，不以頁面載入為中心、而是以網頁和應用上的事件和會話衡量網站使用體驗，併為更多機構實現第一方、特有的資料，那麼這一轉變將開啟重要的市場機遇，將現有的參與者重新洗牌。
公司在營銷和產品上的投資需要行之有效的解決方案，新工具將演化以填補這一空白——而且，由於新工具越來越複雜，具有深層次測量的專業技能的新開發人員和分析人員將湧現出來，並會非常吃香。
理想的解決方案是什麼樣的？鑑於前端和和後端的堆疊都多種多樣，系統需要變得非常靈活。對於情況如何發展，第三方錯誤追蹤指出了一個令人興奮的方向。Bugsnag 之類的服務幾乎每種語言都有庫，這些庫能在伺服器層執行，並能以 REST 方式與流資料就錯誤和異常進行互動。分析也可以以同樣的方式進行。
不過，希望機構能利用這一機遇收回他們對其資料的所有權，並且開源工具能得到推動，幫助流資料進入像 Redshift 這樣的第一方資料倉儲，與內部資料結合，被更靈活地使用。整個社群應該聯合起來，為 Web 2.0 應用程式規定一種合理的通用模式。Looker 之類的第三方 BI 服務應該建立在這種專有資料之上，而不是像谷歌分析現在所做的那樣把這些資料藏在無法訪問的地方。
如果這些都能實現，我們就是用一個簡單但殘缺的網站分析系統換來了一個能夠帶來更深刻的洞見的更加豐富、更加複雜的系統。這需要大量的投資和更多的專業技能，但回報將是更好的資訊，以及最終更好的產品、更好的使用者體驗和更出色的商業成果。
最終， 這 將 對 使用者 非常有益
與某些人聲稱的內容攔截器是蘋果促使更多人使用本地新聞閱讀器的祕密詭計正相反，這一改變至少是對使用者非常有益的。在移動端減少網路頻寬佔用以及清理大量繁瑣的東西是值得追求的目標。如上所述，這些頻寬中的一部分無疑將被轉移到來源上，但總體而言，Safari 移動使用者的體驗應該會更好（而且最終當我們把整個網際網路都清理乾淨後，其他所有使用者的體驗都會更好）。
有自己的網站的機構將必須適應這一轉變，否則就會在競爭中處於劣勢。
這一改變還有隱私上的考慮——移除第三方 cookie 將能減少那些與我們已經從購物車裡刪除的商品有關、在網上到哪都能見到的令人尷尬的廣告。但總體而言，對網上隱私的影響可能有限，因為這些公司有別的方法分享資料——其中最重要的就是僅通過分享郵件列表分享資料。通過定製受眾定位，Facebook 已經使這一方法成了主流。通用 ID 和 IP 和解將被更廣泛地使用，對營銷人員和內容平臺將變得更為重要。
這對網際網路也非常有益
通過使我們轉換為使用移動端、移動應用，以及從 Safari 開始對我們如何測量、跟蹤、定位的現狀發起挑戰，蘋果迫使我們對網際網路進行反思。就像移動應用的生態系統產生了更多工作量以及混亂和變化一樣，網站分析上的轉變不會那麼容易。但它也會產生大量的機會和新的贏家。它會為在這個生態系統中更好、更靈活地分析和理解使用者和產品的機制敞開大門。它將促使我們變得更好——更整合、意圖更清晰、更睿智。
是時候了。
題圖來自：JAMBRO/SHUTTERSTOCK
The Web-Tracking Tipping Point
賈斯汀·克勞斯（Justin Krause）是 Asana 的商業智慧和網頁開發團隊的負責人。