以任务为模型的玩法设计

营销平台定义营销玩法：用户在商家平台通过完成某些动作并获得优惠奖励。

在调研了许多平台的实现中，也有些直接把抽奖做为玩法实现！

营销玩法平台第一版也是将抽奖概念设计成玩法概念并落地的，在早期的许多场景中落地且收益效果不错。

随着更多玩法的加入，单纯靠抽兑奖模型去迭代已经力不从心。在整个玩法生命周期中，用户完成任务的交互方式变化太多，而获得奖励只是个结果。在当时的高速的迭代中，是没有更多时间与精力去思考新模型落地，而是在原有模型中，抽出一块服务专门做与用户的交互逻辑，这块代码几乎全部是定制逻辑。在定制的逻辑中再去找共用与抽象！

在这个问题之上，我们尝试用分析演绎法来收集现有玩法，再推演出更合适的模型。

分析法

罗列常用玩法的例子

大转盘
限时限金
真心实意
邀请有礼
红包雨
膨胀红包
会员日

玩法名	玩法规则
大转盘	用户下单完后，在支付成功页弹出大转，用户点击转盘抽奖后可获得一个或多个奖品
限时限金	用户打开限时限金活动页面，分享这个活动到微信好友后，多个好友助力后，用户可获得现金奖励
真心实意	门店老板在门店端小程打开真心实意活动后，分享链接到好友，好友点击链接打开小程序可以领取一张券，好友核销这张券后，门店老板将获得奖励金
邀请有礼	用户分享链接给好友，好友踩链接后下第1单，用户获得奖励，一段时间后，好友再下一单，用户再获得奖励
红包雨	用户在指定页面内，到达时间后，将会下红包雨，用户在规定时间内不停的点，就会在结束时，触发一次抽奖
膨胀红包	用户在首页参与了膨胀红包活动，点击抽奖，将获得一次奖励，点击膨胀，再抽一次奖
会员日	门店创建活动，用户下单完成门店设定的阶梯后，将会获得对应的礼品
下单返	用户下完单后，达到门槛价格或件数，将会获得一张券或现金等

通过以上的例子，提取关键信息【用户下单、用户分享、门店分享、好友助力、用户点链接、用户点膨胀...】，这些都有一个规律，参与者，完成动作，获得奖励。所以，通过分析法，得出的模型为

用户 -> 完成动作 -> 获得奖励

演绎法

有了这个模型之后，再将这个模型带入现有的业务中推演，再反复推敲逻辑的合理性与补充点

玩法名	玩法规则	模型适配（用户，完成动作，获得奖励）
大转盘	用户下单完后，在支付成功页弹出大转，用户点击转盘抽奖后可获得一个或多个奖品	用户下单，用户抽奖获得奖品
限时限金	用户打开限时限金活动页面，分享这个活动到微信好友后，多个好友助力后，用户可获得现金奖励	用户分享，好友助力，用户领取现金
真心实意	门店老板在门店端小程打开真心实意活动后，分享链接到好友，好友点击链接打开小程序可以领取一张券，好友核销这张券后，门店老板将获得奖励金	门店老板分享，用户领取券，用户核销券，门店获得奖励金
邀请有礼	用户分享链接给好友，好友踩链接后下第1单，用户获得奖励，一段时间后，好友再下一单，用户再获得奖励	用户分享链接，好友下单，用户抽奖获得奖品
红包雨	用户在指定页面内，到达时间后，将会下红包雨，用户在规定时间内不停的点，就会在结束时，触发一次抽奖	用户抽奖获得奖品
膨胀红包	用户在首页参与了膨胀红包活动，点击抽奖，将获得一次奖励，点击膨胀，再抽一次奖	用户抽奖获得奖品，用户再抽奖，再获得奖品
会员日	门店创建活动，用户下单完成门店设定的阶梯后，将会获得对应的礼品	用户下单完后，用户获得奖品

通过以上分析，得出每一个动作的完成都可以抽象成一个任务模块

任务模型 = 用户角色 + 完成动作 + 获得奖励

即一个任务的完整模型为

活动	角色	完成动作	获得奖励
大转盘	用户	下单	抽奖
限时限金	用户	分享链接	无
	好友	助力	奖品（券）
	用户	被助力	抽现金
真心实意	门店	分享链接	无
	用户	踩链接	奖品（券）
	用户	核销券	无
	门店	被核销	奖励金
邀请有礼	用户	分享链接	无
	好友	踩链接	无
	用户	被踩链接	奖励
红包雨	用户	打开页面	抽奖
膨胀红包	用户	打开首页	抽奖
	用户	点击按钮	抽奖
会员日	门店	创建活动	无
	用户	下单	获得奖励

活动模板的创建就可以拆解成一个任务一个任务编排了，在上面的拆解中，有个不容易厘清的问题，如真心实意活动中，用户核销触发门店获得奖励金，这是个条件状语从句，即如果用户完成了核销，那么门店将获得奖励。有承上启下的作用。将此逻辑重新推演，便得出如下模型。

有了这个模型之后，我们配置活动如同说话一样简单，再拿这个模型推导现在复杂的玩法

活动	任务	主体	完成动作	触发	事件
真心实意	门店分享	门店	分享链接	无
	用户踩链	用户	踩链接	无
	用户领券	用户	点击领取	用户获得奖品	用户获得奖品
	用户核销	用户	核销券	门店获得奖励金	门店获得奖励金
	售后任务	用户	售后	门店返还奖励金	门店返还奖励金

活动	任务	主体	完成动作	触发	事件
邀请有礼	用户分享链接	用户	分享链接	无
	好友踩链	用户	踩链接	无
	好友下首单	用户	下单	用户获得现金	用户获得现金
	好友下二单	用户	下单	用户获得现金	用户获得现金

在这个模型下，现有的玩法活动都能满足，再有就是完善整个动作属性设计，比如好友下首单，这个首单就是在【下单】这个完成动作的一个属性，还有首单不能低于多少钱也是在这个动作的属性。在每一个动作完成之时，将不再有活动时间的概念，活动时间即每个动作完成时间段。

活动玩法时间

在【真心实意活动】中，我们设定活动时间是1天，比如活动时间是2020-01-01至 2020-01-02，那么这个时间是指门店分享链接时间和用户领券后下单有效期时间，在用户下完单后，第二天开始用户售后到往后7天内售后都算有效，那这个售后时间就是2020-01-02 至2020-01-08这段时间内都是售后有效期。售后时间过完后，再到门店发放奖励金时间，这个时间又是在售后时间过完后，才能发放奖励金，即2020-01-09。那么在这个活动中，我们活动的开始时间和结束时间到底是哪天？

事实上活动时间是个泛指概念！即多数情况下，都是指C端用户的动作完成情况，比如【真心实意的话动】时间就是指用户下单核销在指定时间内就是泛指的活动时间。在整个活动设计中，活动时间可以不用设定，只需要设定每个动作的时间区间就行。

但有时候，用户不理解这些概念，为了让用户能明白活动时间概念，需要将C端玩法时间单独描述出来。

表模型设计

通过已有的表模型，将再模拟创建一个简单的活动模板，看数据是如何流转还有如何运行

以门店推单分享为例，门店分享链接到好友，将获得一次成长积分

活动模板

{
    "activityName": "门店推单",
    "status": "INIT",
    "type": "mdtd",
    "startTime": "2024-08-21 23:00:00",
    "endTime": "2024-08-21 23:00:00",
    "task": [
        {
        }
    ]
}

任务模板

{
    "task": [
        {
            "name": "门店分享任务",
            "startTime": "2024-08-20 20:00:00",
            "endTime": "2024-08-21 23:00:00",
            "subject": {},
            "event": {},
            "target": {}
        }
    ]
}

用户模板

{
    "subject": {
        "name": "门店人群",
        "type": "store",
        "properties": [
            {
                "type": "圈店",
                "key": "cycleStore",
                "value": "圈店code"
            }
        ]
    }
}

动作模板

{
  "action": {
        "name": "分享链接",
        "type": "share",
        "properties": [
            {
                "type": "圈人（非风控）",
                "key": "cycleUser",
                "value": "圈人code"
            },
            {
                "type": "分享主图",
                "key": "shareTitleImg",
                "value": "http://www.baidu.com"
            },
            {
                "type": "邀请码业务编码",
                "key": "qrCode",
                "value": "{\"qr\":\"123\"}"
            }
        ]
    }
}

事件模板

{
    "event": 
        {
            "userId": "门店",
            "event_type": "issue",
            "awardId": "toolActivityId（成长积分）"
        }
}

以上是一个完整的动作完成获得奖励，以条件状语从句整理如下：

如果门店分享一次链接，那么门店将获得一次积分

然后属性值在设计的时候就可以确保在每个动作里业务方需要确认的参数，如

门店每天分享几次，最大分享次数，获得几个积分等等参数

第一性原理推导

第一性原理推导即最简单模式下的数据模型。给模型做减法，在这个模型中，action与event是可以通用的，user表也可以不用，直接在action中增加一个用户id字段就行，也能完整表达其中的意思，如果按这个逻辑，此模型将会简化成这样

在这个简化的版本里，所有用户也可以作为一个属性字段放在action里，太抽象会造成理解成本升高！太具体会造成重复功能过多，如何把握这个尺度一直是个难点。因为业务是扩张还是收缩都能直接影响系统设计。

在action与event表合并后，语义将发生变化，如

用户完成动作获得奖励

在条件定语从句中，完成动作触发另一个事件将不再容易描述

A用户完成动作触发B用户获得奖励

如果将此语义重新组合一下，就符合条件状语从句表述了

用户完成动作触发（奖励|动作），奖励：奖品；动作：用户发放奖励

由此可见，此条件下的逻辑将变得简单，下面将举例来推演这个数据模型是否通用

玩法	条件从句	action数
推荐好友注册	如果用户A邀请好友B成功注册，用户A将获得100积分奖励	2
购物满减	如果用户在单次购物中消费满500元，那么用户将获得50元的优惠券	1
签到奖励	如果用户连续签到7天，那么用户将获得额外的签到奖励	1
社交分享	如果用户分享产品链接到社交平台，并且有好友通过链接购买产品，那么用户将获得该产品的10%返现奖励	2
活动报名	如果用户报名参加特定活动，并且在活动中完成指定任务，那么用户将获得活动奖品	N

以目前的数据模型，起码能支撑现有的用户交互的营销活动。

t_properties

在业务初期，许多设置将是比较笼统的，比如，设置分享链接的标题、规则页，给好友的助力次数，一开始是不清楚这些字段归类的，当业务达到一定量级后，就能找出许多共性。比如分享链接标题、规则页可以按资源概念归类到一起
properties是一种KV结果表模型，在数据工程领域是高表，能表达一切含义。缺点是这种数据不好统计，没有规律，没有索引。而这种形态更非常适合早期的系统功能实现，在达到一定量之后，再分出领域模型也是很方便的

t_award

奖品表就一张表，但这个能做的事比较多，如果表示奖池，将这个表加个parent_id字段就能表示奖池。如果要表示礼包，则只需要将类型与奖池类型区分即可
奖品需要有算法，算法是作用的奖品上，而不是人上。发奖本质上是用户连接奖品，用户是不确定的，而奖品是确定的。所以，奖品上有算法只需要【计数】介入就可以了
至于算法需不需要再建个领域，个人理解，如果业务上有许多算法，并且算法有许多属性值要设定的时候，这个领域建立是有必要的

扩展

假设公司有个直播平台，当主播要求大家发送一段文字，将会获得红包。

这种需求只需要简单转化为

用户-发送特定文字-触发用户获得红包

用户发送特定文字这个可以由任意平台来实现，玩法平台将提供2种能力

1，提供动作的完整实现

2，提供动作完成之后的事件触发机制

关于活动场次的解读

有些活动会有时间限制，比如10点发一波红包雨、12点发一波红包雨、下午再来一波。

在这种场景下，活动的概念在原来的理解中就解释不通，到底活动是一场红包雨，还是多场红包雨才能称之为活动。

按现有设计，解释就简单很多

1，活动是属于多场红包雨

2，每场红包雨是一个任务，每个任务有自己的时间

关于活动时间的解读

活动时间一直是个解释不通的点，在运营看来，活动时间就是一用户参与时间，那么在真心实意里，门店发放奖励金这个还是不是活动时间？用户售后是不是活动时间？

其实，这些都是活动时间，至于具体是哪个是活动时间，由宣传人员自己定。系统只按任务时间来完成标准动作。

所以，活动时间可以是用户参与时间，或是用户参与售后时间，或是门店发放完奖励金时间。但每个任务的时间一定是确定且不容改变的。

关于风控的解读

风控不应该是营销的规则。风控主体是人，活动参与者也是人。营销不应也不能判断风控，营销只关心哪些人参与了活动，不关心这个人是不是风控，但可以把用户参与活动的频次等告知风控。这样，营销在投放出去时，就应该把风控人群过滤了。

posted @ 2024-12-19 18:00 wxwall 阅读(14) 评论(0) 编辑收藏举报

刷新页面返回顶部

wxwall