用Python分析Spotify听歌数据：从JSON解析到可视化全流程

上个月整理歌单的时候我突然发现一个问题自己明明每天都挂着Spotify但一年下来到底听了什么、哪个歌手占据了我耳机里最多的时间我居然完全说不出来。Spotify Wrapped年度总结很漂亮但它只给你看Spotify愿意给你的那几张图真正的原始数据一直躺在账户后台很少有人去主动挖。于是我把Spotify听歌数据导出来用Python做了一次完整的数据分析。这篇文章就是把整个过程摊开讲给你听从导出数据、解析JSON、清洗字段到最终的统计与可视化全部都覆盖。如果你也想用Python分析自己的Spotify听歌数据但不知道从哪一步下手这篇文章应该能让你少折腾一个晚上。1. 为什么要把听歌记录当成一个正经的数据分析项目很多人听到用Python分析Spotify听歌数据的第一反应是不就是导个排行榜吗Spotify Wrapped不是已经给了我年度报告一年前我也会这么想。但当你真正开始处理这一堆记录之后会发现它远比一份榜单有价值。Spotify导出的Extended streaming history包含你每一次播放行为的明细哪首歌、哪个歌手、什么时候开始播、完整播了多久、是正常听完还是切歌、甚至可能是后台自动播放时被你忽略掉的几秒钟。这些数据组合起来完全可以回答一些特别具体的问题我通勤路上听的歌和深夜听的歌是不是完全两批歌手我最近三个月的口味相比上半年变化有多大所谓的我最喜欢的歌手到底是真喜欢还是一直在随机播放里被推送到把听歌数据当作数据分析项目来操作的价值在于它能训练一整套处理真实数据的思维方法。真实的数据永远是脏的时间字段可能有时区问题同一首歌可能有多个版本歌手名的大小写都不统一播放次数很多只有几秒。这些细节在学校里的数据集里往往已经被提前清理干净了但在Spotify导出的原始JSON里全部需要我们自己去面对。你跑完一遍之后pandas、JSON解析、时间处理、分组聚合、matplotlib可视化这些技能就全部实战过了。所以这篇文章不打算泛泛地讲数据分析而是老老实实跟着一条完整链路走数据从哪来、怎么读进来、怎么清洗、怎么分析、怎么画图。我会把每一步的具体代码和我在实际过程中踩过的坑都写清楚方便你直接照着跑。2. 数据获取Spotify隐私设置里的隐藏宝藏Spotify允许每个用户自行导出自己的全部账户数据包括完整的听歌历史。这个入口藏得不算深但很多人不知道。打开Spotify网页版登录后进入账户设置页面找到Privacy settings隐私设置里面有一项是Download your data。然后勾选你需要的项目重点勾选Extended streaming history这里面的听歌记录最完整字段也最丰富——相比之下基础的StreamingHistory文件内容和它差别不大但Extended版本划分得更细致文件也更多。2.1 导出请求的具体操作步骤完整操作路径是这样的进入账户设置后找到Download your data页面会列出所有可导出的数据类型包括账户详情、支付记录、搜索历史、播放列表等。每一项都有单独的勾选框我们需要的是Streaming History下面的Extended streaming history建议只勾这一项其他不需要的都留空避免下载时间过长。提交之后Spotify的服务器会开始打包这个过程通常不会立即完成。我第一次提交之后等了整整四天期间会收到一封邮件通知告诉你数据文件正在准备中。文件准备好之后会收到第二封邮件里面有一个下载链接。下载下来是一个zip压缩包解压后里面会看到一堆命名类似Streaming_History_Audio_2023_2024.json的文件以及一些其他辅助文件。这个等待过程容易被忽略但它是整个项目里唯一一个不可控环节。如果发现几天都没有动静可以重新登录账户检查状态偶尔Spotify会要求重新验证身份或者重新发起请求。2.2 拿到文件后先别急着跑代码先检查这三件事解压zip之后先不要急着把文件交给pandas。我建议先做三件检查。第一确认文件确实是Extended streaming history。文件名里应该包含Audio如果不是你可能下载的是其他类型的数据。第二检查文件数量。听歌时长一年半载的人可能拿到五六个甚至十几个JSON文件每个文件的大小从几百KB到几十MB不等。只用其中一个文件做分析得出的结论会有严重偏差所以后续代码需要把目录下的所有同类文件合并。第三抽样打开一个JSON看看字段结构。Spotify的JSON格式偶尔会加字段不同年份导出的文件字段不一定完全一样。如果不看就直接合并很容易在后续代码里出现KeyError。做完这三步你手里就有了一份最原始的听歌记录数据集。接下来才是Python正式出场的时刻。3. 解析StreamingHistory把JSON变成你熟悉的表格Spotify导出的Streaming History文件结构非常干净寥寥几个字段没有嵌套的复杂结构这一点比很多接口返回的数据友好多了。单个文件里的内容长这样[ { endTime : 2023-08-15 14:32:07, artistName : Radiohead, trackName : No Surprises, msPlayed : 244000 }, { endTime : 2023-08-15 14:33:28, artistName : The Smiths, trackName : There Is a Light That Never Goes Out, msPlayed : 81000 } ]四个字段含义都很明确endTime是这首歌播放结束时的本地时间artistName是歌手名trackName是歌曲名msPlayed是本次播放持续了多少毫秒。注意这里没有记录播放开始时间只有结束时间后续做时段分布时要用时间戳倒推但通常只需要小时级别直接用endTime的小时字段就够了。3.1 用pandas合并所有历史文件处理JSON文件最顺手的方式是用pandas一步到位。把所有Streaming_History_Audio_*.json文件统一合并成一个DataFrame代码量非常短import glob import pandas as pd files glob.glob(spotify_data/*Streaming_History_Audio_*.json) frames [pd.read_json(f) for f in files] df pd.concat(frames, ignore_indexTrue) print(df.shape) print(df.dtypes) df.head()如果你的zip解压之后所有JSON文件都在同一个目录下上面的glob路径改成你的实际路径就行。合并之后先看一眼df.shape确认行数在合理范围。正常来讲哪怕每天只听一小时歌一年也有几千到几万条记录如果合并完只有几百行那大概率是只读到了一个文件或者漏掉了某一年建议回去检查。pd.read_json()读进来之后DataFrame的列顺序就是JSON里的字段顺序endTime、artistName、trackName、msPlayed。列名保持不变后续操作都基于这些列名。3.2 时间字段的初步转换endTime现在还是字符串格式是YYYY-MM-DD HH:MM:SS这种格式的好处是pandas可以非常方便地把它转成datetime类型df[endTime] pd.to_datetime(df[endTime], format%Y-%m-%d %H:%M:%S)转换之后endTime就不再是普通字符串了而是真正的日期时间对象后面按小时分组、按月份分析、计算周几都可以直接用dt访问器操作。字段解析到这里就算完成了pandas已经把一坨JSON变成了整齐的表格。但这时候的数据还不能直接用来分析因为里面藏着好几个会影响结论的问题接下来是清洗环节。4. 数据清洗影响分析结论的三个隐蔽问题如果只做简单的播放次数统计不清洗字段看似也能出结果但出来的数字会误导你。我实际处理的时候至少碰到了下面三个问题每一个都会显著影响分析结论。4.1 endTime时区陷阱endTime看起来是正常的时间字符串但你得确认它是UTC时间还是你的本地时间。Spotify的导出文档在不同时期有不同说法我碰到的情况是文件里的时间显示为本地时间但如果你的账户跨时区使用过或者在迁移过账号地区这里面就很容易出现一小时偏差。判断方法很简单找到最后一条记录的endTime跟你真实最后一次听歌的时间对比一下。如果完全一致那它就是本地时间如果差了整数个小时就需要做时区偏移。我在实际数据里发现过一次性偏差一小时的情况处理办法很粗暴df[endTime] df[endTime] pd.Timedelta(hours1)如果你做完对比发现没偏差就跳过这一步。但一定要做这个验证否则按小时统计的波峰波谷图会整体偏移一小时结论南辕北辙。4.2 播放时长里的无效记录msPlayed是本条记录的播放时长单位是毫秒。很多人会直接把所有记录全部纳入统计结果发现最常听的歌里混进了一大堆只播放了3秒、5秒的记录——那些大概率是你在刷歌单时快速切歌或者随机播放里自动跳过的。这些记录不应该计入真正在听的范畴。我采用的过滤阈值是30秒也就是30000毫秒。小于这个阈值的记录在统计学意义上更像试听而不是听过。你可以按自己的习惯调整但建议至少过滤掉5秒以下的记录否则平均播放时长会被极度拉低。df_filtered df[df[msPlayed] 30000].copy()此时再跑一遍分组统计你会看到排名会发生微妙但真实的变化某个只在随机播放里出现过几次的网红歌可能迅速掉出Top10而真正被完整播放过的歌曲往上走。4.3 歌手名和歌曲名的脏数据Spotify的曲库里同名歌曲非常多不同版本、Live版、Remastered版、Acoustic版可能对应的trackName和artistName都有细微差别。比如同一首歌有的记录写着Under the Bridge有的写着Under the Bridge (Remastered)实际是同一作品但被拆成了两个统计项。我没有做太激进的归一化处理只做了两个基础清洗统一去除首尾空格把英文歌手名统一为首字母大写的形式避免因为大小写差异造成同一歌手被拆成两行的结果。这一步在分组统计之前做df_filtered[artistName] df_filtered[artistName].str.strip().str.title() df_filtered[trackName] df_filtered[trackName].str.strip()至于Remastered、feat.这类异体如何处理就取决于你的分析目标了。如果是精确到歌曲的排名建议保留原样因为(Remastered)确实算另一个录音版本如果只到歌手维度问题不大因为歌手名基本稳定。清洗完之后我们可以干干净净地做真正的分析了。我会从最核心、也最能产出洞察的几个维度入手。5. 第一波分析回答我听什么与我什么时候听这一部分是整个项目的产出核心也是最有意思的地方。我会先用几个简单的分组操作让数据说出三个层面的结论歌手偏好、歌曲偏好、听歌时间习惯。5.1 歌手榜与歌曲榜先回答最直接的问题我听得最多的Top歌手是谁。这只需要一行groupbyartist_stats ( df_filtered.groupby(artistName) .agg(play_count(trackName, count), total_ms(msPlayed, sum)) .sort_values(play_count, ascendingFalse) ) artist_stats.head(10)我更喜欢同时看两个指标播放次数play_count以及累计播放时长total_ms。这两者并不总是同序的。有的歌手你经常完整听完一张专辑播放次数高有的歌手你只是偶尔听到一两首但每首都循环很久累计时长反而更高。两个榜单一起看才能看出你的听歌驱动力到底是喜欢这个人还是喜欢某几首歌两个维度的解读逻辑完全不同。歌曲榜类似为了去重我按artistName和trackName两列一起分组track_stats ( df_filtered.groupby([artistName, trackName]) .agg(play_count(msPlayed, count), total_ms(msPlayed, sum)) .sort_values(play_count, ascendingFalse) ) track_stats.head(10)这里有个小细节分组之后msPlayed用作count计数刚好可以表示播放次数因为每条记录就是一次完整播放事件。total_ms取和即可得到该歌曲累计播放时长。5.2 听歌时段分布你是黑夜型还是白天型第二个有意思的分析是听歌时段分布也就是一天24个小时里每个小时分别产生了多少次播放。先把时间列提取出小时df_filtered[hour] df_filtered[endTime].dt.hour hourly df_filtered.groupby(hour).size()绘图或者直接打表就能看到自己听歌习惯的波峰波谷。我自己跑完发现早上8-9点有一个高峰对应通勤晚上22-23点才是真正的最高峰深夜听歌量远超白天。这个分析看起来简单实际操作中它会剧烈受到你作息的影响而且不需要任何额外的传感器数据只要时间字段干净它就能还原出你耳机里的一天。如果不放心可以用dt.dayofweek限定周一到周日再看看工作日和周末的时段分布差异。周末大概率的最高峰会出现在下午而不是晚上这个对比会很有意思。5.3 月度趋势与季节性如果把时间维度从小时拉宽到月份又可以回答另一个问题我的口味是否在某个时间段发生了突变用dt.to_period(M)提取年月再统计每月的播放量df_filtered[month] df_filtered[endTime].dt.to_period(M) monthly df_filtered.groupby(month).size()月度趋势能看出你听歌的绝对活跃度变化。比如某个月因考试周几乎没听歌播放量会形成一个断崖寒暑假期间如果长时间旅行也可能导致记录断档。这个图表比年度总结里的年度歌手更有叙事感你基本能把每个波动在你的人生时间轴上找到对应事件。到这里分析统计工作已经完成了大半。但数据只有落在图里才更容易被人理解和传播接下来用matplotlib把这些结果画出来。6. 把数字变成图matplotlib可视化实操pandas的分组结果都是Series或DataFrame直接用matplotlib画图非常顺手。我不打算做花哨的可视化只需要几张能放到博客或者发朋友圈的干净图表。6.1 横向条形图歌手Top10横向条形图比纵向条形图更适合展示排名因为歌手名字一般较长纵向排列会互相挤压。代码很简单import matplotlib.pyplot as plt top_artists artist_stats.head(10)[play_count][::-1] plt.figure(figsize(8, 6)) top_artists.plot.barh(color#1DB954) plt.xlabel(播放次数) plt.title(我的 Spotify 歌手 Top10) plt.tight_layout() plt.savefig(top_artists.png, dpi150) plt.show()[::-1]的作用是把排名数据反转让播放次数最多的歌手出现在图表最上方视觉习惯更合理。颜色选Spotify标志性的绿色纯属个人审美你也可以换成任意颜色。如果你是macOS或Linux环境中文字体可能显示为方框乱码这个坑非常常见我直接给出解决方案。6.2 折线图一天中听歌的波峰波谷时段的折线图是另外一幅值得展示的图plt.figure(figsize(10, 4)) plt.plot(hourly.index, hourly.values, markero, linewidth2) plt.xticks(range(24)) plt.xlabel(小时) plt.ylabel(播放次数) plt.title(一天 24 小时的听歌活跃度) plt.grid(alpha0.3) plt.tight_layout() plt.savefig(hourly_trend.png, dpi150) plt.show()折线图能直观看出高峰时段。如果你有两个高峰基本可以认定通勤场景对听歌节奏的真实影响。我自己的图上晚上23点那个尖峰明显高出其他时段一截看了数据才知道我在深夜反而最常听歌。6.3 中文乱码问题matplotlib默认字体是DejaVu Sans不含中文字形所以图中的中文会变成空心方框。最简单的处理办法是显式指定一个系统中文字体plt.rcParams[font.sans-serif] [SimHei, Heiti SC, PingFang SC] plt.rcParams[axes.unicode_minus] FalseWindows下SimHei基本可用macOS下可以试试PingFang SC或Heiti SCLinux则在/usr/share/fonts下装了字体后填入具体的字体名。如果还是不行可以用英文作为图表的标题和轴标签虽然少了点中文的表达但只要数据对图照样有说服力。我个人倾向于图内直接用英文标签避免在不同设备上预览时字体缺失。画完这些基础图你已经能拿到一份足够完整的个人听歌报告了。但如果还想再进一步把这些数据和Spotify的官方知识库连起来那就值得看看下一部分。7. 进阶玩法结合Spotify API给你的数据补上外挂Streaming History里只有歌手、歌曲、播放时长但缺少更丰富的元信息歌曲的时长、封面图、专辑归属、发布时间、曲目热度、音频特征BPM、调性等。如果想把分析从我听了什么升级到我听的歌有哪些共同特征就需要把历史记录和Spotify官方音乐数据库串联起来。7.1 为什么需要Spotify APISpotify为每个曲目分配了独立的Spotify ID但Streaming History的JSON里恰恰不包含这个ID只给了歌手名和歌名。这个限制决定了我们只能靠「歌手名歌名」去搜索匹配。好在Spotify有一个公开的Web API支持根据曲名和歌手名搜索曲目并在返回结果里带上官方元数据。这种半手动的匹配方式足够个人使用但也要意识到它的局限匹配度取决于你听到的版本在Spotify曲库里是否唯一。例如一些现场版、翻唱版会匹配到多个结果需要自己判断取第一个还是取最热门版本。7.2 获取曲目详细信息的一个最小例子想调用Spotify API首先要去Spotify for Developers创建Client ID和Client Secret。标准流程是登录开发者后台创建一个应用然后在设置的Redirect URI里填入一个本地地址。之后用Client Credentials Flow获取一个短期访问token就可以免费请求曲目数据。下面是一个用requests库做搜索的最小示例假设我们已知歌手和歌名import requests client_id your_client_id client_secret your_client_secret # 获取访问token auth_url https://accounts.spotify.com/api/token auth_response requests.post(auth_url, { grant_type: client_credentials, client_id: client_id, client_secret: client_secret, }) token auth_response.json().get(access_token) # 用搜索接口查歌曲 search_url https://api.spotify.com/v1/search response requests.get( search_url, headers{Authorization: fBearer {token}}, params{q: track:No Surprises artist:Radiohead, type: track, limit: 1}, ) rids response.json()[tracks][items] if rids: first_track rids[0] print(first_track[name], first_track[id], first_track[duration_ms])这个脚本能拿到官方曲目ID、专辑名称、发行日期、时长等字段。接下来把拿到的ID作为关联键去请求/v1/audio-features/{id}就能获得BPM、能量值、情绪值这些音频特征。将这些特征与Streaming History按曲目ID合并之后可以做更有趣的分析比如我常听的歌平均BPM集中在多少、去年冬天的歌和今年夏天的歌情绪值是否有明显反差。不过要注意免费API的请求配额有限如果你有好几万条历史记录逐条搜索会非常慢。我的建议是先只取播放次数Top 500的歌曲去补全信息既能控制请求量也能覆盖大部分真实的听歌行为。8. 复盘总结几个真实踩过的坑和想提醒你的点现在把整个流程走完我想再分享几个实际操作中很重要、但一开始我并没有意识到的细节。这些内容算不上惊天动地的大问题却能决定你在做这个项目时是一路畅通还是半路卡壳。8.1 导出数据不是即时到账这是整个流程中最容易让人误判的环节。提交导出请求之后你会收到确认邮件但数据生成可能需要几个小时甚至几天。我第一次做的时候下载了一个只有几KB的zip包打开之后发现里面没有Streaming History文件只有账户基本信息。原因是当时只勾选了非历史数据或者文件还没生成完。建议各位提交请求之后留出足够时间最好是在准备写代码的前一天提交而不是当天开始做才提交。8.2 播放时长过滤阈值强烈建议保留30秒这个阈值是我多次实验后觉得最合适的一个数。太短会混入大量切歌噪音太长又会剔除一些真实播放但歌本来就短的曲目比如一些朋克歌曲不到两分钟但确实被完整听过。你可以根据自己听歌习惯微调比如你觉得自己很少中途切歌可以降到10秒如果经常开着随机播放做家务建议升到45秒。但在统计报告里一定要注明你的过滤条件否则后面分析阶段你自己都会忘了这些数字是建立在什么基础上的。8.3 版本差异化可能会导致歌曲排名失真如果你非常在意单曲播放次数这个指标一定要意识到Spotify会把歌曲的多个录音版本拆开统计。Live版、Acoustic版、Remastered版在Streaming History里都是独立记录但这些版本在普通听众心里往往属于同一首歌。如果只想统计原始的录音室版本建议用音乐库专辑信息做一层过滤不过对大多数个人分析来说拆分版本反而能更准确地反映你真正点开的那个录音版本所以我一般保留原始数据只在解读的时候额外标记。8.4 不要迷信pandas的默认排序分组排序后pandas会把排序结果按索引顺序展示但如果你在同一个脚本里多次groupby再sort_values没有及时重置索引容易出现索引混乱导致后续合并出错。建议在最终输出之前养成好习惯需要重置索引时用reset_index(dropTrue)否则你打印出来的Top10跟图表里的Top10可能会对不上。8.5 私密统计与隐私意识处理自己的听歌数据时虽然数据在自己手里很安全但如果你打算把可视化结果发到社交平台建议在发布前检查一下是否暴露了不想公开的信息。比如某些深夜听的歌或者单曲循环过太多次的歌可能会意外暴露你的情绪状态和生活节奏。这不是吓唬人是数据分析博主分享自己的实战经验时应该提醒你注意的事情。最后再分享一个小技巧。把这个项目跑完一遍之后你会对它产生一种这套脚本不能白写的心态。那就顺手在每个月月底重新运行一次脚本让月度趋势和歌手榜自动生成最新版本这样一整年下来你就有了一份真正属于自己的年度听歌报告比任何平台的年度总结都更细、更真实、更私人。复用脚本的成本几乎为零但每积累一个月数据的叙事能力就强一分。这个习惯我坚持了快一年现在已经成了每月固定的小仪式。