Adjust CTO深度解读留存率以及相关误区

小提示：您能找到这篇{Adjust CTO深度解读留存率以及相关误区}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的Adjust CTO深度解读留存率以及相关误区内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

对于Adjust的很多客户而言，留存率——特别是“Day 1（次留）”的留存率是评估推广活动表现的重要指标。然而，这个被广泛采用的指标是如何定义与计算的，行业间相关的讨论却很少。虽然这种KPI乍看之下似乎简明易懂，但实际上它牵涉到相当复杂的考虑。并且随着定义方式的不同，所产生的数据结果也会大相径庭。

例如

最近从其他归因供应商转换过来的一位Adjust客户发现，他们Day1的平均留存率大幅下跌。就此该客户会认为Adjust计算的方法显然有问题。

这两种方法都正确，不同是对“天”的定义。

这到底是有多难？

当在评估用户安装后的“留存”时，我们的想象情境可能是：该用户在下班返家途中安装我们的应用，并且在第二天早上再次打开该应用。该用户可能在去上班的途中，玩了两轮同一款游戏或连续两晚使用了同一个外卖应用。我们会直觉上认为用户连续两“天”打开了应用；其中，“天”是指特定于该用户的位置与时区的自然日。

那么这时问题出现了。

如果您的所有用户是在单个时区内生活、工作和活动，上述定义实现起来就简单。然而现实世界并非如此。用户遍布全球各地，时区成了程序员不得不面对的棘手问题。面对这个难题，开发者也只能接受用户会在不同时区穿梭的事实。

这也意味着，要想确定您各个用户的自然日是否已变为第二天，是否能视为“Day 1”留存，在实际操作上是件非常困难的事。

这也是目前没有MMP(Mobile Measurement Partner,中译：移动监测伙伴）或移动数据分析供应商使用此定义的原因所在。它操作起来实在是太复杂了。但是，如果“天”的含义并非您认为的那样，那么，您的归因供应商又是如何定义它呢？

“天”的不同定义

要解决这个问题，最简单的方法是使用集中式时钟，创建通用的“标准网上做广告日”。此方法是数据分析供应商最常用的方法，也就是使用协调时间时(UTC)作为时区，他们将该时区用作“天”的全局定义。此方法很容易实现，仅需让服务器知道用户打开应用时处于UTC时区的哪一天。

此定义和我们之前探讨的直觉假设有何不同呢?

如果是欧洲用户，UTC日和实际自然日之间的时差就只有几个小时。根据夏令时和国家/地区的不同，我们与他们的时差很少超过2小时。

但是世界其他国家/地区又如何呢？

在纽约，实际的一天比全局UTC日晚4到5个小时，这种情况不算太好，也不算太糟。幸运的是，在这个时间段，人们通常都处于睡眠之中。然而，旧金山比我们的UTC日晚了7或8个小时。这意味着，如果用户在当地时间下午5点之前打开一个应用，随后再次打开（即使是在同一小时内），他们也将被视为在Day 1留存。显然，这与我们所认为的留存不同。

另一方面，中国比UTC日早8个小时，我们的“午夜”是中国当地的上午8点。如果用户在当地时间上午打开应用，随后在午餐时再次开启，则将被视为留存。显而易见地，这个定义存在严重的问题。在此示例中并没有如实反映“Day 1的留存率”。尽管我们仍然可以根据同一时区内的留存率来比较推广活动的表现，但使用此定义进行全球对比恐怕会造成许多错误。

但是，问题还不止如此。

为了提供定制化服务，许多监测公司允许客户选择不同于UTC的时区来定义其同期群“全局日（global day）”。其想法是，客户可以选定一天，以尽可能贴近真实情况的方式对用户群的“实际天数”做划分。但是，在转变为Adjust的客户海里捞公关危机的示例中，这样做会导致KPI严重失真。

设想一家总部位于中国的公司，其大部分用户都在北美。他们的全局日为北京时间。在这个情况下，“午夜”被很突兀地定义为纽约的中午12点和旧金山的上午9点。通过这样人为的手段将应用最活跃的使用时间划分为不同的两天，我们从而获得了极高的留存率。在午餐休息时间玩两轮游戏（间隔几分钟）的用户将被视为“留存”。

我们要很明确地表示，这种计算留存率的方法不仅是错误的，而且很危险。提供这种方法的MMP，如果没有向客户妥当地解释其缺点和潜在的数据问题，就可能误导广告主为实际上价值不高的用户投注过多预算资金。

应运而生

在过去的几年里，我们一直在研究解决这个问题的方法。我们没有采取通过更改日历上的日期来定义“天”，而是将“天”定义为“24小时”。通过这种方式，我们可以比较用户打开应用的两个时间戳，并确定它们之间是否已超过24小时。

因此，无论用户位于哪个时区或者处于什么样的当地时间，只有该用户24小时后再次打开应用才能被视为“Day 1留存”。所有用户都遵循相同的定义，避免极端情况出现，从而产生具有评估价值及意义的KPI。这很简单，对吧？

不得不面对的问题

对于从其他MMP转换过来的客户，要适应这种方法，一开始可能比较棘手。上述客户可能会发现，他们Day 1的留存率从50%下跌为约25%。这个道理说得通。因为按照日历逻辑，大约有一半在Day 1留存的用户，在安装应用24小时后其实没有返回该应用。尽管如此，没有人愿意看到数据下跌。客户这样的担忧情有可原。

尽管如此，我们的当务之急并非一味追求数据上的美观，而是结合分析和营销，从而实现整体应用生态系统成功和健康的共同目标。这种原理和我们的防作弊套件非常相似，在使用防作弊套件检测出虚假安装后，您的安装量会下降。同样，采用我们的同期群方法可能会导致Day 1的留存率下降。但这并非是一件坏事，它其实提供了更客观、更可操作的统计数据。只是如果UA经理的奖金取决于人为夸大的留存率，那么接下来的情况可能会有点小尴尬了。

总结

总而言之，明智的广告主需要作出最好的决策。理解每个KPI背后的逻辑（例如，时区和地理因素等因素）能帮助您做出更有价值的决定。数据好看固然不错，但数据准确性更为重要，这也是我们采用这个留存率计算方法的原因所在。