我们需要将两套方案结合起来看,但是实际归因时为了确保准确性还采用后者来计算App网速,这样会漏掉一小部分弱网日志,但是不会误判。 因此我们通过流量的消耗来计算App网速,通过在内存中维护一个记录最近3s,6s,9s的流量消耗的队列,可以算出最近App的网络下行速率。 案例:解码任务等待超过10s未开始执行,并且线程池等待队列中请求超过30个,足以证明解码线程池已经因之前某些解码慢的任务堵死。 清洗脏数据前文提到的像素抽样检测方案,我们线上使用的是10*10的采样,到这个数量已经可以准确的识别出占位图和正常图,但是部分细长商品的主图空白部分较多,很容易被误判为占位图,具体表现为图片请求正常,现场快照也正常 这也证明了该策略对脏数据归因的准确性。归因优先级我们目前问题归因的优先级从高到低如下,主要按归因证据的可信度来排序。
要解决这个问题,我们需要一个关键工具:移动归因。一、 什么是归因,它又是如何工作的?简单来说,App归因就是识别并记录每一位新用户是从哪个渠道、哪个广告来的技术。它能帮助我们追溯用户的来源路径。 这种方式就像给设备发“身份证”,通过匹配用户点击广告和激活App时的“身份证”是否一致,来实现精准归因。这是目前最准确的方式,主要用于App内的广告投放。2.剪贴板归因这是H5页面引流的有效方式。 用户安装并打开App后,App会读取这个识别码,从而知道用户是从哪个H5活动页来的。3.渠道包归因这是一种主要应用于安卓平台的归因方法。并在包内预先写入一个的渠道ID。 用户被一篇精彩的“旅游攻略”吸引下载了App,但打开后却要重新搜索,体验很差。在“旅游攻略”H5页面中配置带有文章ID的归因链接。 总结归因的核心目的,是为业务增长中的每一个决策,提供清晰、可靠的数据支持。它连接了市场投放、产品体验和用户运营,是App精细化增长的必备工具。
引言:作者结合丰富实战工作经验,亲笔撰文分享了在APP渠道归因中监测厂商的4种常见解决方案。 作者 | 仲志成 编辑 | 华 子 APP渠道归因之痛 APP分析与网站分析最大的不同之处在于:在网站端完成渠道归因那是轻松简单加愉快,但APP的渠道归因却是个巨大无比的坑。这个坑有多大呢? 有专门做APP渠道归因的公司,做到被巨头收购,成为巨头数据分析产品家族的一份子。 APP渠道归因这个“天坑”对于业务提升有什么负面影响呢?现如今,都是通过分析数据来驱动业务改进。 APP渠道归因最佳实践探索 简单的说,APP渠道归因最佳实践 = Deep Share + User-id,示意图如下: ? 只要在H5能获取到User-id,就能和解决方案4有接近的效果了。 下载APP是那个H5 活动页的次要目标,主要目标是获取销售线索(用表单获得电话号码)。结果莫名其妙的体验了APP渠道归因的最佳实践,完全是“瞎猫碰上死耗子”。
渠道归因(一)传统渠道归因 小P:小H,我又来了。。。最近在做ROI数据,但是有个问题。。。 小H:什么问题,不就是收入/成本吗? 小P:是的,每个渠道的成本很容易计算,但是收入就有点问题了。 小P:不愧是你,对的,用户在付费前经历过很多渠道,我感觉把收入分给谁都不好说 小H:这个也不复杂,关于渠道归因的方式有很多种,比如传统渠道归因、基于马尔可夫链、基于shapley value甚至是基于Attention-RNN 说到渠道归因,那最容易想到的就是传统的渠道归因,这种方法一般是基于业务决策的。 首次归因:首次点击渠道赋予全部转化 末次归因:末次点击渠道赋予全部转化 线性(平均)归因:每个渠道均分转化 位置归因:自定义位置的权重,一般首位占50%,其余为0 时间衰减归因:距离转化的时间越短的渠道 3.0 3 epsilon 315.0 4 eta 3665.5 5 gamma 128.5 6 iota 3980.5 7 kappa 152.0 8 lambda 1054.5 9 mi 2.0 10
最近公司在抖音跑app项目,刚好碰到需要广告的归因注册回传这里来聊聊,核心就三步:接住点击、匹配设备、回传注册。这事儿难在APP一安装,点击时的线索就断了,得靠“设备指纹”来认人。 一、接收数据广告平台会在用户点击广告时,向你预设的监测链接发送一个请求,里面包含了归因的关键:clickid和一堆设备信息。需要有个接口来接住它,并把这些信息存起来。 二、APP激活,上报“我是谁”用户下载安装APP后,首次打开(激活)时,你的APP必须收集当前设备的指纹信息,并上报给你的后端。 总结APP注册归因回传,说白了就是:点击时存线索:接住广告平台给的clickid和设备信息。激活时对暗号:APP启动上报设备信息,后端用OAID/IDFA精确匹配,不行再用IP、时间模糊匹配。 虽然iOS14.5后的ATT框架让IDFA获取变难,但结合IP和时间窗口的模糊匹配,仍能保证大部分场景下的归因准确性。
近期计划出一个系列的文章,详细介绍一下网页及APP坑位流量归因的理论以及实践篇。欢迎大家收藏及转发,针对过程中有疑问的地方,欢迎在公众号内留言互动。 针对视频网站:APP能存在多种多样的功能,可以使得将用户需要的内容曝光在用户面前,在产品迭代的过程中,评估不同的入口(比如通过搜索、关注页、首页推荐eyc可以获取到UP主的视频 ),最终带来用户观看、付费 洞察用户的习惯和行为:知道用户是通过哪些渠道/路径触达到广告或者APP功能,C端用户(新用户、活跃用户、回流用户)是否具有明显的差异性以及人群的画像。 二、归因理论 业内通用五大基本归因方案,如下: 首次触点模型: 多个「待归因事件」对同一个「目标转化事件」作出贡献时,认为第一个「待归因事件」功劳为 100% 。 若采用“根据位置”归因模型,“酒店”和“武汉市万达瑞华酒店”将分别获得 40% 的功劳,而“武汉市酒店”和“武汉市5星级酒店”将分别获得 10% 的功劳。
渠道归因(三)基于Shapley Value的渠道归因 通过Shapley Value可以计算每个渠道的贡献权重,而且沙普利值的计算只需要参加的渠道总数,不考虑顺序,因此计算成本也较低。 pd import matplotlib.pyplot as plt import seaborn as sns 本文所有数据如果有需要的同学可关注公众号HsuHeinrich,回复【数据挖掘-渠道归因 fontdict={'fontsize': 15, 'fontweight': 'semibold', 'color':'#444444'}, loc='center', pad=10 248.21 Channel 5: 75.04 Channel 6: 55.02 Channel 7: 33.14 Channel 8: 52.95 Channel 9: 189.29 Channel 10 总结 日常业务中,可以结合多个方法看一下归因的差异。
openisntall的H5传参安装能够精准归因App安装来源,有效解决因手机厂商拦截/劫持安装包引起的数据偏差,还原真实的渠道推广效果。Android渠道推广拦截安装包到底是怎么产生的? 正因为Android用户被引导到未知的应用商店下载App,才会出现文章开头所提到现象:投放渠道包的渠道有较高点击量,安装量却异常的低。 这种劫持行为就造成了常规渠道投放中数据归因的误差现象,因此,如果不使用归因统计类第三方工具进行介入,渠道质量评估和投放策略的优化也就无从谈起。 Android应用商店拦截如何正确归因数据作为第三方渠道归因监测工具,采用openinstall进行全局Last Click归因(最后一次点击归因),能够在数据统计上,有效避免因应用商店拦截/劫持造成的数据误差 即使用户在下载过程中被引导到任意应用商店,只要最终能顺利下载并打开App,就会归因最初点击的原始渠道进行绑定,从而通过数据还原事实上的推广来源。
前面了解到归因分析的理论知识和数据采集,接着我们看如何搭建数据计算模型。比如我们现在希望对进入UP主视频播放页的来源进行归纳。 一、根据采集信息,对采集页面进行梳理整合。 outputData 输出数据表 bili_ads.ads_dot_detail_1d Objects 归因对象 uuid,user_id Dimensions 归因维度 up_id_com,app_key recent,average startDate 进行归因计算的日期 ${yyyy_mm_dd} traceBackDays 往前追溯的天数 0 maxIntervalHours 最大归因间隔(小时) 3.1 合并待归因和归因目标行为数据 输入:ActionData,targetActionData 中间处理:将ActionData中的additionalFields字段join到targetActionData up主id 30689558 app_key app编码 IOS business_id 业务id 1 business_name 业务名称 娱乐 r_business_id UP主对应业务ID 123
前一节讲到多种流量归因的模型,本质上流量归因是为了辅助我们如何将钱花的更有价值以及高效洞察用户的习惯和行为,为下一步迭代产品的功能提供数据支撑。 今天这一节,结合具体的业务场景来看看流量归因分析如何在数据采集方案上落地的。 业内通用五大基本归因方案 旺盛的小草,公众号:万能的小草网站及APP坑位流量归因分析-(1)理论篇 一、背景 比如B站的产品内,提供了非常多的入口能够使得用户进入直播间里面。 由于涉及到主端APP的快速迭代,单次的分析很难实现复用,因此在这种背景下急需提供标准化的流量归因产品去快速实现流量来源拆解,快速定位KPI异动原因,满足业务运营的日常监控诉求。 STRING 页面名称 6 dateline BIGINT 时间戳 7 uuid STRING 用户唯一编码 8 user_id BIGINT 用户user_id 9 up_id BIGINT UP主ID 10
文章目录 1 归因分析 2 传统归因分析方法 2.1 传统归因分析 2.2.1 最终互动归因模型 2.2.2 最终非直接点击归因模型 2.2.3 最终AD点击归因 2.2.4首次互动归因 2.2.5 线性归因模型 2.2.6 时间衰减归因模型 2.2.7 位置归因模型 2.2.8 自定义归因模型 2.2.9 马尔科夫归因模型 2.2 不同归因方法的使用场景 3 算法归因的几种方法 3.1 夏普里值 5.2 GA中的多渠道归因 5.3 有效触点归因 参考文献 本篇主要是python实现马尔科夫链归因,关联的文章: 多渠道归因分析(Attribution):传统归因(一) 多渠道归因分析:互联网的归因江湖 可以看到用户最后转化的之前经过了哪些路径(需要注意:查看热门路径报告,进入默认是两次以上的,需要在“路径长度”中选择“1次或更多”才会看到跟下图一样的报告,且对应在转化中要选择一个目标,这里还是选择“在线时长超过10 对于种草类平台来说,点击并不是发生转化的必要行为,采用点击归因很容易低估平台的效果。抖音数据显示,有10-25%的用户在看过抖音广告后会去商店或搜索引擎搜索商品信息,从而完成转化。
前面介绍了归因分析的理论、数据采集、数据计算,最后我们着重介绍一下如何对前面生成的数据,进行可视化分析沉淀,让业务能高效的进行日常运营迭代。 3)受众群体特征 其实单纯的通过可视化图表呈现其实远远不够,更多的是我们需要对呈现的数据进行解读,因此小编建议大家有注重点,选择主要的去研究,把重要的流量入口给研究透,然后优化到极致,这样我们的APP
App 激活是指新用户首次打开 App 的行为。在进行一轮广告投放之后,对 App 激活渠道的归因分析是定位用户来源、效果评估和推广成本核算的主要方式之一。 传统的 App 激活渠道归因 目前常见的 App 激活归因方式有设备号归因、渠道号归因、IP+UA 归因等。以下分别进行简要介绍。 1. 设备号归因 设备号归因主要应用于第三方 App 中推广,应用场景以信息流广告为主。 ,由 App 读取剪贴板符合规则的信息并上报到服务器; (4)服务器关联点击时记录的唯一标识和 App 激活后上报的唯一标识进行归因。 总结 精准的归因在 App 推广中非常重要。
渠道归因(二)基于马尔可夫链的渠道归因 在应用当中,序列中的每个点通常映射为一个广告触点,每个触点都有一定概率变成真正的转化。通过这种建模,可以选择最有效,概率最高的触点路径。 本文主要参考自python实现马尔可夫链归因[1]。 马尔可夫链是一个过程,它映射运动并给出概率分布,从一个状态转移到另一个状态。 所以马尔可夫链模型可以用来做归因分析。 1126.342986 7 zeta 291.786394 1093.572697 8 epsilon 635.341342 2280.694761 9 gamma 216.486679 777.796200 10 共勉~ 参考资料 [1] python实现马尔可夫链归因: https://mattzheng.blog.csdn.net/article/details/117296062
解释 这里会引用神策数据很多的介绍,然后进行总结 归因方法 自归因 渠道商帮我们做归因,有的是每个用户打开app都回传给渠道商,渠道商自己归因 有的如华为是从应用商店安装时, 应用商店把归因信息写入到 app, 然后首次安装启动时能从本地存储获取到归因数据 曝光归因 曝光归因由于有数据量极大、不会使用此项 点击归因(常用) 所谓点击归因, 就是点击广告之后首个转化, 基本都是用这种方式归因 归因模型 如果是 deepLink 拉起, 最好加一个延迟 10s 的队列归因, 防止`app`请求先于渠道商监测链接请求 // 1. 查询 app $app = "select * apps where id={$appId}"; // 3. // 修改点击日志状态等等 // 删除所有归因的 $keys, 防止重复归因 // 根据 $app->attribute_cycle_days 设置归因周期 return
本篇主要是python实现马尔科夫链归因,关联的文章: 多渠道归因分析(Attribution):传统归因(一) 多渠道归因分析:互联网的归因江湖(二) 多渠道归因分析:python实现马尔可夫链归因( 当应用从 App Store 或者 Google play 上下载并激活应用后,Facebook要求广告主需要回传其应用的激活数据给到Facebook广告后台进行归因,只要有曝光过的广告媒体都可以分到该次激活的广告收入 2)将应用自然流量上(organic)归因到了Facebook的广告上:广告在Facebook 的流量或者联盟流量上曝光过,但是没有转化,最终用户主动的在Google play或者APP Store 上进行了转化激活 首先,广告主做用户增长的团队需要有懂广告归因的人,况且即便懂了这套归因逻辑,也很难区分有效触点归因“抢”了多少自然量。 说个题外话,Google play 和 App Store 还是有榜单效应和评价体系的,但是国内应用商店则几乎全是广告,给钱就能上。
本篇主要是python实现马尔科夫链归因,关联的文章: 多渠道归因分析(Attribution):传统归因(一) 多渠道归因分析:互联网的归因江湖(二) 多渠道归因分析:python实现马尔可夫链归因( 三) 多渠道归因分析(Attribution):python实现Shapley Value(四) 多渠道归因分析(Attribution):用attention-RNN来做归因建模(附代码demo)(五 所以马尔可夫链模型可以用来做归因分析。 这是一个多渠道归因模型问题。 Google Analytics(分析)的定义有助于:归因模型是一个或一组规则,用于确定如何将销售和转化功劳分配给转化路径中的接触点。 如今,Google Analytics(分析)提供了七个预定义的归因模型,甚至可以定制的自定义模型。
今天,我们将列举一些常用的归因模型,并演示如何使用Googel Analytics 归因模型对比工具来为你的业务挑选最适合的模型。 归因模型应用示例 假设你的网站售卖烧烤架。 Google Analytics 归因模型101 在末次互动归因模型中,我们将转化的全部功劳归于用户的最后一个触点。 末次非直接点击归因模型忽视了直接流量,把转化功劳全归因于在完成销售之前的最后一次渠道点击。 我们再来看更多模型: 与末次互动相似,首次互动归因模型把转化功劳全归因于首次触点——在Grillmaster先生的例子中,即为自然搜索。 线性归因模型在各个渠道之间平均分配成功转化分数。 在Grillmaster先生的例子中,自然搜索和直接来源将各自得到40%的成功交易转化分数,而邮件营销和社交媒体渠道将各自得到10%的分数。
不管是做FOF也好,仅仅想单纯归因也好,Brison是一种比较常见,也算是通用的归因方法,其一般用于权益类或者大类资产配置类基金。 其实Brison归因的逻辑很简单,假设有一个基准,基准在各类资产的配置上的权重分别是wbi(weight of benchmark of asset i),这些资产的收益率分别是rbi(return of benchmark of asset i),同样的,我们有一个需要归因的基金产品,也就是我们自己的组合,在各类资产上的权重是wpi(weight of portfolio of asset i),收益率分别是 所谓的Brison归因就是把一个组合的超额收益分解为资产配置的能力、个券选择的能力、以及交互收益。
deferral.Complete(); //} deferral.Complete(); }); 要接受其他的app page=" + 页面名); 要接受其他的app我们需要设置 我们在说明写:林德熙博客 但说明其实没有什么用,主要是数据格式才是需要我们选择,在上也看到我们可以分享的数据有多种格式,那么满足格式的分享就会在分享看到我们的应用 frame.Navigate(页面,参数) protected override void OnNavigatedTo(NavigationEventArgs e) { } 在App.xaml.cs thumbnail, }; share_operation.ReportCompleted(quickLinkInfo); 文件启动 我们需要关联 在app.xaml.cs } Files包含文件可以拿来 博客:http://blog.csdn.net/lindexi_gd 原文:https://msdn.microsoft.com/en-us/windows/uwp/app-to-app