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