营销渠道的高阶效果评估方法
Web端归因
Deeplink与APP端归因
Deeplink，又叫深度链接技术，是实际中是应用非常广泛的，你一定有见过，我们来看一个例子：
假设我的家人在微信上分享一个JD购入链接给我：
我在微信上点击这个链接后，会有个提示，我可以点击跳转到JD的APP：
我点击后直接跳转到这个产品的详情页面：
无缝跳转到查看的产品详情页面，这个就是Deeplink了，Deeplink有广义和狭义之分，可以分为两种，DeepLink和Deferred Deeplink，目前一般指后者。
DeepLink
DeepLink:名为“深度链接”，这是对于已经安装了APP，并把需要的参数通过URL的形式传递给App，指向特定的页面，主要就是帮助开发者实现，从外部链接到App内部页面的直接跳转，能够能高的提高用户转化率。
Deferred Deeplink
Deferred Deeplink，叫延迟深度链接，这个就增加了判断是否安装APP和匹配，当用户点击链接的时候，先判断APP是否已经安装，如果没有安装，就跳转到应用市场去下载，在这个过程中会传递设备指纹给服务器，如果用户下载完后打开，会通过设备指纹做模糊匹配，然后直接打开相应的页面；如果已经安装了APP，就直接打开APP内对应的页面。
这是一种无障碍场景还原技术，详细的如下图：
使用了深度链接后，用户操作成本明显降低了一至两步，在用户转化的漏斗中，每多一个步骤，漏斗的路径就会多一层，用户流失率也就随之增加。
要想使用这个，是需要做一些技术上的支持的，Deeplink通过Web页面直接调用Android原生app，并且把需要的参数通过URL的形式，直接传递给app。首先看这个过程涉及到哪些参与者：
广告平台：在点击这个广告的时候会有一些跳转，判断，广告平台需要支持，做一些处理才可以打开APP，比如JD能在微信上被打开，这是因为JD跟微信有合作，所以才可以实现，并不代表其他广告主也能够这样做的，比如淘宝就不能再微信上实现，所以Deeplink实现的条件之一就是广告平台要支持。
APP：app需要能够接收参数，传递给app，然后打开对应的Activity，所以第二个条件就是APP本身要支持，
比如前面JD分享的URL是：
这个页面上就有需要传递给Activity的参数ID，因为点击后到达的是该产品详情页面，所以这里的参数ID是产品ID居多。
里面UTM参数是用于归因，这个就类似web端的广告参数覆盖了，可以实现归因的，其他参数是用于分类判断统计，所以传递的参数往往不止只有参数ID，其他的参数是根据需要去传递的。
点击后先判断是否已经安装有app，如果有就直接通过参数ID去调用APP 打开页面，实现的原理就有多种了：
用Scheme是大家比较熟知的方式，不管是iOS还是Android，都可以通过Scheme去打开一个应用，这是最简单粗暴的方式，但是这种方式局限性很大，很多时候显的都不是那么直接，比如在IOS上需要点击右上角去跳转，这种体验非常差；随着系统的升级，iOS出现了Universal Link通用链接技术，如果你的App支持Universal Links，那就可以访问HTTP/HTTPS链接直接唤起APP进入具体页面，不需要其他额外判断。Android也有了App Links深度链接技术，App Links让用户在点击一个普通web链接的时候可以打开指定APP的指定页面。
Scheme：
URL Scheme的作用是打开对应的特定页面，这个是需要提前在APP端配置好的，使得app需要能够接收参数，传递给app，然后打开对应的Activity，传递的ID要跟APP的页面一一对应。
由于涉及到打开页面，那么还需要配置action和category。这样APP才能具备打开页面的能力。
前面讲到的都是Activity，都是安卓的，如果是IOS就去配置info，原理类似，平台不同。
优点：跨平台，普遍支持，开发简单。
缺点：IOS9 以前的是有一个中间提示页面的，很不友好；被部分主流平台禁止了。
Universal Link
Universal Link是苹果推出的类似深度链接的一种技术，能够方便的通过一个https链接来打开app具体页面，如果没有安装app，可以跳转到自定义地址。
App Links
点击一个链接的时候会跳转到app的指定页面，前提是这个页面要经过验证。
实现Universal Link和App Links也需要不少资源支持以及很多复杂的配置步骤，而且这两个方式是基于系统平台的，所以随着系统版本的升级配置方式是会有所不同的，一般建议直接使用第三方解决方案。
深度链接跟短链有相似之处，目前很多的的厂家都提供类似的服务，各个厂家都在建立自己的规则和生态圈，另外这个是否能够投放取决于广告平台是否支持非主域的landing作为投放页面。
这种技术通常运用于App社交分享、App广告引流、App裂变活动、Web to App、分享效果统计、沉默用户唤醒等场景，对广告引流、活动推广、新闻类、电商类、游戏类、视频直播类App的引流推广。
另一个大类的应用就是搜索引擎对app内容的索引了，搜索引擎是可以搜索web的内容，但是app的技术不同，使得搜索平台不能 索引到app的内容，应用深度链接就可以实现，但这个的跟前面的讲到的是有所不同的，因为这里是需要被搜索平台索引，所以是平台提供了一个解决方案，如谷歌App Indexing, 百度APP Link, 必应 App Linking，但目前并没有发展起来，相反部分平台后期变成打压通过搜索唤起APP的这种操作。
归因分析和实战
归因就是将转化分配到不同的渠道上去，因此归因模型，也就是分赃模型。
现在的渠道越来越多的，你可能投放了百度的SEM、今日头条的信息流，腾讯的社交广告……用户使用的设备终端越来越多，你可能在家里使用笔记本、平板、手机，在单位使用台式电脑，或是你使用两个手机……随着用户触发的渠道也越来越多，使用的设备终端越来越多，整个营销分析变得就越来越复杂,这就需要用归因模型去判断渠道的价值，从而可以分配营销资源，资源有限性使得资源的分配变得很小心翼翼，这是营销策略里很重要的一个环节，而在渠道上的分配差异则是与同行的差异所在，合理的分配可能使你企业在市场竞争中脱颖而出。
对于广告主和市场营销人员，合理的规渠道营销预算，实现ROI最大的是每个人非常关心的目标，但是面对现今复杂的营销环境，常常会有如下的一些困扰：
哪个渠道带来的用户最多？
哪个渠道的转化最好？
哪个渠道的成本最低?
KPI情况?
影响KPI最大的渠道?
如何优化渠道提升ROI?
增加或减少某一渠道的预算是否会对其他渠道产生什么影响？
这些，归因模型都可以告诉你，借助归因模型，我们可以实现：
能够将预算分配到不同的渠道去，提升ROI，这就是一个简单的最优化问题了，有限的资源在有效的渠道分配，如何使得产出最大化。
了解不同渠道的协同效应，定位助攻渠道，按漏斗的来理解就是扩大开口。
了解目标受众的习惯和行为，知道受众是通过哪些渠道触达到我们的广告的，这类受众是否具有明显的一些用户属性上的规律。
提供更加客观的理由以取得市场预算，给预算的正确提供数据依据，说服Boss给你更多的预算。
归因模型和实战
GA里面的归因模型有非常多种，分为单触点归因和多触点归因。单触电归因就是讲功能归于首个或最后一个，多触点归因就是讲功能在整个流程上的多个渠道按一定的规则或算法分配。
最终互动归因模型
最后一个渠道获得100%的转化，而不需要考虑用户之前有通过什么渠道进来过的，这种适用于转化时间间隔，转化路径比较短的业务，也就是进来就购买的。
最终非直接点击归因模型
将转化100%归功于最后一个非直接点击进入的渠道，通常直接点击所包含的具体来源的类型是非常多的，如直接点击可能来自收藏夹，直接输入，最热网页，其他难以区分的情况，因为具体的来源难以区分，所以会对数据分析产生影响，为了避免误导，所以将非直接点击排除。如果你的直接流量占比很高的话，这种模型比较实用。
最终AD点击归因
最后一个AD的点击获得100%的转化，强调AD的作用，适用于推广侧重于AD的。
首次互动归因
第一个渠道获得100%的转化，这个模型侧重于用户如何发现你的站点的，强调用户的获客，适用于品牌知名度低的。
线性归因模型
每个渠道平均分配转化，每个渠道都有相同的功劳，明显具有很大的弊端的一种模型，会造成某些渠道的作用被夸大，而某些渠道的作用被低估的。
时间衰减归因模型
越靠近转化时间的渠道的功劳越大，这个模型强调了最后一个渠道的重要性的同时没有忽略之前渠道的贡献，符合推广过程中用户会通过多个渠道进来的情形，更容易被广告主和市场人员接受。
位置归因模型
首尾贡献大，中间平分。
自定义归因模型
如果前面的模型都不适合你，你还可以根据自己的业务特征，受众去自定义符合自己的归因模型，
归因里的坑
1、没有完美的归因模型，任何模型都存在局限性和不足的，现在的营销环境越来越复杂，触发用户的终端设备越来越多，用户从第一次触发到最终做转化决策这个过程并不是模型能够完全，准确概括的。
2、归因一般跟用户识别、打通有密切的关系，通常会通过cookie的形式去是识别用户，而cookie的有效期，用户是否清除cookie，是第一方还是第三方cookie，浏览器对访客的隐私政策对归因都会重大影响。
3、基于原理与漏斗的欺诈，只要懂得归因获取数据的原理，可以研究其中的原理，利用其中的漏斗，人为的干扰归因，这是广告欺诈的一种形式，这种形式会有明显的数据特征。
跨域与跨设备归因的实现方式
跨域这里可以分为跨子域和跨主域，子域就是两个不同的二级域名之间，如ke.ichdata.com和blog.ichdata.com，这两个就是两个不同的子域名了；主语就是两个完全不同的域名了，如www.ichdata.com和www.google.com。
跨设备就是访客通过不同的设备去访问你的站点的时候，站点要能够识别出来是同一个人，这里的跨设备还可以衍生出一种情况，跨浏览器，这种形式也是类似同理的。比如我在早上通过Chrome浏览器访问ke.ichdata.com，下午通过手机访问，我们希望能够识别出是通过一个用户。
要能正确的归因，首先要能识别出是同一个用户。
在跨子域上
如果你使用analytics.js,这个已经默认开启了跨子域跟踪的，直接使用即可，如：
如果你是做GTM管理的，直接配置cookieDomain就行了，这个是允许子域公用cookie，从而可以识别同一用户，如：
上面两种方法都是实现同样的作用，接下来就是引荐流量排除了，是访客在子域跳转的时候还是公用原来的会话，配置
一个用户访问：blog.ichdata.com 然后访问：new.ichdata.com 最后访问:blog.ichdata.com
如果没有设置cookie domain和引荐流量没有设置，会记录2个用户，3个会话 如果设置了cookie domain，但没有设置引荐流量，会记录1个用户，3个会话 如果cookie domain和引荐流量都设置了，会记录1个用户，1个会话
在跨主域上（也就是跨站）
原理：每个站点对应一个GTM容器，每个站点在GTM都做同样配置，将不同站点的数据向同一个GA-view发送，Tag中的allowLinker和cookieDomain是解决不同站点同一用户的识别问题，用户在跨站的时候将用户唯一标示clientid传递到另一个站点公用，从而解决跨站用户唯一性的问题。
设置代码，重点在Tag的设置，CookieDomain是不同站点传递在cookie传递值，allowLinker是传递用户唯一标示符。
注意：跟踪器一定要设置跟原来单站不同的，确保跨站传输数据一致
更为详细的教程请看：https://www.ichdata.com/using-gtn-to-do-cross-site-tracking.html
在跨设备上
跨设备跟踪上目前有两种方式，一种是用UserID，一种是用Google Signals,UserID的缺点只有访客登录的才会被记录关联得到，Google Signals这种是运用谷歌的算法和标识的，对此我们不知道谁跨设备了。
UserID实现详细可以看：https://www.ichdata.com/using-gtn-to-do-cross-site-tracking.html
Google Signals实现详细可以看：https://www.ichdata.com/detailed-explanation-of-the-new-cross-device-reporting-function-in-google-analytics.html
Last updated
