概要:通过AppsFlyer归因模型,我们能判断哪些媒体渠道有效促成了拉新或促活,并将相关的激活或互动行为归因给这些渠道。
什么是归因?
归因用于判断是什么原因促使用户下载应用,或在激活应用后进行各种操作(如再次打开或重新安装)。归因结果分为以下两种:
- 非自然流量:用户与媒体渠道进行了互动(通常通过展示或点击来完成)
- 自然流量:用户没有与媒体渠道进行互动。请注意:为了便于理解,我们经常会使用“该用户被归因为自然流量”这样的表达,但是严格来说这种说法是不准确的,因为自然流量不会被归因。
归因能极大地推动拉新和促活的优化,并提升优化效果。
提示
如需进一步了解归因,我们在AppsFlyer充电站里为您准备了相关课程,视频虽短,但干货满满!
如何计算一次激活?
归因模型是由一系列规则组成的,用于判断转化路径中的哪些营销触点促成了哪些事件。应用营销生态中的每一个参与方,不管是Google Play、App Store、CTV平台,还是Meta ads和Twitter等广告平台,亦或移动度量供应商,他们各自都有自己的归因模型,每个模型对于激活和事件的计算方式都有所不同。
但归因的关键并不在于这些模型间的差异,而在于其规则是否清晰明确、公平公正,以及是否能帮助广告主优化他们的广告计划并比较不同渠道的用户质量。
了解合作方所使用的模型和规则至关重要,特别是要理清适用于AppsFlyer的模型和各种方法之间的细微区别。
根据AppsFlyer的归因模型,可归因事件需符合以下条件:
- 在拉新获客场景中:用户下载并启动应用后,AppsFlyer将该行为计为激活并进行归因。也就是说,AppsFlyer将应用首次启动的时间点计为激活时间戳,这样的设定与广告平台或应用商店有所不同,前者按用户与广告互动的时间计算,后者则按用户下载应用的时间计算。
- 在再营销场景中:
- 再互动(唤醒沉睡用户)
- 再归因(召回流失用户)
归因方法
AppsFlyer使用以下各种方法进行归因:
方法 | 使用ID | 技术 |
归因方 |
安卓(1)
|
iOS | Windows Universal Platform | CTV及游戏平台(3) |
---|---|---|---|---|---|---|---|
Referrer归因 | 是 | 确定性匹配 | AppsFlyer | 是(2) | 否 | 是 | 否 |
设备ID匹配 | 是 | 确定性匹配 | AppsFlyer | 是 | 是 | 是 | 是 |
概率匹配模型 | 否 | 概率匹配 | AppsFlyer | 是 | 是 | 否 | 是 |
数据汇总归因(AAP) | 否 | 数据汇总 | AppsFlyer | 否 | 是 | 否 | 否 |
预装推广 | 否 | 确定性匹配 | AppsFlyer | 是 | 否 | 是 | 否 |
SKAdNetwork(SKAN) | 否 | 确定性匹配 | 苹果 | 否 | 是 | 否 | 否 |
苹果搜索广告 | 是 | 确定性匹配 | 苹果 | 否 | 是 | 否 | 否 |
深度链接 | 否 | 确定性匹配 | AppsFlyer | 是 | 是 | 是 | 否 |
(1)Google Play和第三方商店 (2)第三方商店可用 (3)参见CTV及游戏平台完整列表 |
|
下图展示了Appsflyer的归因优先级。如果在一个新增激活前发生了多个有效互动,AppsFlyer会把该激活优先归因到点击,其次是展示;并会优先使用确定性归因,其次是概率匹配。
以下内容详细阐释了AppsFlyer的各个归因模型。
Referrer归因(安装引荐来源 ,仅限安卓)
从Google Play及部分其他应用商店下载的安卓应用一般可以通过Install Referrer来归因。用户在点击广告链接后跳转到安卓商店,Referrer就会记录该链接的原始URL。这是安卓系统中的主要归因方法。目前Google Play、华为应用商店、三星盖乐世商店和小米GetApps应用商店都支持激活referrer归因。如需了解支持referrer归因的第三方应用商店,请参考此文档。
设备ID匹配
广告平台可以读取用户的设备信息,并在用户点击广告链接或浏览广告时将设备ID发送给AppsFlyer。这样,AppsFlyer就能将发生广告互动的设备ID与AppsFlyer SDK获取的设备ID进行匹配。
设备ID匹配是iOS系统中的主要归因方法。
可用于匹配的ID有以下几种:
- iOS设备:IDFA、IDFV
- 支持Google Play服务的安卓设备:GAID
- 不支持Google Play服务的安卓设备:OAID、Android ID、IMEI、Fire ID
设备ID可以使用归因链接上的SHA1或MD5进行加密处理。
使用IDFV(iOS)进行设备ID匹配
- 对于操作系统为iOS 6.0及以上的设备,我们可以读取其供应商标识符(IDFV),且不受Apple的ATTrackingManager(应用跟踪透明度框架)和LAT(限制广告跟踪)机制的影响。广告主可以通过IDFV来交叉推广旗下的不同应用。
- AppsFlyer SDK默认收集IDFV。
- 根据Apple的说法,只要是来自同一家供应商的应用,它们在同一台设备上的IDFV值都是一样的。
- 当用户第一次激活某个厂商的应用时,Apple就会生成一个对应的IDFV。也就是说,Apple会检查设备上是否有来自同一家厂商的其他应用程序。因此,如果用户删除了某厂商旗下的所有应用程序之后再下载并激活该厂商的产品,Apple就会生成一个新的IDFV。
- 由于IDFV能改善归因效果,因此如果条件允许,请务必发送IDFV。我们会在以下场景中用到IDFV:
- 交叉推广归因。
- 同一设备上的卸载重装归因。
- 原始数据报告。
- 受众定向。
自归因平台的设备ID匹配
首次启动应用程序时,AppsFlyer会检查应用程序设置,判断是否有来自自归因平台(SRN)(例如Meta ads、Snapchat和Google Ads)的流量。
AppsFlyer会使用新增激活的唯一设备ID去查询该应用配置的所有自归因平台(SRN)。这是通过SRN授权AppsFlyer使用的MMP (移动监测合作伙伴) API完成的。根据返回的结果, AppsFlyer可以将新增激活归因给相应的SRN。
概率匹配模型
概率匹配模型是一种利用机器学习来预估广告活动效果的统计技术,能够对以下两种数据进行匹配:
- 用户点击或浏览广告时收集到的数据(前提是概率匹配功能已启用)
- 用户打开应用时收集到的数据
iOS应用的注意事项:
从iOS 14.5+开始,概率匹配模型仅限于自有媒体、交叉推广和网页到端的授权匹配。在其他情况下则会使用Aggregated Advanced Privacy(汇总层级的高级隐私保护,即AAP归因模型)。
功能特点
- 使用统计学原理,而不是通过唯一ID进行匹配。
- 概率匹配是一种备选方案,在追踪码或广告标识符不可用时帮助我们进行归因。由于确定性归因法可以把点击行为匹配到追踪码或ID,因此具有更高的优先级。也就是说,在归因窗口期内,如果条件允许,我们会先使用确定性归因法。
- AppsFlyer会根据用户广告平台来动态地调整归因窗口期。也就是说这个窗口期是会自动变化的,但比其他方法的窗口期要短(最多24小时)。
- 点击型概率匹配功能是默认开启的。
- 浏览型概率匹配功能需要在应用程序设置页面和非SRN对接页面中开启。对于CTV和游戏应用,该功能默认开启。
数据汇总归因(AAP)
我们基于汇总层级的高级隐私保护(Aggregated Advanced Privacy,简称AAP)逻辑,以汇总的方式呈现广告活动的效果数据,彻底阻断任何形式的跨设备跨平台跟踪,以及精确到用户或设备的识别能力。
AAP将Apple SKAdNetwork作为隐私保护的最低标准。除自有媒体和ATT授权用户等Apple明确允许追踪的情况外,AAP是iOS 14.5+设备上的默认归因模型。
与其他归因方法不同,AAP机器学习算法的目标是更准确地通过数据汇总归因来衡量投放效果,而不是匹配到终端用户。
预装广告
在预装广告场景中,预装渠道在设备出厂或激活时就将应用安装在设备上。预装渠道包括以下几种:
- 原始设备制造商(OEM)
- 应用探索平台
- 移动运营商
预装广告的归因方式有以下三种:
AppsFlyer预装来源referrer归因方案能够呈现并衡量设备初次激活以及应用首次打开的数据以及两者之间的差别。该方案会记录带有渠道预装应用的设备激活量,以及该预装应用的首次打开数据,AppsFlyer通过这些数据就能将这类用户归因到相应的预装渠道。
另两种归因方式仅在应用首次打开后判定归因结果,而没有首次打开前的预装设备数据。
广告主可以同时使用以上三种方式,不会造成彼此干扰。
下表说明了各预装归因方式在原始数据报告中的区别:
预装归因方式 | 原始数据报告中的Match_type |
---|---|
AppsFlyer的历史预装归因机制(通过系统属性文档、manifest中的名称等归因) | preload_conf |
Google Play Auto-install(PAI)云预装归因 | preload_pai |
AppsFlyer预装来源referrer归因 | preload_rfr |
AppsFlyer安装来源referrer(点击下载)归因 | af_referrer 用户通过推送通知、第三方应用商店等在设备激活后较长的一段时间内安装应用 |
请注意:该过程可能需要数天或数周,即从用户首次启动设备开始,直到他们首次打开预装应用为止。因此预装广告在AppsFlyer判定归因结果时的优先级最高,且回溯窗口也更长。
深度链接
仅用于再互动,即不需要让用户跳转到应用商店下载应用,因此URL中的信息可以直接关联到点击(以及后续的应用打开)。我们将这种归因方式称为深度链接,这是因为用于归因再互动的信息是通过深度链接URL传递的。
按渠道类型梳理的归因方法和AF功能
在下面的章节中,我们按以下三个纬度详细剖析了各种归因方法的适配情况:
- 媒体渠道:自有或付费
- 所使用的AppsFlyer功能
- 用户设备:安卓或iOS
自有媒体
媒体渠道 | 功能 | 归因方法 | |
---|---|---|---|
Android | iOS | ||
自有媒体:电子邮件(包括ESP)、短信、社交媒体帖子、网红/联盟营销、平面媒体等 | OneLink |
|
概率匹配模型 |
有付费或自然流量的自有移动网站/落地页 | 智能横幅 | 概率匹配模型 | 概率匹配模型 |
OneLink 智能脚本 |
|
概率匹配模型 | |
自有移动应用 | 用户邀请/引荐 |
概率匹配模型 |
概率匹配模型 |
交叉推广 | 设备ID匹配 | 设备ID匹配 |
用户互动归因类型
我们通过设备ID匹配和概率匹配技术,将点击和浏览行为归因到媒体渠道。
点击型归因
广告点击行为是大多数激活的来源,这些广告包括横幅、视频和插屏等样式。
用户点击广告后触发回溯,窗口期默认为7天。在回溯窗口期内发生的激活将作为非自然流量归因到媒体渠道。在窗口期之后发生的激活则视为自然流量,也就是我们常说的“归因到自然流量(organically attributed)”。
- 点击型归因的回溯窗口一般是七天,您也可以根据您和渠道之间的协议来自行调整窗口期的时长。
- 您在AppsFlyer中设置的SRN回溯窗口需要与SRN本身的回溯窗口保持一致。
归因触点类型 |
归因方法 |
范围 |
默认 |
---|---|---|---|
点击归因 (所有已对接渠道)
|
Referrer、ID匹配 |
1–30天 |
7天 |
概率匹配模型 |
0–24小时 |
|
相关文章:回溯窗口
浏览型归因
我们也可以对仅浏览而未点击广告的用户进行归因,把他们匹配到该广告的投放平台。
浏览型归因的回溯窗口:
- 比点击归因的时间短
- 可自行调整。
要启用浏览型归因,请在配置窗口中设置归因回溯窗口期。
这类归因不仅对视频广告点击率较低的视频广告平台非常有利,投放常规广告的传统广告平台也能从中受益。
归因触点类型 |
归因方法 |
范围 |
默认 |
---|---|---|---|
浏览型归因
|
ID匹配 |
0–24小时 |
1天 |
概率匹配模型 |
0-24小时 |
|
在既有点击也有浏览的情况下, 总是优先归因到点击 ,因为点击是更为主动的互动行为。
相关阅读:浏览型归因
高级归因话题
应用内事件
对于每一个带有归因信息的应用激活,AppsFlyer会为其创建一个专属的AppsFlyer ID。这样,AF就能将应用内事件归因到最初带来该激活的媒体渠道。广告主可以使用该信息在相关应用原始数据的基础上追溯用户链路。
如需进一步了解事件归因,请查看此文档。
助攻激活
AppsFlyer会根据激活前的最后一次广告点击或广告展示(若无点击),把激活一对一地归因到渠道。
在助攻激活(即多触点归因)场景中,渠道/广告在归因窗口内触达了用户,但该触点不是用户激活前的最后一次互动行为,我们将这样的情况视为间接促成激活的“助攻”。
AppsFlyer会将这些形成助攻的渠道作为促成激活的辅助方记录激活报告中。
请点击此链接查看详情。
重装激活
如果用户在激活应用后,将其卸载再重新激活,AppsFlyer就会将该行为视为重装激活。AF会根据再归因窗口期对其进行界定,逻辑如下:
- 如果重装激活发生在窗口期之后,AppsFlyer会将其计为新增激活。
- 如果重装激活发生在窗口期内,则分以下两种情况:
如需进行设备测试和多次激活,请在AppsFlyer系统中为相关设备加白。对于未加白的设备,AF仅记录第一次激活。
请注意:AppsFlyer可以对没有设备ID的iOS重装激活进行更准确的归因,但需要您在AF后台的应用配置页中打开这个功能。
重新激活在iCloud中备份过的iOS应用
如果用户在iCloud上备份了一个应用,之后再从备份中恢复该应用(不管是否恢复到同一台设备上),AppsFlyer都不会将其作为新增激活或重装激活。在该场景中,用户的AppsFlyer ID和归因数据保持不变。
再营销归因
应用更新
- 在存量用户更新应用版本的场景中,如果AppsFlyer此前已归因过该用户,则不会再对该行为进行归因。请注意:如果您从其他MMP迁移到AppsFlyer,那么在迁移完成后,存量用户第一次打开应用时,AF会将其归因为自然流量。
- 您可在SDK信息面板中查看按应用版本细分的用户数量指标。