雖然台灣的疫情已經趨緩了,但是國外的病例數還是持續地成長,有些地方甚至發生二次爆發 😥
我就有點好奇,在現在的這個情況之下,是不是大家都乖乖待在家防疫?還是有些國家已經偷偷復工,又或者是哪個國家的疫情變得嚴重了?
前陣子看到許多人分享 Google 的移動趨勢報告 Community Mobility Reports,從這份資料,可以看見不同國家裡人們的移動趨勢,了解疫情對於世界各國的工作與生活造成的影響。
如果把這份資料跟確診數的變化拿來做對比,應該可以看出一些有趣的結果吧?
也沒想太多,我就下載了兩份資料,把它們合併起來玩玩看。剛好最近把 GCP 課程上完,想找個實際應用練習一下,而這個題目實在很適合。
總而言之,就是來打造一個每天自動更新的報表,方便大家觀看移動趨勢報告。
在這篇文章中,我會整理了一些目前觀察到的狀況,也蒐集 Reddit 上面網友的討論,希望讓大家對於這份資料有個初步的認識。有興趣的話,可以點擊文末的報表連結,查看目前的統計數字。
Google 的移動趨勢報告
為什麼 Google Map 可以準確知道每個路口的交通狀況、知道每個景點的人潮趨勢?
只要你有打開 Google 的定位紀錄(Location History),或者你什麼都不知道,任由 Google 預設開啟,那麼,你就是貢獻資料的一份子了。
這些資料會被送到數據中心進行分析,透過差異化隱私(Differential Privacy)的方式將資料去識別化,然後產生各式各樣的精準服務,像是預估車流、人流,又或是現在為了對抗疫情而推出的「移動趨勢報告」。
傳送門:Google 移動趨勢報告
這份資料有這些特性:
- 資料從 2020/02/15 開始提供,並用 01/03 到 02/06 五周的資料當作 Baseline。
- 每日發布,最多可以看到 7 天前的資料。
- 提供六種場域的人流變化,包括:零售及娛樂場所、雜貨與藥局、公園、大眾運輸、工作地點以及住家。
我們可以下載 PDF 收看報告,或者是下載 CSV 檔案做進一步的應用。
而關於資料怎麼來的、差分隱私怎麼做的,Google 也有做說明,詳細可以前往 Google 移動趨勢報告的網站收看。
Apple 的移動趨勢報告
原先我以為只有 Google 有提供人流資料,後來發現原來 Apple 也推出了一個網站讓大家查詢,只不過資料揭露的時間範圍與內容都有所不同。
Apple 的移動趨勢是基於「導航」要求。從網頁上的圖表資料來看,我們可以知道這陣子大家對於不同交通工具的導航需求變化。
傳送門:Apple 移動趨勢報告
這份資料有這些特性:
- 資料從 2020/01/13 開始提供。
- 每日發布,最多可以看到 2 天前的資料。
- 反映「Apple地圖」的導航要求變化,能夠看出開車、步行、搭乘交通運輸工具的變化。
以台灣為例,可以看到搭乘大眾運輸工具的人逐漸變少,近期則是有回穩的趨勢,大概是因為台灣已經連續很多天零確診,大家也比較敢出門。
從移動趨勢報告可以看出什麼?
兩份資料相比之下,Google 提供的移動趨勢報告稍微豐富一點,可以看出六種場域的人流變化,雖然時間延遲了一周,但這不影響我們觀察整個趨勢。
要觀察資料,用網站提供的 PDF 檔案是沒辦法的,我還是下載了 CSV 檔,然後直接把資料丟到 Data Studio 看看有什麼發現。
用 Data Studio 是為了之後直接分享連結比較方便,而且也很方便,可以直接拉出篩選器,快速過濾資料中的日期、國家與區域。
下圖是台灣 2/15 到 4/18 的曲線。我們可以看出一個明顯的規律,每到周末,去公園放風(綠色線)的人數就會變多,而去工作地點(橘色線)的人數就會減少。
因為台灣的疫情控制的相對不錯,曲線變化算是相當穩定。只有在 228 與清明連假有明顯高峰。
反觀美國就不是這樣了,三月的疫情爆發之後,明顯可以看到去工作地點與娛樂場所的人數大幅減少。
觀察1:周末在工作地點的人數增加
不過,這個曲線我倒是有個地方相當不解。為什麼到了周末,去工作地點的人反而暴增呢?
可以看到橘色線每周每周規律變化,而明顯的高峰都落在周末。
後來跟同學討論,也問了一下同事的想法,蒐集到幾個可能性:
- 有些餐廳只有周末營業,那些平日營業的餐廳反而關門了,導致周末下降的幅度沒有那麼大。
- 因為疫情關係,許多公司必須雇用一些人力在公司留守,從事量體溫、消毒等等工作。
- 可能是 Google 判斷工作地點的方式有誤,導致落差這麼大。因為這些資料都是從手機回報,我們認為會主動在 Google Map 上設定工作地點的人不會很多,應該大部分都是演算法自動判定。
我還是很好奇這個現象的成因,真的就是這樣嗎?
不死心的我,又去爬了一下 Reddit 論壇,看看國外的大家都怎麼看待這份資料。
果不其然,看到這篇貼文有人也觀察到這個現象,他好奇為什麼在周末的時候去工作地點的人數出現反彈,而在家的人數則是減少。
他倒是認為,如果大家都在家工作,應該不會特別把工作地點改為住家。
底下有個網友回應他,說得滿有道理的「由於工作地點是透過演算法偵測出來的,所以長期在家工作的話,工作地點或許就自斷轉換成家裡。」
原文:Google can learn what your workplace is if you don’t set it, so it might alsobe the algorithm switching.
這樣的說法,讓我更相信 Google 在工作地點上的判定問題,加上其他總總因素,才導致變周末的高峰吧。
觀察2:公園的人數暴起暴落
除了工作地點特殊的現象之外,論壇上也有人提到公園的怪異變化。像是這位網友提到加拿大的 Nova Scotia 公園人數突然暴增,他百思不得其解。
可以看到右上角 Parks 的變化相當劇烈。
這應該也是資料的問題,後來我看到合理的解釋是因為 Baseline 的資料不夠多而造成的偏誤。
因為冬天比較少人去公園,數值本來就低了,而現在春暖花開,大家會去公園的機會變高,自然也就使得震幅變得更大。如果是採用一年或同樣春季的資料當作基準,變化或許就不會這麼劇烈了。
觀察3:對於個人隱私的疑慮
平常科技公司收集各種數據,大家可能都沒有感覺,覺得不痛不癢。但是像這次的疫情爆發,資料被拿來利用的時候,大家就跳起來擔心起隱私。
這倒是沒有辦法,人性就是這樣,只不過我們還是要回歸理性,看看這些數據,有可能外洩大家的移動軌跡?或是可以看出某個人去過哪裡嗎?
從網站上的說明我們也看到,這些資料已經透過差異化隱私(Differential Privacy)的方式處理過。簡單的說就是在資料上加一些噪音,但又保持整體結果不變,使得攻擊者沒辦法反向推測出原始資料。
雖然 Google 宣稱這樣的方法可以保護大家的隱私,就算資料外洩,也不能保證那項資料就是正確的,因為加過噪音了 😎
當然,我們也可以關掉定位紀錄,但有多少人會去關閉?
很可能關閉之後,就無法使用導航功能,又或者 Google 會跳通知出來告訴你,你將失去更精準的個人化推薦,你願意嗎?
在一系列的威脅利誘之下,我們很可能都臣服也乖乖上交自己的移動數據。
打造自己的移動趨勢報表
前面說到,我想要打造一個屬於自己的報表,把人流資料與確診數做關聯,然後天天更新。於是我就用 GCP 上面的應用服務把它串接起來,最後丟到 Data Studio 做顯示。整個流程如下圖所示:
資料來源有兩個,分別是:
在資料合併時我做了簡化,只根據國家做對應,所以每個國家內的所有區域資料將會全部合併,以至於目前的篩選器最多只能塞選國家,沒辦法篩選區域。
有興趣的話,可以點擊下方的連結前往觀看。如果資料有誤,歡迎在留言區告訴我,我會盡快修補問題。
傳送門:COVID-19 移動趨勢報表 (已下架)
可以看到移動趨勢與確診數的關聯,截圖如下:
至於這個報表怎麼生成的,可以參考另外一篇文章:
建立自己的 COVID-19 儀表板,透過 Google Cloud 搞定整條資料管線
觀察4:移動趨勢與確診數的關聯
把兩份資料連接起來,其實我也沒有看出什麼特別有趣的事情哈哈哈,不過倒是觀察到一個現象:
- 疫情嚴重的幾個國家像是美國、西班牙、義大利、法國都有趨緩的現象,也開始慢慢復工。反倒是醫療資源相對差的國家確診數還在持續暴增中,但也偷偷復工了 😂
下圖是土耳其的移動趨勢與確診數關聯圖,可以看到去工作地點的人數有逐漸上升的趨勢。
印度相對沒有那麼樂觀,確診數還在陡升,可是卻已經開始復工了?這實在有點讓人緊張。
日本因為東京奧運的關係,較晚才承認疫情大爆發。從資料上也看的到,在家防疫的人數直到四月之後才慢慢上升。
如果大家有從資料中發現甚麼特別之處,歡迎留言討論!
小結
這次的疫情讓我看見科技的威力,除了這個移動趨勢報告,Apple 與 Google 也聯手推出 COVID-19 接觸追蹤系統,透過藍芽與去識別化的技術,只要你經過確診者身邊,就有可能收到警告簡訊。
在現在這個氛圍之下,我們實在很難要求自己的隱私,針對這些數據的應用分析,我是樂觀看待,畢竟這些應用的初衷還是要對抗疫情。
不過在看完這份資料後,我會認為資料的正規化可能是後續需要調整的部分。而至於資料的可利用性,我倒是有點懷疑,一點是資料延遲了一周,另一點是這份資料的粒度太大了。
以台灣來說,整體的變化沒甚麼太大起伏,但如果可以看到各個縣市,或許針對連假出遊的政策制定,就會有所幫助,就像台灣的 1968 App 那樣。
資料都有,只是要揭露多少而已。不能讓大家看到太多 😎
而針對我們自己,如果真的想要有隱私的話,那就趕快把手機丟掉,開始原始人生活吧!
傳送門:COVID-19 移動趨勢報表,點擊連結過去後,顯示
「數據分析無法連線至您的資料集。
指定檔案無效,請確認檔案存在且格式為 CSV。
錯誤 ID:13c37e7d」
Hello Xavier,
不好意思,後續沒有維護爬蟲程式,該報表已經下架囉。
Regards,
Jerry