设计导出功能，这三点需牢记

编辑导读：导出功能是产品中的常见功能，虽然能满足用户数据导出的需求，但是也存在着数据安全的风险。那么，在设计一个导出功能时应该考虑些什么呢？本文将从三个方面对此展开分析，希望对你有帮助。

先来看一个假设的场景，小明是某B端数据产品的产品同学，前段时间收到了很多用户关于“导出”功能的需求反馈，分析后得出增加导出功能可以解决用户的问题，为用户带来价值。为此花了一个迭代周期，上线了导出功能。

但是功能上线后，就收到了用户不好的反馈，用户认为“导出功能”虽然解决了数据导出的需求，但是增加了他们关于“数据安全”的风险，产品内的任何账号都可以进行导出动作，无法对账号进行“是否可以导出”的管控，会存在数据泄漏的风险。例如员工A在真实业务场景中不被允许直接拿到买家数据，但员工A通过“导出功能”拿到了订单明细中的买家信息，泄露给竞争对手后导致买家流失，从而造成了业务团队数十万甚至上百万的损失。

为了避免造成损失，用户只好暂时停止使用该产品，希望尽快解决这个问题，甚至有可能造成该用户转用其他产品从而造成了流失。这个场景下，就是小明同学在设计导出功能时，缺少了对“导出权限”的思考，导致原本希望帮用户解决问题的功能，反而给用户带来了损失，也给整个产品带来了损失。

“导出权限”是我们在设计导出功能时具体需要关注的点，事实上，除了“导出权限”外，在整个导出流程中，我们需要注意的点还有很多，本文想从“导出前”、“导出中”、“导出后”3个环节和大家讨论分析需要注意的点。

导出前的定义，即用户在发起导出（点击导出按钮）前这个环节，那么设计导出功能在这一环节需要考虑什么呢？我认为需要考虑2点内容，一是“导出权限”的思考；二是“导出颗粒度”的思考。

在设计导出权限的时候，首先可以思考的是“用户是否可以导出”，即用户能否通过“导出”功能将产品内的数据导出到本地，具体分为两种结果，可以导出与无法导出，而在具体的实现方案上通常会有两种做法。

第一种是对“导出”功能做按钮级别的控制，通过控制了用户是否可见“导出”，从而实现控制“用户是否可以进行导出”，但是并没有对导出数据进行控制，意味着用户只要有导出入口，就能导出所有数据。这种做法优点是配置简单同时传递给用户的也便于理解，只需要对不同账号设置是否有“导出”即可，有“导出”就能导出数据。但是无法对导出的情况做更精细化的区分。

第二种是利用“数据”来实现对用户导出结果的控制，当用户拥有某一数据权限时，就可以通过“导出”拿到这部分数据，但是并没有对“导出”进行控制，用户都可以见到“导出”并使用“导出”，最终导出可见的数据，就是用户数据权限可以见到的数据。这种做法的优点，可以对“导出”结果做更精细化的区分，比如有个人数据权限的用户能导出个人数据，而有个人、团队数据权限的用户能导出个人和团队的数据。但是需要依赖产品内有成熟的数据权限，用户对于该方式的感知也没有那么直接，需要用户去理解“有某一个数据权限就能导出这部分的数据”这层意思。

这两种做法的差异在于，“导出”是否透出给用户可见，以及控制全部数据还是部分数据。在实际业务场景中，这两种做法通常是组合使用的。

案例：

一起来看一组案例，某公司自建了一款地推工作台的应用，方便“地推团队”日常工作收集信息。地推成员通过“工作台-新建客户”录入客户线索，字段包括：客户姓名、客户规模、客户电话、客户地址、客户等级等字段。

地推主管通过“客户信息”菜单审核收集上来的客户线索，审核结束后，财务来计算地推成员的绩效，财务提出希望可以增加“导出”功能，方便直接导出数据后在Excel内进行统计计算。

在这个案例中“地推主管”和“财务”都可以看到客户数据，而两个角色的区别在于“财务”需要将数据导出到本地进行绩效核算，“地推主管”不需要将数据导出。所以产品团队在“客户信息”菜单增加了一个导出按钮，并对“导出”按钮做了控制，财务角色的账号拥有“导出”权限，地推主管角色没有“导出权限”，这就是对“导出”功能做按钮级别的控制在实际场景中的应用。

后来公司业务发展，地推团队不但需要收集客户线索，还需要对“审核通过”后的客户线索进行日常跟进和回访。对于地推成员，需要在“客户信息”菜单查询地推主管审核后分发给自己的客户线索，并将数据导出到本地后打印，方便外出拜访客户时可以用纸质携带客户资料。因此也需要导出权限，但是当前产品通过“按钮”来控制导出权限的做法，只能实现所有客户线索的“可以导出”和“不可导出”，为了避免地推成员拿到全部客户线索后，出现互相抢单的情况，在现有功能下只能赋予“地推主管”导出权限，地推主管导出数据后再去进行逐一的分发。

为此，产品团队，在“地推工作台”内增加了个人数据权限、团队数据权限，并通过“数据权限”来进行导出控制。最终通过赋予“地推成员”拥有“个人数据权限+导出权限”，来实现地推成员只导出个人的数据，这是利用“数据”来实现对用户导出结果的控制在实际场景中的应用。

另外，对于“导出权限”除了“用户是否可以导出”的思考外，还需要思考“导出用户的真实性”，即二次验证环节，验证当前用户的安全性。

导出的数据中很可能包括项目的核心内容，关系到公司安危，其重要性也衍生了一些通过违法手段获利的行为，比如模拟账号登入盗取数据、套用他人账号进行导出等。

因此我们在实际触发导出任务前，可以增加一个二次验证，验证该导出行为是否是账号本人操作，常见的包括“设置的安全码验证”、“绑定的社交账号验证”等，最大可能的保障数据的安全性。

通常的，通过“导出功能”可以把页面上的数据，导出到本地环境，但是如果用户想要导出的数据是下钻的呢？在页面上查询得到的数据是1-3月每个月的汇总数据，但用户想要导出每个月份下每一天的数据，即1.1-3.31号每一天的数据。这里出现了不同的颗粒度，如果导出1-3月每个月的汇总数据，就是按月颗粒度导出数据；如果导出1.1-3.31号每一天的数据，就是按日颗粒度导出数据。

由此可见，导出颗粒度是存在相对关系的，比如大小关系，从上文的导出时间维度看，按月导出是大颗粒度，而按日导出是小颗粒度。当存在多个导出颗粒度时，就跟需要详细标明不同导出的数据颗粒度，让用户明确感知到通过“导出”可以拿到的数据颗粒度是什么，这也是我们需要在“导出前”环节思考的。

通过一个案例来看一下吧，某电商后台“商品分析模块”，提供了两种导出形式的数据，形式1，提供商品一段时间的销售额之和；形式2，提供商品一段时间每一天的销售额。

这里也出现了不同导出颗粒度之间的相对关系，在相同时间段内，同一个字段，形式2导出的数据加起来，就等于形式1导出的数据。由此可见形式1导出的是商品一段时间内的汇总数据，而形式2导出的是商品一段时间内的明细数据，这就是两种不同的“导出颗粒度”，需要我们通过文案来透出两者的区别，帮助用户明确理解通过哪一种形式可以拿到怎么样的数据，常被用于同时存在“多个导出”的场景下使用。

文章开头，小明提的简单的导出方案，已经包括了“导出环节”中发起导出入口，导出结果反馈等部分，导出中的主体流程通常都是被大家注意并且重视的，这里想要讨论在导出中需要注意的是一些细节，这些细节给用户带来体验的提升。

用户通过导出拿到的数据字段，常见的是和页面展示的字段保持一致的。但在实际业务场景中，用户想要的导出字段存在比页面上少或者多的情况。

先来看下，用户想要导出的字段比页面上少的场景。出现这种场景的原因是，页面提供的内容是为了满足不同用户的需求而存在的，所覆盖的业务比单一用户多的多。

以常见的“销售记录”为例，销售记录中有订单相关、用户相关、商品相关等字段，不同字段的组合可以满足用户的需要，但是对于单一用户来说，部分字段与它所关心的业务无关，这部分字段对于该用户来讲就是多余的，用户A只关心销售记录中的订单数据，导出后得到的商品相关字段可能就会变成一种负担，需要用户去进行删除，从而增加了用户的操作成本。

系统提供可导出字段为m个字段，比如字段1、字段2、字段3 页面展示的字段为n个字段，比如字段1、字段2、字段3 这里m=n，页面展示的字段即为系统支持用户导出的字段 当用户实际使用的字段x≤n=m时，就是用户想要导出字段小于页面的场景

再来看下，用户想要导出的字段比页面上多的场景。出现这种场景的原因是，页面提供的内容是有限的，展示太多字段会出现滚动条并且导致增加用户查找某一字段的成本，因此页面上展示的字段通常是覆盖目标用户群体的大部分需求而存在的，这就会造成一个问题，导出字段如果和系统支持导出一致，会使得部分字段对于大部分用户来说是无效字段；导出字段如果和页面支持一致，使得小部分用户得不到“系统提供但是页面之外”的字段，使得该部分用户的需求无法被满足。

系统提供可导出字段为m个字段，比如字段1、字段2、字段3、字段4、字段5 页面展示的字段为n个字段，比如字段1、字段2、字段3 这里m>n，页面展示的字段小于了系统支持用户导出的字段 当用户实际使用的字段n