以APP拉新为例，分享一套数据分析框架。

产品运营三大核心指标:拉新、活跃、留存。相信每个小伙伴都不陌生。不同的产品阶段可能会有不同的操作策略重点，但对H5活动、广告、软文本传播、渠道交换等各种新活动并不陌生。每一轮交付活动都需要衡量投入产出比ROI，每次活动结束时都需要重新讨论，每一轮迭代交付都可能验证一些猜测。我们的目标是通过各种方式优化合理的投入成本，最大限度地产生效果。但在实际操作中，经常会遇到各种各样的交付方式：这个渠道说，我们不能直接跳转下载；渠道说，我们是品牌，高曝光是我们的优势，转型与我无关；有时，有三个不同的位置x3材料x3跳转模式，跳转应用市场下载木材，打开应用木材，如何衡量效果，头有点头晕...但事实上，我们关心以下方向:合理投资，优化路径，最大化产出。总之，我们关心的是投入产出比。简而言之，我们关心的是：投入产出比。（通过不同的渠道更新）如何找到最大的投入产出比是每个负责新业务的合作伙伴都头疼的问题。从上图的流程来看，我们可以优化几个环节：产品是否有吸引力，渠道是否高质量，交付方式是否高效，效果是否符合预期。这里暂时不讨论产品定位，我们只讨论丰富多彩的渠道效果优化。我有100种姿势，问你是否敢尝试~这里，虽然我们以应用程序拉新为例，讨论多渠道效果数据分析系统，但实际上适用于每个即使不是应用程序产品，或者你的拉新不是增加应用程序用户为核心，可以重用这个数据分析框架。设定预期目标首先，对于任何交付活动，我们都必须定义其目标输出。只有在清晰的效果测量系统下，渠道数据的比较才有意义，多渠道ROI才有可比性。对于APP新推出活动，常见的预期效果可能是：提高对APP的认知（广泛传播）成为APP用户（APP下载和激活）在APP中完成特定行为（如购买、身份验证或收到礼品包），我们以常见的新“APP下载和激活”为例，首先建立一个数据漏斗，看看我们需要观察哪些数据。如果我们想监控上述内容，③对于效果数据，我们将继续在激活后添加下一级漏斗，统计过程，如添加购物车、确认订单和付款。在这样的漏斗过程中，我们可以建立监控指标，有时监控数据可能无法实现理想的统计指标，我们可能需要补充其他监控指标，有时不需要如此准确的数据粒度。我们最终监控的数据指标如下(表1)：通过MTA的新报表-安装源分析，可以实现效果数据部分。为什么这里增加了“下载所用网络的比例”？原因是从下载到安装，这两个事件属于APP应用市场，开发者不能主动收集，但我们仍然关心转换步骤，主要担心如果用户处于糟糕的网络环境中，下载行为可能终止，所以这里使用“网络比例”等辅助字段数据。辅助字段数据主要用于优化转换效果的准备。在确定目标后，我们可以在第二步记录交付过程中的数据。这部分数据记录的主要目的是方便复盘时的分析比较，优化迭代时更有方向。根据埃里克·莱斯在《精益创业》中的观点，每一次实验迭代实际上都是为了获得证实的认知。应用于推广交付系统下，每次交付策略的设计都是为了验证交付策略的有效性，提高效果产出。这个链接是一个多路分支，为了更好地定位问题，我们需要做一些版本记录。过程图大致如下:记录过程表2:(表2: 广告策略记录)*根据不同的交付方式，可能会有一些不同的记录方式**具体的策略信息可以在详细的表中记录，然后在表2后映射表1的效果数据，以获得完整的交付活动记录。然后，具体的交付策略的有效性可以通过数据验证。验证目标是什么样的交付策略需要在交付开始前进行规划，以便在数据分析中得出有效的结论。对于收集到的许多详细数据的分析和优化效果，我们可以在数据上做一些结果分析。首先，我们可能想验证的是交付材料对渠道1的横幅-1的影响。然后，我们可以单独拿出表2中的渠道1，得到以下表格：（表3。交付材料对渠道1的横幅-1的影响）。如果我们想比较横幅和横幅流量的差异，我们可以得到：我们也可以根据人群的定向交付效果和不同的交付时间，通过数据验证我们的策略，优化投入产出比，甚至通过渠道效果质量对比等多个维度进行数据分析。因此，虽然有成千上万的姿势，但效果路径总是相似的。因此，虽然有成千上万的姿势，但效果路径总是相似的。如果你有丰富多彩的交付策略，不要担心，不要惊慌，整理路径，控制策略版本，使用A/BTEST加快验证迭代速度，最终获得有效的交付策略和最大的投资回报率效果。以上是关于交付效果的数据指标系统共享。类似的分析思路可以在不同需求的交付方案中重复使用，包括一些在线和离线操作活动。事实上，这个框架也可以重复使用。