1 Min. Read

渠道如何最大程度利用AppsFlyer现有对接机制

Avatar Jane Hou Sep 17, 2015

AppsFlyer对广告主承诺最好的服务同时,也同样以高效和深度的整合机制全面支持渠道合作伙伴,以帮助渠道健康成长。

归根到底,都是为了与媒体渠道协同帮助广告主以最快速度完成广告投放配置,同时保证每个投放活动都能在量和质量上达到预期效果。具体如何实现“协同”, 请看以下分析。

预定义对接形式

首先,需要明确的是实现对接的基础是搞清楚双方服务器对话中应该包括哪些必要信息。一方面要明确作为渠道,你需要从AppsFlyer服务器获取什么信息;同样的,AppsFlyer作为第三方监测平台需要获取哪些与广告点击相关的参数。在基础信息上达成一致后,AppsFlyer便可提供双方服务器对话过程中回传(postback)的基础结构。

作为第三方的AppsFlyer,首先最基本的可以向一个媒体渠道回传每一个归因到该渠道的激活信息。除此之外,渠道也可以要求AppsFlyer回传剩下其他并非归因到自己“旗下”的激活信息。第一种方式的意义是显而易见的,那第二种呢?对媒体渠道而言,第二种情况可以帮助你们优化资源,防止把点击和曝光浪费在已经成功被其他渠道转换的用户和自然用户身上。

我们同样也会支持应用内事件数据的回传, 因为AppsFlyer的SDK已经全面支持富应用内事件追踪,所以渠道从我们这儿获取的用户行为数据更加适应精细优化的需求。

当回传发生在多方服务器的时候,例如涉及子渠道的情况,我们会强烈建议媒体渠道能够考虑在向AppsFlyer回传点击数据的时候包括以下信息:

1) Device ID:如果渠道能在向AppsFlyer回传的点击信息中包括device id, 那么我们便能够使用基于device id的归因方法。当然如果您无法提供device id信息,也无需紧张!我们基于大数据机器学习的指纹技术也能够为归因提供可靠依据。

2)Publisher ID: publisher id(子渠道号)与AppsFlyer实现共享能够帮助广告主更加全面评估渠道质量,避免因为渠道整体效果看似不尽如意就一票否决的情况发生。我们不仅接受数字格式的Publisher id, 在上游渠道不愿意透露真正的子渠道号的情况下, 也可以用其他数据格式代替。

3) 成本:如果渠道可以实现向我们回传成本数据, 在这样的透明度下,广告主便能够一目了然定位到那些投入产出比最大的广告, 加大对应的投放预算。

AppsFlyer如何为渠道和广告主减负

与AppsFlyer做服务器对服务器的对接,为什么说是在为渠道和广告主减负?

想象一下,如果广告主使用的第三方仍然需要反复地手动配置追踪,广告主需要将对应的参数人工拼凑成一条一条追踪链接。这不仅会占用渠道和广告主双方大量的人力资源, 同时如果手动配置的过程中出错,那无奈地返工很可能意味着广告投放地被迫推迟。这就是为什么我们在与渠道对接的过程中,需要预先把追踪链接格式定义好。使用预设好的追踪链接,广告主仅仅只需要复制粘贴的简单操作就能够保证AppsFlyer能追踪到对应渠道的广告投放效果。

还不相信这其中的便利?看看下面广告主配置追踪的步骤就知道了:

  1. 点击进入媒体源(渠道)配置页面

2. 选中需要配置的渠道

3. 复制粘贴下方的追踪链接(Tracking Link)

如果对接的时候,定义了从AppsFlyer向渠道回传应用内用户行为数据的格式,那么需要广告主做的相关配置也十分简单。只需要按照下方图例中,将SDK层级做的埋点事件和对应事件在渠道上的名称做一个匹配就搞定了。具体的匹配实现形式,有两种。
第一种,如下图的下拉菜单形式。

第二种, 是文字框的形式,广告主需要将对应的事件名称填入框中。

一旦,广告主正确完成匹配, 我们便能够按照预设的格式,把每个事件数据回传给渠道。并且,如果中途发现广告主需要匹配的事件在右端渠道对应的事件列表里并没有对应, 这个时候渠道只需要将对应的新事件名称添加到我们服务器上就可以了,并不涉及大返工。

如何通过与AppsFlyer在应用内事件上的对接,帮助渠道从用户行为角度优化流量

首先,明确AppsFlyer提供两种形式的应用内事件追踪:

1)标准型应用内事件

这种形式的应用内事件追踪,每个事件名称对应一个事件价值。广告主可以很清晰地通过这种形式知道一个用户到底做了什么。例如,用户是否通过机票预订应用下单成功,游戏玩家是否创角等。

标准型应用内事件数据相较于后一种类型较轻便,更加方便渠道实时接收并且处理来自AppsFlyer的事件数据回传,从而实现投放优化。当然,如果渠道暂时无法实时接收应用内事件的数据,广告主也可以通过手动下载对应的原始数据报表,将成功把商品放入购物车但是没有完成订单的用户筛选出来,针对这部分用户以鼓励完成订单为目的进行二次投放。

2)  富应用内事件 (Rich in-app events)

完整的描述一个应用内事件,有的时候使用一个参数是不够的。例如,”加入购物车“这一事件,对于一个电商应用来说其中富含的信息还包括货品类型,数量,单价,货币种类等等。这个时候,使用AppsFlyer提供的富应用内事件就能追踪到更加全面的用户行为信息。富应用内事件帮助广告主能同时使用多个不同参数完整描述一个事件的价值,而单独一个参数的值或者不同参数的组合都可以作为细分用户和精准投放的依据。

游戏广告主如果使用标准型应用内事件,只能够通过标记一个用户是否充值进行精准投放;而如果使用富应用内事件,该广告主可以找出那些充值且充值数额达到一定标准的用户。这样的好处对于广告主来说是显而易见的,而如果渠道能够实时接受富应用内事件的回传,便可以依据这部分数据对正在跑的广告进行及时优化,同时不断积累用于精准投放的用户数据。

渠道和广告主登陆AppsFlyer数据后台,都可直通原始数据

AppsFlyer作为独立第三方监测平台,不断推动着整个移动广告行业朝着更加透明和成熟的方向发展。媒体渠道的数据后台和广告主的数据后台都能够直接下载原始数据日志报表。这极大提高了渠道和广告主进行数据差异排查和深度数据分析等工作的便利性。