我将分享我们对新用户的实验经验，以及不同的定位组合是如何工作的，因为我们已经做了很多工作。如果你不感兴趣，你可以跳过调查部分，只检查我们现在使用的解决方案。

**我们的调查部分：**首先，当我们集成Firebase时，我们担心Audiences无法正常工作，因为所有当前用户在集成后都将被视为新用户，因此我们检查了几种方法，并采用了一种创建特定用户属性的方法，我们在客户端为旧用户/新用户指定了不同的用户属性。例如，我们创建了一个名为adv_experiment_enrolled的用户属性，并在客户端指定了值'enrolled'/'not_enrolled'，因此安装此版本后所有新用户都成为'enrolled'，而更新版本后的旧用户则成为'not_enrolled'。我们只是在实验中使用该用户属性作为目标。这很好，但这不是一种通用的方法，我们可以轻松地用于所有实验，我们需要为每个新实验创建用户属性。

因此，经过几个月的集成，我们尝试了Audiences方法，这就是@jackes在这里描述的First Open Time用户属性：https://stackoverflow.com/a/50075684/2723437我们有几个问题，首先，他们似乎在填充这种观众方面遇到了一些麻烦，只有~3-5%的新用户进入那里。我们还根据First Open事件本身创建了一个Audience，并使用它，它的普及率更高，接近我们的真实的安装数量。但我们我也注意到了这种方法的问题，最大的问题是一个实验只有20-30%的用户来自该受众。我们测试了它，并注意到我们的一些指标，似乎用户在第一次会话中没有注册这个实验，因为1）Firebase需要一些时间在Audience中注册用户，2）Remote Config默认情况下有12 h缓存，因此对于大多数新安装来说，它并不是一个真正的数据。

目前看来效果不错的解决方案：

我们很惊讶Firebase确实有第一次打开时间的用户属性，但不允许将其用作实验的目标（这将是非常有帮助的解决这个问题tbh），所以我们只是决定尝试我们的良好经验与用户属性的目标和应用一般的方法第一次开放时间用户属性所以我们创建了自己的custom_first_open_time，专门针对特定时间后的目标安装（我们只使用当前平台的时间戳，以秒为单位）。
重要提示：

• 在加载远程配置之前，必须设置用户属性。
• 一旦生成了第一个打开时间，就必须在客户端持久地保存它（通常使用iOS/Android的NSUserDefaults/SharedPreferences）
  实验配置示例：

没有尝试，但应该可以工作。在Firebase Console中创建一个具有以下条件的受众：第一次打开时间大于或等于某个日期。该日期应为开始实验后的第二天。

Firebase终于使之成为可能。https://firebase.google.com/docs/remote-config/config-analytics?authuser=0&hl=en#target_first_open