Facebook Ads与AppsFlyer的数据差异

概要:本文重点解释了Facebook Ads和AppsFlyer之间的归因模式差异。

Facebook Ads与AppsFlyer的差异

移动获客生态中的各大平台都有其独有的归因模式,AppsFlyer和Facebook也不例外。而双方归因模式的不同会使得Facebook和AppsFlyer面板中呈现的数据也有所差异。

虽然我们一直与Facebook保持紧密的合作,以尽可能地减少这样的差异,但广告主仍应了解下文所述的各种数据差异成因。

AppsFlyer与Facebook的数据差异判断方式

对比Facebook Event Manager和AppsFlyer报告中的事件,如果事件数量相差很大,说明可能存在数据差异。

归因模型的差异

原因 Facebook AppsFlyer

点击型归因窗口期

7天(请注意:某些情况下,默认窗口期会有所变化)。

1-30天。使用Facebook时,请务必将该窗口设置为7天。

浏览型归因窗口期

1天(请注意:某些情况下,默认窗口期会有所变化)。

默认情况下为1天,但可以配置为1-48小时(建议保留此默认值)

多源归因

Facebook无视其他渠道的广告互动,将激活归因给自己。

AppsFlyer使用末次点击归因(详情请见AppsFlyer归因模型 )。

跨设备归因

Facebook按用户归因,将在不同平台(iOS/安卓/PC端)上完成的点击和激活关联到相关用户。

AppsFlyer按独立设备归因,将相关互动和激活归因到完成这些操作的设备。

时区差异

Facebook Ads默认的报告时区为PST。请将Facebook Ads Manager中的时区调整到您在AppsFlyer后台应用配置中设定的时区。

AppsFlyer中默认的应用时区为UTC+0。您可以在应用配置页面中更改时区设置,使其与Facebook Ads Manager中的时区一致。

Google Install Referrer

通过Google Play Install Referrer将不带设备ID的激活归因到Facebook时,AppsFlyer不会上报给Facebook。因此,这类激活只会出现在AppsFlyer面板中,Facebook Ads中则没有相关数据,从而会导致数据差异。

深度链接再互动归因

通过深度链接促成的再互动不会上报给Facebook Ads。因此,这类激活只会出现在AppsFlyer面板中,Facebook Ads中则没有相关数据,从而会导致数据差异。

点击型和浏览型归因

AppsFlyer支持点击型归因和浏览型归因。为了尽量减少Facebook Ads和AppsFlyer之间的数据差异,请确保您在AF中设置的点击和展示回溯窗口与Facebook Ads中对应的默认窗口期保持一致。

Facebook Ads中默认的点击型回溯窗口为7天。虽然在某些情况下默认窗口期会有所不同,但仍建议您将AppsFlyer中的点击型回溯窗口设为7天,与Facebook的默认设置保持一致。

请进入Facebook后台检查Facebook中的点击和浏览型归因窗口期是否与AppsFlyer中的设置一致。建议您根据Facebook的窗口期调整AppsFlyer中的配置,使其保持一致,如下图所示:

Facebook_Discrepancies.png

 示例

假设您在AppsFlyer后台将com.greatapp应用的Facebook点击回溯窗口期设为1天,而在Facebook中该窗口期默认为7天。如果用户在Facebook中点击了Greatapp的广告,并在之后的2-7天内激活该应用,这些用户在AppsFlyer中会被记录为自然流量,而Facebook则会将其归因给自己。

媒体渠道受限导致的数据差异

到2021年10月28日为止,所有展示归因(VTA)的用户数据都呈受限状态,不向广告主开放
从2021年10月29日开始,除了展示归因外,该限制还扩展到点击归因的用户数据。汇总报告不受此限制影响。

由于Facebook Ads不发送用户级别数据,因此AppsFlyer无法将形成转化助攻的展示和点击归因到Facebook Ads。

 示例

  • 用户在Facebook上浏览并点击AwesomeApp的广告。之后该用户又在名为GreatAdNetwork的广告平台上看到并点击了AwesomeApp的广告,然后安装了该应用。
  • 由于这次转化发生在Facebook Ads的回溯窗口内,因此FB会认领该转化。
  • AppsFlyer则会将该次转化归因给GreatAdNetwork广告平台,因为该平台带来了应用激活前的最后一次广告互动。
  • AppsFlyer不会将Facebook Ads记录为助攻渠道,因为Facebook Ads的原始数据受限。


但是,对于点击归因,如果广告将用户引导到Google Play Store,则广告主可以通过Google Install Referrer获得归因数据。AppsFlyer会用Referrer中的字段填充原始数据报告并呈现给广告主,同时使用该数据对没有设备ID(即启用了LAT)的用户进行归因。

应用内事件差异

Facebook和AppsFlyer的激活后事件(如应用内购)数据中也可能出现差异。下表列出了造成这些差异的常见原因,并提供了相应的建议,帮助您尽量避免相关差异:

原因 说明 AF建议

自归因

Facebook会将事件归因到促成该事件的FB广告,而AppsFlyer会将事件归因到最初的获客渠道。

对于Facebook单方面归因给自己的激活和互动,如果其实际的末次广告互动来自其他平台,AppsFlyer就会将FB记录为助攻
您可以结合Facebook获得归因的转化数据与Facebook作为助攻的转化数据一起查看,以减少数据差异。

生命周期定义差异 Facebook将用户的生命周期界定为最长7天,也就是说,用户点击广告的7天之后发生的事件不会出现在Facebook数据中。
而AppsFlyer将Facebook用户的生命周期界定为最长180天。
对于由Facebook广告带来的用户,如需评估其在广告互动的7天之后的价值,请使用AppsFlyer的数据,更全面地了解用户价值。
未映射的事件 AppsFlyer通过SDK获取事件信息,如果您未将相关事件映射到Facebook,则AF不会向其发送这些事件。 请确保将所有代表用户质量的应用内事件都映射到Facebook
未发送的收入 AppsFlyer通过SDK获取收入信息,如果您未选择发送收入,则AF不会将其发送给Facebook。 在AF渠道对接配置的应用内事件回传部分,请务必对收入相关事件(如购买等)选择发送值与收入
Facebook数据缺少事件值 如果参数和值的结构正确,AppsFlyer就会将其作为映射事件的一部分发送给Facebook。 请根据AppsFlyer推荐的结构打点SDK应用内事件,以充分映射Facebook事件值。

为什么UA面板中会出现再营销广告带来的激活?

再营销广告的目的是让已经激活相关应用的现有用户再次打开该应用(即再互动)。另外,如果AppsFlyer识别到某设备上之前安装过该应用,则会将该次转化记录为再归因

如果Facebook向新用户再归因窗口之后重装激活应用的用户投放了再营销广告,AppsFlyer会将这些用户记录为新增激活,而在Facebook中这些用户则会出现在再营销广告下。

但如果重装激活发生在原始激活后的再归因窗口期内,AppsFlyer会将其记录为再归因,呈现在再营销面板中,而Facebook则会将其记录为新增激活。

 注意

对于再营销广告,Facebook会在同一个面板中呈现所有相关激活,而AppsFlyer则会在数据总览面板和再营销面板中分别呈现新增激活和再归因/再互动。

跨设备归因

Facebook会上报跨设备归因,因此有时广告所定向的平台(iOS/安卓)与用户最终激活的平台可能会不一致,从而造成数据差异。

 示例

Linda在她的安卓手机上点击了一则有关GreatApp应用的Facebook广告。Facebook上报Linda完成的点击,并将其记录在名为“Android Females”的原始安卓广告系列下。然后,Linda决定在她的iPad上下载GreatApp。在Linda首次打开该应用时,AppsFlyer会向Facebook查询该次iOS激活的来源,这时Facebook会回复该激活来自“Android Females”广告系列。

验证规则和Protect360

如果您启用了AppsFlyer的验证规则功能,则AF可能会按照您设定的规则拦截部分来自Facebook的激活,从而造成数据差异。在这样的情况下,Facebook会将相关激活归因给自己,而AppsFlyer则会拦截这些激活。

同理,如果您使用了AppsFlyer的Protect360防作弊解决方案,也可能会出现被FB自归因而被AF拦截的激活。

 示例

GreatApp的UA经理Jeff创建了一个名为SPNA的广告系列,定向投放到生活在北美的西班牙语用户。为了确保定向准确性,Jeff将验证规则设置为仅接受美国和加拿大的用户。
这时,某个位于西班牙的Facebook用户点击了该广告并激活应用,Facebook就会将该次激活归因给自己,而AppsFlyer则会因为该激活不符合验证规则而将其拦截下来。

SDK相关的数据差异

有些情况下,广告主会在其应用中同时接入AppsFlyer和Facebook的SDK。这会导致激活和应用内事件的数据差异,具体如下:

  • 激活:如果用户应用首次启动时Facebook Ads SDK比AppsFlyer SDK先进行初始化,那么只有Facebook Ads会记录这次激活,AppsFlyer不会记录到该激活。因此请确保应用首次启动时AppsFlyer SDK会在Facebook Ads SDK之前完成初始化。
  • 应用内事件:对于同时由Facebook SDK和AppsFlyer SDK上报的事件, Facebook不会进行去重。也就是说,Facebook可能会上报双倍的收入等事件,造成数据虚高。
    请使用以下任一方法避免Facebook Ads重复上报应用内事件: