hinge data analysis
1.0.0
Hinge 允許使用者請求匯出在使用應用程式時收集的個人資料。如果您有 Hinge 帳戶，您可以透過前往「設定」->「下載我的資料」來請求您的資料。滿足此要求通常需要 24 到 48 小時，資料準備好後，Hinge 會提供包含您的個人資料的.zip檔案。
Hinge提供的資料匯出包含多個文件，但最主要的是index.html文件，用於渲染帶有顯示不同資料的選項卡的網頁。 Hinge 提供的選項卡標記為：使用者、配對、提示、媒體、訂閱、全新開始和自拍驗證。除了查看提示的更改或查看您上傳的圖片之外，這些數據並不是特別有用，尤其是在「匹配」選項卡上，這應該是最有趣的部分。
Hinge 匯出中的「匹配」選項卡包含「匹配」列表，或者更確切地說是「交互」列表，正如我在該項目中所說的那樣，如下所示：
第 1 場2024-01-22 20:13:22 贊
第 2 場2024-01-23 20:15:42 贊
第 3 場2024-01-23 20:37:27 比賽
2024-01-23 20:39:45 聊天：你好，世界！
2024-01-23 21:49:26 刪除
Hinge 提供的配對清單還有很多不足之處，這就是為什麼我決定建立這個項目，分析和視覺化來自 Hinge 資料匯出的有趣見解。
該應用程式是一個多頁面 Dash Plotly 應用程序，在端口8050上的 Docker 容器中運行。使用以下命令建立 Docker 建置映像： docker compose build並使用以下命令執行應用程式： docker compose up -d 。該應用程式將在 http://0.0.0.0:8050/ 上提供。若要關閉容器，請使用docker compose down 。
該頁面將呈現有關應用程式的資訊以及如何使用它的說明。
「上傳檔案」部分可讓使用者上傳matches.json或user.json檔案進行分析。目前，程式期望該檔案名稱為matches.json或user.json ，因為它們位於 Hinge 提供的匯出中。選擇檔案後，上傳框下方應顯示上傳的檔案名稱。
「資料洞察」部分包含用於顯示包含與匹配資料或使用者資料相關的資料的頁面的連結。按一下「配對」或「使用者」以顯示任一主題的資訊和圖表。視覺化最初將顯示為空白圖表，直到上傳檔案並重新載入圖表。點擊「重新載入圖表」按鈕將使用上傳的資料重新產生圖表。
比賽分析頁麵包含多個圖表，顯示比賽資料的不同面向。出於隱私原因，Hinge 僅提供有關用戶操作的數據，因此大多數數據與用戶如何與其他用戶互動有關。
第一個圖是互動漏斗，它是使用者與其他使用者之間發生的不同類型互動的視覺化。漏斗「獨特互動」最外層的部分是發生的獨特互動的總數。這是用戶收到但未回覆的讚、用戶發送但未回覆的點讚以及用戶發送的讚導致匹配和聊天的組合。
漏斗是查看用戶發起了多少互動以及有多少互動導致匹配和對話的好方法。
您發送的「傳出讚」部分包含更詳細地了解用戶傳出點讚的圖表。第一個圖表顯示了用戶多次喜歡的應用程式上的用戶。這種情況令人困惑，因為尚不清楚這是如何發生的，但在數據中確實很少發生。右側第二個圓餅圖顯示了使用者透過留言發送的傳出點讚數的比率。
在圓餅圖下方，有一個名為「當您喜歡某人的內容時您評論的內容」的表，該表顯示用戶喜歡其他用戶的個人資料時在其他用戶的個人資料上留下的評論。此表對於查看用戶在喜歡其他用戶時對其他用戶說了什麼非常有用。
下一部分按天操作類型的頻率顯示使用者每天在應用程式上執行的不同操作的頻率。這對於查看活動模式以及它們在應用程式上最活躍的時間非常有用。
之後，有一個餅圖，名為“您將電話號碼給了多少人？” ，這恰恰表明了這一點。在用戶進行的所有導致聊天的互動中，此圖顯示了導致用戶洩露電話號碼的聊天次數的比率。這是在假設用戶以下面列出的常見格式之一共享其電話號碼的情況下進行的。
匹配分析的最後一部分顯示每個聊天的傳出訊息。此條形圖是用戶在交換訊息的每次互動中發送的訊息數量的分佈。這對於查看用戶與其他人的對話的平均長度非常有用。
此選項卡目前正在建設中，並將在未來版本中提供。
Hinge 會不時更改和更新資料匯出的架構，這可能會或可能不會破壞當前的分析程式碼並使內容過時。到目前為止，我還沒有經歷過任何破壞我的程式碼的架構更改，但我認為隨著時間的推移，將會發生更改，並且事情將不再起作用。目前我還沒有找到一種方法來及時了解他們的架構變更。
由於 Hinge 沒有提供任何文檔，因此我對資料做出一些假設：
where block_type = 'remove' ）可以向任一方向移動，這意味著該區塊可以代表某人刪除與該用戶的匹配，也可以代表用戶刪除與其他人的區塊在匯出資料中可能發生多種情況，Hinge 將其稱為「匹配」。這些並不都是“匹配”，因為有些事件只是簡單的傳出的喜歡而沒有得到回報。這就是為什麼我將它們稱為交互，其中交互代表用戶和另一個人之間發生的相遇（喜歡、匹配、聊天、阻止）。
以下是資料中發生的不同互動場景：
| 喜歡 | 匹配 | 聊天記錄 | 堵塞 | 意義 |
|---|---|---|---|---|
| X | 用戶發送了一條傳出訊息，但對方不喜歡回复 | |||
| X | X | X | 用戶發出了一個外向的點贊，其他人也回覆了他們，至少交換了一條訊息 | |
| X | X | 用戶收到了點贊，用戶也給了對方點贊，並且至少交換了一條訊息 | ||
| X | 匹配被刪除或“不匹配”，無法分辨誰不匹配誰。由於某種原因，其中許多在沒有任何其他資訊的情況下存在，並且無法判斷它最初連結到哪個交互 | |||
| X | X | 用戶收到了傳入的點贊，用戶回讚了對方，沒有交換任何訊息，並且匹配被刪除 |
我有一長串的增強和修復列表，我想對應用程式進行改進，以使其變得更好。若要查看現有內容，請查看儲存庫中的「項目」標籤。
