簡介一份基于Python的B站視頻數(shù)據(jù)分析可視化系統(tǒng)的畢業(yè)設(shè)計(jì)論文文檔適合需要完成數(shù)據(jù)分析類課題的本?？粕?、研究生以及對B站數(shù)據(jù)挖掘、推薦系統(tǒng)感興趣的開發(fā)者參考。系統(tǒng)設(shè)計(jì)完整覆蓋網(wǎng)絡(luò)爬蟲獲取數(shù)據(jù)含視頻標(biāo)題、上傳者、播放量、點(diǎn)贊數(shù)、Pandas進(jìn)行數(shù)據(jù)清洗與統(tǒng)計(jì)、Echarts繪制柱狀圖/餅圖/折線圖以及基于協(xié)同過濾算法的個(gè)性化視頻推薦同時(shí)分析了不同用戶發(fā)布個(gè)數(shù)、粉絲量、視頻長度、觀閱人數(shù)與輿情分布等內(nèi)容具備從數(shù)據(jù)采集到可視化展示的閉環(huán)思路。壓縮包內(nèi)為1個(gè)docx文件大小約2.31MB論文包含獨(dú)創(chuàng)性聲明、中英文摘要、目錄、緒論、國內(nèi)外研究現(xiàn)狀、關(guān)鍵技術(shù)介紹及系統(tǒng)實(shí)現(xiàn)等正式章節(jié)可作為畢業(yè)設(shè)計(jì)寫作模板與系統(tǒng)設(shè)計(jì)參考。目前已有469人學(xué)習(xí)瀏覽適合用于快速搭建同類數(shù)據(jù)分析選題框架或借鑒其中的爬蟲、可視化與推薦模塊實(shí)現(xiàn)方法。1. 項(xiàng)目背景與核心思路1.1 為什么做這個(gè)系統(tǒng)做B站視頻數(shù)據(jù)分析這件事起因其實(shí)很樸素。作為內(nèi)容創(chuàng)作者和重度B站用戶我一直在思考一個(gè)問題一個(gè)視頻發(fā)布后到底是什么決定它能不能火是標(biāo)題長度、發(fā)布時(shí)間還是分區(qū)選擇、UP主粉絲量這些直覺式的猜測如果沒有數(shù)據(jù)支撐終究是拍腦袋。2023年B站月活用戶已經(jīng)突破3億每天產(chǎn)生的視頻數(shù)據(jù)量驚人如果能把這些數(shù)據(jù)抓到本地做分析用可視化圖表把規(guī)律呈現(xiàn)出來很多問題就能從“我覺得”變成“數(shù)據(jù)顯示”。這個(gè)項(xiàng)目的定位很清晰做一個(gè)輕量級的B站視頻數(shù)據(jù)分析系統(tǒng)覆蓋數(shù)據(jù)采集、清洗、存儲(chǔ)、分析、可視化全流程。采集目標(biāo)鎖定在B站熱門視頻排行榜、分區(qū)視頻信息和UP主基礎(chǔ)數(shù)據(jù)分析方向聚焦在視頻熱度特征、發(fā)布時(shí)間規(guī)律、UP主粉絲量與播放量的關(guān)系這三個(gè)維度上。系統(tǒng)最終產(chǎn)出一套Web可視化看板讓不懂?dāng)?shù)據(jù)分析的人也能直觀看出B站內(nèi)容生態(tài)的運(yùn)行規(guī)律。我個(gè)人覺得這類項(xiàng)目最大的價(jià)值不在于代碼多復(fù)雜、算法多高深而在于把一個(gè)完整的數(shù)據(jù)分析流程真實(shí)跑通——從網(wǎng)頁上拿到數(shù)據(jù)到數(shù)據(jù)庫里存起來再到前端圖表展示出來。這套流程是數(shù)據(jù)行業(yè)通用的換任何平臺(tái)、任何數(shù)據(jù)源都成立。所以這個(gè)系統(tǒng)的設(shè)計(jì)原則是每個(gè)模塊盡量獨(dú)立接口清晰方便替換數(shù)據(jù)源和擴(kuò)展分析維度。1.2 系統(tǒng)整體架構(gòu)設(shè)計(jì)整個(gè)系統(tǒng)分四層數(shù)據(jù)采集層、數(shù)據(jù)存儲(chǔ)層、數(shù)據(jù)分析層、可視化展示層。數(shù)據(jù)采集層用requests庫請求B站API加隨機(jī)延時(shí)和請求頭偽裝來降低被風(fēng)控的概率數(shù)據(jù)存儲(chǔ)層選用SQLite原因很簡單——單文件、零配置、Python內(nèi)置支持對個(gè)人項(xiàng)目和畢設(shè)場景完全夠用數(shù)據(jù)分析層用pandas做數(shù)據(jù)清洗和特征提取用時(shí)間序列分析、相關(guān)性分析等統(tǒng)計(jì)學(xué)方法挖掘規(guī)律可視化展示層采用Flask ECharts的組合Flask負(fù)責(zé)提供數(shù)據(jù)接口和頁面路由ECharts在瀏覽器端渲染圖表。技術(shù)選型上有個(gè)關(guān)鍵決策圖表渲染沒有用Python系的Matplotlib或PyECharts而是選擇了前端ECharts。原因在于交互體驗(yàn)——ECharts支持鼠標(biāo)懸浮查看數(shù)值、圖表縮放、數(shù)據(jù)刷選這些操作在瀏覽器里的展示效果好得多。PyECharts生成的HTML雖然也能交互但遇到圖表聯(lián)動(dòng)、動(dòng)態(tài)請求數(shù)據(jù)這些場景就有些力不從心。系統(tǒng)業(yè)務(wù)邏輯上預(yù)先設(shè)計(jì)了三個(gè)核心分析模塊模塊分析內(nèi)容可視化形式視頻熱度分析各分區(qū)播放量、點(diǎn)贊、投幣、收藏的分布與趨勢柱狀圖、折線圖發(fā)布時(shí)間分析不同時(shí)間段的視頻發(fā)布量與播放表現(xiàn)熱力圖、散點(diǎn)圖UP主畫像分析粉絲量級對視頻表現(xiàn)的影響頭部UP主特征散點(diǎn)圖、餅圖系統(tǒng)中還有一個(gè)容易被忽略但很關(guān)鍵的設(shè)計(jì)所有抓取的數(shù)據(jù)都保留了原始JSON字段。這樣做的考慮是數(shù)據(jù)分析階段如果發(fā)現(xiàn)缺字段不需要重新爬數(shù)據(jù)直接從原始記錄里取就行。這個(gè)設(shè)計(jì)在后來的調(diào)試中確實(shí)幫我省了不少事。2. 核心功能模塊與實(shí)現(xiàn)要點(diǎn)2.1 數(shù)據(jù)采集模塊B站API的請求策略B站開放了一批公開接口不需要登錄就能獲取熱門視頻列表、視頻詳情這些基礎(chǔ)數(shù)據(jù)。系統(tǒng)選用了以下核心接口https://api.bilibili.com/x/web-interface/popular熱門視頻列表https://api.bilibili.com/x/web-interface/view視頻詳情https://api.bilibili.com/x/relation/statUP主粉絲數(shù)https://api.bilibili.com/x/web-interface/archive/rank分區(qū)排行榜Requests請求需要帶齊請求頭重點(diǎn)是User-Agent和Referer。B站對裸requests請求的風(fēng)控比較嚴(yán)格不帶headers很容易被識(shí)別為爬蟲。實(shí)測中我用的最小請求頭配置是headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Referer: https://www.bilibili.com/, Origin: https://www.bilibili.com }請求頻率上做了個(gè)自適應(yīng)控制每次請求后隨機(jī)休眠1-3秒如果連續(xù)觸發(fā)風(fēng)控返回-412錯(cuò)誤碼休眠時(shí)間自動(dòng)翻倍到5-10秒。有個(gè)細(xì)節(jié)值得說B站接口返回的JSON里播放量和點(diǎn)贊數(shù)這些字段是字符串類型而不是數(shù)字。這是因?yàn)锽站數(shù)據(jù)值超過一定范圍后會(huì)用科學(xué)計(jì)數(shù)法表示直接取出來存字符串后續(xù)分析還得做轉(zhuǎn)換不如在清洗階段統(tǒng)一處理。數(shù)據(jù)采集階段只負(fù)責(zé)拿原始數(shù)據(jù)清洗邏輯全部下沉到pandas處理階段這樣職責(zé)更清晰。2.2 視頻信息采集的字段設(shè)計(jì)采集的視頻信息表設(shè)計(jì)為13個(gè)字段核心字段包括視頻IDbvid、標(biāo)題、分區(qū)、UP主、播放量、點(diǎn)贊數(shù)、投幣數(shù)、收藏?cái)?shù)、分享數(shù)、彈幕數(shù)、發(fā)布時(shí)間、視頻時(shí)長、視頻簡介。其中bvid是唯一標(biāo)識(shí)后續(xù)增量更新時(shí)以bvid去重。分區(qū)字段存的是分區(qū)名稱而不是分區(qū)ID。直接存名稱的理由很實(shí)在——分析展示階段不用再做一次ID到名稱的映射查詢雖然存儲(chǔ)上多一些冗余但換取的是開發(fā)效率和分析便利。數(shù)據(jù)量在萬級以下時(shí)這種冗余完全可接受。采集任務(wù)做了完整的狀態(tài)記錄采集批次、采集時(shí)間、成功條數(shù)、失敗條數(shù)都存到日志表里。這樣可以回溯每次采集的完整情況排查問題時(shí)能快速定位是網(wǎng)絡(luò)波動(dòng)還是接口變更導(dǎo)致的失敗。3. 數(shù)據(jù)清洗與分析的實(shí)操細(xì)節(jié)3.1 數(shù)據(jù)清洗那些必須踩的坑數(shù)據(jù)清洗是整個(gè)項(xiàng)目里最不炫酷但最能消耗時(shí)間的事情。實(shí)際抓下來的數(shù)據(jù)臟的程度遠(yuǎn)超想象第一類是字段缺失。部分視頻沒有點(diǎn)贊數(shù)據(jù)可能是隱私設(shè)置有的沒有視頻簡介。對于缺失值分析字段采用直接剔除法非分析字段用默認(rèn)值填充。第二類是異常值。有個(gè)視頻的播放量顯示為-1這種明顯是接口異常返回的臟數(shù)據(jù)分析時(shí)直接過濾。第三類是文本數(shù)據(jù)中的特殊字符。一些視頻標(biāo)題里包含表情符號(hào)、HTML實(shí)體字符比如amp;清洗時(shí)統(tǒng)一做正則替換。清洗邏輯用pandas的apply函數(shù)逐行處理def clean_dataframe(df): # 過濾異常播放量 df df[df[play_count] 0] # 去除標(biāo)題中的特殊字符 df[title_clean] df[title].str.replace(r[^\w\u4e00-\u9fa5], , regexTrue) # 發(fā)布時(shí)間轉(zhuǎn)標(biāo)準(zhǔn)格式 df[pub_time] pd.to_datetime(df[pub_date], units, utcTrue).dt.tz_convert(Asia/Shanghai) return df發(fā)布時(shí)間字段踩了個(gè)時(shí)區(qū)坑。B站API返回的發(fā)布時(shí)間是Unix時(shí)間戳毫秒級直接pd.to_datetime會(huì)得到一個(gè)UTC時(shí)間和北京時(shí)間差了8小時(shí)。不做時(shí)區(qū)轉(zhuǎn)換的話后續(xù)按小時(shí)分析發(fā)布規(guī)律時(shí)會(huì)整體偏移得出完全錯(cuò)誤的結(jié)論。這個(gè)問題的解決方式已經(jīng)在上面代碼中體現(xiàn)——先轉(zhuǎn)UTC再轉(zhuǎn)上海時(shí)區(qū)。3.2 三個(gè)核心分析方向的實(shí)現(xiàn)分析模塊是整個(gè)系統(tǒng)的大腦圍繞熱度特征、時(shí)間規(guī)律、UP主畫像三個(gè)方向展開熱度特征分析計(jì)算了每個(gè)分區(qū)的平均播放量、平均點(diǎn)贊率點(diǎn)贊數(shù)/播放量、平均投幣率、平均收藏率。這些比率指標(biāo)比絕對數(shù)值更有意義能揭示不同分區(qū)用戶的互動(dòng)習(xí)慣。比如科技區(qū)視頻的點(diǎn)贊率平均在3%左右而音樂區(qū)的點(diǎn)贊率可能只有1.8%這反映了不同分區(qū)用戶的行為差異不能簡單用播放量來衡量一個(gè)視頻是否成功。時(shí)間規(guī)律分析先把pub_time提取小時(shí)字段然后按小時(shí)分組統(tǒng)計(jì)視頻發(fā)布量和平均播放量。結(jié)果發(fā)現(xiàn)B站視頻發(fā)布的高峰集中在晚上18點(diǎn)到22點(diǎn)但很有意思的是凌晨0點(diǎn)到2點(diǎn)發(fā)布的視頻平均播放量反而更高。這可能是因?yàn)樯钜拱l(fā)布視頻競爭少更容易進(jìn)入推薦候選池或者是深夜觀眾粘性更高。這個(gè)發(fā)現(xiàn)就是數(shù)據(jù)驅(qū)動(dòng)決策的典型例子——憑直覺很難想到這個(gè)規(guī)律。UP主畫像分析的核心是粉絲量與視頻表現(xiàn)的相關(guān)性計(jì)算用Python的scipy.stats.pearsonr計(jì)算皮爾遜相關(guān)系數(shù)。結(jié)果是粉絲量與播放量的相關(guān)系數(shù)約0.42屬于中等正相關(guān)。說明粉絲量對播放量有影響但不是決定性因素內(nèi)容本身質(zhì)量同樣重要。這個(gè)結(jié)論給創(chuàng)作者的實(shí)際啟示是不要因?yàn)榉劢z少就放棄創(chuàng)作優(yōu)質(zhì)內(nèi)容依然有機(jī)會(huì)獲得高播放。3.3 關(guān)鍵指標(biāo)的選擇邏輯系統(tǒng)中定義了視頻綜合得分這個(gè)指標(biāo)公式為綜合得分 播放量×0.5 點(diǎn)贊數(shù)×0.2 投幣數(shù)×0.15 收藏?cái)?shù)×0.1 分享數(shù)×0.05。這個(gè)權(quán)重分配參考了B站用戶行為理論播放代表觸達(dá)點(diǎn)贊代表認(rèn)可投幣代表強(qiáng)烈認(rèn)可收藏代表對價(jià)值的肯定分享代表主動(dòng)傳播。按傳播學(xué)中參與度遞進(jìn)的理論越深度的行為權(quán)重越高。但投幣數(shù)權(quán)重為什么低于點(diǎn)贊數(shù)在實(shí)際數(shù)據(jù)統(tǒng)計(jì)中發(fā)現(xiàn)用戶投幣行為比點(diǎn)贊行為稀缺得多很多高播放視頻的投幣率不到1%。權(quán)重如果給太高少數(shù)硬幣多的視頻會(huì)主導(dǎo)整個(gè)排名。用這個(gè)綜合得分對視頻排序后選出來的Top視頻比單純按播放量排序更有參考價(jià)值——因?yàn)樗C合反映了視頻在各個(gè)維度上的表現(xiàn)。4. 可視化看板的實(shí)現(xiàn)與效果4.1 Flask后端的數(shù)據(jù)接口設(shè)計(jì)后端接口設(shè)計(jì)遵循一個(gè)原則接口只返回前端需要的數(shù)據(jù)結(jié)構(gòu)不做多余的邏輯。比如熱度分析接口最終返回一個(gè)JSON對象包含分區(qū)的名字列表、平均播放量列表、平均點(diǎn)贊率列表。前端拿到數(shù)據(jù)直接做圖表配置不需要再臃余處理。app.route(/api/hot_analysis) def hot_analysis(): df load_data_from_db() result df.groupby(category).agg( avg_play(play_count, mean), avg_like_rate(like_count, mean) ).reset_index() return jsonify({ categories: result[category].tolist(), avg_play: result[avg_play].tolist(), avg_like_rate: result[avg_like_rate].round(4).tolist() })這里有個(gè)性能優(yōu)化數(shù)據(jù)量大時(shí)每次前端刷新都實(shí)時(shí)查庫聚合會(huì)比較慢。優(yōu)化方案是首次請求后把聚合結(jié)果緩存到內(nèi)存里設(shè)置5分鐘的過期時(shí)間。在Web頁面做5分鐘級別的數(shù)據(jù)刷新完全夠用而響應(yīng)時(shí)間從原來的800ms降到20ms體驗(yàn)差異非常明顯。4.2 前端圖表配置與交互細(xì)節(jié)前端頁面采用單頁布局頂部是數(shù)據(jù)總覽卡片區(qū)展示視頻總數(shù)、UP主總數(shù)、平均播放量等匯總指標(biāo)中間是熱度分析的柱狀圖和折線圖下方左右分欄放時(shí)間熱力圖和UP主散點(diǎn)圖。ECharts配置中的關(guān)鍵點(diǎn)var chart echarts.init(document.getElementById(hotChart)); chart.setOption({ tooltip: { trigger: axis }, grid: { left: 3%, right: 4%, bottom: 3%, containLabel: true }, xAxis: { type: category, data: categories }, yAxis: { type: value, name: 平均播放量 }, series: [{ data: avgPlays, type: bar, barMaxWidth: 40, itemStyle: { color: new echarts.graphic.LinearGradient(0, 0, 0, 1, [ { offset: 0, color: #ff6a88 }, { offset: 1, color: #ff99ac } ]) } }] });tooltip設(shè)置為trigger: axis在柱狀圖里觸發(fā)更順手鼠標(biāo)滑過坐標(biāo)軸就能看到該分區(qū)的所有指標(biāo)比默認(rèn)的item觸發(fā)只顯示當(dāng)前柱子要好用很多?？梢暬窗宕罱ㄍ瓿珊髮Ρ攘硕嗳藚f(xié)作場景下的數(shù)據(jù)看板需求。企業(yè)級數(shù)據(jù)可視化通常要考慮多用戶權(quán)限、定時(shí)刷新、大屏適配這些需求但這個(gè)項(xiàng)目的目標(biāo)場景是個(gè)人使用——單用戶、手動(dòng)刷新、瀏覽器查看所以架構(gòu)上不做過度的擴(kuò)展設(shè)計(jì)。有需要可以根據(jù)用戶需求把Flask換成FastAPI把SQLite換成MySQL遷移成本都不高。5. 系統(tǒng)部署與運(yùn)行的全流程記錄5.1 環(huán)境搭建和依賴管理運(yùn)行環(huán)境是Python 3.9依賴庫版本鎖定如下requests 2.31.0、pandas 2.0.3、flask 2.3.2、scipy 1.10.1。推薦用venv創(chuàng)建虛擬環(huán)境避免系統(tǒng)Python環(huán)境被污染。裝依賴用一條命令pip install requests pandas flask scipyPython環(huán)境配置本身是一個(gè)新手容易卡住的地方。如果電腦上有多個(gè)Python版本需要在虛擬環(huán)境里確認(rèn)python --version輸出的是預(yù)期版本。另外國內(nèi)網(wǎng)絡(luò)環(huán)境下用pip默認(rèn)源下載可能極慢建議臨時(shí)指定清華鏡像源pip install -i https://pypi.tuna.tsinghua.edu.cn/simple requests pandas flask scipy5.2 爬蟲調(diào)度與數(shù)據(jù)庫初始化爬蟲模塊的定時(shí)邏輯用兩種方式實(shí)現(xiàn)開發(fā)調(diào)試階段用time.sleep循環(huán)控制部署上線后用系統(tǒng)crontab定時(shí)觸發(fā)。首次部署時(shí)踩了個(gè)坑連續(xù)抓取約200條數(shù)據(jù)后B站接口開始返回風(fēng)控錯(cuò)誤碼。排查發(fā)現(xiàn)原因是單個(gè)IP的短時(shí)請求頻率過高。解決辦法是在采集腳本中加入請求計(jì)數(shù)每達(dá)到50條請求強(qiáng)制休眠60秒。這個(gè)策略調(diào)整后單次任務(wù)可穩(wěn)定抓取1000條以上的數(shù)據(jù)沒有被風(fēng)控?cái)r截。數(shù)據(jù)庫初始化使用SQLAlchemy的ORM模型建表。SQLite文件在項(xiàng)目根目錄下生成首次運(yùn)行python init_db.py會(huì)自動(dòng)建表。整個(gè)項(xiàng)目的數(shù)據(jù)庫操作都封裝在db.py模塊里上層業(yè)務(wù)邏輯不直接寫SQL語句后續(xù)把SQLite替換成MySQL時(shí)只需要改這一個(gè)文件的連接方式即可。5.3 一條命令跑通全流程項(xiàng)目提供了run.py作為統(tǒng)一入口支持三個(gè)參數(shù)crawl表示執(zhí)行數(shù)據(jù)采集analyze表示執(zhí)行離線分析web表示啟動(dòng)可視化服務(wù)。日常使用頻率最高的是python run.py crawl --pages 5 python run.py web --port 8000第一條命令抓取5頁熱門視頻數(shù)據(jù)第二條命令啟動(dòng)Web服務(wù)瀏覽器輸入http://localhost:8000就能看到可視化看板。6. 常見問題與排查經(jīng)驗(yàn)6.1 請求被風(fēng)控返回412錯(cuò)誤這是爬蟲新手最容易遇到的問題。B站對異常請求的判斷維度包括User-Agent是否符合主流瀏覽器、請求頻率是否合理、是否存在明顯機(jī)器行為特征。處理措施按優(yōu)先級排先檢查請求頭是否完整再降低請求頻率另外給每次請求加隨機(jī)延時(shí)用time.sleep(random.uniform(1, 3))這種寫法定期更換User-Agent。如果以上都不行考慮用代理IP池輪換出口地址但這對個(gè)人項(xiàng)目復(fù)雜度偏高前期不太建議優(yōu)先嘗試。6.2 pandas分組聚合效率太低當(dāng)數(shù)據(jù)規(guī)模達(dá)到5000條以上時(shí)pandas的groupby().apply()操作明顯變慢。瓶頸通常出現(xiàn)在自定義聚合函數(shù)上。優(yōu)化為使用groupby().agg()內(nèi)置方法速度提升顯著。如果還需要更復(fù)雜的計(jì)算先用SQL在數(shù)據(jù)庫層做聚合pandas只負(fù)責(zé)加載最終結(jié)果。6.3 發(fā)布時(shí)間的時(shí)區(qū)偏移問題這個(gè)問題前面提過一次但在系統(tǒng)聯(lián)調(diào)時(shí)最容易漏數(shù)據(jù)庫里存的時(shí)間戳和分析出來的按小時(shí)分布完全對不上每小時(shí)都有8小時(shí)的偏移看起來毫無規(guī)律。建議的處理方式是采集入庫時(shí)統(tǒng)一轉(zhuǎn)換為北京時(shí)間字符串存儲(chǔ)分析階段直接用字符串解析分析階段就不會(huì)有時(shí)區(qū)困擾。6.4 前端圖表數(shù)據(jù)不更新一種常見的bug重啟Flask服務(wù)后瀏覽器上看到的圖表用的還是舊數(shù)據(jù)。原因是瀏覽器對同URL的GET請求做了緩存。排查時(shí)可以在請求URL后加時(shí)間戳參數(shù)強(qiáng)制繞過緩存fetch(/api/hot_analysis?ts${Date.now()})6.5 視頻標(biāo)題里的特殊字符導(dǎo)致JSON報(bào)錯(cuò)部分視頻標(biāo)題中包含emoji或特殊符號(hào)json.loads時(shí)會(huì)拋出解析異常。解決方式是在數(shù)據(jù)入庫前用ensure_asciiFalse對JSON字符串做編碼或者用errorsignore參數(shù)去掉無法解析的字符。7. 項(xiàng)目總結(jié)與后續(xù)擴(kuò)展思路這個(gè)系統(tǒng)從數(shù)據(jù)采集到可視化展示完整跑通了一遍核心收獲不是某個(gè)技術(shù)點(diǎn)的熟練而是對“數(shù)據(jù)驅(qū)動(dòng)內(nèi)容決策”這句話有了真實(shí)的體感。平時(shí)猜的B站爆款規(guī)律比如黃金發(fā)布時(shí)間、標(biāo)題長度效應(yīng)、分區(qū)流量差異在數(shù)據(jù)面前有的被驗(yàn)證有的被推翻。這就是數(shù)據(jù)分析的價(jià)值所在——它不生產(chǎn)結(jié)論但檢驗(yàn)結(jié)論。實(shí)際使用過程中我自己的一個(gè)體會(huì)是做這類項(xiàng)目別一上來就想著用最復(fù)雜的框架、最熱門的工具鏈先把一個(gè)最小的數(shù)據(jù)閉環(huán)跑通——能拿到數(shù)據(jù)、能存下來、能畫出一張圖。哪怕這張圖很丑、指標(biāo)很簡單但這個(gè)閉環(huán)本身就是最大的技術(shù)突破。后續(xù)再按需加功能、換工具、優(yōu)化性能都是漸進(jìn)的過程。后續(xù)有興趣可以沿著這幾個(gè)方向擴(kuò)展一是接入彈幕數(shù)據(jù)做彈幕情感分析判斷視頻觀眾的情緒傾向二是定時(shí)抓取數(shù)據(jù)做時(shí)間序列預(yù)測估算一個(gè)視頻發(fā)布三天后的總播放量三是增加多平臺(tái)對比把抖音、西瓜視頻的數(shù)據(jù)也納入分析范圍形成跨平臺(tái)內(nèi)容生態(tài)的橫向比較。這些方向在數(shù)據(jù)基礎(chǔ)已經(jīng)打好的前提下擴(kuò)展起來都不是特別困難的事。本文還有配套的精品資源點(diǎn)擊獲取