我们如何通过重新考虑邀请来增加Sentry的月度活跃用户
在其核心部分，Sentry是一个提醒您注意生产软件中的缺陷的工具。但它所做的不仅仅是将堆栈跟踪放入您的收件箱：Sentry提供了强大的工作流来帮助您的团队确定根本原因，对您的团队进行分类，并通过评论和通知跟踪持续关注的问题。
这些协作功能可以帮助您快速解决软件问题。但这里的关键词是协作；如果您的整个团队无法访问Sentry，您可能会发现自己很快就会被无休止的积压问题淹没，而且没有人可以帮助。
2019年底，成长团队把让我们的用户更容易邀请队友加入他们的哨兵作为我们的使命。为达致这个目标，我们处理了三个截然不同的范畴：
扩展Sentry的权限模型，允许更多类型的用户发送邀请。
我们的理论是：改善邀请用户的用户体验，并将流程民主化以包括所有团队成员，将显著增加整个团队的采用率。(旁白：的确如此。)。
在深入了解我们所做的更改及其对底线的影响之前，让我们快速回顾一下用户邀请是如何工作的：您在下面看到的Add Member to Organization页面。
这种隐藏在Sentry账户设置中的整页体验存在一些问题：
因为这是一整页，读到它就意味着你会被断章取义，不管你之前在做什么。
邀请多个用户时，您只能将组分配给相同的角色和团队集合。
有趣的是，为了提高可发现性，我们以前引入了一些“快速链接”来更容易地访问此页面。但这些链接分散在应用程序中，当用户发出邀请成员意图的信号时，它们不会出现在上下文中。
这些用户体验和发现挑战感觉就像是显而易见的起点。但是，我们决定从头开始重新思考整个体验，而不是仅仅满足于一种新的“改进”形式。
我们的第一反应可能并不令人惊讶，我们的第一反应是将这个页面转换成一个模态页面，它设法将前面展示的所有功能都压缩到一个更小、更简洁的体验中。它实际上做得更好：模式更清楚地表明您可以邀请多个用户，并允许您为每个被邀请者设置唯一的权限。
虽然在Web应用程序中有时会过度使用模态，但我们相信这种方法将解决关键的可发现性和导航问题：它可以在不离开当前页面的情况下在上下文中显示，并且完成表单会返回到您正在做的事情。
在这一点上，我们另外引入了按钮，以便在整个Sentry中以上下文方式启动邀请新成员模式：
查看问题并注意到同事的可疑行为？如果他们还不是您的哨兵组织的一部分，您现在可以当场邀请他们。
尝试将问题分配给团队成员，但在受理人列表中看不到他们的名字？现在，您可以在下拉列表中选择邀请他们。
创建一个新团队？现在，您可以随时随地直接邀请新成员加入该团队。
当我们开始在整个应用程序中推出新的“邀请新会员”体验时，我们清醒地认识到：只有大约一半的哨兵用户可以实际使用我们的新模式。这是因为从历史上看，只有拥有所有者或经理级别权限的人才能邀请其他团队成员。拥有这些权限的用户加起来占活动用户的比例不到50%。
限制向帐户管理员添加新用户的能力是软件工具的常见做法，Sentry也不例外。当一名员工加入一个新团队时，通常会看到这样的交流：
艾丽斯：太棒了，我们用的是哨兵。你能把我加进这个组织吗？鲍勃：啊，我不能邀请你。也许问问珍？
在完美的情况下，会找到您的一名管理员，他们会手动将新的队友添加到帐户中。但有时那个人是不知名的，或者在度假，或者可能需要几天、几周甚至几个月的时间。
我们开始问自己：如果我们可以释放团队成员来快速跟踪整个过程，并邀请成员自己，会怎么样？这导致了我们的下一个重大变化：更新我们的权限模型，允许成员请求邀请其他成员。
现在，当非管理员打开邀请新成员模式时，它会根据上下文更改为“请求邀请”，而不是直接邀请。点击“发送”会向所有组织管理员发送一封电子邮件，提示他们批准任何未完成的请求。
在这一点上，我们已经建立了我们认为是非常棒的新用户体验，我们刚刚将可以利用它的用户数量增加了一倍。但这种开放用户邀请的做法让我们思考：如果还有更多我们没有接触到的未开发用户呢？
在上一节中，我们重点介绍了一个场景，其中一个队友请求另一个队友访问Sentry。由于我们最近的变化，用户可以请求自己邀请他们的团队成员，而不是必须跟踪并询问他们的帐户管理员。
但是这个场景仍然有一个把关元素：新的队友必须向另一个队友请求访问权限。如果新队友发现来自斯莱克哨兵的警报源于他们最近的变化，而周围没有人授予他们访问权限，该怎么办？不幸的是，他们会落在认证墙上，这会阻止他们走得更远。
这就提出了一个问题：是否有未开发的潜在用户来源，我们没有通过将邀请限制为活动哨兵用户来接触到？如果新用户根本不需要询问任何人会怎么样呢？
因此，为了让这个聚会继续进行，我们深入研究并额外允许外部用户请求加入组织。
现在，当用户登录到组织的登录页面时，他们可以选择“请求加入”，这将要求提供用户的姓名和电子邮件地址。点击Send(发送)后，组织所有者将收到一封电子邮件，提示他们批准加入请求。以防万一，还要求他们的组织完全禁用该功能。
在开发了一个新的上下文邀请模式和两个对邀请友好的权限更改之后，我们确信这些更改将对用户行为产生强大的影响。现在是时候把我们的钱放在我们的代码所在的地方了，并验证所有这些艰苦的工作是否真的起到了作用。
我们验证产品变更有效性的标准程序是通过A/B测试(也称为拆分测试)。这意味着利用我们的应用程序代码在同一时间段内为不同的用户群提供不同的体验，并比较结果。这一步需要额外的努力，但这是值得的-因为另一种选择是满足于数据的前后快照，这太容易受到季节性或营销推动等外部因素的影响。
ℹ️要了解更多关于我们如何在哨兵执行A/B测试的信息，请参阅之前的这篇博客文章。
A/B测试很容易让人忘乎所以，而且有太多的排列，以至于你没有足够的数据在统计上有意义。因此，为了简单起见，我们决定所有的治疗都将获得新的模式体验，我们的“治疗”小组将专注于新的许可更改。
这样我们就有了4种不同的治疗方法，我们向4个同等规模的客户群推出了这4种治疗方法：
我们确定成功的主要标准是：这些处理中的哪些会增加被接受的邀请(从而增加新用户)？
接受同时启用邀请请求和邀请治疗请求的用户增加21%。
允许更多的用户邀请团队成员可能会导致更多的用户邀请团队成员，这可能并不令人惊讶。同时启用这两个功能集甚至更好(考虑到它们相辅相成)，这可能也就不足为奇了！
让更多的用户加入您的平台固然很好，但是如果这些用户从未真正使用过产品，那又有什么意义呢？要真正相信我们的改变是成功的，我们还需要确保治疗组中的受邀者确实在使用Sentry。
在内部，我们认为“活跃用户”是那些在30天内与产品有意义地互动的人(而不是刚刚登录)-例如，查看或分类问题。在基线处理中，用户在以71.3%的比率接受邀请后变得活跃。在其余的治疗组中，这一数字从72.7%到78.4%不等。
第一个有趣的观察是，尽管我们让邀请用户变得更容易，但邀请的总体接受率实际上是上升的。这与转换优化项目在漏斗的一个部分改进指标的趋势背道而驰，而牺牲了漏斗中进一步向下的其他指标。这可以归因于在新的流程中邀请了更多合格的用户。
第二个观察结果是，INVITE VARIANT的请求明显优于其他VARIANT。我们的猜测是，这是因为成员邀请他们的团队成员进行协作是获得新的敬业用户的最好方式之一。
在积累了足够的数据来对我们的结果充满信心(并发布上面的数据)之后，我们最近关闭了A/B测试，并向所有组织推出了这些更改。如果您是任何组织的Sentry用户，现在您将发现这些新的上下文邀请链接和邀请友好的权限更改可供使用。
最初是一个简单的项目来改进我们的邀请UX，后来扩展到包括有意义的权限更改，这些更改显著提高了新用户加入和使用Sentry的速度。我们没有部署任何诡计或“增长黑客”来实现这些结果；我们只是通过避开用户并让他们解决自己的问题来使产品变得更好。作为产品开发人员，没有比这更令人满意的了。
该项目是我们多学科发展团队的共同努力：Evan Purkhiser(软件工程师)、Megan Heskett(软件工程师)、John Manhart(设计师)、AJ Jindal(增长负责人)和Adhiraj Somani(产品经理)。
哨兵的成长工程团队正在招聘！如果您有兴趣帮助我们使用数据改善Sentry的入职、用户体验和整体采用率，我们很乐意与您交谈。请查看我们在https://sentry.io/careers/.上的公开职位
