数据产品中对导出功能的思考

晌午 2023-07-27 18:16:02

前段时间，产品内上线了一个新的统计模块，出于上线时间的考虑，第一期没有提供“导出”功能，上线后不久就有用户向我反馈需求，产生了如下对话：

用户A：为什么这个新的统计模块没有支持导出功能呢？
产品：想了解下，希望增加导出功能的原因是什么呢？
用户A：这部分数据我要进行本地保存归档。
产品：好的感谢反馈。

从这段对话中，可以了解到用户希望导出数据的目的，是为了进行数据的归档和保存，而这一需求是无法通过产品内部实现的，可以增加“导出”功能以解决用户的问题。

但如果用户A回答，希望增加“导出功能”的原因是：该统计模块提供的数据分析图表太少，他想要导出到Excel后自己进行数据加工；这种情况下，我们应该给用户提供“导出功能”来解决这个问题吗？还是分析用户想要加工的图表是什么，考虑是否通过增加图表来解决用户的问题呢？

这里可以发现和“导出”相关的需求，不能简单的就决定做“导出”，需要进行思考和分辨；本文就想和大家讨论，在数据产品中对“导出功能”的思考。

一、判断用户导出的真实意图

什么是导出？百度百科的定义是，将当前系统中的一批数据输出到系统之外的某个指定位置。

我的理解是——用户将系统内某个模块的数据，通过某一种格式（常见的有xlsx、csv等）输出到本地环境。

首先，我们可以思考，为什么我们要做“导出功能”呢？因为“导出功能”可以解决用户的问题，为用户提供价值，向用户提供了产品外的延伸价值。

第1个价值，导出可以将“用户数据”脱离于产品系统而存在，导出后的数据是独立存放在用户本地电脑上的，可以满足用户做一些系统之外的延展行为。

产品是在不停迭代的，在某一些情况下，产品还无法满足用户需求时，就可以通过“导出”功能来帮助解决，用户希望在产品内进行数据分析；但是产品提供的数据分析还比较基础，满足不了专业的数据分析用户进行分析，这时候如果有“导出”功能，用户可以通过“导出”将数据导出到本地，进行自己分析。

“导出功能”成为了一个平衡产品功能和用户需求之间的过渡，满足用户去做一些当前系统之外的延展行为。

第2个价值，导出可以解决在产品内做不到或者没必要支持的一些用户行为。

因为产品是无法满足用户的所有行为的，有的是做不到，有的是没必要。

用户没有连接网络却希望看到产品内的数据，这是产品“做不到”；用户已经不在为产品付费但仍然希望产品能提供数据查看，这是产品“没必要”。

用户的部分行为是我们产品无法支持的，或者与产品核心价值冲突的；而导出功能恰好可以解决这个问题，一方面满足了用户需求，一方面也避免在一些边缘功能上花费资源。

案例：

一起看下文章开头中用户A的需求，在这之前介绍下该产品的背景，该数据产品是一款线上付费工具。

新增的统计模块展示3个部分，数据查询区域，数据展示区域，数据图表区域，其中：

数据查询区域支持时间查询，最多限制31天；
数据展示区域表格支持分页，每页展示10条数据；
数据图表区域支持图表分析，仅支持折线图

产品经理，产品经理网站

需求1：用户需要进行数据归档

“用户为什么想要导出数据？”

用户希望能将数据导出后进行归档，以应对“离线使用数据”，“停止续费后继续使用历史数据”等场景。

“用户导出数据是用来做什么呢?”

在本地系统内进行保存，进行数据归档。

“有没有其他方案可以来代替导出？”

提供的产品无法支持离线使用，停止续费后用户无法登陆，因此无法满足用户的需求。

那么如果用户的需求转变成如下需求2了呢？

需求2：用户导出数据到Excel后自己进行数据加工

“用户为什么想要导出数据？”

因为用户需要对数据进行一些数据分析工作，而该模块内只提供了基础的折线图，无法满足用户的数据分析需求，用户想要导出后自己做分析。

“用户导出数据是用来做什么呢?”

用户导出数据的目的是进行“数据分析”，由此可见，合适的“数据分析”才是用户的最终目的，“导出”只是用户实现目的的方式。

“有没有其他方案可以来代替导出？”

判断用户需要的“数据分析”程度后，发现用户需要的是简单的图表分析能力，包括柱形图、饼图等在内的一些基础图表，符合本产品大部分用户的价值，可以通过增加“基础图表能力”来解决

通过案例可以发现，收集到用户关于“导出”的需求后，我们需要针对不同的场景进行分析，判断用户需要导出的真实意图。

找出哪些符合“导出”价值的需求：

其一，导出帮助解决了产品无法支持的用户诉求，像是需求1中的用户需要通过导出进行数据归档的诉求，这部分“导出”需求是完全可以纳入到迭代中进行开发支持的。

其二，导出作为了平衡产品功能和用户需求之间的过渡，满足了用户产品之外的延展性需求，比如需求2中“导出”功能可以满足用户将数据导出后自己去做分析，通过“导出”可以满足用户的需求；但这并不是最优的做法，只是一个过渡策略，因为作为一个数据产品，更希望能让用户将数据留在产品内；为此，我们需要分析用户的“数据分析”需求，将符合大部分用户的“数据分析”需求，作为一个功能在产品内进行实现，而比较定制化、个性化的“数据分析”让用户通过导出功能去自行分析。

二、选择同步导出还是异步导出

通过判断用户导出的真实意图后，确定需要通过“导出”功能来解决用户的问题，就需要我们确认具体的导出形式。

常见的导出形式有两种，分别是同步导出和异步导出，分别对应了不同的用户场景，让我们一起来了解下如何选择导出方式吧。

1. 完整导出的流程

在选择导出方式前，我们先需要了解用户完成一次“完整导出”流程所需要经历的环节，一起看下这个用户故事。

用户故事：小明是一个客服主管，在“客服绩效”工具内，查询近30日店铺客服团队中每个客服的值班情况并进行考核，完成之后他需要将数据进行归档；小明点击“导出”按钮，等了一会后，收到导出成功的反馈，通过浏览器下载文件后，小明拿到了导出数据。

从这个用户故事中，可以简单总结出用户完成一次完整导出需要经历的环节，数据查询 -> 发起导出 -> 服务器处理导出任务 -> 反馈给用户导出结果（成功/失败）-> 用户拿到导出数据。

下面我们可以结合这个环节来具体分析“同步导出”和“异步导出”：

2. 同步导出

同步的定义是两个或两个以上的动作在随着时间变化过程中保持一定的相对关系，动作2的执行需要动作1的完成，同步导出可以理解成在导出过程中，环节与环节之间是有保持相关性的。

从一次完整的导出流程看，和用户具有相关性的环节包括“主动发起导出”、“得到反馈结果”。在单个导出任务中，两者是必然具有先后顺序的，得先发起导出任务，才会有导出结果。

那么在多个导出任务中呢？多个导出任务，就会产生多个“主动发起导出”环节和“得到反馈结果”环节；在同步导出下，这些环节与环节之间也是保持相关性的，后发起的导出任务，需要等待前一个“导出任务”返回结果后才能开始进行。

产品经理，产品经理网站

一起来看下客服主管小明的一个案例，小明在周一经常需要在公司管理群内同步上一周客服团队的工作情况，为此小明需要从“系统-统计模块”中不同的菜单导出相关的数据，整合到自己常用的Excel里的周报模版中。

因为，“系统-统计模块”提供的客服数据字段分布在不同的统计菜单内，例如菜单1提供了客服团队的销售数据，菜单2提供了客服团队的工作量数据，菜单3提供了客服团队的值班情况；而小明进行汇报的周报模版是自己公司的一个本公司专属的报表，需要从不同的菜单中导出数据，再将需要的字段填入周报模版中。

在小明的这个场景下，用户导出的所需的时间较短，就通过提供“同步导出”来解决；小明分别在菜单1和菜单2下发起“导出任务”，各个任务按顺序依次进行并反馈结果，小明按发起任务的顺序，先拿到了菜单1的导出数据再拿到了菜单2的导出数据。

这里采用的“同步导出”，考虑到了两个方面的因素，一方面是需要导出的数据都是统计数据，是原通过始数据加工后的结果，数据量较小；另一方面，导出的时间维度短，多为周和日的维度，也使得数据量变小。

从这里我们可以看出，同步导出适合“导出数据量较小”的场景，帮助用户按顺序拿到导出结果数据。

3. 异步导出

异步的定义是两个或两个以上的动作不需要共同的时间关系，动作2的执行不受动作1的影响，异步导出可以理解成在导出过程中，环节与环节之间不一定具有先后顺序。

同样的，单个任务的导出中，“主动发起导出”势必在“得到反馈结果”之后，而在多个导出任务中，后发起的导出任务，不需要等到前一个“导出任务”返回结果才能开始进行。

产品经理，产品经理网站

仍然通过小明的工作案例来回顾下“异步导出”的使用场景吧——小明日常工作除了绘制周报以外，还有一个周期性的工作，需要在每个月的月末对“明细数据”进行导出归档；而“明细数据”也是分布在系统内的不同模块中的，例如“订单明细”、“聊天明细”、“在线明细”等，小明需要从不同的菜单下载这些数据，然后再统一进行数据归档。

在该场景下，系统通过“异步导出”来解决，小明分别在“订单明细”，“聊天明细”，“在线明细”下发起了导出任务，各个任务同时进行；并根据文件大小先后完成下载，小明按文件量大小的顺序，先拿到数据量小的文件，再拿到了数据量大的文件。

这里采用“异步导出”是因为，一方面在明细模块的导出动作是多个的，包括和订单相关的明细，和聊天相关的明细等等；另一方面，小明导出的时间维度较长，常以月作为单位。

多个任务加上部分文件数据量大的情况下，如果采用同步导出，就会导致任务与任务之间需要互相等待；而“异步导出”能够支持多个任务互不干涉，很好的解决了这个问题。

从这我们可以得出——异步导出适合“数据量比较大”的场景，帮助用户解决任务与任务之间互不干涉的问题。