一、前言
神策分析 Web JS SDK，是一款輕量級用于 Web 端和 H5 端的數據采集埋點 SDK，它的核心功能是數據采集和發(fā)送數據到指定的服務端。具體而言，是指使用原生 技術實現代碼埋點、全埋點、可視化全埋點、網頁熱力圖和觸達圖等功能。下面，我們將對這些功能逐一進行介紹。
二、數據采集
對于 SDK 而言，數據采集是指在用戶行為觸發(fā)時（例如：進入某個頁面、點擊了某個按鈕等），按照既定的數據格式，將用戶的行為進行數據化。按照采集方式的不同，可以分為代碼埋點、全埋點和可視化全埋點等。
2.1代碼埋點2.1.1 概要介紹
代碼埋點又稱為自定義埋點。具體含義是：在 SDK 初始化之后，對于每一個關注的事件，調用 track() 等相關接口，將采集的數據保存到發(fā)送隊列中，然后按照一定的發(fā)送策略將數據發(fā)送到指定的服務端。例如：某個 li 元素被點擊，如果想采集這個 li 元素的點擊事件，就需要在 li 元素的 click 事件代碼中采集數據。
2.1.2 使用場景
代碼埋點有很多優(yōu)點：
（1）精準控制埋點位置。
（2）靈活的自定義事件和屬性，方便采集豐富的業(yè)務相關數據。
（3）可以滿足精細化的分析需求。
當然，代碼埋點也有相應的缺點：
（1）埋點代價比較大，每一個控件的埋點都需要添加相應的代碼，不僅工作量大，而且需要技術人員參與。
（2）更新的代價比較大，每一次更新埋點方案，都必須修改代碼。
（3）所有前端埋點方案都會面臨的數據傳輸時效性和可靠性的問題，這個問題只能通過在后端采集數據來解決了。因此，可以知道代碼埋點適用于需要精準控制埋點位置、靈活的自定義事件和屬性等精細化需求的場景。
2.2全埋點2.2.1 概要介紹
全埋點又可以稱為自動埋點。具體含義是：當集成使用了 SDK，開啟了對應的配置項，就可以自動采集數據。采集的范圍包括：頁面瀏覽、頁面元素點擊、視區(qū)停留等。
（1）頁面瀏覽：用戶打開網站或者 H5 頁面時，立即觸發(fā)一次頁面瀏覽事件，然后采集相關數據并發(fā)送到指定的服務端。
（2）頁面元素點擊：用戶在網站或者 H5 頁面內，對于 a input 元素進行點擊時，觸發(fā)頁面元素點擊事件，然后采集相關數據并發(fā)送到指定的服務端。
（3）視區(qū)停留：用戶在網站或者 H5 頁面內，有效停留一點時間，比如 4 秒（時間可以自定義），觸發(fā)了 的滾動。此時，會采集相關數據，記錄有效瀏覽，并發(fā)送到指定的服務端。
2.2.2 使用場景
全埋點有如下優(yōu)點：
（1）展示宏觀指標，滿足基本數據分析需求。通過展現 PV、 UV 等網站分析的宏觀指標，告訴運營人員每個控件被點擊的量有多少，哪些控件值得做更進一步的分析，有助于企業(yè)了解用戶行為，為進一步數據分析指明方向。
（2）技術門檻低，使用與部署較簡單。只需要嵌入 SDK，極大程度避免了因需求變更、埋點錯誤等原因導致重新埋點的復雜工作。
（3）用戶友好性強。自動向服務器發(fā)送數據，避免手工埋點的失誤。
同時，全埋點也有一些缺點：
（1）全埋點只能采集到用戶交互數據，且適合標準化的采集，自定義屬性的采集需要代碼埋點來輔助。每個用戶的交互行為均有許多屬性，全埋點無法深入到更細、更深的粒度。例如：在電商行業(yè)中，用戶點擊 “購物車” 是一次交互行為。全埋點會忽略用戶信息、商品品類等其他維度信息，此時需要配合代碼埋點來輔助數據采集；再如用戶上滑屏幕時js點擊滑動到指定位置，內容瀑布流的底部載入、商品或廣告的加載展示、下拉菜單中下拉內容的數據點擊等情況，這類自定義行為的采集需要代碼埋點來輔助實現。由于全埋點僅適合標準的方案采集，一些數據分析平臺也開始支持用戶為每個事件添加自定義屬性，如此能大大擴展事件分析的效能。
（2）全埋點是前端數據采集方式之一，因此具有前端埋點的天然缺陷。例如，數據采集不全面、傳輸時效性較差、數據可靠性無法保障等問題。全埋點的技術原理依賴網站終端技術開發(fā)的嚴謹性與規(guī)范性、網絡狀態(tài)、網絡口徑等因素。因此，可以知道全埋點適用于以較小的埋點代價采集盡可能多的用戶行為數據的場景。
2.3可視化全埋點2.3.1 概要介紹
運營人員能夠對用戶行為進行分析的前提，是對大量數據的掌握。在以往，這個數據通常是由開發(fā)者在控件點擊、頁面瀏覽等事件中通過編寫埋點代碼來完成數據采集的。然而傳統的操作模式每當升級改版時，開發(fā)和測試人員就需要不斷重復的對代碼進行更新，整個流程耗時長，無法滿足業(yè)務的需求。可視化全埋點應運而生，它可以通過一個操作界面，直接指定采集某個頁面的瀏覽事件或某個元素的點擊行為。例如，訂單詳情頁面的瀏覽事件、提交訂單按鈕的點擊、支付按鈕的點擊等。同時，可以為這個點擊行為定義一個特定的分析事件來記錄和追蹤。可視化全埋點為埋點工作提供了一個可視化的操作工具和界面，讓埋點變得更加顯而易見和易于操作，只需要簡單的選擇關注的按鈕，并設置相應的采集屬性，即可完成埋點工作，如圖 2-1 所示。
圖 2-1 可視化全埋點
2.3.2 使用場景
介紹了可視化全埋點的功能之后，下面我們來看下它有什么優(yōu)缺點：
優(yōu)點：（1）讓埋點行為可見，操作起來更容易。（2）降低埋點的技術壁壘，運營人員可直接埋點，無需研發(fā)參與。（3）降低埋點成本，提高了埋點的效率。（4）避免了代碼層面的變動，減少了代碼變動出 bug 的風險。
缺點：（1）可視化全埋點目前還只是提供部分元素點擊事件的埋點，埋點的范圍比較有限。（2）不支持增加自定義屬性。下面，我們列舉一個常見的運營場景：
運營需要對一個公司推出的拉新活動做一個分析，分析不同拉新活動的效果，不斷調整拉新策略和偏重。通常，運營將設計好的追蹤數據節(jié)點和格式設計好發(fā)給研發(fā)部門埋點。研發(fā)部門會安排人力，并排期開發(fā)。開發(fā)完成后，由于代碼上的變動，需要進行測試驗收。測試驗收后，才可以進行版本的發(fā)布。這個過程因為還涉及到部門的交互，整個流程耗時會比較長。這是第一版的準備工作，提前花一些時間還是可以接收的。但第一版的分析結果出來后，需要快速迭代新的運營策略時，此時活動依然在進行。必須保證快速調整和迭代，按照以往的流程就來不及調整了。
因為活動不可能停滯，等待重新埋點上線。這種情況極大的限制了運營的效率。因此，可以通過可視化全埋點來解決上述問題。它靈活、方便，不需要開發(fā)者對數據埋點添加任何代碼，只需要運營人員連接管理平臺并選擇頁面中需要埋點的元素，即可添加隨時生效的頁面埋點。這讓運營人員可以獨立完成一個運營計劃的設計、推廣和效果分析的閉環(huán)。并且操作方便快捷，相比于以往的開發(fā)者參與代碼修改需要排期開發(fā)、測試以及發(fā)版的流程上來說，時效性上有了一個巨大的提升。
以往運營人員進行一次運營活動，在設計、溝通需求、開發(fā)、測試、發(fā)版、分析運營數據這個龐大的流程中消耗大量時間。同時，如果考慮到運營過程中的調整，那以往的流程更是一個災難。可視化全埋點恰恰能夠很好的解決這個痛點，讓運營人員可以掌握整個運營活動的閉環(huán)。快速的迭代和分析運營效果，極大提高運營的效率，提升運營的價值。
2.4網頁熱力圖2.4.1 概要介紹
網頁熱力圖又可以稱為點擊圖，即應用一種特殊高亮的顏色形式，顯示頁面或頁面組區(qū)域中不同元素點擊密度的圖示。在用戶行為分析領域，點擊分析被應用于顯示頁面或頁面組（結構相同的頁面，如商品詳情頁、官網博客等）區(qū)域中不同元素點擊密度的圖示。包括元素被點擊的次數、占比、發(fā)生點擊的用戶列表、按鈕的當前與歷史內容等因素。網頁熱力圖的數據來源自頁面元素點擊采集的數據，如圖 2-2 所示。通過網頁熱力圖可以顯示頁面的點擊率和點擊占比的信息，同時可以觀察用戶的點擊習慣和分析一些關鍵位置按鈕的點擊效果。
圖 2-2 網頁熱力示意圖
2.4.2 使用場景
網頁熱力圖是一個很直觀和典型的數據可視化分析的功能。對于網頁來說，點擊是最重要的用戶行為。所有的用戶操作都離不開點擊，所以通過網頁熱力圖觀察點擊的頻率和占比是非常有價值的。對于運營人員來說，直觀展示出頁面元素的點擊分布和占比，可以直接看到用戶點擊的痕跡和分布，了解頁面上最受歡迎的點擊位置，呈現訪客熱衷的區(qū)域，幫助運營人員或管理者評估網頁設計的科學性。另外，相比于其他的柱狀圖、折線圖和數據表格的可讀性，網頁熱力圖直接將原始頁面展示給運營人員，可以直觀的得到分析的結果，看到用戶的點擊頻率和占比。
2.5網頁觸達圖2.5.1 概要介紹
網頁觸達圖，以水平線的方式劃分頁面被用戶瀏覽的比率，適用于一些有縱向滾動條的頁面。觸達圖依賴全埋點的預置事件 $ 的采集。默認情況下，用戶在瀏覽頁面時，有 4 秒的停留時間，即為有效瀏覽。最終根據所有用戶有效瀏覽頁面的高度占比，來計算和劃分網頁觸達圖。我們默認首屏展示的內容，所有用戶都已經瀏覽，另外計算有 4 秒的停留即為有效瀏覽。當用戶打開頁面后，停留時間大于等于 4 秒時，觸發(fā)了頁面的縱向滾動，此時計算當前頁面的底部到頂部的高度差，并記錄和采集數據。最終，如果該用戶在頁面上有多次這樣的有效瀏覽行為，我們計算一個最大的高度差，作為該用戶的瀏覽深度。通過網頁觸達圖可以分析出整個瀏覽頁面的用戶觸達深度和比例，有益于運營人員和網頁設計人員將重要的引流入口放到客戶觸達比例較高的部分，實現更高的引流和轉化比。
2.5.2 使用場景
對于數據分析的同學來說，會通過 PV、UV 監(jiān)測頁面流量是否增加，使用網站訪問深度監(jiān)測網站用戶粘性等。同時，也存在下面的需求：
（1）想要了解某網頁用戶關注的頁面位置怎么辦？
（2）想要通過某活動落地頁用戶的瀏覽深度優(yōu)化設計方案，提升運營效果，怎么辦？網頁觸達圖就是為了解決以上問題而設計產生的。觸達圖的展示，通過水平的觸達線，展示頁面或頁面組（結構相同的頁面，如商品詳情頁、官網博客等）等區(qū)域中用戶瀏覽頁面深度的占比，并動態(tài)地展示頁面中鼠標所在位置的用戶觸達率，如圖 2-3 所示。
圖 2-3 網頁觸達示意圖
其中，首屏默認為 100%，正常情況下頁面越往下滾動，瀏覽的占比越低。因此，網頁觸達圖可用于分析如詳情頁、著陸頁等類型頁面中用戶的瀏覽深度，幫助優(yōu)化頁面的內容、結構的設計。
2.6預置屬性采集
預置屬性是 SDK 預先采集頁面上的某些屬性，例如：頁面路徑 $url 、頁面標題 $title 、屏幕寬高（$、$ ）等。這些屬性會由 SDK 自動采集，然后和手動采集的屬性一起發(fā)往指定的服務端。這些屬性是自動采集，不需要開發(fā)者增加代碼，極大增加了數據采集的范圍和便利性。采集的預置屬性，是數據分析中涉及的重要分析緯度，自動采集極大降低了開發(fā)和采集的成本，是可以拿來即用的部分。介紹了預置屬性采集功能之后，下面我們來看下它有什么優(yōu)缺點：
優(yōu)點：自動幫用戶采集了很多頁面上的相關屬性，讓數據更加全面，分析維度更加豐富。
缺點：因為邏輯是在 SDK 內已經固定的，所以無法滿足細分或者定制化的需求（有定制化的需求，需要自定義屬性采集）。預置屬性涉及的面非常廣，屬性的種類也有很多，會在后續(xù)的專題中詳細講解，在此就不過多展開了。
三、 數據緩存與發(fā)送
在介紹完 SDK 的數據采集功能之后，我們來介紹下其他的核心功能：數據緩存與發(fā)送。
3.1數據緩存
大部分 Web JS 數據采集使用的是即時采集、即時發(fā)送的策略，沒有使用本地緩存。這樣減少了復雜的緩存、讀取和發(fā)送的控制流程。但是，無法避免的是當網絡情況不佳時，數據發(fā)送失敗的問題。數據一旦發(fā)送失敗，由于沒有緩存的邏輯，就會造成數據丟失。另外，一個常見的場景是：關閉頁面時，有發(fā)送數據的需求。
例如：點擊了某個按鈕，跳轉到另外一個頁面。此時，由于發(fā)送數據的同時切換頁面引起瀏覽器環(huán)境的破壞和中斷，導致發(fā)送數據的請求有未發(fā)送出去的風險，從而導致了數據的丟失。基于以上原因，SDK 增加了緩存模式。數據產生后，首先緩存在瀏覽器的 中。對于存儲的數據可以配置發(fā)送策略：默認是每 6 秒發(fā)送一次數據，或者當存儲數據達到 6 條時發(fā)送一次數據。如果數據發(fā)送不成功，會默認重新發(fā)送。直到發(fā)送成功后，才會從 中移除。這樣，可以有效的降低一些數據發(fā)送過程中的丟失問題。
不過，由于 的存儲空間有限制，默認只能存儲 200 條數據，超過的數據會按照默認的即時 img 請求發(fā)送數據。由于瀏覽器本身不具有固定設備內存可以使用， 也有存儲數據的限制，所以無法大規(guī)模緩存數據，只能限定緩存部分數據。數據存儲的形式不止一種，為什么 SDK 選擇 ？早期的瀏覽器只能通過 來存儲數據，后來我們逐漸增加了 ， 等存儲方式，現代瀏覽器還包含 。
比較下這幾種方案的特點，如表 3-1 所示：
表 3-1 緩存方案對比
（1）：因為存儲的數據量不能超過 4K，數據量較小，且 會被帶在 http 中。
（2）：只可以存儲 內的數據。
（3）：NoSQL 數據庫，本地可以存儲 250M 以上的數據。數據量很大，但是性能一般，在 500 ms 內，且操作相對麻煩。
（4）：可以理解為是一個文件存儲，可以大約存儲 5M 的數據，不同瀏覽器實現不一致，這個數據量比較合適。綜合考慮后，針對用戶行為這樣的數據， 相對合適。同步的 API 可以確保數據的一致，同時性能好，頻繁寫入幾乎感覺不到延時。
3.2數據發(fā)送
3.2.1 發(fā)送的方式
常見的數據發(fā)送方式有 img 發(fā)送、ajax 發(fā)送和 發(fā)送，下面對這幾種發(fā)送方式進行簡要的介紹：
（1）img 發(fā)送：默認使用 img 發(fā)送數據。對于跨域的兼容比較好js點擊滑動到指定位置，發(fā)送的形式就是創(chuàng)建一個 img 元素，src 帶上所有要發(fā)送的數據。執(zhí)行過程無阻塞，不會影響用戶體驗，而且相對與 對象發(fā)送 GET 請求，性能上更好。局限性是 get 請求所攜帶的數據大小是有限的。
（2）ajax 發(fā)送：常見的一種請求方式，為了不影響業(yè)務流程，默認是異步發(fā)送數據。采用的是 post 形式發(fā)送數據，數據較為安全，且發(fā)送數據的大小基本不受限制。
（3） 發(fā)送：當關閉頁面發(fā)送數據的時候，經常受到頁面容器 的影響，會導致數據來不及發(fā)送，進而產生丟失的問題。 是瀏覽器的新發(fā)送策略，可以避免頁面容器 時數據發(fā)送丟失的問題。不過，目前該功能還未普及。另外，需要補充強調的是：批量發(fā)送是采用 ajax post 異步形式發(fā)送數據的。批量發(fā)送，是建立在上面提到的緩存數據的基礎上。SDK 默認是選擇立即發(fā)送的 img 方式。當通過配置項，將發(fā)送修改為批量發(fā)送模式時，會將數據先進行 緩存，然后一次性將多條數據整合到一起，通過一個請求發(fā)送到指定的服務端。由于數據體相對來說比較大，默認使用的是 ajax post 異步發(fā)送的方式。下面從幾個角度來分析 img、Ajax、 的優(yōu)缺點，如表 3-2 所示。
表 3-2 發(fā)送方式對比
3.2.2 發(fā)送的順序
SDK 采集的是網頁端的數據，用戶的行為數據通過網絡請求發(fā)送到指定的服務端。但是，網絡請求是有波動的。如果是先后連在一起觸發(fā)的數據，可能會出現先發(fā)后到的情況。比如：點擊按鈕跳轉頁面，會先發(fā)送的一個點擊事件，緊接著跳入新頁面，會發(fā)送一個頁面瀏覽事件。事實上，經常會出現用戶的行為序列中點擊事件和頁面瀏覽事件顛倒的問題。直觀來看，用戶行為會非常不合理：先觸發(fā)了后一個頁面的頁面瀏覽事件，接下來的行為卻是前一個頁面的某個按鈕的點擊事件。那如何解決這個問題呢？答案是構建發(fā)送隊列。發(fā)送隊列有兩個優(yōu)點：
（1）為了不影響用戶的業(yè)務流程，SDK 一般采用的是異步加載的方式插入頁面。因此，會有一些頁面一打開就需要觸發(fā)的事件，在觸發(fā)時 SDK 還未正常引入核心源碼并完成初始化。此時，SDK 就會將觸發(fā)的事件存入發(fā)送隊列中。等待 SDK 源碼加載完畢并初始化成功后，立即執(zhí)行發(fā)送隊列。這樣保證了數據不會丟失，解決了異步加載 SDK 的問題。
（2）保證用戶行為數據按照正確的順序入庫，形成正確的行為序列。這是如何做到的呢？SDK 在發(fā)送隊列中的數據時，默認會按照順序發(fā)送，當前一條數據返回發(fā)送成功的狀態(tài)后，依次發(fā)送下一條數據，這保證了大部分正常流程的數據發(fā)送正確。但是，萬一前面的數據發(fā)送卡住了，一直沒有狀態(tài)返回怎么辦？SDK 的解決方案是設置超時時間：: 隊列發(fā)送超時時間，默認值 300 毫秒，如果數據發(fā)送時間超過 還未返回結果，會強制發(fā)送下一條數據。: 數據發(fā)送超時時間，默認值 3000 毫秒，如果數據發(fā)送超過 還未返回結果，會強制取消該請求。構建發(fā)送隊列可以解決 Web 端行為數據發(fā)送順序錯亂的問題。
四、總結
本文對于 Web JS SDK 進行了簡明扼要的介紹，概述了 Web JS SDK 的基本功能，旨在讓大家對于它有一個初步的了解。關于具體使用和實現原理等相關知識，會在后續(xù)的文章中逐步向大家介紹。
作者：郭政 神策數據 |Web JS SDK 技術顧問
我是郭政，神策數據 Web JS SDK 技術顧問，主要從事 Web 方面技術的研究和學習。希望能在開源博客中，和大家多交流，多學習。平時喜歡看看書，跑跑步，希望保持自己身體和心靈一直在路上。