背景

现在大家对互动玩法应该已经司空见惯，很多APP或多或少都会在业务场景中采用各式各样的互动玩法来吸引用户，让用户在参与互动的同时，得到平台权益，进而提升平台心智，达到促活拉新目的。随着闲鱼规模变大，平台权益扩展，基于任务+抽奖的互动玩法在日常以及大型营销活动中应用越来越多。

痛点分析

对于活动中的互动玩法，从设计到研发再到验收上线的流程大致如上，在具体实践过程中，我们经常会遇到以下问题：

1. 底层能力抽象不够：业务开发同学需要关注玩法底层交互逻辑，不同活动需重复开发，开发成本高；

2. 问题难排查：互动玩法的配置包含抽奖、任务、积分等多个平台，链路复杂涉及数据交互多，其中一个环节配置错误，都有可能出现任务完成不了、抽奖次数不增加、抽奖不成功等问题，链路复杂无疑给排查问题增加了不少困难；

3. 配置问题后知后觉：抽奖、任务、积分等配置问题运营无法自助排查，往往需要在测试过程中由测试或者技术同学介入排查，占用开发时间，严重影响活动上线效率。

技术方案

针对上面的痛点，对问题进行抽象，我们期望建设互动玩法标准化，当前阶段关键解法主要是以下三点：

1. 抽象互动能力：实现互动玩法标准化交互，沉淀面向开发者的互动玩法SDK，提高开发效率；

2. 建设自助排查能力：在实现玩法在互动配置平台自测环节中，提供问题调试排查能力，引导运营自助解决配置问题，只有自测通过后才能提测，从而降低测试成本；

1. 统一互动配置平台：通过统一的闲鱼互动配置平台串联抽奖、任务、积分配置，建立标准流程，校验关键配置的准确性，让运营在提测前保证玩法整个流程顺畅。

互动任务标准化

大多数情况下，抽奖活动中都会有任务玩法，用户需要通过完成任务来增加抽奖次数。闲鱼的任务体系是使用淘系任务中心进行搭建的。任务与抽奖的链路如下图所示。

闲鱼的互动任务有以下几种类型：

1. 仅跳转：点击任务按钮，进行页面跳转，并将任务参数以url参数形式带到后链路，后链路在特定操作后进行任务上报；

2. 完成并跳转：点击任务按钮，在页面跳转同时进行任务上报；

3. 浏览任务：浏览任务与仅跳转任务类似，除了可以在后链路进行任务上报之外，也可以在当前页面进行任务上报。

关于任务上报，目前闲鱼主要有两种方案：前端上报、事件采集上报。

1. 前端上报：当用户领取任务后，在定制场景下请求任务中心上报服务，完成任务；

2. 事件采集上报：闲鱼通用事件采集系统对用户特定行为进行采集，采集到行为信息后请求任务中心上报服务，完成任务。

下面以两个典型的任务来介绍任务上报链路，分别是会场浏览任务和关注闲鱼号任务，前者是前端进行任务上报，后者是事件采集进行上报。

在互动任务标准化建设过程中，前端在淘系任务中心的列表组件基础上，进行二次封装，简化组件配置，并且加一些闲鱼的定制能力，最终形成闲鱼通用的任务列表组件。

互动抽奖标准化

前端在实现抽奖标准化中，主要是抽象抽奖能力，将抽奖通用逻辑封装成SDK，提高业务开发效率。

• 需求分析

1. 在进行抽奖之前，先初始化活动数据，获取用户在当前活动中的状态以及活动本身的相关数据；

2. 支持登录状态校验，允许用户未登录时访问页面，当用户进行抽奖时，执行登录逻辑，并且登录返回活动后重新进行活动初始化；

1. 支持页面聚焦后，自动刷新活动数据，重新初始化活动；

2. 抽奖之后，在展示当前抽奖结果的同时，支持自动更新中奖纪录，并且刷新活动数据；

1. 测试过程中，当抽奖出现异常时，可以及时排查出问题，提供解决问题方法。

• 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的具体原因并提供解决方法，展示给运营和测试同学。自助排查功能使用流程如下图所示。

互动配置标准化

互动玩法配置链路复杂，为了降低配置成本，减少配置错误，我们提出配置标准化方案。标准化配置主要解决以下三个问题：

1. 标准流程配置：引导运营一步一步进行配置，将复杂的配置链路流程化，避免有所遗漏；

2. 配置校验：在配置过程中，会拉取当前步骤中对应的配置进行校验，提示错误配置；

3. 完整链路测试：在活动提测之前，需要运营自测活动配置，在通用测试页面中，完成做任务增加抽奖机会到抽取奖励减少抽奖机会这一完整链路，只有自测通过后才能提测。

目前建设的抽奖标准化配置流程如下：

1. 选择投放计划：拉取当前运营同学在抽奖配置平台中配置的投放计划列表，选择投放计划后展示投放计划中的权益配置；

2. 权益确定：选择投放计划中的权益，并进行限制规则配置；

1. 选择兜底投放计划：支持选择当前投放计划的兜底计划；

2. 高级配置：确定权益发放安全码配置以及抽奖后扣减的积分配置。

效果

1. 互动玩法的标准化实现在闲鱼内多个互动场景中落地，如双11的节后鱼生活动、五福主题的鱼生有福活动、闲鱼币狂欢日、天天赚钱等。

2. 前端对互动逻辑的封装抽象，互动模块开发效率有显著提升，开发工时相对减少50%；

3. 运营和测试同学使用SDK调试能力，实现了快速定位问题，开发零成本介入问题排查；

4. 运营按照标准流程对互动活动进行配置，在配置过程中，提前检验配置的正确性，降低了后续活动测试成本。

总结

互动玩法已然成为一种常用的运营手段，在玩法落地过程中，我们分析痛点，不断探索，以技术手段降低互动玩法上线成本，并且取得了显著效果。

在实现互动玩法标准化后，我们会继续抽象基础互动玩法，搭建一个玩法模块化的互动玩法平台，抽象基础玩法，如抽奖、签到、抽签、投票等。在互动玩法平台上，运营同学可以自助配置玩法，无需开发和测试同学高成本投入，活动上线效率与质量也可以得到有效保障。