使用移动A/B测试，您可以在不编写代码的情况下测试应用程序的更改。您可以衡量对任何转换的影响，例如注册或购买。在本社区提示中，我们将提供在iOS或Android应用程序中运行a/B测试的演练和最佳实践。安装程序要开始进行移动A/B测试，您只需要在应用程序中安装并初始化Mixpanel SDK。如果您还没有完成这一步，您可以跳转到我们的iOS集成文档或Android集成文档来获取有关安装Mixpanel的说明。要处理复杂的A/B测试，这些测试超出了修改UI元素的范围，例如更改视图流、修改定义的常量等等，您需要在应用程序中实现开发人员调整（iOS/Android）。调整允许您从Mixpanel面板的舒适性调整代码中的实际变量。一旦向代码添加了调整，当连接到a/B测试设计器时，它将出现在Mixpanel UI中。需要注意的是，不同的UI元素具有不同级别的可调属性。下面是使用a/B测试修改iOS UIKit基本内置元素的不同方法的快速参考。创建A/B测试我们打算借用丹青的开源游戏2048，假装这是我们令人难以置信的上瘾游戏。到目前为止，我们对这个应用程序了解到的一点是游戏运行速度很快。因此，我们有一个假设：如果我们能让瓷砖移动得更快，用户将玩更多的游戏，这将导致他们更多地返回我的应用程序！让我们创建一个使用Mixpanel的移动A/B测试来测试这个假设的实验。我们在游戏中设置了动画速度的变量作为一个调整，我们可以在a/B测试中进行调整。我们为用户创建了三种变体：正常速度比一般人快真的很快先测试一下你的实验一旦你创建了变体，最好在你的应用程序中测试这个实验，以确保a/B测试按照你计划的方式执行。由于这只是一个测试，所以您需要确保您是唯一一个提供该实验的用户。您可以通过在A/B测试中确定自己的目标，使用电子邮件等唯一标识符进行筛选。一旦你点击"保存并运行"实验将排队发送到你的设备，我们可以跳转到应用程序直接测试它。为了确保您可以看到Mixpanel SDK获取新的A/B测试并将它们应用到您的应用程序中，请在应用程序中启用调试和日志记录（iOS/Android）。启用调试和日志记录后，您现在可以看到Mixpanel库在应用程序运行时执行的所有幕后操作。例如，我可以看到我的应用程序变为活动状态，然后库检查是否有任何实验。日志甚至会显示从我们的服务器检索到并最终应用于当前用户的原始实验数据。在你的实验被彻底测试之后，你准备好向大众发布它！分析结果在Mixpanel数据中记录实验信息有几种方法："实验开始"事件：在向用户提供设备上的实验时跟踪此事件。因此，您应该将此事件用作占位符，以了解何时实际已将实验部署到设备上并对用户处于活动状态。"实验"超性能：这个超级属性存储了用户曾经接触过的所有实验和变体的列表。由于超级属性将附加到所有后续事件中，因此您可以通过先前显示用户的实验来筛选报告。最终，这两个工具为您提供了分析实验数据的独特方法。如果您希望查看基于活动实验的统计信息，则应该使用"实验已开始"事件，并将"实验Id"属性设置为要分析的实验。如果您希望看到暴露在前一个实验（不一定是活动的）中的用户的行为，可以使用"实验"属性并按特定实验进行分段。还记得我们的2048游戏速度实验吗？通过利用"实验开始"事件和"实验"属性，我们可以创建一个保留报告，看看是否有更多的人使用不同的游戏速度返回我们的应用程序！在这个例子中，从长远来看，我们的第二个变体将用户带回了稍多的地方。掌握了这些知识后，你就可以对代码进行更改，这样你的实验中的获胜值现在就被设置为应用程序下一个版本中所有用户的默认值。最佳实践多个变体A/B测试创建多个实验孕育了一个测试环境，这使得找到任何转换改进的根本原因变得困难。我们建议进行针对性的测试，并在开发新的代码方面进行决定性的改进。让我们把这个概念应用到前面的游戏中。在我们的实验中，我们可能需要A/B测试多个东西：一个整数代表速度，一个布尔值代表夜间模式，一个文本值代表你输了的消息。在这个场景中，您应该在Mixpanel中创建一个A/B测试，每个不同的调整值都作为它们自己的变体。不应为每个调整值创建一个测试。以这种方式创建测试的结果是，您将能够将所有这些场景相互比较，从而最终确定哪个因素会导致最佳转换。不要把一个变体作为你的第一个观点当应用程序打开并初始化Mixpanel SDK时，默认情况下，我们的库将从服务器请求实验信息。我们努力优化我们的服务器响应时间，然而，重要的是要注意，在你的初始应用程序打开你不会立即收到一个实验。这样做是为了防止在应用程序中使用此功能时由于延迟而导致的性能问题。如果您希望在初始应用程序视图上进行A/B测试，那么Android和iOS的过程是不同的。对于iOS，您应该启用选项checkForVariantsOnActive（默认情况下启用）以在应用程序打开时获取数据，然后在从服务器检索到实验信息后使用joinExperiencesWithCallback方法应用实验信息。对于Android，您应该使用addOnMixpanelUpdatesReceivedListener来了解何时有可用的测试数据，然后使用joinExperienceAvailable（）方法将实验应用于视图。在使用这种类型的A/B测试时，不要忘记考虑传递延迟，因为延迟无法解释，可能会导致最终用户体验不佳。绑定调整（仅限iOS）A/B测试的位置参数值只有在您进入实验并执行该调整的代码块后才会被分配。在此之前，调整将显示为默认值。最佳实践是使用mptwakbind在收到测试后立即应用调整值：UILabel*label=[[UILabel alloc]init]；mptwakbind（label，text，@"label text"，@"Hello World"）；现在，当这个调整被更改时，您将立即看到应用于给定对象和属性的位置参数的新值。这允许你在整个应用程序中安全地使用调整，而不必担心实验中的调整值是否已经应用。静态属性的目标用户我们的iOS库对事件和配置文件更新进行排队，这些请求每60秒刷新一次，或者在应用程序的后台处理。这意味着，根据应用程序打开时尚未设置的人员属性，协调针对用户的实验目标是很困难的。以一个实验为例，这个实验是为了在新的应用程序发布后显示某个特性，其中目标标准是"app Version"的属性等于2.0.0。它需要一个people set调用来更新"App Version"属性，并对属性更新进行队列刷新，这样用户才有资格进行实验。A/B测试将不会显示，直到用户在下一次重新启动应用程序时点击一个新的decise调用。在这样的场景中，你要么必须对应用程序生命周期中稍后应用的测试感到满意，要么利用A/B测试目标来简单地针对所有用户进行测试，这样它就可以更快地交付了。A/B测试、分析、修改、重复虽然在上面的设置一节中强调了这一点，但必须重申，为了有效地使用A/B测试，您不应该让实验无限期地运行。相反，您应该A/B测试应用程序的一部分，分析实验结果，然后对代码进行适当的修改。如果您对运行的每个A/B测试以相同的方式重复上述过程，随着时间的推移，您的应用程序UX将根据A/B测试结果进行改进，并且您将能够在应用程序的其他部分继续运行其他A/B测试。对在应用程序中设置和使用Mixpanel mobile A/B测试有疑问吗？伸出援手support@mixpanel.com跟聪明的人说话，快。