据了解发现,相较于产品忠诚度,用户更看重体验的愉悦感和价值感。如何围绕用户流失和留存全面“战斗”是产品能够持续发展并在行业中脱颖而出的关键。A/B 测试作为神策数据 SDAF 闭环的有机组成,能够依托神策的闭环生态助力企业迅速感知与反馈,帮助企业产品抢占市场。

       如何对产品体验做出正确、快速的感知不是盲目的“拍脑袋”式决策,也不能单纯凭借个人感觉来做决定,每个种植在互联网“土壤”的产品都需深知一个制胜“法宝”——A/B 测试。如何快速、方便、高效地通过 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]关注神策数据公众号,回复“A/B 测试”即可免费体验。

       当然,可视化对元素的支持不是固定的,我们“克制”地保留了暂未在实际场景中使用能力的开启,采取更加灵活的配置化元素的能力,您可以在需要时快速更新管理端通信配置,支持需要的元素类型。如下为详细的设计图:

       在神策可视化编辑器的功能扩展上,我们完全按照统一的接口约定来实现,减少 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 测试基础的小白快速上手、避免踩坑。

       补充阅读:

       [1]支持修改的 HTML 标签范围:

       [2]https://github.com/sensorsdata/abtesting-sdk-web

       [3]https://manual.sensorsdata.cn/sa/2.3/tech_ab_testing_web-50987163.html

风险提示 ： 文章呈现的所有信息仅作为参考，不构成投资建议，一切投资操作信息不能作为投资依据。投资有风险，入市需谨慎!