App 邀请机制是每个产品几乎必做的功能点，它一般以两种形式存在：一是作为常置功能用于推荐，二是作为裂变活动用于邀请。
无论以哪种形式出现，都可以归为社交分享的一种表现方式。相较于营销推广，邀请好友机制显然获客的预算成本低得多。另外，邀请的优点不仅在于引流新用户，在邀请时无形中也增强了老用户对产品的认同感和活跃度。简单来说，这是产品低成本拉新促活的不二之选。
但实际在使用邀请码机制拉新过程中，效果依然不明显，是产品自身问题呢？用户不愿意安装？还是哪个环节出现问题呢？
大家是否考虑过在邀请环节里出现用户流失的情况呢？
下面先介绍填写邀请码与免邀请码优势与劣势。
一、传统填写邀请码
原理非常简单：邀请人生成一个专属的邀请码给到被邀请人（新用户）填写即可。
而填写邀请码环节的出现，本质上是满足开发者和推广人员的统计需求，却没有考虑用户的体验，反而在安装过程增加一个填写环节，增加了潜在用户流失的可能（操作流程越复杂，用户的流失率就越高）。一旦老用户认为奖励的意义不大，新用户又对“填写邀请码”环节的繁琐产生了反感，选择“放弃注册”或者“跳过邀请码”，邀请注册活动就会以失败告终。
为什么用户会在填写邀请码环节戛然而止呢？
主要原因是：邀请码是由人工操作填写，大多数用户会在这一步里失去耐心。而填写邀请码本质是为了满足开发和推广人员的统计需求，我们为什么不能去掉用户填写邀请码码的步骤呢？使用程序自动填写，同时也可以满足开发和推广人员的统计需求呢？
下面就介绍基于传统填写邀请码优化出来的方案。
二、免填邀请码
事实上国内已有好几家服务商提出解决方案了。例如：openinstall、sharetrace …，这里就不逐一介绍了，实现的原理基本一致。
就拿sharetrace来说实现的原理吧：
开发者在分享的H5页面上集成sharetrace的web sdk，发布分享链接时会在url后面拼接需要的参数（邀请码、渠道号等），例如：A用户的URL后面带的参数可能是code=A，B用户分的URL参数就是code=B。
当终端访问这个分享的H5页面时，openinstall的web sdk 会上传这个终端的设备信息和url拼接的参数，上传到服务器进行判断，再使用sdk从第三方服务器再取回暂存的自定义参数。
开发者根据各自的需求，在分享链接自定义各种动态参数。比如通过在分享链接url中附带App邀请人的用户id，就可达到免填邀请码的效果。
根据这种原理，可以实现精准识别每个安装来源。可以不填邀请码又可以满足开发和推广人员的统计需求。
三、结语
说到这里，相信大家已经了解传统填写邀请码与免邀请码的区别吧。
可以说免邀请码方案更合适现阶段的推广手段，同时这项技术自然也可以应用到无数领域中，只要有渠道来源监测或识别的需求，都可以满足。
该文章我也发布到了CSDN: 地址
