我們正在見證互聯網發展中的一個分水嶺——在蘋果推出內容攔截器後，我們看待和理解我們網上的用戶的方式將發生深刻的改變。
這看上去並沒有多麼重要。雖然廣告攔截器在桌面瀏覽器上存在了很多年，但類似谷歌分析的產品仍然成爲了測量和監測網站的行業標準。但這些都即將改變——個人產品和分類將因爲移動版 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 的商業智能和網頁開發團隊的負責人。