在iOS上使用激活事件时,Firebase A/B测试不计算用户

Question

我们正在使用当前版本的Firebase iOS框架(5.9.0),当我们尝试运行具有激活事件的A/B测试实验时,我们发现了一个奇怪的问题.

由于我们希望在首次启动时运行实验,因此我们在启动远程配置时显示的app start上有一个自定义启动画面.提取完成后,我们立即激活提取的配置,然后检查我们是否收到了有关实验参与的信息,以便适当地重新配置下一个UI.在我们确定当前实例实际上应该是测试的一部分,因此激活事件之前,还有其他检查已完成.基本上,代码看起来像:

<code that shows splash>

…

[[FIRRemoteConfig remoteConfig] fetchWithExpirationDuration:7 completionHandler:^(FIRRemoteConfigFetchStatus status, NSError * _Nullable error) {

    [[FIRRemoteConfig remoteConfig] activateFetched];

    if (<checks that see if we received info about being selected to participate in the experiment and if local conditions are met for experiment participation>) {

        [FIRAnalytics logEventWithName:@"RegistrationEntryExperimentActivation" parameters:nil];

        <dismiss splash screen and show next UI screen based on experiment variation received in remote config>
    } else {
        <dismiss splash screen and show next UI screen>
    }
}

使用上面的方法(这是完全直接的IMO)无法正常工作.在调试器和Firebase日志记录启用后,我可以在日志中看到发生了竞争条件问题.基本上,Firebase activateFetched()调用不会在activateFetched调用中同步设置"条件用户属性实验ID",而是在之后的短时间内设置它.因此,我们在activateFetched之后立即触发激活事件不会触发此条件用户属性,并且后续实验漏斗/目标事件未正确标记为实验的一部分(实验甚至不首先激活).

如果我们更改代码以延迟发送激活事件一些任意延迟:

<code that shows splash>

…

[[FIRRemoteConfig remoteConfig] fetchWithExpirationDuration:7 completionHandler:^(FIRRemoteConfigFetchStatus status, NSError * _Nullable error) {

    [[FIRRemoteConfig remoteConfig] activateFetched];

    if (<checks that see if we received info about being selected to participate in the experiment and if local conditions are met for experiment participation>) {

        dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(0.5 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{

            [FIRAnalytics logEventWithName:@"RegistrationEntryExperimentActivation" parameters:nil];

            <dismiss splash screen and show next UI screen based on experiment variation received in remote config>
        }
    } else {
        <dismiss splash screen and show next UI screen>
    }
}

实验的条件用户属性可以事先正确设置并由事件触发(导致实验激活和后续事件被正确标记为实验的一部分).

现在,这段代码显然非常难看并且容易出现竞争条件.保守地将0.5秒的延迟设置为在所有iOS设备上足够,但是¯_(ツ)_ /¯.我已经多次阅读了可用的文档,并尝试查看所有可用的API方法,但没有成功确定开始发送事件的正确点应该是什么.如果该activateFetched方法使用重新配置内部对象的异步过程,则可以期望一种回调方法向调用者指示完成所有操作的时间点,以便重新配置并准备好供应用程序进一步使用.似乎框架工程师在远程配置配置文件激活后需要立即发送激活事件时没有预料到用例...

还有其他人遇到过这个问题吗？我们是否遗漏了API中的内容？是否有更聪明的方式让它activateFetched完成它的东西？

希望一些Firebase工程师也可以用他们的智慧来加入:)

谢谢