背景：
做产品和运营的小伙伴，对裂变营销情有独钟，主要原因无非裂变营销有一些独有的优势：
成本低，低预算就可以达到很好的效果
易传播，在各个平台上基于人群的传播速度非常快
容易形成口碑，在人群中传播容易形成对品牌的口碑
但是在做裂变营销的过程中，对于很多初创团队或者非互联网企业来说，实现这套流程是有难度的，包括时间成本，系统的复用性，系统的健壮性和在不同社交媒体的适配等，都是问题，短时间内很难上线，所以今天我们屡一下这个路径里面所用到的技术支撑。
场景
我们今天将以这个场景来看一下技术的链路：
1. A用户从App分享活动到社交平台
2. B用户可以在社交平台看到活动信息，参加活动
3. 系统判断A和B的邀请关系，以及B的活动完成情况
4. 系统发放奖励给邀请者A和被邀请者B
技术链路
社交裂变基本需要涉及到这么几个模块：
1. App内的分享能力，支持分享到多平台，如微信，QQ，微博等
2. 在社交平台内传播，需要记录传播关系
3. 传播链接或二维码，能够无缝启动应用，或者引导用户去下载App
4. 用户启动App后，需要能够在App内做场景还原
5. 确定邀请关系，并上报服务器
以上这套能力基本上是可以完成整个社交裂变分享场景的能力，接下来我们将以市场是第三方公司友盟提供的一些能力，来实现这套链路。
分享能力
分享现在已经是非常成熟的能力了，如果只专注微信，则直接集成官方的SDK就可以了， 可以直接在微信开放平台，申请账号，获得Key和Security，然后按照说明文档执行就好。
如果是集成多个平台，如微信，QQ，微博等，建议使用集合式SDK，一个套件就可以完成多平台集成：
在友盟官网下载集合SDK，勾选所需要的平台
集成可以采用自动集成方式，也可以使用手动集成方式，手动集成基本上就是解压包拿到jar包以后，放在自己的工程里
接下来根据不同的Android或iOS平台，一步一步集成就好，这个可以参考官网文档，不做赘述，比较简单
传播关系记录
如果要记录传播关系，是需要在工程里面自定义一些参数，并将这些参数在分享时候传递出去的，比如我们在代码里设置下面几个：
user_id=xxx(设置你自己App的用户识别码)
share_platfrom=android/ios(区分哪个系统分享出来的)
share_target_platform=sdk.platform（区分分享到微信还是QQ等哪个平台去了）
.....
其他一些你希望带出去的参数，都可以提前定义好。定义完成以后，我们其实不能明文传出去，因为有些还是涉密信息的，所以这里有个加密过程，可以调用SDK里面的方法，将这些参数打包变为一个rootTrackcode，将这个code信息放在链接中对外传播。
此时还需要做一件事，就是在分享的H5链接里面，需要能够接收到你分享出来的参数，所以此时需要在H5里面集成一个JS SDK。
其实这个SDK很简单，主要完成两个能力：
用于接收我们客户端分享出来的信息
用DeepLink的能力，最后将我们的App启动起来
所以这个SDK是一个必备的信息，他的实现也比较简单，就跟正常集成三方的JS SDK一样的步骤。
启动App
启动App这一步，是用DeepLink能力，Deeplink（深度链接）是一种能够实现应用之间无缝跳转的技术。在移动端，DeepLink能够实现点击H5链接直接跳转到目标App具体页面的功能。例如您可以将App内的一个H5页面链接通过微信分享给好友，好友点击这个链接就能直接拉起对应的App并直接跳转到对应详情页，而不是App首页。如果好友未下载App则会跳转到App下载页面，下载成功后仍然能打开App指定页面。这样能大大缩短用户使用路径，降低用户流失率。因此Deeplink功能被广泛用在众多行业App拉新推广等场景，例如：
电商类App：在分享商品链接中点击，进入 App 内对应店铺或购物页面
资讯类App：在分享新闻链接中点击，进入 App 内对应内容页面
游戏类App：在分享邀请组队的链接中点击，进入 App 内对应的游戏房间或战队队伍中
广告App：在社交平台点击相关广告，进入 App 内对应内容页面
拉新活动：例如老带新邀请、福利抽奖等 H5 页面活动，参与者可以点击进入 App 内对应活动参与页面
由于Deeplink技术已经演变了很多年，因此不同操作系统都有着不同版本的Deeplink技术，下面会介绍两种最常用的Deeplink方法
1.URL Scheme方法
在iOS 9和安卓10（M）之前，移动端实现Deeplink的方式都是通过URL Scheme。一般形式是这样的：Scheme://host:port/path?query=xxxxxxx。
Scheme：表示的是一个 URL 中最初始的位置，即 :// 之前的那段字符，我们可以用Scheme来定位对应的App。例如淘宝的Scheme就是taobao、支付宝的Scheme就是alipay，新浪微博的Scheme是sinaweibo。
path：代表了想要跳转的指定页面
query：代表了想要传递的参数。URL Scheme方式优点在于实现简单，但弊端也很明显：
微信、微博、手百禁掉了部分App的Scheme。造成的后果是用户不能直接从微信内H5页面唤起APP,而是得通过右上角浏览器打开的形式，在浏览器内直接唤起App。
H5页面会弹出一个提示框：“是否打开某某App”，需要让用户点击确认一次，增加了用户使用流程2.Universal link方法Universal link 是苹果公司在2015年推出的新一代Deeplink方法，iOS9及以上的用户可以通过点击一个https 链接无缝地跳转到一个App应用内的指定页面，中间不需要用户点击确认打开App，也不需要用户在右上角跳转通过safari打开跳转。如果用户没有安装这个App，则会跳转到App的下载页面。可以看出Universal link方式比URL Scheme方式更好，并且目前国内微信、QQ已经支持Universal link形式的跳转，因此更推荐您采取Universal link的形式在iOS端唤起App。
所以DeepLink的JS SDK就是我们上一步所集成的那个，无需再额外集成了。
也就是说我们基本上集成了Share的SDK和JS SDK这两个，就具备了我们全链路的分享+追踪+启动的能力。
判断A和B用户的邀请关系
还记得我们上面说的需要让你传的自定义参数吗? 在这里就派上用场了，经过在社交平台上的传播链路，最终我们前面的那个code会在启动App时候，上报到服务器上去，然后在被启动用户的客户端里，我们同时上报这个B客户的ID，两个ID之间的匹配关系就可以得到了。
当然在B用户里，我们其实可以有更多的场景来去定义，比如是启动事件，还是注册事件，还是下单购买事件等，这些事件都可以通过自定义的方式来上报，下面是一个自定义参数的例子：
先初始化：
public class UmengApplication extends Application {
@Override
public void onCreate() {
super.onCreate();
// 初始化SDK
UMConfigure.init(this, "您的appkey", "您的渠道", UMConfigure.DEVICE_TYPE_PHONE, null);
// 选用合适的页面采集模式，这里以LEGACY_MANUAL为例
MobclickAgent.setPageCollectionMode(MobclickAgent.PageMode.LEGACY_MANUAL);
// 支持在子进程中统计自定义事件
UMConfigure.setProcessEvent(true)；
然后定义自定义上传参数
Map<String, Object> music = new HashMap<String, Object>();
music.put("music_type", "popular");//自定义参数：音乐类型，值：流行
music.put("singer", "JJ"); //歌手：(林俊杰)JJ
music.put("song_name","A_Thousand_Years_Later"); //歌名：一千年以后
music.put("song_price",100); //价格：100元
MobclickAgent.onEventObject(this, "play_music", music);
提前初始化onEventObject
获取关系
最后获取邀请关系也比较简单，通过接口就可以了，现在友盟平台拿到你的Key和Security
然后调用相应的OpenAPI，传入邀请者ID，然后即可获取到被邀请者ID，剩下的就是你业务逻辑的处理了。
总结
综上所述，整个过程涉及到客户端SDK的能力，传播网页H5中的能力和最终服务端匹配能力。每个环节都值得我们深入研究，使得链路更顺畅，用户体验更好。
