经验梳理：用户研究中对流失用户的回访

今天，产品经理小组谈到了用户研究的问题，只不过是问卷、用户访谈等方法，都是战术操作，在战略层面，我们都知道研究是为用户研究服务的。用户研究的话题可以大也可以小。讨论的维度至少应该是产品、技术和操作的三个维度。无论单独讨论哪个方面，都需要结合相应的产品背景、团队、人群等，然后提出有针对性的建议和方法。几乎不可能在短时间的讨论、思考和总结中得到一个普遍的结果，可以解决每个人的问题。因此，如果你今天想总结和分享，你只需要在用户研究中回访失去的用户。以前段时间做的流失回访为背景，梳理经验。希望能给大家带来一些帮助或启发。产品背景：我们团队的产品是企业SaaS服务。目前的表现形式是*表格，用户可以在我们的平台上实时填写、共享和协调多人数据。嗯，我做B2B。在用户增长方面，产品应用于GrowthHacker中的“AARRR“模型，简单来说就是从用户获取、激活、留存、盈利、传播五个维度，在不同阶段有针对性地改进转化，形成良性循环。目前，在获取方面，产品每天都有固定的增长，但在激活和保留方面面临着相当大的挑战。这两个转化率可能只有不到50%，用户的整体增长和积累已经到了平稳期，产品日积月累的弊端也开始显现。如果方向不改变，产品很可能会在不知不觉中下降。回访目的：发现用户激活和保留产品存在的问题，规划产品未来迭代周期的发展方向。使用研究方法：让我们从小团队开始。只有10人，没有足够的资源和时间专门做研究。因此，我们只花了一天的时间在产品的关键节点上进行回访。受各种特定因素的影响，我们最终选择了最简单、最直接的方式——电话回访。每种用户访谈方式的数据分析基础都有其局限性和优势。但无论如何，数据分析都是最Base的。写脚本，问用户的问题，再到最后的统计分析，都是基于数据的。在这次回访中，数据分析有三个维度：定义用户丢失的每个产品都是不同的。就我们自己而言，我们所做的是表格，所以定义用户丢失的基本点主要包括：用户创建的表格数量、每个表中的数据量和表格共享合作的次数。不需要太多的数据，抓大放小，这三点基本上可以覆盖80%的用户使用。选择用户什么时候离开你的时间节点，这一点极其重要，很多产品都不知道为什么要死。还是找三个最重要的数据:第一次登录时间点，最后一次登录时间点，两个时间内的登录次数。结合以上两种数据，流失用户可以分层大致划分流失用户的层次，定义游客用户、初级用户、中级用户和重度用户。根据这些条件，SQL可以直接从后台筛选出相应级别的用户。我们选择了每个级别的100个用户，然后打开它们。访谈脚本写作(图片来自百度UED)在拨打电话之前，必须清楚地知道你想在对话中获得什么信息，这就是访谈脚本存在的意义。首先，在我们自己的平面上，我们想要什么样的信息，解决什么样的问题？针对这些要点，将相应的问题分解成小块后，我们会从自己切换到用户的角度来考虑问题，从而设计出我们想提出的问题，把这些问题整理成树枝，然后整理成大纲，采访脚本就出来了。以本次采访为例。使用上述方法，每次对话获得的信息如下：问题类别：在本次采访中，我想得到的最终答案是，PC和移动用户在使用中损失的原因是什么，以及它们的用户特征有什么不同？为了制定未来的产品线规划。结合产品现状，选择了稳定性、易用性、功能不全、功能过多四类问题。应用场景：用户在什么情况下使用我们的产品，用它来做什么？具体问题：用户在使用中遇到了哪些具体问题？详细谈谈，尽量了解每一个细节。竞争产品信息：用户是否使用过类似的产品，因为其他人很好？为什么走？脚本:沟通技巧问什么已经很清楚了，但是能不能问就看沟通技巧了，专业上就是脚本。说话是每个Sales必备的基本技能，做过Marketing的产品经理应该并不陌生，简单来说就是说话的艺术。对于产品经理来说，学习基本的同理心足以应对如此简单的回访。或者这个例子，当我想咨询用户使用产品功能时，如果我从自己的角度来看，沟通肯定会疏远。在换位思考之前，对话可能是：之后的对话基本上毫无意义。当我们站在对方的角度时，对话会更有效率和自然地得到我们想要的信息：然后有针对性的唠叨。这样一套简单的话，不仅仅是问题类别，使用场景，具体的问题几乎都出来了。稍微聊一点，竞品信息也没什么好说的。在不断的沟通中，演讲也需要有针对性的总结，涉及行业知识的各个方面，是一个非常大的系统，感兴趣的朋友和他们周围的Sales聊天会非常有收获。访谈结束后，我们必须将平面切换到自己的角度，分析数据，抽象整理和呈现，总结，得到产品想要的，解决最终问题。总结大概就是这样，最后多提一下产品经理的能力培养。用户回访似乎只是一次流失，包括PM的产品思维、技术基础和言语技巧。很多PM看起来很杂，但实际上确实是。可以成为团队的灵魂还是附庸，看PM自己想成为什么样的PM。嗯，墨水就在这里。欢迎留言交流