起点学院课程

方法论:如何从0到1搭建一套完整的邀请体系?

9 评论 1.2万 浏览 62 收藏 13 分钟
15天0基础极速入门数据分析,掌握一套数据分析流程和方法,学完就能写一份数据报告!了解一下>>

如何从0到1搭建一套完整的邀请体系?本文将从是三个角度来思考这个问题,一起来看看~

最近对邀请好友做任务类的产品功能思考还是挺多的,有一些思考分享给大家。

写文章前,再把人人都是产品经理上的邀请好友类文章,刷了大半,有很多都挺不错:有深度、有案例、有数据、有实操建议。

贴部分好文如下:

方法论:如何从0到1搭建一套完整的邀请体系

方法论:如何从0到1搭建一套完整的邀请体系

大部分文章都基本会落脚在:邀请功能的某个点或者整条线上,比较易读,也有冲击力。但我较少看到:体系化的文章(或许我没看到)。

今天笔者试着来写一写:如何从0到1搭建一套完整的邀请体系。笔者才疏学浅,仅是一个角度思考,欢迎一起探讨成长!

在构建邀请体系时,笔者以如下3个问题反思它的价值:

  1. 这套方法论,是不是一种可迁移的能力?不管是哪个行业、哪个产品阶段都能使用。
  2. 这个邀请框架,从满足业务诉求上,是不是延展性强、复用性高?
  3. 这种组件化的设计理念,是不是可以快速适配80%以上的邀请需求?

如果,以上问题都有肯定的答案,那么它的目的就达到了。

本文框架概览:

1. 为何要做邀请功能?

2.系统化的邀请体系该如何设计?

2.1 搞懂宏观:邀请流程视图及底层架构

2.2 发力微观:做个有灵魂的产品

2.3 设计组件化:四两拨千斤的能力

3. 邀请能力升级:数据驱动产品迭代

1. 为何要做邀请功能?

万事万物皆有因果。做之前,搞清楚为什么做,往往更为关键。

你可能会说:竞品做了一个邀请功能超级好,带来了很多增长,我们也做一个试试;

或者老板说:最近我们产品的用户增长遇到了瓶颈,需要用老带新的方式,提供新的增长点。都可以的,搞清楚目标及定位就ok。

笔者认为:邀请功能持续被大家推崇,有两个大原因:

  1. 流量红利消失带来的焦虑感。付费型流量贵、质量不可控;私域流量不一定具有普适性、也未必玩得转;
  2. 邀请功能作为其中一个流量抓手。免费、可控、有背书,自带BMG式的出场让大家满怀期待。

当然,从大方向上的达成一致,并不意味着条件成熟。是否真的、需要立马采取行动?不妨用下面的三个问题check下。

(1)当前产品所处的是什么阶段?

种子期、成长期、稳定期、衰退期,相对来说,拉新和稳定期比较适合借助MGM来获得更多的增长。

(2)当前产品遇到了什么问题?

增长乏力、留存低、复购差。如果这些问题都存在,可以考虑启动MGM。

(3)解决产品当前的问题只有邀请这一种?

自然的流量太少、付费的流量太贵,主动推的流量质量差。那么玩好MGM是个不错的选择。

上述问题,如果你都想清楚了,那就开始行动吧!

二、系统化的邀请体系该如何设计?

邀请好友功能,一般说成MGM(member get member),会员拉会员,即为常说的老(M1)带新(M2)。根据开篇说的三个问题,体系化的邀请功能该如何思考及落地?

2.1 搞懂宏观:邀请流程视图及底层架构

(1)邀请流程视图

从用户来角度,邀请功能有一套完整的、标准的流程视图:M1先做什么?M2后做什么?最终他们获得什么?

见下图:

方法论:如何从0到1搭建一套完整的邀请体系

共7步,每一步都有对应的要点及交付物,这样也就方便需求方快速地提交需求并及时响应,下面以:step2和step4 举例说明下(完整的内容,可联系笔者)

step2:业务交付内容

MGM作为平台的能力,需要适配不同业务方的需求,比如平台运营,需要拉新、拉回流;某一块业务,需求就偏向于拉业务的销量。

此表的作用有两个:

  1. 充分调研业务的需求,因为作为设计者,你不可能完全了解业务;
  2. 管理业务的需求,按照业务的迫切程度,排出优先级及管理预期。

方法论:如何从0到1搭建一套完整的邀请体系

step4:M1邀请页

这个页面非常关键,也是决定分享率的重要因素。在设计的过程中,既要考虑页面框架的通用性,也要考虑特殊业务场景的需求。但M1的邀请页设计的核心是不变的:把握M1的需求,给予他们一个充分的动机,并降低他的完成成本,即为:需求–动机–能力。

动机:为什么用户愿意发起邀请,是因为活动福利,还是因为炫耀?

能力:用户发起、达标是否容易达成?流程是否足够简单?

方法论:如何从0到1搭建一套完整的邀请体系

(2)MGM底层架构

上面说了MGM的用户视角规范流程,但仅有前端的规范是远远不够的。产品经理需要抽象出邀请功能的系统能力,以对接上前端应用。见下图,分4大模块;数据、系统能力、运营配置以及前端应用。一个MGM需求要快速上线、功能要高可用,就要重点打磨两个方面:

MGM的组件能力:邀请组件能够快速在业务场景、活动页面配置并上线。

中台能力-达标工厂:简单的业务不需要中台,如果是一个金融类的产品,就有非常多的达标条件,需要将各类条件抽象出来,集合成业务中台,实现各类业务快速组装、配置、调用的诉求。

方法论:如何从0到1搭建一套完整的邀请体系

2.2 发力微观:做个有灵魂的产品

有了整体的框架,还不够,还需要从细节处着手,从微观层面发力。在邀请类功能里,什么是微观?微观是:产品界面的信息结构如何布局,交互细节如何设计。

M1邀请页面、M2参与页,并不是简单的信息堆砌,它是有灵魂的,遵循一定的设计逻辑的,笔者称之为:加工流水线。

较多的启发也来自于,何杨老师写的《产品文案如何写,才能高效表达产品卖点》一文中的精髓:池子法则。图示如下:A代表动机,B代表能力。有了持续、稳定的输入,才有更优质的输出。

方法论:如何从0到1搭建一套完整的邀请体系

利益池:枚举邀请页面的利益点,挑选、提炼重点几条对M1触动最大的利益点。

动机池:包含行动目的,以及采取行动所需付出的成本。

成品池:对关键元素进行加工,利益点&动机&能力,排优先级并逐一陈列。

具体怎么应用:以瑞幸咖啡的M1邀请页面来举例。

利益池:

  1. 奖励一杯咖啡
  2. 好友免费喝一杯

动机池:

  1. 动机:现在我想免费喝
  2. 能力:分享一下就好了,很简单

成品池:

品牌主图+利益点(易记忆)、采取行动(分享)、查询奖励(关注点)、活动规则(收起)

概括:页面结构清晰、利益点突出、参与流程直接。整体设计丝毫不拖泥带水。

方法论:如何从0到1搭建一套完整的邀请体系

2.3 设计组件化:四两拨千斤的能力

这一部分,交互视觉的同学是大有可为的模块。目标就是:通过设计模块组件化,能够像乐高积木一样,快速搭建出一个MGM活动页面。组件可复制、可延展。这样一来,就可以快速支持业务需求。

笔者认为可以抽象的组件有:

  1. MGM入口场景的设计图
  2. 页面主图的利益点排布规范:花钱的、不花钱的
  3. 奖励内容设计:花钱的:定额奖励/阶梯奖励/惊喜奖励;不花钱的:情感化分享卡片
  4. 邀请流程模块:流程事项123
  5. 活动规则:展示形式,页面平铺还是弹窗

先搭载整个设计化组件框架,再根据业务活动一次次优化、完善,最终形成完整的MGM设计组件库,减少重复劳动。

3. 邀请能力升级:数据驱动产品迭代

一个有价值的产品,一定是能接受住考验的。而数据,就是其最好的证明。因此,笔者愿意将数据部分单独来讲,反思下从开篇我们说的:3个问题。

3.1 方法论是否能迁移

就要监测这一套系统的方法论,能否适配各类业务、各种行业。大家不妨放到各种业务场景下,检验它的可用性。

3.2 框架是否高可用

1)是否支持各类业务达标要求,反观达标工厂的颗粒度支持情况。

2)邀请活动的效果:M1分享率、M2达标率,两者所对应出来的指标,如果过低,就要从两个纬度思考:未分享前:突出利益点,分享后:增加流程管控:触达能力(未达标提醒、活动快结束提醒)、常态的参与入口。

3.3 设计组件能否支持80%以上的需求

每来一个活动,请反思现有的设计组件,能否满足,是否需要重新设计?

以上就是本次要分享的内容,我们来小结下:

  1. 首先想清楚为什么要做邀请功能,不能病急乱投医
  2. 构建邀请体系:既要有宏观视野,又要从微观发力,以设计组件实现四两拨千斤
  3. 以数据监测不断驱动产品迭代升级

以上,就是本次分享到内容~

送大家一句话:切勿夜里想千路,明日走老路,想清楚就行动吧!

#专栏作家#

行走的大雄,微信公众号:大雄背起行囊,人人都是产品经理专栏作家。金融产品经理,有多款千万级产品设计运营经验,喜欢健身、跑步,关注做事的杠杆方法。

本文原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash, 基于CCO协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
起点学院课程
评论
评论请登录
  1. 垃圾文章

    回复
  2. 如何搭建邀请功能体系能,有具体资料分享么?想学习拜师,😊

    回复
  3. 瑞幸这种拉新的烧钱方式不具有普适性啊…

    回复
  4. 不要制造名词垃圾好不,什么是mgm,我百度了,米高梅

    回复
    1. MGM是用户增长基本名词,这个要都算名词垃圾只能说明你比较露怯啊同学

      回复
    2. 这个词确实不常见

      回复
    3. 国内公司应用一般都说人拉人 挺多互联网公司都这么称呼 其实还挺常见的

      回复
  5. 打卡 ,所以到现在这种情形看 瑞幸这种邀请方式是好还是坏呢

    回复
    1. 至少从用户基数来说是成功的

      回复