我菜固我在

博客园 首页 新随笔 联系 订阅 管理

App 邀请机制是每个产品几乎必做的功能点,它一般以两种形式存在:一是作为常置功能用于推荐,二是作为裂变活动用于邀请。

无论以哪种形式出现,都可以归为社交分享的一种表现方式。相较于营销推广,邀请好友机制显然获客的预算成本低得多。另外,邀请的优点不仅在于引流新用户,在邀请时无形中也增强了老用户对产品的认同感和活跃度。简单来说,这是产品低成本拉新促活的不二之选。

但实际在使用邀请码机制拉新过程中,效果依然不明显,是产品自身问题呢?用户不愿意安装?还是哪个环节出现问题呢?
大家是否考虑过在邀请环节里出现用户流失的情况呢?

下面先介绍填写邀请码与免邀请码优势与劣势。

一、传统填写邀请码
原理非常简单:邀请人生成一个专属的邀请码给到被邀请人(新用户)填写即可。


而填写邀请码环节的出现,本质上是满足开发者和推广人员的统计需求,却没有考虑用户的体验,反而在安装过程增加一个填写环节,增加了潜在用户流失的可能(操作流程越复杂,用户的流失率就越高)。一旦老用户认为奖励的意义不大,新用户又对“填写邀请码”环节的繁琐产生了反感,选择“放弃注册”或者“跳过邀请码”,邀请注册活动就会以失败告终。

为什么用户会在填写邀请码环节戛然而止呢?
主要原因是:邀请码是由人工操作填写,大多数用户会在这一步里失去耐心。而填写邀请码本质是为了满足开发和推广人员的统计需求,我们为什么不能去掉用户填写邀请码码的步骤呢?使用程序自动填写,同时也可以满足开发和推广人员的统计需求呢?

 


下面就介绍基于传统填写邀请码优化出来的方案。

二、免填邀请码
事实上国内已有好几家服务商提出解决方案了。例如:openinstallsharetrace …,这里就不逐一介绍了,实现的原理基本一致。

就拿sharetrace来说实现的原理吧:

开发者在分享的H5页面上集成sharetrace的web sdk,发布分享链接时会在url后面拼接需要的参数(邀请码、渠道号等),例如:A用户的URL后面带的参数可能是code=A,B用户分的URL参数就是code=B。
当终端访问这个分享的H5页面时,openinstall的web sdk 会上传这个终端的设备信息和url拼接的参数,上传到服务器进行判断,再使用sdk从第三方服务器再取回暂存的自定义参数。
开发者根据各自的需求,在分享链接自定义各种动态参数。比如通过在分享链接url中附带App邀请人的用户id,就可达到免填邀请码的效果。

 


根据这种原理,可以实现精准识别每个安装来源。可以不填邀请码又可以满足开发和推广人员的统计需求。
     
三、结语
说到这里,相信大家已经了解传统填写邀请码与免邀请码的区别吧。
可以说免邀请码方案更合适现阶段的推广手段,同时这项技术自然也可以应用到无数领域中,只要有渠道来源监测或识别的需求,都可以满足。

该文章我也发布到了CSDN: 地址

 

posted on 2020-05-14 09:43  大侠(cer)  阅读(600)  评论(0编辑  收藏  举报