简介
您觉得在AppsFlyer后台配置Facebook广告追踪需要多久？
如果您的app已经集成了Appsflyer SDK并且在Facebook Ads里添加了您的app，那么您只需要不到一分钟！
实现Appsflyer对Facebook广告的追踪，不需要操作Facebook Login或集成Facebook SDK。只需要按照以下步骤操作即可。
Facebook App ID
但首先，如果您还没有在Facebook for developers里面添加您的应用，请按照以下步骤创建Facebook app ID:
- 登陆Facebook的 App Dashboard
- 在Apps下点击 Create New App
- 填写您App的名称，以及一个唯一的namespace
追踪Facebook广告基本设置
使用Appsflyer追踪Facebook广告，请请按照以下步骤配置：
- 当您在Facebook添加app时，会得到一个唯一的Facebook App ID。
复制Facebook App ID并切换到AppsFlyer后台。
- 点击左侧导航栏里的Integrated Partners(媒体平台配置)。
- 搜索“Facebook”，点击logo打开Facebook配置页面。
- 在Integration标签页内Facebook App ID栏里将之前得到的ID粘贴进去。
-
将 Enable Retargeting 按钮 打开 并设置Re-Engagement Window(再互动类型广告的归因窗口期，即应用内事件归因给再营销广告的时长)。 您可以分别按“天”设置 (1-90天)，按“小时”设置hours (至多23小时)，甚至总生命周期长：
-
我们建议将 Click-Through（点击） 归因窗口期保持在 28天以保持和Facebook一致:
- 我们建议将 View-Through（展示） 归因窗口期保持在1天, 依然是为了和Facebook保持一致：
- 点击 保存并关闭此页。
祝贺您！您已经完成了AppsFlyer追踪Facebook广告的基本配置！
(在AppsFlyer后台仍未看到来自Facebook的广告追踪结果？点击 此处)
Facebook广告追踪高级设置
当完成以上基本设置，您可以进一步了解以下高级设置。
设备层级数据
Facebook默认不会公布用户层级的原始数据。
点击配置按钮 (或 here) 点击接受Facebook的 Terms of Service（服务协议）. 这一步将准许AppsFlyer收集并给您开放Facebook的设备层级原始数据。
应用内事件匹配
- 将按钮 In-App Event Postbacks（应用内事件回传）打开
- Sending Option（发送数据选项）中的for all SDK defined events（针对SDK集成中埋点的所有事件）是 归因给所有广告平台及Organic的事件, 即您会给Facebook开放发送应用的所有用户数据。
- 点击Add Event（添加事件）给事件列表里添加SDK事件
- 填写以下参数：
| Parameter Name参数名称 | Description描述 |
|---|---|
| SDK Event Name SDK事件名称 | Appsflyer通过SDK集成或Server to Server的方式接收到的应用内事件的名称。 提示 - 在列表上没有看到您想要添加的事件? 请确认这个事件被一个非自然激活的设备触发过，确认之后再查看列表。 |
| Partner Event Identifier广告平台方事件标志 | 给您的事件选择最恰当的Facebook端默认事件名称。您也可以选择FacebookCUSTOM（自定义）事件。 |
| Send Revenue发送收入数据 | 如果未被勾选 - AppsFlyer 会将除了收入参数（由af_revenue 参数定义）以外的所有其他参数发给广告平台。 如果勾选了 - AppsFlyer 将会给广告平台发送这个事件下的所有参数包括收入参数（如果有收集）。 |
如需了解更多关于Facebook应用内事件匹配的信息，请点击 此处.
再营销归因
Appsflyer对Facebook的再营销归因，使广告主能够通过AppsFlyer的相关后台数据，将广告产生的互动行为合理归因，衡量用户的质量及post的效果。
Cost（成本）, Clicks（点击）和Impressions（展示） 数据
同步 Facebook Cost（花费数据） 功能不仅能让您获取Facebook在广告计划，广告组和创意层级的花费数据，还能获取集成的广告点击和展示数据。
- 确保您登陆的Facebook个人账户拥有对应Facebook账户的操作权限。登陆的用户必须拥有Facebook Business Manager的全部广告计划的投放权限。
- 来到 Data Enrichment 标签页
- 点击Facebook Login按钮
- 当提示页面展示后，允许AppsFlyer获取Facebook广告计划的数据。
注意
如果您拥有多个Facebook账户权限的个人账号，建议将所有的账户都通过以上的“Facebook Login”登陆，以防止数据关联不完整。
如需了解更多的关于Facebook的花费，点击和展示数据的信息，请点击 此处。
Ad Revenue Tracking
如果您的应用在使用Facebook Audience Network Ad Revenue来实现广告变现，那您可以在Appsflyer上追踪Facebook广告变现收入数据。无论有无内购事件，这将给您提供 完整的用户收入数据。
开始追踪 Facebook Audience Network Ad Revenue：
- 在 Data Enrichment 标签页将Get Ad Revenue Data打开。
- 在Event Source处配置对应的广告变现应用内事件。举例说，如果您的广告变现收入基于展示，建议将其设置为一个与广告展示相关的事件。对于每一个变现平台都可以单独设定一个最合适的事件源。此外，您还可以使用
af_app_opened事件来定义。这样广告收入就被归因给了每一次应用打开。 - 该Ad Revenue 广告变现事件会随后展示。这将是一个可读事件，名称为[source event]_monetized（例如上文中展示的Ad_Watched_Monetized）。广告变现收入事件在控制面板里展现为一个附加的事件。
- 点击 Facebook Ad Revenue 以开启收集Facebook Audience Network Ad Revenue on Facebook数据。登陆您的Facebook账户以授权”Facebook Audience Network Ad Revenue“。
- 点击 保存并关闭该页面。
Facebook应用内事件匹配
Advertisers can easily map their in-app events, SDK or S2S, to Facebook's pre-defined events.广告主可以通过SDK或者S2S的方式轻松地将埋点的应用类事件和Facebook预定义事件相匹配。
这样广告主就能运用Facebook的高级优化功能，并建立自定义受众与相似受众（Custom and Lookalike Audience ）功能。
自定义应用内事件匹配
AppsFlyer允许广告主通过Facebook Event Identifier里的“CUSTOM”选项将任意自定义应用内事件发送给Facebook。
通过SDK配置的事件名称和事件值（包括事件的参数）将会原封不动地发送给Facebook。
注意
将SDK事件与相应的Partner Event Identifier（渠道方事件标志）匹配，对于使用Facebook的App Event Optimization、Value-Based Optimization或Dynamic Product Ads等功能至关重要。
匹配为“CUSTOM”的事件无法用于优化。
如需了解更多的关于富应用类事件及其参数要求，请查阅 这篇文档。
Custom事件参数自动匹配
通过Appsflyer和Facebook的深度对接，Appsflyer端埋点的标准SDK事件参数都会自动与Facebook预先定义好的参数匹配。例如， Appsflyer的af_revenue参数会被转化为Facebook端的 valueToSum 参数。 如此一来，带有revenue参数的事件就能在Facebook上监测并优化。
下表罗列了所有通过Custom渠道方事件标志的方式匹配，并且自动发送给Facebook的Appsflyer事件参数。
| AppsFlyer Parameter（AppsFlyer参数） | Facebook Parameter（Facebook参数） |
|---|---|
| af_city | fb_city |
| af_class | fb_travel_class |
| af_content_id | fb_content_id |
| af_content_list | fb_content_id |
| af_content_type | fb_content_type |
| af_country | fb_country |
| af_currency | fb_currency |
| af_date_a | fb_checkin_date |
| af_date_b | fb_checkout_date |
| af_departing_arrival_date | fb_departing_arrival_date |
| af_departing_departure_date | fb_departing_departure_date |
| af_description | fb_description |
| af_destination_a | fb_origin_airport |
| af_destination_b | fb_destination_airport |
| af_destination_list | fb_destination_ids |
| af_hotel_score | fb_hotel_score |
| af_level | fb_level |
| af_max_rating_value | fb_max_rating_value |
| af_num_adults | fb_num_adults |
| af_num_children | fb_num_children |
| af_num_infants | fb_num_infants |
| af_order_id | fb_order_id |
| af_payment_info_available | fb_payment_info_available |
| af_preferred_neighborhoods | fb_preferred_neighborhoods |
| af_preferred_num_stops | fb_preferred_num_stops |
| af_preferred_price_range | fb_preferred_price_range |
| af_preferred_star_ratings | fb_preferred_star_ratings |
| af_price | fb_price |
| af_quantity | fb_num_items |
| af_region | fb_region |
| af_registration_method | fb_registration_method |
| af_returning_arrival_date | fb_returning_arrival_date |
| af_returning_departure_date | fb_returning_departure_date |
| af_revenue | _valueToSum |
| af_search_string | fb_search_string |
| af_success | fb_success |
| af_suggested_destinations | fb_suggested_destinations |
| af_suggested_hotels | fb_suggested_hotels |
| af_travel_end | fb_travel_end |
| af_travel_start | fb_travel_start |
| af_user_score | fb_user_score |
事件和参数的限制
关于发送的事件数据 Facebook附加了一些限制：
- 一个事件最多只能含有25个参数。
- 事件名称和参数名称的字符数必须在2到40个之间，并且有且只能包含字母和数字字符，下划线，连字符或空格。
- 参数值的长度不得超过100个字符。
- Appsflyer的事件名称可以和Facebook的事件名称一样（如，fb_price），但是名称一样的事件不能通过Custom的方式发送给Facebook。不用同样的名称是比较保险的方式。
注意
除了以上的参数，Appsflyer会将Custom事件 原封不动 发送给Facebook。移动应用的拥有者需要确保Appsflyer的事件是否符合Facebook的要求。
Facebook资源渠道
您可以看到Facebook的广告计划、广告组、广告创意维度的数据，也可以看到Facebook资源渠道维度的数据。
- Facebook channel - 来自Facebook移动端应用的用户
- Instagram - 来自Instagram移动端应用的用户
- Messenger - 来自Messenger移动端应用的用户
- AudienceNetwork - 来自Facebook网盟应用的用户
通过这个纬度的数据，您可以比较Facebook的不同资源渠道的用户的质量。
Facebook和代理
代理商和FMPs可以在Appsflyer上代表广告主投放和追踪广告，或者与广告主的Facebook广告一起投放。为了让代理投放的广告会被正确归因给代理，campaign名称必须以代理在AppsFlyer的命名开头。
如需了解更多关于代理和Facebook安装激活追踪的信息，请点击此处。
另外，代理商不能更改Facebook的归因窗口、开关再营销广告。. 但如有需要，代理可以请广告主进行修改配置。
此外，代理无法修改回传给Facebook的应用内事件。因为Facebook针对应用内事件回传的要求是获得所有安装激活的数据信息，包含非Facebook来源的用户（这部分用户有可能不是该代理投放的流量）。
下图展示了广告主给代理授权的所需步骤：
追踪非Google Play商店Android应用的Facebook广告
Facebook暂不支持为非Google Play商店Android应用创建新用户获取广告计划，例如，百度商店。
但您可以按照以下步骤投放并追踪非Google Play商店的Android app：
- 开发者需要为每一个第三方安卓应用商店分别准备单独的APK。了解更多详情 ，请点击此处。
- 在Facebook上创建"Link click"类型的广告计划，该广告会将用户带到一个落地页。
- 落地页需包含"安装应用"的按钮，该按钮背后需包含一条AppsFlyer自定义追踪链接
。该链接必须包含落地页再跳转参数，af_r。 - 用户点击“安装应用”按钮后会被带到第三方应用商店，下载激活应用后会被归因。
提示
因为在移动网页上无法获取用户的设备ID，AppsFlyer会使用 fingerprinting 方式来完成归因。
如需了解如何在Facebook追踪亚马逊商店应用的细节指导，请点击的 此处。
Facebook花费
获取Facebook花费 (包括点击和展示)数据操作起来超级简单，但仍会有写问题被广告主频繁问及。
你会在下文看到最常被问起的关于Facebook花费关联功能的问题、相关解释及示例。
注意
一旦您配置好了Facebook花费，请勿改变Facebook广告计划、广告组、广告创意的名称，否则有可能会造成非常严重的数据差异或数据丢失。
Facebook花费常见问题
当您用以上提到的方式第一次以Facebook Admin身份登陆时，Appsflyer最多只能收到过去30天的Facebook花费数据。更早之前的花费数据不会显示。
这里的花费，点击，展示数据是指以Admin获取数据前30天至少发生过一个转化的所有的广告计划。
Facebook每过几个月可能就会重置花费数据的授权状态。如果您发现花费数据在AppsFlyer控制面板中停止展示，请重新以Facebook Admin登陆配置。
如果Facebook Admin账户更改了登陆密码，那您必须重新登陆配置。
AppsFlyer每隔几个小时会Facebook拿到整合的点击，展示和花费数据。所以，您的点击行为可能需要几个小时后才能显示在AppsFlyer后台。
因为Appsflyer仅仅得到整合的Facebook的点击和展示数据，因此，完整的点击、展示原始数据无法在AppsFlyer获取。而原始数据报告里的点击和展示数据是最终带来新增激活的点击和展示。
如果您在AppsFlyer后台用Geo分组(Group By)展示数据，可以获得所有国家的整体花费数据，但如果您在国家(Geo)栏单独选择了某一个国家，则无法显示花费。
Facebook和AppsFlyer在归因模型上有若干内在差异，这就导致了Facebook和AppsFlyer后台呈现花费数据的差异：
- Facebook的跨设备归因 - 有时这一点会导致广告计划的点击来自某一种设备系统(iOS/Android)，而花费数据来自另外一种设备系统。
- Facebook的非移动广告计划(non-mobile campaigns)- 在这些广告计划，类似于Facebook的链接点击广告计划，(link click campaigns)，电脑端用户最终或许会下载移动应用。对于这类跨设备广告计划，AppsFlyer不会展示花费数据，然而，如果点击和激活是被同一台设备触发，AppsFlyer则会收到相关的花费数据。
例如，一个电脑端用户在Facebook点击了一个广告被带到了落地页，一周后，这个用户在自己的iPhone设备上下载了这个iOS应用，虽然这个安装激活被AppsFlyer归因并展示，但这个跨设备的的安装的花费数据并不会展示。 - 过去7天没有产生任何转化的广告计划 - AppsFlyer只会同步过去7天有转化的广告计划的花费数据。 如果您刚刚配置获取Facebook花费数据，而某些广告计划在过去7天甚至更久都不是“活跃”状态，则不会展示花费数据。
单个用户获取成本是花费除以安装数得出的结果。因为 AppsFlyer和Facebook在安装激活的归因不同，平均单个用户获取成本则不同
尽管Facebook Business Manager里同时给若干个Facebook用户授权投放广告，也只需要其中一个用户来执行花费数据关联的操作。
但是，如果这个执行的用户只有部分Facebook广告计划的投放权限，那剩下没有权限的广告计划的点击、展示、花费数据则无法展示在AppsFlyer后台。
目前只有Facebook的新用户获取类广告的花费数据能够在AppsFlyer后台同步，再营销广告还不可以哦。
如果您浏览器里此刻登陆的Facebook用户曾经操作过登陆步骤，这个页面会直接关联到您的Facebook账号。如果您需要用不同的Facebook执行登陆操作，请先登出(log out)您浏览器此刻登陆的Facebook账户，刷新AppsFlyer Facebook配置页面后重新操作。
和AppsFlyer数据划分逻辑不同， Facebook端无法区分普通安卓应用和亚马逊应用（虽同样基于安卓应用）的花费数据。
因此，亚马逊商店用户的花费数据可能被划分到普通安卓应用广告计划的用户上。
Facebook花费示例
A.Flyer先生是一位广告主。
在3月27日--4月3日期间，他在Facebook上投放了两个新用户获取类型的广告计划。
广告计划 A: UK_Female_30:
花费: $1000 (Facebook提供的广告计划总花费)
平均单个获客成本eCPI: $1,000 / 400 (广告计划带来的总激活数) = $2.5
广告计划 B: US_Male_30:
花费: $500
平均单个获客成本eCPI: $500 / 100 (广告计划带来的总激活数) = $5
根据以上图表, A.Flyer先生的Facebook花费是以广告计划为维度计算的。
默认情况下，在集成报告里您能看到Facebook所有广告系列的花费总数据：
根据以上图表, A.Flyer先生的Facebook总花费是按照以下方式计算的：
所有Facebook广告计划:
总花费: $1,000 + $500 = $1,500 (Facebook提供的广告计划总花费)
总安装激活量: 400 + 100 = 500
平均单个获客成本eCPI: $1,500 / 500 = $3 (平均单个获客成本eCPI是在当天结束时计算每一个广告计划/广告组/广告创意的数据)。
Facebook和AppsFlyer的数据差异
作为移动用户获取生态圈里的两大重要主体，AppsFlyer和Facebook在归因模式方面有不同的地方。这可能会导致Facebook和AppsFlyer后台数据显示的差异。
尽管我们在和Facebook一起努力将差异降到最小，但广告主仍需要该注意以下几种可能造成差异的原因。
归因模型的不同
| 原因 | AppsFlyer | |
|---|---|---|
|
点击归因窗口 |
默认28天，但广告主可自行调整为1-30天 |
|
|
展示归因窗口 |
1 day |
默认1天,但可调整为1-48个小时 |
|
安装激活记录日期 |
Facebook将安装记录在广告点击发生的当天。 |
AppsFlyer将安装记录在应用首次激活的当天。 |
|
多渠道来源 |
Facebook无法得知其他广告平台的广告来源且只做自归因 |
AppsFlyer归因给最后一次有效点击 (如需了解更多关于AppsFlyer归因的信息，请点击 此处) |
|
跨设备归因 |
Facebook基于“Facebook用户”来归因，用户在不同设备（安卓，iOS，网页端等）发生了点击并安装应用，Facebook最终都会归因。 |
AppsFlyer基于“唯一设备”归因, 该设备同时观看/点击了广告，之后下载激活了应用，AppsFlyer才会归因。 |
点击和展示归因
AppsFlyer同时支持点击和点击和展示归因。减少Facebook和AppsFlyer的数据差异，请确保AppsFlyer后台点击和展示归因窗口时间和Facebook一致。
您可以在Facebook上找到相应的页面来和AppsFlyer比较点击和展示归因窗口。我们推荐您根据下图将AppsFlyer的归因窗口和Facebook的保持一致：
示例
假设您的应用 com.greatapp在AppsFlyer上Facebook点击归因窗口是7天，但是Facebook的默认归因窗口是28天。那么那些点击了greatapp的Facebook广告，但在8-28天之后才首次打开应用的用户会被AppsFlyer归为自然用户，但是Facebook却会把他们归为Facebook带来的用户。
应用内事件差异
两边平台的差异还会发生在AppsFlyer和Facebook后台展示的应用内事件中(例如: 应用内购买)。下表描述了最常见的差异原因以及如何缩小差异：
| 原因 | 描述 | AppsFlyer的建议 |
|---|---|---|
|
安装数据差异 |
AppsFlyer和Facebook针对某些用户的安装归因结果不同，那么这个用户后续触发的事件, 会有不同的归因结果。 |
缩小安装的数据差异则可以缩小相关应用内事件数据的差异。 |
| 用户生命周期定义的不同 | Facebook的用户生命周期是28天，意味着如果广告点击超过28天后的触发的事件Facebook就不会显示了。 而Appsflyer的Facebook用户生命周期是180天。 |
如果您需要评估Facebook用户超过一个月的价值，使用AppsFlyer的数据相对更加全面。 |
| 未匹配事件 | AppsFlyer通过SDK获取原始的事件，但这些事件默认条件下不会自动匹配到Facebook后台，因而也不会发送给Facebook。 | 确保将所有表明用户质量的应用内事件传给Facebook（请参考下面的截图）。 |
| 收入金额未发送 | AppsFlyer通过SDK获取原始的收入数据，但不会自动发送给Facebook。 | 确保将应用内事件回传页面的Send Revenue栏勾选上，例如下图的购买事件示例。 |
| Facebook后台缺少事件值 | 在事件集成正确的前提下，如果完成了事件匹配，AppsFlyer会将所有参数和值发送给Facebook。 | 根据 AppsFlyer推荐的参数结构 来完成应用内事件埋点以确保时间的所有值都可以发送给Facebook。 |
为什么在新用户获取的后台能看到再营销广告计划的数据？
一个再营销广告计划会使老用户再次打开手机里已经激活过的应用，让用户(再互动(re-engagement))。然而，当AppsFlyer识别出这个设备曾经下载激活过该应用，再营销广告让这个已经卸载应用的用户重新下载激活，那么这个转化会被归因为重装(re-attribution)。
但如果, 在一个再营销广告计划中, Facebook将新用户 或早于 设置的重归因窗口的卸载用户 re-attribution window定位目标受众，那么用户在下载激活后，会被AppsFlyer判定为新获取的用户, 尽管这是一个再营销广告系列。
但如果卸载重装的用户，重装距离首次安装的时间间隔在设定的重归因窗口之内 ，那AppsFlyer会将该转化判定为“重装(re-attribution)”并显示在Re-targeting相关报告页，然而在Facebook后台可能会显示为获取的新用户。
注意
Facebook后台会将再营销广告带来的安装展示在同一个地方，但在AppsFlyer后台，这些安装可能会分散在“数据概览Overview”页面(新安装)和“再营销Retargeting”页面(重装re-attribution和再互动re-engagements)。
跨设备归因
Facebook支持跨设备归因。这会导致某些时候Android广告计划带来的激活，会呈现在iOS应用的AppsFlyer页面内，反之亦然。
示例
Linda用自己的安卓设备在Facebook客户端点击了GreatApp的广告。Facebook将Linda的点击记录在最初的定位“Android女性用户”的广告系列上。Linda决定在她家的iPad上安装GreatApp。当Linda首次打开app时，AppsFlyer会询问Facebook索要这次IOS安装的来源，而Facebook会回答广告系列“Android女性”。
验证规则(Validation Rules) 和防作弊产品Protect360
如果您在使用AppsFlyer的产品--验证规则(Validation Rules)，那么当从Facebook而来的安装被过滤掉时，AppsFlyer和Facebook之间就会存在数据差异。这种情况下，Facebook会将这些安装归因于它自己，而AppsFlyer则会过滤掉这些安装。
同理，如果您使用了AppsFlyer的反作弊功能Protect360，也可能存在Facebook归因了而AppsFlyer过滤了某些安装的情况。
示例
Jeff，GreatApp的市场投放经理，投放了一则SPNA的广告系列，定位了在北美洲说西班牙语的用户。Jeff为了验证AppsFlyer Validation Rules验证规则这个产品的有效性，创造了一则验证规则，只接受来自加拿大和美国的新增用户，其余地区的新增用户会被过滤到自然流量。
当一个来自于西班牙的Facebook用户点击了广告且安装激活了该应用，Facebook会自归因此次安装，但是AppsFlyer会根据验证规则过滤掉这次安装。
Facebook对接问题排查
如果您已经完成了Facebook的基本对接配置，但在AppsFlyer的报告里并没有看到来自Facebook的新增用户数据，请您先确保在完成对接配置之后，Facebook广告的确带来了新安装。
如果有，请参考以下原因：
SDK集成文档里有提过，iOS的集成必须添加AdSupport.framework来收集IDFA。没有设备ID的话AppsFlyer仍旧可以用指纹识别(fingerprinting)的逻辑来归因，但对Facebook这个广告平台来说，必须收集IDFA这一重要设备信息，AppsFlyer才能完成对其的归因。您可以在安装原始数据报告里检查“IDFA”一列是否为空。
安卓设备的安装在没有收集GAID的情况下也能被追踪到，但是我们强烈推荐您收集GAID来确保归因的高度准确性。
还有另外一种可能，这个Facebook App ID的确存在，但您或许混淆了Android应用和iOS应用的Facebook App ID。
当您在创建Facebook App install广告的时候，您可以从一个下拉框里选择您的应用或者将该应用在商店的链接地址粘贴在对应的选项框里。这两种方式在Facebook上都可以操作，但是第二种方式会导致AppsFlyer追踪失败，所以建议您选择第一种--下拉菜单选择应用的方式来配置。
正确的配置方式 - 归因正常
错误的配置方式 - 归因失败
Facebook 常见问题
默认情况下，Facebook只会发送新增转化数据和再营销广告数据。但是，您可以轻松配置以获取 Facebook广告系列的展示、点击、花费数据。
这个新的广告系列至少要带来一个新增转化，才会显示在AppsFlyer后台。
例如，一个新的广告带来了100个点击但没有任何安装转化，那该广告不会展示在AppsFlyer后台。而另外一则广告之后1个点击但这个点击带来了新增用户，那么就会展示在AppsFlyer后台。
1. 在AppsFlyer后台打开Facebook配置页面
2. 点击 Terms of service (下图中标蓝的部分)
3. 跳转到Facebook页面并接受Terms of service
或者直接跳转到Facebook的这个页面。 here.
一旦同意之后，所有的原始数据都能从AppsFlyer获取了。
如果您已经集成双方的SDK，请确保在AppsFlyer后台不要配置给Facebook回传任何应用内事件，以免Facebook重复计算事件。
- 在Facebook后台验证App ID并检查该Facebook App ID是否有任何地理位置或受众年龄的限制。
- 如果追踪已经在进行，那就证明该应用在Facebook developer portal已经公开展示了。您可以无视这条错误警告。
将这些窗口的在AppsFlyer的值缩短会减少Facebook在AppsFlyer上的归因数。
而将这些窗口在AppsFlyer的值调大不会产生影响，因为那些在Facebook归因窗口之外产生的安装将不会被归给Facebook。