2016/9/22

軟體的盈利模式

當辛辛苦苦開發好一個應用程式、一套系統,如果想要期望這個軟體能夠養家活口、甚至是榮華富貴,就必須要思考一個問題:如何向使用者收錢?

軟體可以收錢的模式,大致可分為幾種類型:
  • 依功能計價
  • 依資料容量計價
  • 依使用人數計價
  • 依使用時間計價
  • 依內容與服務計價


依功能計價

這是最傳統的收費模式,許多的大型軟體公司早期都是用這樣的方式來獲利、起家的,像是 Microsoft、Oracle、Adobe。過往都是採用賣斷的方式,只能向使用者收取一次性的費用。在現今的行動平台也還是有多的開發者採用這種模式,使用者透過系統廠商提供的平台來付費下載程式。或是程式容許免費下載但內含購買選項,鎖上一部份的功能,在你需要時向你收錢。

這種模式其實對於開發者來說是比較沒有經濟效益的,就像是 Apple 的 iPhone 一旦目標客戶都賣過一輪後,勢必就得面臨營收數字下滑的情況一樣。但是和硬體產品不同的是,硬體壞了可視情況收取維修費,軟體還得不斷地更新程式來修正錯誤但幾乎收不到錢。在收入銳減的情況下還要持續不斷地投入成本,很容易就陷入資金上的危機。所以有的軟體公司為了持續地獲利,只好使用各種名目來改版,讓使用者再掏一次錢出來。儘管新增加的功能不見得是使用者需要的,使用者在憂心不相容及終止支援的心態之下,還是會迫於無奈地買單。

隨著網路環境的成熟,後續出現新的盈利方式就是租賃。一些大型的軟體公司也都開始改採這種模式,以月、年為週期計價來向使用者收費。有的軟體更進一步地提供免費的安裝並限定時間試用,試用滿意後再開始付錢,甚至直接在雲端上提供功能省去了軟體安裝的步驟。只不過這對使用頻率不高的使用者來說並不划算,一個月使用一次和天天都使用付的錢是一樣的,相對地就可能會有客群流失的疑慮,尤其是當所開發的軟體有競爭對手、俱高度替代性的時候。

對依功能計價的這一種收費模式來說,雲端所帶來的好處是不用再想方設法地限制使用者運行程式的環境,像是設計硬體鎖之類的。這類的方法多少有帶來一點嚇阻非法使用的效果,但是道高一尺、魔高一丈,還是有被破解的版本會在市面上流傳。當然這種版本是沒有執行限制的,非法的不用特殊的工具開心地使用,合法的要設定個半天搞不好還因為相容性問題不能執行,結果反而產生了是在懲罰合法的付費使用者的現象。上了雲端之後,則是一個都跑不掉,更不用擔心有破解版導致獲利上的損失,只不過有山寨版出現來搶生意又是另外一件事了!

在行動平台上依功能計價有一點是需要注意的,一般來說這個模式原則上都是付費後只能安裝在一個裝置上,或是約定最多只能同時裝在多少個裝置上,像是 Apple 和微軟都有提供類似的限制。但是 Google Play 目前只認帳號,所以只要在 Android 上切換到有購買的帳號就可以下載已付費的 App,而且理論上是無限多台。


依資料容量計價

就是程式本身會限制使用者可以產生或是程式能夠處理的資料量,當資料量達到上限就必須要再付費來取得新的資料空間。這個模式本身並不是什麼新鮮的手法,只是上了雲端之後更有強制性,因為資料都在服務端,使用者要增加也只能乖乖地付錢。最典型的例子大概就屬雲端空間了,因為這種程式最核心的工作就是用來管理資料空間,像是:OneDrive、iCloud、Google Drive、DropBox。

只是單純地以資料容量來做為盈收的依據,其實還是會有一些在收益上的盲點。如果使用者的資料特性是流動的,就可以在既有的空間中不斷地替換資料來使用程式。舉個例子來說,假設有一個線上的專案管理系統,一開始限制只能新增五個專案,超過要收費。但當一個使用者同時會進行的專案最多只有四個,專案結束了資料只要封存就好,所以對這種使用者來說,五個專案是夠用的,只要專案結束後把資料清掉再開始新的循環就行了。對付錢的來說是一個好消息,但對收錢的來說可能就不是了,除非程式還有另外的收錢選項。

所以這類型的線上服務商,早期叫 ASP (Application Service Provider) 之後有另一種說法叫 SaaS,除了會限制資料的數量,有時還會和功能一併組合成購買的選項。就像前面提到過的,這是程式雲端化後所產生的另一個獲利優勢,由於程式和資料都掌握在提供服務的一端,所以在收費策略上具有更多的籌碼。


依使用人數計價

跟依資料容量計價的模式很像,只是把資料換成了可以使用程式的人數。

這是微軟慣用的收費策略,在還沒深入了解微軟產品的授權結構之前,會以為要建置一個以微軟產品為基礎的 Client-Server 環境只要付錢替二端的硬體各買一套作業系統就行了,了解之後才發現事情並沒有這麼簡單。在伺服器那端除了要作業系統的使用授權之外,還有所謂的「用戶端存取使用權 CAL」(Client Access Licenses)。是的,連線存取也是要授權的,否則在法律上是無權與 Server 連線。由於微軟的產品種類繁多,CAL 的組合也相對地複雜,如果真的要認真的收錢,微軟真的搞得清楚他的客戶有沒有付足額的費用?

當然,也不是只有微軟才這麼做,不過像微軟這種計價模式大概也只有這種等級的軟體公司才承擔得起對應的維運成本。一般的方式有可能用帳號的名稱來認定,也有可能用連線的設備來認定。像是允許使用者可以設定多少個登入的帳號,或是連線的設備要先經過系統的登記,超過就要再收費。更簡單一點的就不管開多少帳號、使用多少連線的設備,只限定同時在線的連線數量,也就 Concurrent 數,多了服務端就拒絕連線。

在盈收上需要考量的問題和依資料容量計價是類似的,因為設備或帳號又不見得直接對應到個人,所以有可能只買了一個授權然後全公司用,全公司只要協調好使用的時間不要重疊就行了。在認定上,公司的人員本來就是有流動的可能,若要嚴格地追究起來很容易和使用者之間形成羅生門。結果就是如果要以這種模式來計價,在數字的估算上就需要保守一點。


依使用時間計價

就如同我們打電話照通話時間計費一樣,是依據使用者使用程式的時間長短來決定費用多寡。和先前提到的租賃不同之處,就像電信收費模式,之前的是月租制,現在這個算是儲值卡。直接向使用者依照使用時間計價的模式並不是業界主流的作法,但目前有一種很熱門的方式是依使用時間向第三方收錢,那就是行動平台上 App 內含的廣告。廣告收益和時用使用量有什麼關係?在 App 內放置的廣告通常靠的是曝光率或點擊率來累積收益的數字,所以當使用者用得愈久,可以顯示廣告的次數就愈多,相對地曝光率或點擊率就會提高,也等於是變相地依使用時間來計價。

這種模式透過向第三方收錢可以減少爭議,使用程式的人覺得沒付出什麼代價就可以使用程式,付錢的人覺得曝光的目的達到了,開發程式的人有收到在金錢上的回饋,皆大歡喜。但如果是要直接向使用者依時間計價,卻又是另外一回事了!首先是要如何記錄使用者使用的時間,並且向使用者提出收費的明細?不管是要事先收錢還是事後付費,都會需要有一定程度的後台系統來維持運作。

此外,使用時間的認定也很容易有爭議,假設今天程式使用到一半,小孩哭鬧要餵奶、換尿布,程式沒關的情況下算不算是使用的時間?程式處理資料的效率不夠好要照時間收錢是不是合理?使用者心裡的 OS 會不會是:程式處理的比較慢也要收錢,誰知道是不是故意寫得比較慢?我就是沒錢買比較好的硬體,結果反而因為程式處理比較久要多付錢?

也許在評估過投入後台加上處理使用者爭議的成本,還不如直接賣斷比較省事。同時,開發的應用程式使用的頻率很低,也許設定一次之後就不會再使用,這樣的程式使用這個計價模式就不是一個很好的選項,應該要考慮其他不同的收費模式。


依內容與服務計價

這是目前應用最廣泛的盈利模式,因為受到早期網路免費風氣的影響,再加上開發工具愈來愈先進使得製作軟體的技術門檻大幅降低,以致競爭激烈,所以單純地想靠程式本身來獲利並不是一件容易的事。用這種模式計價時,程式所能帶來的盈收助益都常都不是重點,又或是開發技術的門檻不高,只能以內容或服務取勝。

在這個模式中,能夠用來計價的標的可以有很多種面向。以內容為例,在行動平台上經濟規模最大的應該就屬遊戲類型程式,遊戲本身也許要付錢也許不要,但後續的盈收重點是在遊戲的關卡上,而關卡就是遊戲的內容。雖然開發關卡也是需要成本,但這樣的模式最少把軟體的價錢分散在不同的內容上,降低購買的基準,也減少使用者的抗拒心理。

不過要談內容比較接近的應該是媒體或出版業所開發的系統,畢竟產生內容才是他們的本業、他們的強項。內容反而是他們的重點,程式是附屬的。不光是內容,很多的行業由於受到網路所帶來的衝擊,必須透過把實體的服務帶入網路來進行轉型,程式上提供的功能則是把業務延伸到網路世界的墊腳石。

這同時也會讓這類型的程式陷入一個盲點是:業者往往只注重內容或服務的銷售而忽略了對使用者在使用程式的友善度,或是所呈現的內容過於單一、侷限。於是有另外一種新的服務的模式是用程式來建立平台,開發系統的人透過平台上的銷售行為來抽取傭金,內容或服務的提供者只需專注在自己擅長的領域,達成一種專業分工合作的形式。

所謂的平台目前最熱門的就屬 Google 和 Apple 所提供的各式商店,程式、新聞、雜誌、圖書、音樂、影片,幾乎是想把所有數位的商品都囊括在內。而賣實體商品常見的就是網購、拍賣平台,賣服務的則有訂機票、訂飯店、找住宿、叫車等形形色色的軟體。就連通訊軟體都不是靠程式或通訊服務來獲利,而是透過平台販賣貼圖,甚至是販賣週邊的商品。

看似商機無限,只不過不論是要單純地賣內容、服務,還是要做平台抽成,都需要有足夠的後台來支撐,這包含了人力、資金。可以想見期初就要投入大量的成本來等待獲利,並不是獨立的開發者想選就能選的。所以,這個計價的模式最大的限制在於還得要看開發者有沒有本錢做這樣的生意。







0 意見:

張貼留言