據了解發現，相較于產品忠誠度，用戶更看重體驗的愉悅感和價值感。如何圍繞用戶流失和留存全面“戰斗”是產品能夠持續發展并在行業中脫穎而出的關鍵。A/B 測試作為神策數據 SDAF 閉環的有機組成，能夠依托神策的閉環生態助力企業迅速感知與反饋，幫助企業產品搶占市場。

如何對產品體驗做出正確、快速的感知不是盲目的“拍腦袋”式決策，也不能單純憑借個人感覺來做決定，每個種植在互聯網“土壤”的產品都需深知一個制勝“法寶”——A/B 測試。如何快速、方便、高效地通過 A/B 測試在交互體驗上贏得先機？這就不得不提及神策 A/B 測試的可視化試驗。以下為本文重點內容：

• 可視化試驗是什么

• 可視化試驗的應用

• 可視化試驗功能支持

• 可視化試驗性能介紹

可視化試驗是什么

大多數互聯網公司的決策者需要借助數據來推動有關決策，這意味著如果能更快更便捷拿到客戶的反饋和數據，便能擁有更多先機和智慧決策。因此，在 A/B 測試中我們需要更便捷、更靈活的方式來運行更多的試驗。

最明顯的試驗莫過于用戶可見更改（例如對用戶界面的修改），但是每次從研發到產品的發版鏈條較長，對試驗反饋速度的影響很大。在此背景下，可視化試驗應運而生。它使我們能夠更快更便捷地驗證試驗、發版產品，甚至可以作為臨時性產品功能的有力支撐。

可視化試驗是指通過可視化編輯的方式修改頁面元素，無需代碼編程即可快速進行文本、圖片的替換和樣式調整，生成不同版本的試驗方案。具體包括文本的內容替換、字號、粗斜體、文本超鏈接地址以及超鏈接的打開方式（新窗口/當前窗口）；圖片的替換、寬高和邊框樣式。

可視化試驗的應用

我們可以設想以下幾個場景：

• 公司有多個營銷活動， 每次都需要開發同學根據不同策略開發不同頁面（整體變化不多，卻需要發布多個活動）

• 產品在設計和需求上僅有些許不同，或文案上需要在少數用戶群中快速驗證方案效果，卻需要整體走研發→ 測試 → 發版流程 （反饋速度大打折扣，打破了整體產品思想連續性）

• 已經有多套宣傳落地頁，根據活動不同僅需局部改動、研發修改才能做 A/B 試驗

此時，我們就需要 A/B 測試的可視化試驗幫助我們迭代產品文案及宣傳營銷策略，不用依托研發的整體流程，快速進行分流驗證，讓我們有效驗證方案。

這里需要強調，A/B 測試可視化試驗的最明顯提升主要包括兩方面：

一是效率提升。那么便可以降低試驗成本（包括人力成本、交流成本等），針對單個網頁或者營銷落地頁，進行頁面中某些文本、圖片的替換和編輯，通過所見即所得的界面操作生成不同版本的試驗策略，無需代碼編程即可快速發布試驗。

二是業務指標提升。試驗成本變低，業務人員就可以做更多的試驗，提升轉化、用戶活躍的幾率就會變大。舉個例子，神策服務的某個企業服務客戶，之前只做功能方面的試驗，用了神策 A/B 測試之后，因為試驗方便快捷，順便做了一個功能按鈕位置的試驗，在調整按鈕位置后，用戶注冊會員率提升了 46%。

在此前發布的文章《從技術視角看什么才是值得擁有的 A/B 測試？》?中，我們已經了解了 A/B 測試在提升功能和性能兩個維度的技術實踐。接下來，我們可以根據神策數據 A/B 測試試驗類型做橫向對比，幫助大家更簡單易懂地看出可視化試驗對于其他試驗在特殊場景下的優勢。如下圖所示：

通過比較我們可以發現，相較于其他試驗，可視化試驗的優勢主要體現在易用性和高效上。本文將主要分析 A/B 測試中，可視化試驗在易用性和高效性上的優勢。

可視化試驗功能支持

如何打造強大、高效、易用的 A/B 測試可視化試驗？我們從以下幾點來論述。

1、快速試驗類型切換

相比較其他試驗來說，可視化試驗的創建和其他試驗的創建幾乎一樣，如果您在使用神策A/B 測試，那么上手成本幾乎為零。我們可以看下創建試驗的界面：

在信息填入環節，可視化試驗和多連接試驗的操作方式及路徑相同：按照要求填寫需要做試驗的頁面 URL 即可。為了確保地址正確，還可以針對當前試驗鏈接進行校驗。在配置關注指標時，選取受眾用戶等步驟和其他類型的試驗創建相同。

如果您在創建試驗過程中發現試驗的類型不符合當前場景，您也可以快速切換成符合您當前場景的試驗。同時，在切換時我們也會保留您在創建其他類型試驗（除了不同類型中不兼容的試驗組）的配置，無需重新創建，大大縮減了您在切換類型上的時間。

2、可視化編輯器

A/B 測試可視化試驗中最重要的支持是可視化編輯器，市面上 A/B 測試可視化編輯大體上有兩種方案：

神策 A/B 測試可視化編輯器在設計之初，為了使產品交互更加簡單高效，選擇使用 Iframe 方案，能夠讓使用者在編輯可視化試驗時更趨于編輯器的試驗效果，更加專注于試驗的目的，而不需要花太多時間去學習如何使用可視化編輯器，減少了學習成本。編輯器的示例圖如下：

實時編輯預覽，無需編碼，所見即所得，在試驗上線后分流生效時，用戶會在被分配在不同的組中，展示出編輯器中調整的效果。編輯器能滿足現有的大部分場景需求，包含以下類型：

（1）文本編輯

• 文本內容：支持文本內容的替換

• 字號大小：支持修改文本字號大小

• 文本顏色：支持修改文本顏色和文本背景顏色

• 文本樣式：支持修改文本對齊方式、粗斜體以及下劃線

• 文本鏈接：若編輯的文本為超鏈接，可替換要跳轉的鏈接地址

（2）圖片編輯

• 圖片地址：支持圖片的替換

• 圖片尺寸：支持修改圖片寬高

• 圖片描邊：支持修改圖片邊框樣式

（3）修改記錄

• 查看修改記錄：支持查看當前分組相對于對照組的所有修改點

• 恢復初始設置：針對某條修改記錄，一鍵恢復到初始值

具體支持編輯的元素大致分類可參看文章末尾附錄部分[1]。

當然，可視化對元素的支持不是固定的，我們“克制”地保留了暫未在實際場景中使用能力的開啟，采取更加靈活的配置化元素的能力，您可以在需要時快速更新管理端通信配置，支持需要的元素類型。如下為詳細的設計圖：

在神策可視化編輯器的功能擴展上，我們完全按照統一的接口約定來實現，減少 SDK 和編輯器的耦合，留出了較強的擴展能力。整體流程可以簡化來看：Iframe（轉載產品頁面）——可視化交互接口——編輯器?

那么這樣會對產品有什么影響呢？直接的好處在于減少 SDK 更新升級，因為在進行交互接口設計時包含了對整體交互的定義及元素配置支持。如果您使用的是神策 A/B 云管理端，在線升級就能配置增量支持元素能力。

減少可視化 SDK 升級意味著產品會更大程度減少對研發迭代的依賴。當然也不僅僅如此，如果獲得 A/B 測試可視化 SDK 的集成（神策 A/B Web SDK 已開源），可以實現可視化交互接口的編輯器（即實現上圖的 Visual Configurator 部分），一個開箱即用的可視化編輯器就誕生了，接下來便可以進行二次開發。

3、分組快速編輯

在點擊分組編輯后，我們支持無刷新地在當前頁面上進行試驗組的試驗查看；支持快捷新增、修改和刪除試驗分組信息。支持的操作內容包括：

（1）支持切換視圖模式（網頁設備和移動設備）和視圖區域大小（調整頁面比例）

（2）支持切換網頁模式：例如訪問試驗頁面前需要進行登錄操作，切換到“網頁模式”后，即可進行正常的頁面訪問跳轉。（當從網頁模式切換到編輯模式后，需要確保當前編輯頁面的 URL 與試驗 URL 一致）

4、高清截圖

為了能讓使用者感知到試驗中的改變，最便捷的方式是使用預覽圖快速展示。動態截圖預覽，跟進改變后生成預覽截圖，根據開源 chromium ?進行截圖，和瀏覽器打開幾乎一致。每個試驗的頁面修改能夠清晰的通過預覽截圖查看到。

5、強大開源的可視化 SDK

（1）開源 SDK。[2]

（2）應用接入：需集成 Web SDK 開啟使用，詳情參見 SDK 集成指南。[3]

整體面向交互接口的設計，可以讓我們的接口靈活通用。

可視化試驗性能介紹

產品體驗中，網頁加載速度是很重要的產品指標。Think with Google 中有統計當網頁加載用時從 1 秒增加到 7 秒時，移動網站訪問者的跳岀概率會增大 113% 。

在界面渲染上，業界經常關注三個指標：

• FP（First Paint）：首次繪制，標記瀏覽器渲染任何在視覺上不同于導航前屏幕內容的時間點

• FCP（First Contentful Paint）：首次內容繪制，標記的是瀏覽器渲染第一幀內容 DOM 的時間點，該內容可能是文本、圖像、SVG 或者 canvas 等元素

• FMP（First Meaning Paint）：首次有效繪制，標記主角元素渲染完成的時間點，主角元素可以是視頻網站的視頻控件，內容網站的頁面框架也可以是資源網站的頭圖等。

從 A/B 可視化試驗產品角度來看，在對性能的保證方面需要我們關注以下兩點。

第一，對于產品本身來說，要保證 A/B 可視化編輯器整體使用的流暢，我們對下幾個方面進行了思考：

• 使用編輯器中加載出編輯頁面的速度

• SDK 加載速度

• 編輯響應速度

第二，客戶使用 A/B 測試可視化對本身產品的影響：

• 可視化試驗的渲染

• 可視化試驗的分流

• 可視化試驗的拉取數據

秉承“為客戶帶來價值”和“把事情做到極致”的理念，接下來我們重點討論一下神策在可視化試驗對客戶的影響方面上的思考及優化。

客戶使用 A/B 測試做可視化試驗可能產生的影響之間具有“各自有著獨特的優化場景卻并不相互獨立”的關系。這里我們用一個具體的例子來說明。

客戶 A 在做按鈕交互方案的試驗時，常見的交互做法如下：

渲染步驟為：改變顏色 → 改變邊框 → 改變文案。拉取的試驗數據也會包含三條改變記錄。我們可以想象得到，如果對可視化試驗改動稍大時，我們的元素記錄改變數據將會有數倍的增長。

神策 A/B 測試的可視化試驗引入了元素快照的概念，整體的調整優化如下：

我們把同一個元素的改變合成一個快照的形式，在改動一個元素時，保存的數據會減少 N-1 （N 為對元素修改的次數），與此對應那整體渲染個數也會減少，拉取數據的量（網絡傳輸快）也會減少，SDK 渲染速度會變得更快。

對于可視化的分流速度，和其他的試驗類型幾乎無差別。經過對分流接口統計，在 QPS 5K 時，接口平均耗時可以穩定在 2ms。

為了減少修改變動對客戶本身頁面的影響，我們對可視化試驗數據采取和業界不同的設計方式，在可視化結構層減少渲染的數量。經過實際測試，未集成 SDK 到集成 SDK 未命中試驗，加載時長增加 0.1s；集成 SDK 未命中試驗到命中試驗，加載時長增加 0.4s。由此可見集成 Web 可視化試驗插件對性能及頁面加載時長并無較大影響。

總結

在 A/B 測試中，可視化試驗在易用和效率兩方面具有較大優勢，對于 A/B 測試的小白來說，上手成本較低，能夠降低試驗的實施成本和分析成本，通過標準化的試驗指標計算快速發現、終止不符合預期的試驗，降低試驗的實施門檻，幫助沒有 A/B 測試基礎的小白快速上手、避免踩坑。

總結

以上是生活随笔為你收集整理的效率提升看得见 神策 A/B 测试可视化试验能力正式上线的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。