如何合并并统计多个 CSV 文件中的记录

核心要点:

  • 在多个 CSV 文件中统计记录不仅仅是一个计数任务;它需要一个主列表、明确的匹配规则以及一种保留每个记录来源 CSV 的方法。
  • 可靠的工作流在汇总之前将每次导出合并为一个可追溯的表,以便每个计数都可以追溯到源文件,并检查是否存在重复或缺失的记录。
  • 匡优数言可以处理多文件 CSV 工作流(包括上传 30 多个文件),然后根据自然语言指令进行合并、计数、标记缺失记录并生成汇总报告。

当每个系统、查询、营销活动或报告周期都导出为独立的 CSV 时,难点不在于计数。

难点在于如何在不丢失数据含义的情况下合并这些文件。

本文基于一个真实的 Super User 上的问题:如何跨不同的 CSV 文件合并和统计条目。该用户有一个包含电子邮件地址的主 CSV,以及 50 个或更多查询 CSV 文件。每个查询文件都包含回复该查询的电子邮件地址。期望的输出是一个主列表,其中每个电子邮件地址都有一个计数,显示他们回复了多少个查询文件。

这是一个非常实际的电子表格问题。每当团队为每个调查、营销活动、查询、产品、供应商、工单队列或报告周期导出一个 CSV 时,就会出现这种情况。

有些用户出现在每次导出中。有些只出现几次。有些查询文件可能有不同的表头。有些回复可能是重复的。有些预期的用户可能从未出现。问题听起来很简单,但工作流程却很混乱。

有用的输出不仅仅是一个数字。它是一个汇总报告,显示哪些记录匹配、它们出现的频率、它们在哪些文件中缺失以及哪些行需要审查。

同样的问题也出现在混乱的 RSVP(报名)列表中:一个文件可能使用 Yes,另一个使用 Y,还有一个使用 X。对于用户回复报告,这些变体在计数被信任之前必须标准化为回复状态规则。

计数前具有不一致回复值的混乱响应数据

从准确的源结构开始

对于这类问题,通常有两种文件:

文件类型 示例列 用途
主用户列表 email 最终输出中应出现的完整用户列表
查询回复文件 email, reply 每个查询一个文件,包含已回复的用户

最稳妥的输出不仅是 emailreply_count(回复计数)。更好的输出通常包括:

  • email (电子邮件)
  • 该电子邮件回复的查询文件数量
  • 该电子邮件出现的源文件列表
  • 该电子邮件缺失的预期查询文件列表
  • 重复回复标记
  • 审查备注

这种结构在回答用户真实问题的同时,保持了结果的可审计性。

在合并前定义计数规则

在合并任何内容之前,先定义计数的含义。

你想统计的是:

  • 每个用户在所有文件中的总回复数?
  • 每个用户出现的文件数量?
  • 每个查询组的回复数?
  • 每次导出的唯一用户数?
  • 日期范围内的回复数?

这些是不同的报告。

如果计数规则不明确,你最终可能会得到一个看起来正确但回答了错误问题的表格。

例如,如果同一个电子邮件在 query_07.csv 中出现了两次,这应该算作一个已回复查询还是两个回复行?对于原始问题,可能的业务规则是每个查询文件每个用户计一次。这意味着同一个文件内的重复项应该被标记,而不是盲目地计算两次。

在构建工作簿之前,用通俗易懂的语言写下规则。

先盘点 CSV 导出文件

将每个文件视为一个可能与其他文件不完全匹配的数据源。

对于每个 CSV,记录:

  • 来源或查询名称
  • 日期范围
  • 行数
  • 用户标识符字段
  • 回复字段
  • 文件特定过滤器
  • 缺失列
  • 重复记录
  • 命名不一致

这一步通常会揭示真正的问题。有些文件可能使用用户名,而另一些使用用户 ID。有些可能每个回复占一行,而另一些可能每个用户占一行并带有计数统计字段。

如果字段不一致,计数逻辑就会出错。

在计数前规范化用户身份

用户名不是稳定的标识符。

如果可能,请通过唯一 ID 而不是显示名称进行统计。如果只有名称可用,请创建一个规范化的映射表:

  • 大小写
  • 空格
  • 标点符号
  • 别名
  • 备用拼写
  • 缺失的前缀或后缀

当一个用户出现在许多 CSV 文件中时,这一点尤为重要。一个不一致的名字可以将一个人拆分为两个不同的计数。

如果不存在稳定的用户 ID,请在报告中注明。计数可能仍然有用,但确定性较低。

如果最终输出需要审查和共享,而不是仅作为原始表格保留,那么这里是引入轻量级 AI 报告工作流的好地方。

在汇总前构建合并表

不要直接跳转到总计。

首先将文件合并到一个包含以下列的工作表中:

  • 源文件
  • 用户 ID 或规范化的用户名
  • 回复计数
  • 回复文本或状态
  • 日期
  • 查询或组标签
  • 审查标记

数据合并后,你可以计算:

  • 每个用户的总回复数
  • 每个用户的文件计数
  • 每个文件的平均回复数
  • 缺失的文件参与情况
  • 异常用户
  • 重复记录

这种结构使报告更易于审计。它还为你提供了一种将每个汇总行追溯到源 CSV 的方法。

对于回复计数报告,合并后的工作表可能如下所示:

源文件 email 原始回复 是否计入 审查备注
query_01.csv user1@example.com yes yes 匹配成功
query_12.csv user1@example.com replied yes 同义词映射
query_18.csv user2@example.com blank no 空回复
query_22.csv user3@example.com yes review 同一文件中有重复邮件

然后主汇总表可以如下所示:

email 已回复查询文件数 已回复文件列表 缺失文件数 审查备注
user1@example.com 18 query_01, query_03, query_12... 32 正常
user2@example.com 0 blank 50 未发现回复
user3@example.com 7 query_02, query_04, query_22... 43 query_22 中有重复

每月报告前的 CSV 数据质量检查

单独审查缺失的用户

缺失的用户不应在计数中消失。

如果一个用户出现在一个文件中而没有出现在另一个文件中,这可能是正常的。或者这可能意味着导出不完整。

为以下情况创建一个单独的审查列表:

  • 在某些文件中缺失的用户
  • 预期用户没有记录的文件
  • 标识符不一致的用户
  • 行数异常的导出文件
  • 未能成功加载的文件

这有助于报告审查人员了解低计数是真实的信号还是仅仅是数据问题。

如果该工作流每月或每周重复一次,请将其链接到更广泛的 每月 CSV 报告工作流,以便文件处理和报告步骤保持一致。

如何让 匡优数言 解决此问题

当 CSV 文件乱到计数逻辑不断变化,或者团队不想手动构建 Power Query 步骤时,匡优数言 就派上用场了。

你可以同时上传主 CSV 和查询 CSV 导出文件。匡优数言 支持多文件工作流,包括在一次对话中处理 30 多个文件,因此这非常适合查询批次、营销活动批次和导出的报告文件夹。

一个强大的提示词(Prompt)应该描述文件、计数规则和输出选项卡:

我上传了一个主用户文件和许多查询回复 CSV 文件。

主文件在 email 列中包含预期用户的完整列表。
每个查询 CSV 包含回复该查询的用户,也通过 email 标识。

请创建一个可下载的 Excel 工作簿,包含以下工作表:
1. 主回复计数 (Master Reply Count):主列表中的每个 email 占一行,并带有该 email 出现的查询文件数量。
2. 合并回复 (Combined Replies):将所有查询 CSV 文件追加到一个表中,并添加“源文件”列。
3. 缺失用户审查 (Missing Users Review):对于每个 email,显示哪些查询文件没有该 email 的回复。
4. 文件 QA (File QA):显示每个源文件的行数、重复 email、缺失 email 值和异常表头。

每个 email 在每个查询文件中最多计一次。如果一个 email 在同一个查询文件中出现两次,请将其标记为重复,而不是计两次。

你也可以要求更简单的输出:

创建一个包含 email 和 reply_count 的主表。统计每个 email 出现在多少个上传的查询 CSV 文件中。使用主用户列表作为完整的输出列表,包括回复数为零的用户。

匡优数言 可以帮助:

  • 识别正确的计数列
  • 规范化名称或 ID
  • 将文件合并为一个可审查的表
  • 标记缺失的用户和可疑的缺口
  • 汇总参与模式
  • 生成用于审查的报告视图

这比要求通用的聊天机器人“统计回复”更有用,因为问题不仅仅是算术。它涉及文件结构、身份匹配和解释。

如果最终结果需要与团队共享,匡优数言 可以帮助将合并后的数据转换为更具可读性的 Excel 到仪表板工作流,而不是将结果保留为原始汇总。

一个有用的 匡优数言 提示词应该指明回复规则和审查输出,而不仅仅是要求一个总数:

提示 匡优数言 使用明确规则统计不一致的响应

同样的模式适用于用户回复之外

重要的模式是:主列表、多次导出、按键合并、统计出现次数,然后审查缺失或重复的记录。

这种模式出现在各种业务团队中。

对于财务:

  • 统计哪些成本中心提交了每月预算文件。
  • 统计有多少个银行对账单导出文件包含给定的交易 ID。
  • 跨多个应付账款 (AP) 导出文件匹配供应商发票,并标记付款运行中缺失的供应商。

对于电子商务:

  • 统计有多少个市场导出文件包含每个 SKU。
  • 识别在一个渠道中缺失但在另一个渠道中存在的产品。
  • 跨多个平台 CSV 统计退货、评价或退款案例。

对于营销:

  • 统计有多少个营销活动导出文件包含每个潜在客户的电子邮件。
  • 将网络研讨会、新闻通讯和表单响应文件合并为一个参与度评分。
  • 标记出现在付费活动文件中但从未出现在后续响应文件中的潜在客户。

对于供应链:

  • 统计有多少供应商回复了每周确认请求。
  • 跨仓库、承运商和供应商导出文件匹配货运 ID。
  • 标记出现在需求文件中但未出现在可用库存文件中的 SKU。

在每种情况下,相同的提示词结构都适用。命名主列表,命名源文件,定义什么算作有效出现,并要求 匡优数言 保留源文件追踪。

实际的计数工作流

使用以下顺序:

  1. 确定计数规则
    总回复数、文件参与度或唯一用户计数。

  2. 盘点每个 CSV
    记录表头、字段、行数和时间范围。

  3. 规范化用户身份
    首选 ID。如果需要,标准化名称。

  4. 将所有文件合并到一个表中
    保持源文件可见。

  5. 构建汇总表
    根据需要统计回复、文件或参与情况。

  6. 创建缺失用户审查列表
    将数据缺口与真实的低活跃度区分开来。

  7. 添加简短说明
    告诉读者计数的含义以及哪些内容仍需审查。

要避免的常见错误

  • 不要直接统计显示名称而不检查别名。
  • 不要假设每个 CSV 都使用相同的行结构。
  • 不要将缺失的用户与有效计数折叠在同一个表中。
  • 不要忘记解释报告统计的是回复、用户、文件还是唯一出现次数。

总结

跨多个 CSV 文件合并和统计记录实际上是一个报告问题。

有用的输出是一个合并的、可审查的汇总,显示谁出现在哪里、出现的频率以及哪些记录需要注意。

Excel 可以处理逻辑。Power Query 可以使其可重复。当团队希望从多次导出转向可共享的报告,而不丢失缺失用户或混乱文件结构的线索时,匡优数言 非常合适。

开始使用:将 CSV 回复导出转换为可审查的报告

如果你的回复散落在许多 CSV 文件中,请将导出文件上传到 匡优数言,并用通俗易懂的语言描述计数规则。要求它合并文件、规范化用户身份、统计回复,并单独列出缺失或可疑的记录。

立即体验 匡优数言,将手动 CSV 计数替换为团队真正可以审查的报告。

AI赋能数据, 决策胜券在握!

无需写代码与函数,简单对话让匡优数言自动处理数据、生成图表。立即免费体验,感受AI如何颠覆你的Excel工作流 →

立即免费体验

猜你喜欢

求和前如何清洗 Excel 列中的混合数据
Excel AI

求和前如何清洗 Excel 列中的混合数据

看起来像数字的列可能仍无法使用。在求和前,请清理杂乱数据并保留审核记录。

Ruby
如何在制作 Excel 仪表板前进行数据清洗
Excel AI

如何在制作 Excel 仪表板前进行数据清洗

当老板要求基于13个原始数据集制作仪表盘时,首要任务并非绘图,而是构建能让图表产生价值的数据工作流。

Ruby
如何将每月导出的 CSV 文件转化为客户就绪报告
Excel AI

如何将每月导出的 CSV 文件转化为客户就绪报告

CSV 导出文件不等同于报告。本指南提供了一套可重复的工作流,助您将原始数据转化为清晰的分析报告、执行摘要、仪表板视图,以及方便利益相关者审阅的共享链接。

Ruby
如何在 Excel 中制作员工培训差距报告
Excel AI

如何在 Excel 中制作员工培训差距报告

两份电子表格并不等同于合规报告。本文介绍了一套实用的工作流,用于将员工培训记录与岗位要求进行比对,并找出真实的差距。

Ruby
如何在不同排序顺序下保持两个 Excel 视图同步
Excel AI

如何在不同排序顺序下保持两个 Excel 视图同步

当两个工作表需要以不同顺序显示相同的记录时,最稳妥的方法通常是:建立一个源数据表,通过公式生成不同视图,并设置缺失记录检查。

Ruby
如何为自定义日期范围创建月度报告
Excel 智能

如何为自定义日期范围创建月度报告

许多报告并不遵循自然月。如果您的业务报告周期是从 24 日到次月 23 日,日期窗口必须纳入报告逻辑,而非事后手动调整。

Ruby
未受保护且未隐藏:获取访问后如何清理混乱数据
数据清洗

未受保护且未隐藏:获取访问后如何清理混乱数据

受锁定的工作表常隐藏最混乱的数据。了解如何将混乱、未受保护的行转化为结构化洞察,无需手动格式化马拉松。

Ruby
如何在 API 自动化前设计 Google 表格图书库存系统
Excel AI

如何在 API 自动化前设计 Google 表格图书库存系统

对于小型图书馆而言,首要挑战并非 API,而是设计一张非技术志愿者也能轻松维护的简单库存表。

Ruby