背景
现在大家对互动玩法应该已经司空见惯,很多APP或多或少都会在业务场景中采用各式各样的互动玩法来吸引用户,让用户在参与互动的同时,得到平台权益,进而提升平台心智,达到促活拉新目的。随着闲鱼规模变大,平台权益扩展,基于任务 抽奖的互动玩法在日常以及大型营销活动中应用越来越多。
痛点分析
对于活动中的互动玩法,从设计到研发再到验收上线的流程大致如上,在具体实践过程中,我们经常会遇到以下问题:
-
底层能力抽象不够:业务开发同学需要关注玩法底层交互逻辑,不同活动需重复开发,开发成本高;
-
问题难排查:互动玩法的配置包含抽奖、任务、积分等多个平台,链路复杂涉及数据交互多,其中一个环节配置错误,都有可能出现任务完成不了、抽奖次数不增加、抽奖不成功等问题,链路复杂无疑给排查问题增加了不少困难;
-
配置问题后知后觉:抽奖、任务、积分等配置问题运营无法自助排查,往往需要在测试过程中由测试或者技术同学介入排查,占用开发时间,严重影响活动上线效率。
针对上面的痛点,对问题进行抽象,我们期望建设互动玩法标准化,当前阶段关键解法主要是以下三点:
-
抽象互动能力:实现互动玩法标准化交互,沉淀面向开发者的互动玩法SDK,提高开发效率;
-
建设自助排查能力:在实现玩法在互动配置平台自测环节中,提供问题调试排查能力,引导运营自助解决配置问题,只有自测通过后才能提测,从而降低测试成本;
-
统一互动配置平台:通过统一的闲鱼互动配置平台串联抽奖、任务、积分配置,建立标准流程,校验关键配置的准确性,让运营在提测前保证玩法整个流程顺畅。
互动任务标准化
大多数情况下,抽奖活动中都会有任务玩法,用户需要通过完成任务来增加抽奖次数。闲鱼的任务体系是使用淘系任务中心进行搭建的。任务与抽奖的链路如下图所示。
闲鱼的互动任务有以下几种类型:
-
仅跳转:点击任务按钮,进行页面跳转,并将任务参数以url参数形式带到后链路,后链路在特定操作后进行任务上报;
-
完成并跳转:点击任务按钮,在页面跳转同时进行任务上报;
-
浏览任务:浏览任务与仅跳转任务类似,除了可以在后链路进行任务上报之外,也可以在当前页面进行任务上报。
关于任务上报,目前闲鱼主要有两种方案:前端上报、事件采集上报。
-
前端上报:当用户领取任务后,在定制场景下请求任务中心上报服务,完成任务;
-
事件采集上报:闲鱼通用事件采集系统对用户特定行为进行采集,采集到行为信息后请求任务中心上报服务,完成任务。
下面以两个典型的任务来介绍任务上报链路,分别是会场浏览任务和关注闲鱼号任务,前者是前端进行任务上报,后者是事件采集进行上报。
在互动任务标准化建设过程中,前端在淘系任务中心的列表组件基础上,进行二次封装,简化组件配置,并且加一些闲鱼的定制能力,最终形成闲鱼通用的任务列表组件。
互动抽奖标准化
前端在实现抽奖标准化中,主要是抽象抽奖能力,将抽奖通用逻辑封装成SDK,提高业务开发效率。
需求分析
-
在进行抽奖之前,先初始化活动数据,获取用户在当前活动中的状态以及活动本身的相关数据;
-
支持登录状态校验,允许用户未登录时访问页面,当用户进行抽奖时,执行登录逻辑,并且登录返回活动后重新进行活动初始化;
-
支持页面聚焦后,自动刷新活动数据,重新初始化活动;
-
抽奖之后,在展示当前抽奖结果的同时,支持自动更新中奖纪录,并且刷新活动数据;
-
测试过程中,当抽奖出现异常时,可以及时排查出问题,提供解决问题方法。
SDK API
-
初始化SDK初始化时,除活动配置平台生成的活动ID外,其他都是选传。
import Oliver from "@ali/pcom-fin-oliversdk";
const oliverSdk = new Oliver({
/**
* 抽奖活动Id
*/
activityId: '544',
/**
* 其他选项
*/
options: {
/**
* 活动参数
*/
oliverparams: {
/**
* 是否需要权益的详情,默认false
*/
needBenefits: false,
/**
* 否需要权益详情,只有抽取的情况下才生效,默认false
*/
needDetails: false,
/**
* 否需要是否已经中奖过的信息,只有 needDetails 为true时候生效 非必须不要使用性能及其差,默认false
*/
needHadWin: false,
/**
* 扩展参数,用于服务端能力扩展
*/
extend: {}
},
/**
* 是否需要页面聚焦后自动刷新活动数据,默认true
*/
autoUpdate: true,
/**
* 是否需要判断登录态,默认true
*/
checkLogin: true
},
/**
* 活动数据返回回调
*/
dataWatcher: (data) => {}
});
-
抽奖
oliverSdk.draw(params: {
// 抽取扩展参数
extend?: PlainObject;
// 指定权益抽取
idleOliverBenefitCode?: string
}).then(res => {
// do some things
})
-
获取权益列表
oliverSdk.getLogs(params: {pageSize: number; curPage: number}).then(res => {
// do some things
})
-
更新活动数据
oliverSdk.update;
Hooks
为了降低业务上层开发同学对SDK的使用成本,考虑提供基于集团Rax方案的Hook能力。
业务层开发只需在调用方法时,依据数据变化来进行交互展示。这样既减少了上层代码量,同时降低开发成本。下面是Hook的使用代码示例:
import useOliver from '@ali/pcom-fin-oliver-raxhook';
// 使用hook
const { oliverData, drawResultData, draw } = useOliver({
activityId: '544'
});
// 监听活动数据
useEffect( => {
const availableTimes = oliverData?.availableTimes || 0;
// do some things
}, [oliverData]);
// 监听抽奖结果
useEffect( => {
// do some things
}, [drawResultData]);
// 抽奖
draw;
自助排查
以往在抽奖活动测试验收过程中,服务端返回的异常code对于运营和测试同学来说非常不友好,没有直接展示异常原因,每次都需要技术同学介入来排查问题。为了快速定位问题解决问题,我们考虑提供问题调试能力,让运营和测试同学可以自助排查问题。
抽奖SDK中有一个日志存储功能,在测试环境中将用户操作记录和服务端返回的数据存储在本地,另外提供一个日志列表页面,在页面中对日志进行解析,提供异常code的具体原因并提供解决方法,展示给运营和测试同学。自助排查功能使用流程如下图所示。
互动配置标准化
互动玩法配置链路复杂,为了降低配置成本,减少配置错误,我们提出配置标准化方案。标准化配置主要解决以下三个问题:
-
标准流程配置:引导运营一步一步进行配置,将复杂的配置链路流程化,避免有所遗漏;
-
配置校验:在配置过程中,会拉取当前步骤中对应的配置进行校验,提示错误配置;
-
完整链路测试:在活动提测之前,需要运营自测活动配置,在通用测试页面中,完成做任务增加抽奖机会到抽取奖励减少抽奖机会这一完整链路,只有自测通过后才能提测。
目前建设的抽奖标准化配置流程如下:
-
选择投放计划:拉取当前运营同学在抽奖配置平台中配置的投放计划列表,选择投放计划后展示投放计划中的权益配置;
-
权益确定:选择投放计划中的权益,并进行限制规则配置;
-
选择兜底投放计划:支持选择当前投放计划的兜底计划;
-
高级配置:确定权益发放安全码配置以及抽奖后扣减的积分配置。
效果
-
互动玩法的标准化实现在闲鱼内多个互动场景中落地,如双11的节后鱼生活动、五福主题的鱼生有福活动、闲鱼币狂欢日、天天赚钱等。
-
前端对互动逻辑的封装抽象,互动模块开发效率有显著提升,开发工时相对减少50%;
-
运营和测试同学使用SDK调试能力,实现了快速定位问题,开发零成本介入问题排查;
-
运营按照标准流程对互动活动进行配置,在配置过程中,提前检验配置的正确性,降低了后续活动测试成本。
互动玩法已然成为一种常用的运营手段,在玩法落地过程中,我们分析痛点,不断探索,以技术手段降低互动玩法上线成本,并且取得了显著效果。
在实现互动玩法标准化后,我们会继续抽象基础互动玩法,搭建一个玩法模块化的互动玩法平台,抽象基础玩法,如抽奖、签到、抽签、投票等。在互动玩法平台上,运营同学可以自助配置玩法,无需开发和测试同学高成本投入,活动上线效率与质量也可以得到有效保障。
,