把播客每集数据批量导入Google Sheets

原文要点

原作者Incrementors的免费n8n模板：手动触发运行，先调用Spotify for Creators（Anchor API）查出节目的Spotify show URI并提取show ID，再拉取全部单集列表并拆分成逐集处理；对每一集请求播放量、独立听众、收听时长、留存等表现指标，与单集元数据（标题、发布日期、时长）合并；每集之间稍作等待以降低限流概率；最后每集一行追加到Google Sheets。授权所需的podcast ID和Bearer令牌要从自己浏览器会话中抓取并粘贴进配置值，且需确认API基础地址适合自己的账号。流程只负责采集入表。

这次做成什么

在本站照做的目标：重建一条“手动触发→查节目ID→拉单集列表→逐集取指标→等待防限流→追加到表格”的采集流程。原模板无工作流文件下载，本站提供节点级搭建方案、字段映射表和一份合成测试数据，先用假数据验证表格结构，再换真实令牌跑一次完整采集。

准备什么

• 一个n8n实例，能使用HTTP Request、Split In Batches（或循环）、Wait、Google Sheets节点
• 一个已发布单集的Spotify for Creators播客账号，并能登录其网页后台
• 从自己浏览器会话复制的podcast ID与Authorization Bearer令牌
• 一个Google账号及已建好的目标表格，含名为Episode Analytics的标签页

具体怎么做

1. 建表并写入表头

   在Google Sheets新建表格，标签页命名Episode Analytics，首行写入字段：Episode ID、Title、Publish Date、Duration、Plays、Streams/Downloads、Unique Listeners、Consumption Hours、Median Consumption、Audience Retention。复制地址栏文档ID。在n8n凭据里配置Google Sheets OAuth2。

2. 抓令牌并填配置

   登录Spotify for Creators网页后台，打开浏览器开发者工具的Network面板，刷新页面，在请求头中找到Authorization: Bearer开头的令牌，连同你的podcast ID一起复制。在n8n工作流起始处放Set节点存PODCAST_ID、AUTH_TOKEN、API_BASE、SHEET_ID四个配置值。令牌属于会话凭据，过期后需重新抓取，不要把含真实令牌的工作流导出分享。

3. 手动触发并查节目ID

   用Manual Trigger节点起手，接HTTP Request节点：按配置里的API_BASE请求节目信息接口，从响应中解析Spotify show URI并用Set或Code节点提取show ID。先只跑这一段，确认能拿到ID再继续，避免后面整段返工。

4. 拉单集列表并逐集循环

   第二个HTTP Request节点请求单集列表，随后用拆分节点把响应数组拆成一条一集。循环体内：HTTP Request请求该集的表现指标，用Set节点把指标与该集元数据（标题、发布日期、时长）合并成一行扁平字段；循环尾部放Wait节点，等待数秒后再处理下一集，降低触发限流的概率。

5. 逐行追加到Google Sheets

   循环输出接Google Sheets节点，操作选Append，指向Episode Analytics，按表头做字段映射。先用下方合成测试数据手动跑一遍确认列对齐，再切换到真实API跑全量。跑完检查表格行数与后台单集数是否一致。

可直接复制的材料

{
  "PODCAST_ID": "替换为浏览器会话中抓取的podcast ID",
  "AUTH_TOKEN": "Bearer 替换为浏览器请求头中的令牌",
  "API_BASE": "按原文提示核对适合自己账号的Anchor API基础地址",
  "SHEET_ID": "替换为Google表格文档ID",
  "SHEET_NAME": "Episode Analytics",
  "WAIT_SECONDS": 3
}

episode_id,title,publish_date,duration_sec,plays,streams_downloads,unique_listeners,consumption_hours,median_consumption_pct,audience_retention_pct
ep-001,开播第一期：为什么我们开始做播客,2026-08-01,1820,420,398,355,196.5,62,58
ep-002,第二期：远程办公的坑,2026-08-08,2105,615,590,501,318.2,68,63
ep-003,第三期：嘉宾对谈独立开发者,2026-08-15,2640,890,861,720,512.7,71,66

输入与输出示例

本站虚构演示，未真实调用Spotify接口；行数、数值均为合成示例，非作者运行结果。

输入

手动触发一次，节目共3集（ep-001至ep-003），每集循环间隔等待3秒，使用上方合成数据模拟API返回，追加到Episode Analytics标签页。

对应输出

表格追加后末尾三行示例：
ep-001 | 开播第一期：为什么我们开始做播客 | 2026-08-01 | 1820 | 420 | 398 | 355 | 196.5 | 62 | 58
ep-002 | 第二期：远程办公的坑 | 2026-08-08 | 2105 | 615 | 590 | 501 | 318.2 | 68 | 63
ep-003 | 第三期：嘉宾对谈独立开发者 | 2026-08-15 | 2640 | 890 | 861 | 720 | 512.7 | 71 | 66
日志显示每集之间等待3秒，共追加3行，无429限流报错。

做完检查这些

• 只运行查节目ID这一段时，能在节点输出里看到解析出的show ID
• 用合成数据跑循环后，Episode Analytics表的行数等于测试单集数，且每行十列无错位
• 连续两次运行之间令牌未过期时，第二次运行不会报401；报401说明需要重新抓令牌
• 循环日志中能看到每集之间的等待间隔生效，而非瞬间连续发请求

容易卡住的地方

• Bearer令牌来自浏览器会话，有有效期，过期后所有请求401，需重新从开发者工具抓取
• 原文明确提示API基础地址需按自己账号核对，地址不对会在第一步就失败
• 去掉Wait节点或间隔太短容易触发限流，导致中间若干集数据缺失而表格行数变少
• 令牌属于敏感凭据，把含令牌的工作流JSON导出分享等于泄露账号访问能力
• 本流程只采集入表，不做任何趋势分析或图表，分析需要另行搭建
• 拆分节点配置不对会把整个列表当成一集写入，导致表格只有一行乱码式数据