<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Freemium on Tarragon</title><link>https://tarrragon.github.io/blog/tags/freemium/</link><description>Recent content in Freemium on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Fri, 02 Oct 2026 00:00:00 +0800</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/freemium/index.xml" rel="self" type="application/rss+xml"/><item><title>短網址的商業模型：訂閱、自架、平台內建與廣告插頁各由誰出資維持轉址</title><link>https://tarrragon.github.io/blog/business/case-analyses/url-shortener-business-models/</link><pubDate>Fri, 02 Oct 2026 00:00:00 +0800</pubDate><guid>https://tarrragon.github.io/blog/business/case-analyses/url-shortener-business-models/</guid><description>&lt;p>這篇拆解短網址這個產品類別裡，各家業者靠誰出的錢維持轉址，以及每一種出資方式對「連結會活多久、點擊會不會被記錄」做了什麼承諾。資料取自各家的方案頁與說明頁、官方公告、新聞報導與一篇學術研究；方案頁與說明頁的內容是 2026-10-02 查閱時的狀態，會隨業者調整而變動，所以文中寫方案之間的結構差異與查閱當日的分級內容、不寫價格，採用前以各家當下的方案頁為準。&lt;/p>
&lt;p>要不要買現成服務、以及這些承諾怎麼轉成自建時的需求規格，見 &lt;a href="https://tarrragon.github.io/blog/backend/00-service-selection/url-shortener-requirements/" data-link-title="0.23 短網址服務的需求定義：自建或購買、保存期限、目的地修改與濫用處理的規格" data-link-desc="短網址服務交給工程之前要定案的需求決定：自建或購買、點擊資料的地位、連結的保存承諾、目的地能否修改、建立者的範圍、短碼的可猜測性、網域策略與可用性分級；多數答案由商業模型推出，目的地修改、短碼可猜測性與可用性分級由使用情境決定">0.23 短網址服務的需求定義：自建或購買、保存期限、目的地修改與濫用處理的規格&lt;/a>；需求規格怎麼落到實作，見 &lt;a href="https://tarrragon.github.io/blog/backend/00-service-selection/url-shortener-implementation/" data-link-title="0.24 短網址服務的實作：短碼生成、對照表儲存、轉址快取與點擊紀錄" data-link-desc="以需求已定案為前提的實作取捨：建立與轉址兩條路徑的流量形狀、各種短碼生成方式的可猜測性與協調成本、轉址狀態碼與各層快取怎麼影響停用或修改連結多久生效、點擊事件的非同步紀錄、濫用防護、服務結束時的靜態轉址與網域去向，以及換掉任一項需求決定時要重選的實作位置">0.24 短網址服務的實作：短碼生成、對照表儲存、轉址快取與點擊紀錄&lt;/a>。&lt;/p>
&lt;h2 id="轉址功能的邊際成本差異化空間與出資方式的界定">轉址功能的邊際成本、差異化空間與出資方式的界定&lt;/h2>
&lt;p>短網址的核心功能是收到一個短碼、回一個轉址到長網址。這個功能的&lt;a href="https://tarrragon.github.io/blog/business/knowledge-cards/marginal-cost/" data-link-title="Marginal Cost" data-link-desc="說明邊際成本及其對商業模式擴張性的決定作用">邊際成本&lt;/a>接近零：多轉址一次只是多一次資料庫查詢與一個 HTTP 回應。功能本身也沒有差異化的空間——對點擊的人來說，經過哪一家的轉址都是抵達同一個目的地，而 MIT 授權的開源專案 YOURLS 讓任何人都能在自己的主機上架一套。&lt;/p>
&lt;p>功能沒有差異、成本接近零、任何人都能自己架，這是 &lt;a href="https://tarrragon.github.io/blog/business/knowledge-cards/commodity-business/" data-link-title="Commodity Business" data-link-desc="判斷一間公司是否受困於大宗商品結構（產品同質、定價被市場決定、利潤被上下游夾擠）時，辨識 commodity 特徵和突圍路徑的概念">commodity business&lt;/a> 的形狀，而客戶很難只為這類功能本身付錢。早期業者的經歷印證了這一點：TinyURL 在 2002 年推出，2004 年 Wired 的報導記載它的營運成本由 Google AdSense 廣告支付，創辦人表示服務會維持免費，同時計畫對客製化與統計功能收費（&lt;a href="https://www.wired.com/2004/03/honey-i-shrunk-the-url/">Wired, 2004&lt;/a>）；tr.im 在 2009 年宣布關站時，營運方的說法是「沒有辦法靠縮網址賺錢，使用者不會為它付費」，而 Twitter 幾乎已經欽定 bit.ly 為市場的勝出者（&lt;a href="https://www.theregister.com/software/2009/08/10/trim-cuts-air-supply-says-no-money-in-tiny-web-20-pot/660990">The Register, 2009&lt;/a>）。&lt;/p>
&lt;p>業者仍然按每月可建立的連結數計價（Bitly 的方案頁在每一級方案列出每月可建立的 QR code 數與連結數），但連結數只是計量單位，讓客戶升級的理由落在轉址以外的功能上。所以要問的是維持轉址的錢從哪裡來，本篇把答案統稱為&lt;strong>出資方式&lt;/strong>，它由兩件事界定：誰出錢，以及出錢的人買到什麼。出錢的有四方：建立連結的人（付訂閱費給業者）、自架者自己（付主機與網域費）、母公司（以其他業務的預算支付平台內建的短網址）、廣告主（付廣告插頁的廣告費）。向建立連結的人收費的業者，各自用不同的功能當付費理由：點擊分析、品牌網域，或代管開源專案的託管版本；同一家業者可以同時用好幾個理由，Dub 就同時賣分析與託管。和短網址一起出現的 QR code 與 link-in-bio 是點擊分析這個付費理由往外的成長方向；連結能活多久，則取決於每一種出資方式能維持多久。&lt;/p>
&lt;h2 id="點擊資料分析功能的訂閱分級與保留期">點擊資料：分析功能的訂閱分級與保留期&lt;/h2>
&lt;p>每一次轉址都經過短網址服務，所以服務能記下這次點擊的時間、來源、地理位置與裝置類型。這份點擊資料對建立連結的人有價值：行銷團隊靠它判斷哪一個活動、哪一個管道帶來了流量。以點擊分析為核心的業者把這份資料做成訂閱制的 &lt;a href="https://tarrragon.github.io/blog/business/knowledge-cards/saas/" data-link-title="SaaS" data-link-desc="說明雲端訂閱軟體的商業模式與經濟特徵">SaaS&lt;/a>，用免費方案吸引使用者，再依分析能力分級收費，這種「免費方案加付費分級」的定價叫 freemium。&lt;/p>
&lt;p>Bitly 是這一型的代表。它在 2008 年成立，2017 年 Spectrum Equity 對它做了 6,300 萬美元的多數股權投資，投資方的合夥人形容經營團隊在投資之前完成的轉變是「把公司從只有免費服務，轉成快速成長、已經獲利的 freemium SaaS」（&lt;a href="https://www.spectrumequity.com/news/bitly-receives-investment-from-spectrum-equity/">Spectrum Equity, 2017&lt;/a>）。Bitly 的方案頁上，各級方案以每月可建立的連結數計量，同時以點擊資料區隔：免費方案看不到歷史資料，付費方案的資料保留期從 30 天逐級延長到企業方案的 2 年，城市層級與裝置類型的細分要到較高的方案才開放（&lt;a href="https://bitly.com/pages/pricing">Bitly 方案頁&lt;/a>）。以開源起家的 Dub 用同一條軸分級，分析資料的保留期從免費方案的 30 天逐級延長到 Advanced 方案的 5 年，企業方案不設上限（&lt;a href="https://dub.co/pricing/links">Dub 方案頁&lt;/a>）。&lt;/p>
&lt;p>保留期適合當分級的主軸，因為它對客戶的價值隨時間增加：保存越久，能做的跨季、跨年比較越多；而點擊資料按小時彙總之後體積很小，延長保留期對業者的邊際成本低，所以這條分級軸對應的主要是客戶的支付意願，不是業者的成本；業者沒有公開資料保存的成本結構，這是由彙總後的資料量推出的判斷。&lt;/p>
&lt;p>點擊分析型收入對產品的要求是：客戶付費買的是點擊數字，而瀏覽器可能把轉址結果存起來，之後的重複點擊直接在本機轉往目的地、不經過服務；所以轉址回應要限制瀏覽器保存的時間，讓點擊在很短的時間窗內就回到服務被記錄，記下的點擊事件也不能遺失。這個要求轉成需求規格的過程，見 &lt;a href="https://tarrragon.github.io/blog/backend/00-service-selection/url-shortener-requirements/" data-link-title="0.23 短網址服務的需求定義：自建或購買、保存期限、目的地修改與濫用處理的規格" data-link-desc="短網址服務交給工程之前要定案的需求決定：自建或購買、點擊資料的地位、連結的保存承諾、目的地能否修改、建立者的範圍、短碼的可猜測性、網域策略與可用性分級；多數答案由商業模型推出，目的地修改、短碼可猜測性與可用性分級由使用情境決定">0.23 短網址服務的需求定義&lt;/a> 的〈點擊資料的地位：付費功能或內部參考，以及對應的規格〉一節。&lt;/p>
&lt;h2 id="網域品牌短網址的定價與切換成本">網域：品牌短網址的定價與切換成本&lt;/h2>
&lt;p>短網址預設使用業者自己的網域（例如 &lt;code>bit.ly/xxxx&lt;/code>），企業客戶通常想換成自己的&lt;strong>品牌網域&lt;/strong>（例如 &lt;code>go.example.com/xxxx&lt;/code>；各家方案頁多稱為「自訂網域」，指的是同一件事）。品牌網域的價值有兩層：點擊的人看得到建立連結的是誰，信任度較高；連結的名聲也和業者共用網域上的其他使用者分開，別人用共用網域散布釣魚連結，不會連累到品牌網域。&lt;/p>
&lt;p>各家對這項功能的定價差異很大。Bitly 把品牌網域放在中階以上的付費方案，多個網域另外加購（&lt;a href="https://bitly.com/pages/pricing">Bitly 方案頁&lt;/a>）；Rebrandly 的免費方案就附一個自訂網域，付費分級改依詳細點擊資料的數量、團隊協作與合規認證（&lt;a href="https://www.rebrandly.com/pricing">Rebrandly 方案頁&lt;/a>）；Short.io 的方案頁直接標明每一個方案都包含自訂網域與點擊分析（&lt;a href="https://short.io/pricing">Short.io 方案頁&lt;/a>）。品牌網域在 Bitly 仍是付費牆，在 Rebrandly、Short.io 這類以品牌網域為主打的業者已經成了吸引使用者的入門功能，付費牆移到了分析與合規。&lt;/p>
&lt;p>品牌網域還改變了客戶的&lt;a href="https://tarrragon.github.io/blog/business/knowledge-cards/switching-cost/" data-link-title="Switching Cost" data-link-desc="說明切換成本如何鞏固客戶留存">切換成本&lt;/a>。連結使用業者的網域時，客戶換業者就得放棄所有已發出的連結，這是一種 &lt;a href="https://tarrragon.github.io/blog/business/knowledge-cards/lock-in/" data-link-title="Lock-in" data-link-desc="說明鎖定效應如何形成護城河">lock-in&lt;/a>；連結使用客戶自己的網域時，客戶把網域的 DNS 指到新業者、匯入&lt;strong>短碼對照表&lt;/strong>（每個短碼對應到哪一個長網址的那份資料；前提是舊業者允許匯出、新業者接受匯入既有短碼），舊連結就能繼續運作。所以品牌網域對客戶是保險，對業者則降低了綁定客戶的力量；免費附自訂網域的業者，等於讓新客戶從第一條連結起就不被綁定。&lt;/p>
&lt;h2 id="相鄰產品qr-code-與-link-in-bio">相鄰產品：QR code 與 link-in-bio&lt;/h2>
&lt;p>轉址本身沒有差異化空間，業者成長的方向是和短網址一起出現的相鄰產品。業者產生的動態 QR code（碼裡編的是短網址，不是目的地）運作方式和短網址相同：印在實體物品上，掃描後同樣經過一次轉址，同樣能記錄掃描資料。link-in-bio 頁面（社群帳號自介欄位裡放的那一條連結，點進去是一頁列出多條連結的頁面）則是短網址往「一條連結承載多個目的地」的延伸。QR code 印上實體物品之後就無法更換，它背後短網址的存續條件和一般連結相同，而且更難補救；停止付費之後印好的 QR code 還轉不轉址，要在簽約前查清楚，見〈訂閱型業者的收入重心與連結承諾的預警訊號〉。&lt;/p>
&lt;p>Bitly 在 2021 年收購 QR code 生成服務 Egoditor，並把產品線合稱為 Customer Connections Platform，涵蓋連結管理、QR code 與 link-in-bio。收購公告附上的規模數字是 Bitly 與 Egoditor 合併後有 32.5 萬名付費客戶、年度經常性收入超過 7,500 萬美元，並且已經獲利（&lt;a href="https://www.prnewswire.com/news-releases/bitly-emerges-as-global-saas-leader-with-acquisition-of-egoditor-301434779.html">收購新聞稿, 2021&lt;/a>）。2023 年 1 月 Bitly 另外公布 2022 年的年度經常性收入超過 1 億美元、客戶超過 50 萬（這份公告沒有區分付費客戶，也沒有提到獲利）（&lt;a href="https://www.prnewswire.com/news-releases/bitly-wraps-2022-surpassing-100m-in-arr-and-500-000-global-customers-301724225.html">Bitly 新聞稿, 2023&lt;/a>）。&lt;/p>
&lt;h2 id="開源核心與自架收入安排與營運責任">開源核心與自架：收入安排與營運責任&lt;/h2>
&lt;p>轉址功能容易實作，也就容易開源。開源方案有兩種收入安排。Dub 採 open core：主要程式碼以 AGPLv3 授權公開，企業版功能放在另一個商業授權的目錄裡，同時提供託管服務收費（&lt;a href="https://github.com/dubinc/dub">Dub GitHub&lt;/a>）。YOURLS 以 MIT 授權發布，沒有付費方案，營運靠贊助（&lt;a href="https://yourls.org/">YOURLS&lt;/a>）。&lt;/p>
&lt;p>選擇自架的組織省下訂閱費，同時接下業者原本承擔的幾件事：網域要自己續約、主機要自己維持運作、濫用要自己處理、點擊資料裡的個人資料要自己負責保管與刪除。網域與主機停了，連結就跟著失效；濫用沒處理，網域就可能被封鎖清單擋下（見〈連結永久性：各出資方式下連結的存續條件〉與〈廣告插頁：廣告抽成的差價與濫用風險〉兩節）。所以自架是把成本從訂閱費換成營運責任，而不是消除成本。&lt;/p>
&lt;h2 id="平台內建平台自己經營短網址的用途與預算來源">平台內建：平台自己經營短網址的用途與預算來源&lt;/h2>
&lt;p>社群平台與電商平台自己經營短網址，不向任何人收費。這類短網址對平台的用處由平台自己的需求決定。&lt;/p>
&lt;p>X（前 Twitter）的說明頁列出它把貼文中的連結一律改寫成 t.co 短網址的理由：讓長網址放得進字數上限；量測點擊次數，當作判斷貼文相關性的品質訊號；比對潛在危險網站的清單，點到時顯示警告頁。使用者不能選擇不被縮短，t.co 也不對外提供一般的縮網址服務（&lt;a href="https://help.x.com/en/using-x/url-shortener">X 說明頁&lt;/a>）。電商的推薦計畫是另一種用途：Amazon Associates 產生的短連結會自動帶入推薦者的追蹤 ID，讓推薦帶來的購買能被歸因、分潤給推薦者（&lt;a href="https://affiliate-program.amazon.com/help/node/topic/GJMMT7G4C8K4Y3AY">Amazon Associates 說明頁&lt;/a>）。各平台縮短連結的理由不同：LinkedIn 的說明頁對自動縮短連結只寫了「方便閱讀」，沒有提到安全掃描（&lt;a href="https://www.linkedin.com/help/linkedin/answer/a521889/short-urls-in-shared-posts">LinkedIn 說明頁&lt;/a>）。&lt;/p></description><content:encoded><![CDATA[<p>這篇拆解短網址這個產品類別裡，各家業者靠誰出的錢維持轉址，以及每一種出資方式對「連結會活多久、點擊會不會被記錄」做了什麼承諾。資料取自各家的方案頁與說明頁、官方公告、新聞報導與一篇學術研究；方案頁與說明頁的內容是 2026-10-02 查閱時的狀態，會隨業者調整而變動，所以文中寫方案之間的結構差異與查閱當日的分級內容、不寫價格，採用前以各家當下的方案頁為準。</p>
<p>要不要買現成服務、以及這些承諾怎麼轉成自建時的需求規格，見 <a href="/blog/backend/00-service-selection/url-shortener-requirements/" data-link-title="0.23 短網址服務的需求定義：自建或購買、保存期限、目的地修改與濫用處理的規格" data-link-desc="短網址服務交給工程之前要定案的需求決定：自建或購買、點擊資料的地位、連結的保存承諾、目的地能否修改、建立者的範圍、短碼的可猜測性、網域策略與可用性分級；多數答案由商業模型推出，目的地修改、短碼可猜測性與可用性分級由使用情境決定">0.23 短網址服務的需求定義：自建或購買、保存期限、目的地修改與濫用處理的規格</a>；需求規格怎麼落到實作，見 <a href="/blog/backend/00-service-selection/url-shortener-implementation/" data-link-title="0.24 短網址服務的實作：短碼生成、對照表儲存、轉址快取與點擊紀錄" data-link-desc="以需求已定案為前提的實作取捨：建立與轉址兩條路徑的流量形狀、各種短碼生成方式的可猜測性與協調成本、轉址狀態碼與各層快取怎麼影響停用或修改連結多久生效、點擊事件的非同步紀錄、濫用防護、服務結束時的靜態轉址與網域去向，以及換掉任一項需求決定時要重選的實作位置">0.24 短網址服務的實作：短碼生成、對照表儲存、轉址快取與點擊紀錄</a>。</p>
<h2 id="轉址功能的邊際成本差異化空間與出資方式的界定">轉址功能的邊際成本、差異化空間與出資方式的界定</h2>
<p>短網址的核心功能是收到一個短碼、回一個轉址到長網址。這個功能的<a href="/blog/business/knowledge-cards/marginal-cost/" data-link-title="Marginal Cost" data-link-desc="說明邊際成本及其對商業模式擴張性的決定作用">邊際成本</a>接近零：多轉址一次只是多一次資料庫查詢與一個 HTTP 回應。功能本身也沒有差異化的空間——對點擊的人來說，經過哪一家的轉址都是抵達同一個目的地，而 MIT 授權的開源專案 YOURLS 讓任何人都能在自己的主機上架一套。</p>
<p>功能沒有差異、成本接近零、任何人都能自己架，這是 <a href="/blog/business/knowledge-cards/commodity-business/" data-link-title="Commodity Business" data-link-desc="判斷一間公司是否受困於大宗商品結構（產品同質、定價被市場決定、利潤被上下游夾擠）時，辨識 commodity 特徵和突圍路徑的概念">commodity business</a> 的形狀，而客戶很難只為這類功能本身付錢。早期業者的經歷印證了這一點：TinyURL 在 2002 年推出，2004 年 Wired 的報導記載它的營運成本由 Google AdSense 廣告支付，創辦人表示服務會維持免費，同時計畫對客製化與統計功能收費（<a href="https://www.wired.com/2004/03/honey-i-shrunk-the-url/">Wired, 2004</a>）；tr.im 在 2009 年宣布關站時，營運方的說法是「沒有辦法靠縮網址賺錢，使用者不會為它付費」，而 Twitter 幾乎已經欽定 bit.ly 為市場的勝出者（<a href="https://www.theregister.com/software/2009/08/10/trim-cuts-air-supply-says-no-money-in-tiny-web-20-pot/660990">The Register, 2009</a>）。</p>
<p>業者仍然按每月可建立的連結數計價（Bitly 的方案頁在每一級方案列出每月可建立的 QR code 數與連結數），但連結數只是計量單位，讓客戶升級的理由落在轉址以外的功能上。所以要問的是維持轉址的錢從哪裡來，本篇把答案統稱為<strong>出資方式</strong>，它由兩件事界定：誰出錢，以及出錢的人買到什麼。出錢的有四方：建立連結的人（付訂閱費給業者）、自架者自己（付主機與網域費）、母公司（以其他業務的預算支付平台內建的短網址）、廣告主（付廣告插頁的廣告費）。向建立連結的人收費的業者，各自用不同的功能當付費理由：點擊分析、品牌網域，或代管開源專案的託管版本；同一家業者可以同時用好幾個理由，Dub 就同時賣分析與託管。和短網址一起出現的 QR code 與 link-in-bio 是點擊分析這個付費理由往外的成長方向；連結能活多久，則取決於每一種出資方式能維持多久。</p>
<h2 id="點擊資料分析功能的訂閱分級與保留期">點擊資料：分析功能的訂閱分級與保留期</h2>
<p>每一次轉址都經過短網址服務，所以服務能記下這次點擊的時間、來源、地理位置與裝置類型。這份點擊資料對建立連結的人有價值：行銷團隊靠它判斷哪一個活動、哪一個管道帶來了流量。以點擊分析為核心的業者把這份資料做成訂閱制的 <a href="/blog/business/knowledge-cards/saas/" data-link-title="SaaS" data-link-desc="說明雲端訂閱軟體的商業模式與經濟特徵">SaaS</a>，用免費方案吸引使用者，再依分析能力分級收費，這種「免費方案加付費分級」的定價叫 freemium。</p>
<p>Bitly 是這一型的代表。它在 2008 年成立，2017 年 Spectrum Equity 對它做了 6,300 萬美元的多數股權投資，投資方的合夥人形容經營團隊在投資之前完成的轉變是「把公司從只有免費服務，轉成快速成長、已經獲利的 freemium SaaS」（<a href="https://www.spectrumequity.com/news/bitly-receives-investment-from-spectrum-equity/">Spectrum Equity, 2017</a>）。Bitly 的方案頁上，各級方案以每月可建立的連結數計量，同時以點擊資料區隔：免費方案看不到歷史資料，付費方案的資料保留期從 30 天逐級延長到企業方案的 2 年，城市層級與裝置類型的細分要到較高的方案才開放（<a href="https://bitly.com/pages/pricing">Bitly 方案頁</a>）。以開源起家的 Dub 用同一條軸分級，分析資料的保留期從免費方案的 30 天逐級延長到 Advanced 方案的 5 年，企業方案不設上限（<a href="https://dub.co/pricing/links">Dub 方案頁</a>）。</p>
<p>保留期適合當分級的主軸，因為它對客戶的價值隨時間增加：保存越久，能做的跨季、跨年比較越多；而點擊資料按小時彙總之後體積很小，延長保留期對業者的邊際成本低，所以這條分級軸對應的主要是客戶的支付意願，不是業者的成本；業者沒有公開資料保存的成本結構，這是由彙總後的資料量推出的判斷。</p>
<p>點擊分析型收入對產品的要求是：客戶付費買的是點擊數字，而瀏覽器可能把轉址結果存起來，之後的重複點擊直接在本機轉往目的地、不經過服務；所以轉址回應要限制瀏覽器保存的時間，讓點擊在很短的時間窗內就回到服務被記錄，記下的點擊事件也不能遺失。這個要求轉成需求規格的過程，見 <a href="/blog/backend/00-service-selection/url-shortener-requirements/" data-link-title="0.23 短網址服務的需求定義：自建或購買、保存期限、目的地修改與濫用處理的規格" data-link-desc="短網址服務交給工程之前要定案的需求決定：自建或購買、點擊資料的地位、連結的保存承諾、目的地能否修改、建立者的範圍、短碼的可猜測性、網域策略與可用性分級；多數答案由商業模型推出，目的地修改、短碼可猜測性與可用性分級由使用情境決定">0.23 短網址服務的需求定義</a> 的〈點擊資料的地位：付費功能或內部參考，以及對應的規格〉一節。</p>
<h2 id="網域品牌短網址的定價與切換成本">網域：品牌短網址的定價與切換成本</h2>
<p>短網址預設使用業者自己的網域（例如 <code>bit.ly/xxxx</code>），企業客戶通常想換成自己的<strong>品牌網域</strong>（例如 <code>go.example.com/xxxx</code>；各家方案頁多稱為「自訂網域」，指的是同一件事）。品牌網域的價值有兩層：點擊的人看得到建立連結的是誰，信任度較高；連結的名聲也和業者共用網域上的其他使用者分開，別人用共用網域散布釣魚連結，不會連累到品牌網域。</p>
<p>各家對這項功能的定價差異很大。Bitly 把品牌網域放在中階以上的付費方案，多個網域另外加購（<a href="https://bitly.com/pages/pricing">Bitly 方案頁</a>）；Rebrandly 的免費方案就附一個自訂網域，付費分級改依詳細點擊資料的數量、團隊協作與合規認證（<a href="https://www.rebrandly.com/pricing">Rebrandly 方案頁</a>）；Short.io 的方案頁直接標明每一個方案都包含自訂網域與點擊分析（<a href="https://short.io/pricing">Short.io 方案頁</a>）。品牌網域在 Bitly 仍是付費牆，在 Rebrandly、Short.io 這類以品牌網域為主打的業者已經成了吸引使用者的入門功能，付費牆移到了分析與合規。</p>
<p>品牌網域還改變了客戶的<a href="/blog/business/knowledge-cards/switching-cost/" data-link-title="Switching Cost" data-link-desc="說明切換成本如何鞏固客戶留存">切換成本</a>。連結使用業者的網域時，客戶換業者就得放棄所有已發出的連結，這是一種 <a href="/blog/business/knowledge-cards/lock-in/" data-link-title="Lock-in" data-link-desc="說明鎖定效應如何形成護城河">lock-in</a>；連結使用客戶自己的網域時，客戶把網域的 DNS 指到新業者、匯入<strong>短碼對照表</strong>（每個短碼對應到哪一個長網址的那份資料；前提是舊業者允許匯出、新業者接受匯入既有短碼），舊連結就能繼續運作。所以品牌網域對客戶是保險，對業者則降低了綁定客戶的力量；免費附自訂網域的業者，等於讓新客戶從第一條連結起就不被綁定。</p>
<h2 id="相鄰產品qr-code-與-link-in-bio">相鄰產品：QR code 與 link-in-bio</h2>
<p>轉址本身沒有差異化空間，業者成長的方向是和短網址一起出現的相鄰產品。業者產生的動態 QR code（碼裡編的是短網址，不是目的地）運作方式和短網址相同：印在實體物品上，掃描後同樣經過一次轉址，同樣能記錄掃描資料。link-in-bio 頁面（社群帳號自介欄位裡放的那一條連結，點進去是一頁列出多條連結的頁面）則是短網址往「一條連結承載多個目的地」的延伸。QR code 印上實體物品之後就無法更換，它背後短網址的存續條件和一般連結相同，而且更難補救；停止付費之後印好的 QR code 還轉不轉址，要在簽約前查清楚，見〈訂閱型業者的收入重心與連結承諾的預警訊號〉。</p>
<p>Bitly 在 2021 年收購 QR code 生成服務 Egoditor，並把產品線合稱為 Customer Connections Platform，涵蓋連結管理、QR code 與 link-in-bio。收購公告附上的規模數字是 Bitly 與 Egoditor 合併後有 32.5 萬名付費客戶、年度經常性收入超過 7,500 萬美元，並且已經獲利（<a href="https://www.prnewswire.com/news-releases/bitly-emerges-as-global-saas-leader-with-acquisition-of-egoditor-301434779.html">收購新聞稿, 2021</a>）。2023 年 1 月 Bitly 另外公布 2022 年的年度經常性收入超過 1 億美元、客戶超過 50 萬（這份公告沒有區分付費客戶，也沒有提到獲利）（<a href="https://www.prnewswire.com/news-releases/bitly-wraps-2022-surpassing-100m-in-arr-and-500-000-global-customers-301724225.html">Bitly 新聞稿, 2023</a>）。</p>
<h2 id="開源核心與自架收入安排與營運責任">開源核心與自架：收入安排與營運責任</h2>
<p>轉址功能容易實作，也就容易開源。開源方案有兩種收入安排。Dub 採 open core：主要程式碼以 AGPLv3 授權公開，企業版功能放在另一個商業授權的目錄裡，同時提供託管服務收費（<a href="https://github.com/dubinc/dub">Dub GitHub</a>）。YOURLS 以 MIT 授權發布，沒有付費方案，營運靠贊助（<a href="https://yourls.org/">YOURLS</a>）。</p>
<p>選擇自架的組織省下訂閱費，同時接下業者原本承擔的幾件事：網域要自己續約、主機要自己維持運作、濫用要自己處理、點擊資料裡的個人資料要自己負責保管與刪除。網域與主機停了，連結就跟著失效；濫用沒處理，網域就可能被封鎖清單擋下（見〈連結永久性：各出資方式下連結的存續條件〉與〈廣告插頁：廣告抽成的差價與濫用風險〉兩節）。所以自架是把成本從訂閱費換成營運責任，而不是消除成本。</p>
<h2 id="平台內建平台自己經營短網址的用途與預算來源">平台內建：平台自己經營短網址的用途與預算來源</h2>
<p>社群平台與電商平台自己經營短網址，不向任何人收費。這類短網址對平台的用處由平台自己的需求決定。</p>
<p>X（前 Twitter）的說明頁列出它把貼文中的連結一律改寫成 t.co 短網址的理由：讓長網址放得進字數上限；量測點擊次數，當作判斷貼文相關性的品質訊號；比對潛在危險網站的清單，點到時顯示警告頁。使用者不能選擇不被縮短，t.co 也不對外提供一般的縮網址服務（<a href="https://help.x.com/en/using-x/url-shortener">X 說明頁</a>）。電商的推薦計畫是另一種用途：Amazon Associates 產生的短連結會自動帶入推薦者的追蹤 ID，讓推薦帶來的購買能被歸因、分潤給推薦者（<a href="https://affiliate-program.amazon.com/help/node/topic/GJMMT7G4C8K4Y3AY">Amazon Associates 說明頁</a>）。各平台縮短連結的理由不同：LinkedIn 的說明頁對自動縮短連結只寫了「方便閱讀」，沒有提到安全掃描（<a href="https://www.linkedin.com/help/linkedin/answer/a521889/short-urls-in-shared-posts">LinkedIn 說明頁</a>）。</p>
<p>平台內建的短網址是平台的<strong>成本中心</strong>：它只產生營運成本、本身不帶進收入，預算由母公司的其他業務支付，換到的點擊訊號、安全掃描與歸因資料都留在平台內部使用。成本中心的存續取決於母公司還需不需要它，goo.gl 的關站過程就是這個存續條件的實例（見〈連結永久性：各出資方式下連結的存續條件〉）。</p>
<h2 id="廣告插頁廣告抽成的差價與濫用風險">廣告插頁：廣告抽成的差價與濫用風險</h2>
<p>廣告插頁型的短網址把付錢的方向反過來：業者付錢給建立連結的人。點擊者點下短網址之後，先看到一頁廣告（插頁），再繼續前往目的地；業者向廣告主收費，再把其中一部分分給建立連結的人。一篇 2014 年發表的研究記錄了這個差價：2013 年 10 月 adf.ly 對美國流量向廣告主收取每千次廣告曝光 5 美元，付給建立連結的人每千位美國訪客 3.94 美元（<a href="https://sites.cs.ucsb.edu/~chris/research/doc/www14_shortads.pdf">Nikiforakis 等, WWW 2014</a>）。現行的同類服務仍公開這種依國家分級的每千次瀏覽付款表（<a href="https://ouo.io/rates">ouo.io 付款頁</a>）。</p>
<p>金錢誘因讓這一型的濫用風險高於其他出資方式。同一篇研究發現，受檢的主要廣告型服務都沒有把插頁上的廣告內容適當隔離，惡意廣告可以控制頁面、把點擊者轉往其他網站；2013 年 1 至 7 月間，自動分析惡意網頁的服務 Wepawet 記錄到 892 條廣告型短網址的插頁因為上面的廣告而被判定為惡意（與最終目的地無關），其中 80.7% 來自 adf.ly。安全廠商 Malwarebytes 在 2017 年也記錄到 adf.ly 經由廣告網路的腳本把使用者轉往惡意廣告網域（<a href="https://www.malwarebytes.com/blog/news/2017/05/roughted-the-anti-ad-blocker-malvertiser">Malwarebytes, 2017</a>）。</p>
<p>短網址被拿來藏匿目的地這件事，讓維基百科這類平台選擇整類封鎖。英文維基百科在垃圾連結白名單的常見請求說明裡，把 adf.ly、bit.ly、TinyURL、youtu.be 等短網址列為幾乎一律拒絕放行，並說明這些網域在全域層級被封鎖，理由是短網址可以被用來繞過維基百科的垃圾連結黑名單（<a href="https://en.wikipedia.org/wiki/MediaWiki_talk:Spam-whitelist/Common_requests">維基百科白名單常見請求</a>）。這個封鎖不分出資方式，正規的分析型業者也一起被擋：濫用者的行為讓整個產品類別的連結都失去了在這類平台上流通的資格。</p>
<h2 id="連結永久性各出資方式下連結的存續條件">連結永久性：各出資方式下連結的存續條件</h2>
<p>連結的持有人不是業者的付費客戶，手上只有短網址，服務停止轉址的那一天，連結就失效，而他們自己沒有任何修復的途徑。所以連結使用業者的網域時，連結能活多久由業者決定（使用客戶自己的品牌網域時，客戶可以把連結搬走，見〈網域：品牌短網址的定價與切換成本〉），而業者能維持多久，取決於有沒有一個出資者在支付轉址的成本。</p>
<p>Google 的 goo.gl 是成本中心型短網址的實例。2018 年 4 月 Google 停止讓新使用者建立 goo.gl 短網址，既有使用者可以繼續使用到 2019 年 3 月，同時承諾所有既有連結會繼續轉址到原本的目的地（<a href="https://developers.googleblog.com/en/transitioning-google-url-shortener-to-firebase-dynamic-links/">Google 公告, 2018</a>）。2024 年 7 月 Google 推翻這個承諾，宣布 goo.gl 連結在 2025 年 8 月 25 日之後停止運作，理由是超過 99% 的連結在公告前一個月內沒有任何活動；2025 年 8 月 1 日公告再度更新，改為只停用 2024 年底沒有活動、且已顯示即將停用提示的連結，其餘連結保留（<a href="https://developers.googleblog.com/en/google-url-shortener-links-will-no-longer-be-available/">Google 公告, 2024 年發布、2025 年更新</a>）。Google 當年建議 goo.gl 使用者遷往的 Firebase Dynamic Links 也在 2025 年 8 月 25 日關閉，所有連結停止運作（<a href="https://firebase.google.com/support/dynamic-links-faq">Firebase FAQ</a>）。2018 年的承諾在 2024 年與 2025 年各被改了一次，最後留下的標準是「這條連結還有沒有人在用」。</p>
<p>找不到收入來源的獨立業者，連結的存續同樣取決於有沒有人支付轉址的成本。tr.im 在 2009 年關站時保證連結至少轉址到當年年底；Bitly 提議代管 tr.im 的對照表，或讓 tr.im 加入封存計畫，tr.im 選擇嘗試出售服務（<a href="https://techcrunch.com/2009/08/10/trim-cuts-off-bitlys-301works-idea-wants-to-sell">TechCrunch, 2009</a>）。同年 Internet Archive 推出封存計畫 301Works：成員定期把短碼對照表交給 Internet Archive 備份，成員關站時，短網址網域的技術控制（不是所有權）移交給 301Works 繼續轉址（<a href="https://archive.org/post/273961/url-shorteners-working-with-internet-archive-for-long-term-preservation">Internet Archive 公告, 2009</a>）。這個安排是讓永久性承諾不依賴業者存續的一種做法：把對照表與網域交到業者以外的人手上。工程面的退場安排（網域的去向、靜態轉址、交給封存機構）見 <a href="/blog/backend/10-system-evolution/namespace-and-domain-disposition/" data-link-title="10.6 命名空間與網域的處置：續約、名稱保留與回收、懸空 DNS" data-link-desc="服務結束時網域與名稱的去向，以及它們決定外部引用是失效還是易手：網域的續約與出售、交給中立方的技術控制、套件與雲端資源名稱釋出後被重新申請與佔位、雲端資源刪除後的懸空 DNS 與子網域接管，以及綁在可過期網域上的帳號身分">10.6 命名空間與網域的處置：續約、名稱保留與回收、懸空 DNS</a> 與 <a href="/blog/backend/10-system-evolution/handover-and-archival/" data-link-title="10.8 移交：資料匯出、開源與交給社群或封存機構" data-link-desc="服務結束時把讓外部引用繼續運作所需的資料、程式碼與網域交出去：交給直接客戶的資料匯出、開源程式碼能不能獨立運作、社群接手需要提供者事先留下什麼、封存機構的兩種取得方式（業者合作交出與外部爬取），以及交不出去的部分">10.8 移交：資料匯出、開源與交給社群或封存機構</a>。</p>
<p>訂閱型業者把永久性寫進方案條款，而且不同方案承諾的內容不同。TinyURL 的方案比較表上，一般方案的連結預設永不過期，大量建立連結的方案預設 90 天到期（<a href="https://tinyurl.com/app/pricing">TinyURL 方案頁</a>）。永久性在這裡是一項可以定價的規格。</p>
<h2 id="訂閱型業者的收入重心與連結承諾的預警訊號">訂閱型業者的收入重心與連結承諾的預警訊號</h2>
<p>本篇對短網址出資方式的判讀依賴兩個假設，各自有可監控的訊號：</p>
<ul>
<li><strong>分析資料是訂閱型業者的主要付費理由</strong>：業者若把分析資料的保留期或細分維度開放給免費方案，或者付費分級的主軸換成別的功能（例如合規認證；查閱當日 QR code 數量已經和連結數並列為分級額度），代表點擊資料的付費價值在下降，收入重心正在移動。</li>
<li><strong>連結永久性的強度跟著出資者走</strong>：成本中心型短網址的母公司公告產品整併或停止新建連結時，是既有連結進入風險期的訊號；訂閱型業者被收購、或方案條款新增預設到期時間時，對已發出連結的承諾也要重新確認。</li>
</ul>
<p>依賴第三方短網址的組織，最低成本的保險是使用自己的品牌網域，並定期匯出短碼對照表：網域在自己手上、對照表也在自己手上時，業者關站、漲價或改條款都只影響轉址由誰執行，連結本身可以搬到另一家業者或自架的服務上。另一件要在簽約前從方案條款查到答案的事，是降級或停止付費之後，業者網域上的既有連結還會不會繼續轉址。</p>
<h2 id="可遷移框架核心功能商品化之後的出資方式與產品承諾">可遷移框架：核心功能商品化之後的出資方式與產品承諾</h2>
<p>短網址的案例可以推廣到其他核心功能已經商品化的產品類別。客戶願意只為核心功能付錢時，周圍的出資方式就不是分析的主線；邊際成本、差異化空間、開源替代品三者都指向「客戶不會只為核心功能付錢」時，要找維持核心功能的錢由誰、為了買到什麼而出，而那個出資方式決定產品要對誰做什麼承諾。</p>
<table>
  <thead>
      <tr>
          <th>出資者與付費理由</th>
          <th>出錢的人買到的內容</th>
          <th>對持有連結的人的承諾</th>
          <th>交給工程的規格</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>建立連結的人，為點擊分析付費</td>
          <td>分析與保留期</td>
          <td>由付費客戶的存續出資</td>
          <td>重複點擊不被瀏覽器快取吞掉、點擊事件不能遺失</td>
      </tr>
      <tr>
          <td>建立連結的人，為品牌網域付費</td>
          <td>信任與名聲隔離</td>
          <td>網域在客戶手上，可以搬到別家</td>
          <td>同一短碼在不同網域是不同連結、客戶網域的 TLS 憑證自動簽發、對照表可匯出</td>
      </tr>
      <tr>
          <td>建立連結的人，為託管服務付費</td>
          <td>免自行維運</td>
          <td>由託管業者的存續出資</td>
          <td>對照表可匯出、可自架的部署形態</td>
      </tr>
      <tr>
          <td>自架者自己</td>
          <td>資料與網域留在自己手上</td>
          <td>由自架者自己續約網域與維持主機決定</td>
          <td>對照表可匯出、可自架的部署形態</td>
      </tr>
      <tr>
          <td>母公司（平台內建）</td>
          <td>訊號、安全掃描與歸因</td>
          <td>由母公司的需求決定，需求消失時可能收回</td>
          <td>建立時與轉址當下的惡意網址檢查、點擊記錄</td>
      </tr>
      <tr>
          <td>廣告主（廣告插頁）</td>
          <td>廣告曝光，分潤給建立者</td>
          <td>無明確承諾，且金錢誘因吸引濫用</td>
          <td>插頁隔離與濫用處置，否則整類被封鎖</td>
      </tr>
  </tbody>
</table>
<p>表中各列交給工程的規格，在 <a href="/blog/backend/00-service-selection/url-shortener-requirements/" data-link-title="0.23 短網址服務的需求定義：自建或購買、保存期限、目的地修改與濫用處理的規格" data-link-desc="短網址服務交給工程之前要定案的需求決定：自建或購買、點擊資料的地位、連結的保存承諾、目的地能否修改、建立者的範圍、短碼的可猜測性、網域策略與可用性分級；多數答案由商業模型推出，目的地修改、短碼可猜測性與可用性分級由使用情境決定">0.23 短網址服務的需求定義</a> 轉成需求決定：</p>
<ul>
<li>為點擊分析付費那一列 → 〈點擊資料的地位：付費功能或內部參考，以及對應的規格〉</li>
<li>為品牌網域付費那一列 → 〈自訂網域與網域名聲的隔離〉</li>
<li>母公司那一列 → 〈自建或購買：自建成立的理由與自建之後的長期成本〉</li>
<li>廣告主那一列的濫用處置 → 〈建立者的範圍與濫用處理〉</li>
<li>「對持有連結的人的承諾」這一欄 → 〈連結的保存期限與保存承諾〉</li>
</ul>
<p>需求定義與實作兩篇以自建短網址服務的營運者為視角，涵蓋自用的組織與把短網址當產品賣的業者；為託管服務付費那一列的「可自架的部署形態」是開源專案發布給別人自架時的規格，廣告主那一列的「插頁隔離」只在經營廣告插頁時需要，兩篇都只涵蓋其中的對照表匯出與濫用處置；自架者自己那一列對應需求定義篇的〈自建或購買：自建成立的理由與自建之後的長期成本〉。</p>
]]></content:encoded></item></channel></rss>