我们能为您提供什么帮助?

关于流量来源解析

  • 更新

概览:使用流量来源解析,借助落地页加载时可用的 URL 参数和引荐来源数据,识别每次网页访问的初始媒体渠道、广告活动和渠道。 这为归因提供了所需的流量来源上下文,以便准确归因后续网页事件,包括用户获客事件。

什么是流量来源解析?

在网页归因中,落地页加载(网页访问)是用户与网站的首次交互。 AppsFlyer 依赖当时可用的信息,例如 URL 参数和引荐来源数据,来识别用户的媒体渠道、广告活动和渠道。

这一过程称为 流量来源解析,用于从 URL 参数中识别并解析媒体渠道和广告活动信息。 AppsFlyer 会捕获这些参数并确定其优先级,以判定一次访问的初始流量来源上下文。

流量来源解析是一个归因前流程。 这些已解析的参数之后可能会在归因流程中被覆盖。

流量来源解析的作用并不会随着访问结束而终止。 其结果会提供流量来源上下文,供后续归因流程用于归因后续网页事件,包括用户获客事件。

要构建准确的 URL,了解流量来源解析的机制至关重要。 如需了解如何创建结构良好的 URL,请参阅为落地页 URL 选择归因参数

流量来源解析流程

流量来源解析遵循结构化的多步骤流程,逐步为每次网页访问构建归因上下文。 每个步骤都会提供一层特定信息,从记录访问本身到对流量进行分类以用于报告。 流量来源解析流程使用的数据由 Web SDK 或 Web S2S 捕获。

该流程包括以下步骤:

  1. 访问记录:捕获用户到达网站的时刻,并记录一次访问事件,即使当时尚不知道流量来源。 这样可确保在应用归因逻辑之前,先衡量所有符合条件的用户进入。
  2. 媒体渠道解析:分析 URL 参数和引荐来源数据,以识别推动此次访问的平台或合作伙伴,或判定此次访问为自然流量。
  3. 广告系列解析:解析与已识别媒体渠道相关的细粒度广告系列详情,以支持详细的表现分析。
  4. 渠道分类:根据已解析的媒体渠道,将每次访问归入某个高层级流量渠道,为报告和分析提供标准化视图。

步骤 1:访问记录

访问记录是 Web 性能衡量流程的第一步。 它发生在媒体渠道解析和归因之前,作为预处理层捕获原始用户活动。

这一逻辑分两个阶段运作。 首先,它会对引荐来源进行分类(即用户到达您网站之前访问的域名)。 然后,它会根据引荐来源类型,评估用户的应用打开状态以及是否存在媒体渠道信息,以决定是否记录此次访问。

第 1 阶段:引荐来源分类

AppsFlyer 会将引荐来源分为以下三类之一:

  • 外部排除(例如支付处理方,或您已排除在追踪范围之外的任何域名)
  • 内部排除(例如您自己的子域名或登录流程)
  • 其他(所有其他引荐来源)

第 2 阶段:应用打开状态评估和访问记录

AppsFlyer 会根据引荐来源类型评估应用打开状态,并决定是否记录此次访问:

  • 外部排除:永不记录此次访问。
  • 内部排除:系统会抑制基于引荐来源的归因,因为该引荐来源并非真实的获客来源。
    • 如果存在活跃的应用打开(应用打开在无活动 30 分钟后会被视为非活跃;否则视为活跃),则不会记录此次访问。
    • 如果没有活跃的应用打开,则会记录此次访问,但该引荐来源会被视为自引荐并被忽略。 除非 URL 包含归因参数(UTM、PID、点击 ID 等),否则此次访问会被记录为自然流量。
  • 其他:
    • 如果没有活跃的应用打开,则记录此次访问。 新的应用打开无论其他条件如何,都会被视为一次新的访问。
    • 如果存在活跃的应用打开,且存在非直接媒体渠道(UTM、PID、点击 ID 等),则记录此次访问。 此次回访可能会触发一次再营销转化(再互动),用于对后续事件进行归因。
    • 如果存在活跃的应用打开,且不存在媒体渠道信息,则不要在该应用打开期间记录新的访问。
流量解析流程

第 2 步:媒体渠道解析

媒体渠道解析流程会判断一次访问是否属于:

  • 非自然:已找到特定的归因来源。
  • 自然:未识别到归因来源(例如,用户直接输入 URL 或使用书签)。

在媒体渠道解析过程中,AppsFlyer 会通过评估从落地页 URL 路径和查询字符串中提取的参数,确定一次网页访问的来源。

为获得最佳结果,请使用 AppsFlyer 专用参数,例如 pidaf_campaign,以提供最高级别的粒度和控制。 AppsFlyer 也可识别行业标准参数,例如 UTM 标签和点击 ID,让您无需更改现有广告衡量设置即可立即开始。

AppsFlyer 会按优先级顺序解析媒体渠道。 一旦成功识别出某个来源,流程就会停止。 媒体渠道解析流程包括以下步骤:

1. 排除域名

首先,AppsFlyer 会检查这次访问是否来自您的排除列表中的某个域名。 如果该域名已被排除(例如您的内部域名,或 PayPal 这类支付处理商),则此次访问将被自动忽略或归类为 自然

如需详细了解在将 Web 应用添加到 AppsFlyer 时如何指定要排除的域名,请参阅排除的域名

2. AppsFlyer PID(合作伙伴 ID)

如果该域名未被排除,AppsFlyer 会在 URL 中查找 pid= 参数。

  • 如果找到了,媒体渠道将直接从该值中获取。
  • 以下社交媒体合作伙伴会使用特定的显示标签,而不是原始 URL 参数值。
URL 参数(PID) 媒体渠道显示名称
pid=iossearchads_int 苹果搜索广告
pid=facebook_int Facebook 广告
pid=metweb_int Facebook 广告
pid=twitter_int Twitter
pid=twitterweb_int Twitter
pid=googleads_int googleadwords_int
pid=tiktokweb_int tiktokglobal_int
pid=snapweb_int snapchat_int

3. UTM参数

如果在 URL 中找不到 PID,AppsFlyer 会评估 utm_sourceutm_medium 参数,以识别媒体渠道。 最终的解析结果由这两个字段的组合决定。

UTM 逻辑的工作原理

  • 在大多数情况下,AppsFlyer 会提取 utm_source 的原始值,并将其用作媒体渠道,从而确定媒体渠道。
  • 如果 utm_mediumemailmaile-mail,媒体渠道会自动解析为 e-mail
  • 如果存在 utm_medium 且其值不是 email 值,AppsFlyer 会根据特定的自定义映射规则检查该值(请参阅下方映射表)。
  • 如果缺少 utm_medium,或其值不匹配任何自定义规则,AppsFlyer 会回退为使用 utm_source 作为媒体渠道。

UTM 映射规则

utm_source utm_medium 媒体渠道
Google cpc / ppc / paidsearch / paid_search / paid-search / search / paid googleadwords_int
谷歌 cpm / 展示 / 横幅 / 视频 / 列表 dv360_int
dfa / dbm / dcm / doubleclick cpm dv360_int
Facebook / FB / Meta cpc / ppc / cpm / cpa / paidsocial / paid-social / paid_social / paid Facebook 广告
Bing / microsoft / ms cpc / ppc / paidsearch / paid_search / paid-search / search / paid bingsearch_int
Yahoo / Gemini cpm / 展示 / 列表 yahoogemini_int
twitter cpc / ppc / paid / paidsocial / paid-social / paid_social Twitter
Snapchat / snap swipe / cpc / ppc / paid / paidsocial / paid-social / paid_social snapchat_int
pinterest cpc / ppc / paid / paidsocial / paid-social / paid_social pinterest_int
tiktok cpc / ppc / 付费 / 付费社交 / 付费-社交 / 付费_社交 tiktokglobal_int

4. 点击 ID

如果 URL 中既没有 PID,也没有 UTM 参数,AppsFlyer 会尝试使用 点击 ID 来识别媒体渠道。 这些是由特定广告平台自动追加到 URL 的唯一标识符。

AppsFlyer 使用以下点击 ID 映射对访问进行归因:

点击 ID 参数 解析后的媒体渠道
gclidwbraidgbraid googleadwords_int
msclkid bingsearch_int
twclid Twitter
vmcid yahoogemini_int
sccid snapchat_int
li_fat_id linkedin_int
ttclid tiktokglobal_int
tbclid taboola_int
ob_click_id outbrain_int
dicbo outbrain_int
yclid yandex_int
rdt_cid reddit_int

epik

pinterest_int

oppref

openai_int

 说明

  • AppsFlyer 不会使用 fbclid 进行流量来源解析,因为 Meta 会将其附加到 Facebook 的付费和自然点击中。 如需将流量归因于 Meta,请包含 pid=facebook_int,或将 utm_source 设置为相应的 Meta 来源值。
  • dclid 参数不用于媒体渠道解析。 在使用 CM360 时,dclid 是一个 Campaign Manager 360(CM360)标识符,可能会与其他点击 ID 一同出现,例如 fbclid(Facebook)或 ttclid(TikTok)。 仅使用 dclid 可能会导致解析结果错误。

5. HTTP referrer

如果在 URL 中未找到查询参数(PID、UTM 或点击 ID),AppsFlyer 会使用 http_referrer 来识别流量来源。 这依赖于一种内部解析机制,该机制会提取域名主机并将其映射到媒体渠道。

解析机制

为识别来源,AppsFlyer 会通过以下方式清理引荐来源字符串:

  1. 将 URL 精简为仅保留主机
  2. 移除域名后缀(如 .com.org 等顶级域名,或 .co.uk 等扩展名)
  3. 移除域名前缀(例如 www.m.l.,或 lm.)

示例:www.mywebsite.com?param=example 的引荐来源会解析为媒体渠道 mywebsite

引荐来源映射规则

如果域名主机包含… 解析后的媒体渠道
mail.outlook. 邮件
t.co twitter
googleads.g.doubleclick.net googleadwords_int
tpc.googlesyndication.com dv360_int

搜索引擎映射

如果域名主机包含… 解析后的媒体渠道
google。 Google 搜索
search.yahoo Yahoo 搜索
bing.com Bing 搜索

Android 应用引荐来源

如果访问来源于 Android 应用,则引荐来源主机按如下方式映射:

应用引荐来源字符串 解析后的媒体渠道
com.google.android.googlequicksearchbox Google 搜索
com.google.android.gm 邮件
com.linkedin.android linkedin
com.twitter.android twitter
org.telegram.messenger telegram

步骤 3:广告系列解析

在步骤 2 或 3 中确认媒体渠道后,AppsFlyer 会尝试识别具体的广告系列详情。

AppsFlyer 按优先级顺序从以下 URL 参数中提取广告系列信息:

URL 参数(多个) 映射到 优先级顺序
caf_campaignutm_campaign 广告系列名称
  1. c
  2. af_campaign
  3. utm_campaign
af_c_id, af_campaign_id 广告系列 ID
  1. af_c_id
  2. af_campaign_id
af_adset 广告组名称
af_adset_id 广告组ID
af_ad 广告名称
af_ad_id 广告 ID
af_keywords 关键词

步骤 4:渠道分类

除了识别媒体渠道外,AppsFlyer 还会自动将每次访问归类到某个渠道中。 此分类可帮助您从高层级了解原始数据报告和数据面板中的流量类型。 在原始数据报告和数据面板中。

渠道类别包括:

  • DIRECT:用户直接输入了 URL,或使用了书签。 未识别到归因来源。
  • 自然搜索:来自 Google、Yahoo 和 Bing 等搜索引擎的非付费流量。
  • 社交媒体:来自社交平台的流量。 
  • EMAIL:来自 email 广告活动或 email 服务提供商的流量。
  • 广告:由付费广告带来的流量。
  • 引荐:来自其他网站的流量,可通过引荐来源识别。
  • 其他:不符合上述任何类别的流量。

注意:每次访问都会分配到一个渠道。 此分类基于已识别的媒体渠道和归因方法,自动且确定性地完成。