點擊統計重要嗎？沒統計的短網址（drrop / ppt.cc）適合什麼場景
bit.ly / lihi 有完整點擊統計，drrop.cc / ppt.cc 沒有。為什麼有些短網址服務「故意」不做統計？這篇拆解 trade-off 與適用場景。
bit.ly 後台能看每條短網址的：點擊次數、地理位置、來源、裝置、瀏覽器、點擊時段、reference。資料密度高，對行銷人是寶。
但 drrop.cc、ppt.cc、myppt.cc 等服務完全不做點擊統計 — 後台只有「click_count」一個數字（甚至有些連這個都不顯示給 user）。
為什麼有些服務「故意」不做統計？這個 trade-off 對你的場景重要嗎？本文拆解 4 個面向。
為什麼有統計：bit.ly / lihi 的價值主張
bit.ly Pro 月費 $35 起，價值就在 analytics。典型 use case：
- 行銷活動 ROI：發 newsletter 內含 5 條短網址，看哪條點擊率最高
- A/B test：兩條版本不同的 CTA 連結，比較轉化
- 流量來源歸因：知道你的文章主要被哪個社群轉發（FB / Twitter / LinkedIn）
- 裝置 / 地區分析：知道 user 是手機還是桌面、台灣還是日本
對「需要數據做決策」的場景，統計是核心功能。
為什麼沒統計：drrop / ppt.cc 的設計選擇
「沒統計」不是省事 — 是隱私導向設計的必然結果。
① 完整點擊統計 = 大量個資收集
要實作 bit.ly 等級的統計，伺服器要記：
- IP 地址（每次點擊都記）
- User-Agent（裝置 / 瀏覽器 / OS）
- Referer（從哪個網站點過來）
- 時間戳（精確到秒）
- 點擊者地理位置（從 IP 推算）
這些資料等同於追蹤每個點擊者的行為足跡。即便資料「只給短網址擁有者看」— 服務方手上仍持有龐大個資 DB。
對 GDPR / CCPA / 台灣個資法的合規門檻很高。
② 不存 IP = 不能做統計
drrop.cc 設計上不存原始 IP — 只存 HMAC-SHA256(IP) 雜湊 + 國家碼，用於 rate limit。
雜湊後的 IP 不能反推 → 無法做地理 / 來源歸因 → 自然沒辦法生統計報表。
這是主動限制自己的能力，換取「即使我們資料庫被駭，也拿不到 user IP」的保證。
③ 服務定位差異
bit.ly / lihi 是商業工具，目標 user 是企業 / 行銷人。 drrop.cc / ppt.cc 是中性工具，目標 user 是個人臨時用途。
商業場景需要 analytics；個人臨時場景不太需要 — 反而隱私更重要。
對比 matrix
| 屬性 | bit.ly Pro | lihi.io | drrop.cc | ppt.cc / myppt |
|---|---|---|---|---|
| 點擊次數 | ✓ | ✓ | ✓（總計） | ✗ |
| 地理位置 | ✓ | ✓ | ✗ | ✗ |
| 來源 referrer | ✓ | ✓ | ✗ | ✗ |
| 裝置 / 瀏覽器 | ✓ | ✓ | ✗ | ✗ |
| 時段分析 | ✓ | ✓ | ✗ | ✗ |
| 不存 IP | ✗ | ✗ | ✓ | ✓ |
| 月費 | $35+ | 免費 / pro | 免費 | 免費 |
適合「沒統計」的 4 種場景
① 私密內容分享
傳一段影片 / 圖片給特定一個人 — 你不需要知道對方在哪、用什麼裝置、何時看。這些資料反而是隱私洩漏。
② 不關心 ROI 的個人分享
LINE 群組丟一條維基百科連結 / Twitter 分享一篇文章 — 你純粹是分享，不是行銷活動。沒統計也沒差。
③ 想避免「被看見」的場景
有些 user 不希望短網址擁有者知道他點過什麼（譬如記者、舉報人、敏感角色）。「沒統計的短網址」是對點擊者的保護。
④ 隱私導向的個人品牌
經營「隱私倡議者」「資安研究者」「治療師」這類品牌，自己使用無統計工具 = 言行一致。
適合「有統計」的 4 種場景
① 行銷 ROI 衡量
你發 newsletter 想看哪篇 CTA 最有效。
② A/B test
比較兩個版本的轉化率。
③ Social media 經營
知道你的內容被哪個平台轉發最多。
④ 商業 KPI 報告
每月給老闆 / 客戶看流量數字。
妥協方案：自己做基礎統計
如果你只需要「總點擊次數」，沒統計的短網址也能透過外部方式追蹤：
① Google Analytics 在目標 URL
你的目標 URL（如果是你的網站）裝 GA — 看「來自 drrop.cc 的訪問數」。
② UTM parameter 加到目標 URL
縮短前先給目標加 UTM：
mysite.com/article?utm_source=newsletter&utm_medium=drrop- 縮網址後對方點過去 → GA 仍能識別 UTM
drrop.cc 不會剝 UTM — 目標 URL 完整保留。
③ 短網址服務自己看 click_count
drrop.cc admin 後台能看每條短網址的總 click_count（但只有自己 admin 看，user 看不到自己的）。
終極問題：你真的需要統計嗎？
很多人「以為自己需要」統計，實際上沒看數據做任何決策。每月看一下 bit.ly dashboard、感嘆「點擊不夠多」、然後關掉視窗。
真正會「依數據優化」的 user 是少數。對 80% 的個人 user 來說，沒統計反而是好事 — 少了監控他人的負擔、少了個資外洩風險。
drrop.cc 的選擇
drrop.cc 處於折衷位置：
- 記點擊次數（click_count）— 你的短網址被點幾次（總數）
- 不記任何個人化資料 — 沒有 IP / referrer / 裝置 / 地區
- 不公開儀表板 — 連總點擊次數也不顯示在 user 介面（admin 後台才看得到）
這個選擇是「有最低限度的 admin 監控（防 abuse） + 對 user 完全隱私」的平衡。
FAQ
Q：drrop.cc 真的不存 IP 嗎？
A：對。我們存 HMAC-SHA256(IP + 固定 salt) 雜湊用於 rate limit，不存原始 IP。即便我們資料庫被駭，攻擊者拿到的也只是 hashed 串、無法反推。
Q：我用 drrop.cc 縮網址，能不能事後查點擊次數？ A：目前不行 — 我們沒做 user-facing 統計頁。未來可能會加「點擊次數查詢」（只顯示總次數，不顯示誰、何時、從哪）。
Q：drrop.cc 完全沒任何 analytics 嗎？ A：admin 後台有：總體統計（每日上傳 / 點擊 / 活躍 link）、Cloudflare GraphQL Analytics（worker invocations / D1 reads / R2 storage）。但這些都是聚合層級，沒有 per-user / per-link 追蹤。
Q：bit.ly 的點擊統計準嗎？ A：相對準（基於真實 hit），但有：bot 流量混入（VC / 爬蟲）、cache hit 看不到、broken referrer（多數 referrer 被 modern browser strip）。「精確 ROI」很難。
Q：我能在 drrop.cc 短網址後面加 UTM 嗎？
A：對 — 縮短的時候，給目標 URL 加 UTM 就好。譬如 mysite.com/article?utm_source=line&utm_medium=share。drrop.cc 完整保留 UTM。
最後
「需要統計嗎？」這個問題的答案，反過來問自己比較準：
- 你會根據數據改你的行為嗎？
- 你看完統計，會做什麼決定？
- 還是看完就忘？
如果你不會 based on 數據做事，那你不需要統計 — 用個 privacy-friendly 的短網址（drrop.cc / ppt.cc）就好。
如果你確實會 based on 數據優化，那 bit.ly Pro 月費 $35 是合理投資 — 別省那個錢用 drrop.cc 然後天天恨缺統計。
→ 不需要統計 → drrop.cc 立刻可用