Photo by Eric Nopanen on Unsplash

這篇討論主要會圍繞在採用訂閱制付費的軟體服務,並且列出他們分別採用了什麼樣的定價策略以及場景策略,以及我的一些小觀察&個人心得。

訂閱制正在興起

不論是網路服務或是實體產品,訂閱制越來越能夠被市場所接受,2020 全球訂閱制服務營收成長至 40 億鎂,並且後勢看漲,在 2025 預估來到 78 億鎂,此外,2019 年美國平均每人每年花費 640 鎂在訂閱制產品(以上數據不包涵已經在訂閱經濟概念興起前採用的產品,比如說汽機車強制險)。

從推出免費產品開始

參考前市場上比較成功的訂閱制模型,目前推出訂閱制的服務會同時發行免費版本和付費版本,部分比例的使用者使用過免費版本之後會升級成付費版,一般來說,使用者會選擇升級的原因主要有三個:

  • 免費版裡含有使用數量(次數)限制,想要使用更多請付費
  • 付費版提供客服以及支援服務

不同產品不同的場景策略

不論是限制使用方式,還是數量限制或是提供支援服務,都必須讓使用者頻繁地感受到這些不便利,使用者才會花錢消災(?),在這樣的前提之下,我們需要盡量了解使用者使用產品的場景,並且根據每個場景使用者與產品可能的互動方式規劃對應的策略,下面分析三項產品策略:

Dropbox

2009 年成立的 Dropbox,目前擁有 6 億使用者並且有 2.47 % 的付費使用者。Dropbox 的收費方式是根據使用者的網路空間使用量,2GB 之前免費,下一個級距是 2TB,每個月 9.99 鎂。2019 年這樣的商業模式爲其帶來 18.2 億鎂的營業額,共有 1400 萬的付費使用者。另一方面,Dropbox 提供大量與其他網路服務串接的可能性,大幅度提升其可能被應用的場景。


Photo by You X Ventures on Unsplash

從去年十月開始企劃【實習判官】,到今年四月推出第一個劇本,我一直再想怎麼讓玩家花更多時間在這個產品上,從遊戲的角度來看,這是最有代表性的 KPI。然而,成功的產品都很相似,失敗的產品則各有其失敗的原因,今天從行為經濟學的角度切入,分享幾個我設計遊戲使用到的觀念,希望大家看完都能找到優化產品的方向。

避免過量資訊以及過量選擇

在行為經濟學裡,選項不多的選擇題通常會帶來更好的效果。人類有意識能夠處理的資訊量有限,選項太多的選擇會讓我們陷入選擇困難,也就是大家中午最常聽到的一句話:「午餐不知道吃什麼!我有選擇障礙!」

舉一個很有名的美國超市例子:在 A 超市有 24 種不同品牌的果醬供消費者選擇,另一方面,在 B 超市只有 6 種品牌的果醬,在其他條件狀況不變的情況下,經過統計,在 B 超市消費的果醬數目超過在 A 超市消費的果醬數。另一個情境是當你在停車場找車位的時候,如果你今天面對的是一個有很多位置的停車場,你會花比較多時間決定停放位置,但是如果今天停車場總共只有兩個空車位,你很快就能夠決定要把車停在哪裏。

從遊戲的角度來看,當我們開始要對使用者收費時不應該提供太多選擇

透過選擇分類避免過量選擇

我們現在知道過量選擇會造成使用者選擇障礙,甚至造成營收下降,因此我們必須透過設計來避免過量選擇發生,常見的方式是選擇分類。選擇分類的概念是普林斯頓大學的心理學教授 George Armitage Miller 於 1956 年提出,人類的短期記憶只能記得 7 (加減 2)個選項,也就是說,我們應該盡量把每次選擇的選項控制在 5 至 9 個之間。與其一次給你的使用者超過 7 個選項,建議把超過 7 個選項做妥善分類,變成是先選分類之後再選選項,透過這樣的方式來避免過量選擇。

以常見的 RPG 遊戲舉例,今天讓玩家挑選武器時,盡量不要一次列出 5 把刀然後 5 把劍然後 5 個盾牌等等,而是先讓使用者選擇種類,讓使用者從刀、劍和盾這三種分類先選一種,然後再依據選擇的分類列出該種類裡面的多個選項。製作分類時有一點要特別注意:分類方式必須符合情境,以上述的例子來看,如果我們今天是以顏色來做分類,那麼使用者很可能因為沒辦法想像每個分類裡面的內容而放棄繼續選取。

選擇分類建議我們從 7 這個數量做為進行測試和初始選項數量的基礎,當然實際的狀況還是必須在測試後,依照每個產品的特性和銷售方式調整數量。

小心錨定效應

什麼是錨定效應?消費者會把第一次接觸的定價或是方案當作標準,用來跟之後推出的定價或是方案做比較。也就是說,一旦某個產品在我們心中被決定了價格,這個價格會一直跟著我們,接下來消費者未來會一直拿這個價格跟其他標的比較。

錨定效應在商業上的應用場景相當廣泛,拿餐廳舉例,菜單上面高價格的選項(e.g. 龍蝦)會讓其他低價格的選項看起來相對便宜,即使低價格的選項已經超越平常你在餐廳會點的價格。同理,在遊戲中如果你提供價值 1, 000 元的禮包,會讓架上的 50 元禮包看起來非常便宜

另一跟錨定效應有關的事情是:讓使用者在原本免費的產品付費非常困難。使用者心裡會覺得:「我之前沒有在這個產品上花一毛錢,這個產品對我來說就是免費產品,你現在跟我說要收費會破壞我對產品的認知,非常嚴重!」尤其是在新產品推出的時候(特別是市場上沒有類似的產品)必須特別謹慎處理訂價。

透過誘餌效果設計定價策略

在講解誘餌效果之前,你必須先瞭解:大部分時候我們在計算產品價值的方式,不是依照這個產品能帶給我們多少功能或是效用,而是透過比較大部分的價值依據都是透過比較而得到,如果我們創造了比較的對象,使用者很多時候會直接拿來比較,如果我們沒有創造比較的對象,使用者則會依照自己的喜好(或是類似的產品)找到比較的標的,每個人都會拿標的來比較一番,並且選擇價值最高的。

舉例來說,今天我們去大潤發買電視,電視 A 售價 $200 元,電視 B 售價 $500 元,你會自然而然開始比較後者是不是值得這 300 元的價差。就在這個時候你發現,旁邊另外一台電視 C 售價 $1, 000 元,但是在你眼中和電視 B 差不多,這個時候你會毫不猶豫地購買電視 B,因為你會覺得相較於其他購買電視 C 的人,你賺了 500 元!設計定價策略時別忘了加入誘餌效果,效果絕對讓你意想不到。

沒有人喜歡不確定性

不確定性就像沒有答案的問題,是讓使用者感到害怕的銷售殺手。再讓使用者花錢購買你的產品之前,你必須盡可能列出使用者心中的疑問,並給出解答,然後把解答放在使用者找得到的地方。

使用者在體驗產品的過程中可能因為遺失某些資訊或是得到不完整的資訊而對產品有疑慮,他們會因為這些疑慮沒被解答而覺得耿耿於懷,嚴重一點甚至會感到恐懼。他們不知道自己把電子信箱或是信用卡號碼寫給你會發生什麼事(其實除了資料庫多了一筆資料之外什麼也沒發生),很多使用者甚至會往不好的方向思考(他們會不會把我的個人資料賣掉?),讓你得不到理想的回饋。

Netflix 透過減少不確定性爭取到數以萬計使用者的信任,其著陸頁上最顯眼的資訊並不是其提供什麼樣的服務,而是告訴使用者隨時可以取消訂閱。除此之外,Netflix 會在每個人首月訂閱結束之前(目前方案為第一個月免費),寄信提醒使用者接下來會開始收費,並在信中詢問使用者是否繼續訂閱,主動把事情講清楚總是能夠有效解決使用者對於不確定性的恐懼。在叫車服務 Uber 的時候,使用者叫車後能夠隨時掌握車子的位置以及預計到達的時間,對某些人來說,這甚至比車子能夠多快速到達或是要花多少錢更重要。

透過下面的方法能夠大幅減少不確定性:

  • 找到會讓你的使用者感到不確定的點並解決這些點,在問任何問題或是跟他們索取任何資料之前,跟你的使用者解釋為什麼你需要這些資料
  • 告訴你的使用者其他人都做了些什麼

總結

這篇我整理了我自己常用的五個觀點,簡單來說:

  • 適當的選擇分類方式
  • 第一次定價很重要
  • 主動推出不同方案讓使用者有標的比較
  • 永遠揭露更多資訊給使用者


Photo by Campaign Creators on Unsplash

隨著公司規模和業務拓展,越來越難像從前擔任工程師的時候把時間花在執行上,現在更多時間是需要跟客戶開會、跟設計師或是工程師開會以及跟夥伴開會。有效率的開會只有一種,讓開會沒有效率的因子很多,最近閱讀到一篇討論開會效率的文章,簡單翻譯成部落格文章跟大家分享,有興趣看原文的朋友直接點這裏閱讀原文。

什麼是帕金森瑣事法則?

帕金森瑣事法則(又稱腳踏車雨棚法則)指的是:在會議中拿來被討論的大大小小事情裡面,往往會出現一種現象:事情的重要性往往與花費在討論該件事情的時間程反比,也就是說,我們常常花很少的時間討論重要的事情,而瑣事或是相對比較不重要的事我們卻花很多時間在上面。想像明天下午就是週一的例會,會議議程如下:

  1. 預算 350 元美金的腳踏車雨棚提案
  2. 預算 21 元美金的年度咖啡提案

討論的重點很快轉移到腳踏車雨棚,大家踴躍的表達自己的意見,每一個人都知道雨棚的目的以及具體的外觀。部分與會者開始爭辯什麼的材質是最好,另一部分的人開始討論適合的尺寸是什麼,大家花了 30 分鐘討論雨棚。

最後大家開始討論咖啡,這個時候每個人看起來都像專家,討論爭辯著咖啡的風味、產地、烘焙方式和價格,最後花了 45 分鐘討論下個年度要買哪個牌子的咖啡。令人驚訝的事實是:花在討論咖啡上的時間超過花在討論雨棚加上討論大陽能電廠的時間。在會議結束前,大家決定另外再約會議討論太陽能電廠的提案,由於大家都在會議中貢獻的自己的想法,每個人滿足的回到自己的位置上。

為什麼會發生這個情況?

當一個主題越簡單,越多人會想要發表自己的想法。當主題不是我們熟悉的人事物,比如說像是太陽能電廠,我們很多時候一句話都不會說。相反的,當一個主題廣為人知,即時我們知道自己沒有很棒的想法,我們還是會強迫自己說些什麼,除非我們想讓自己看起來像個笨蛋。哪個笨蛋不會想對腳踏車雨棚說些什麼?每個人都想把自己的想法告訴大家!

對於任何主題,我們不應該給予每個人的意見相同的權重。我們應該更重視那些在主題上專業的人分享的意見。而當自己決定要發言之前,我們應該把精力放在我們自己專業的部分,確保自己的意見有更多建設性並對於會議決策有正面影響。

避免單車雨棚效應

一個常見的做法是確立會議主題。目的就好比一個透鏡,透過它,在會議的每個當下你都可以確定我們是不是在軌道上,或是已經偏離主題。除此之外,你也可以透過它篩選出必須參與這場會議的人選。

套用到上面的例子,你會發現這場會議的主題安排並不妥當,我們不應該在同一場會議裡面同時討論太陽能電廠和腳踏車雨棚,這是一場主題過於廣泛的討論。

總結

每天只有 24 個小時,當開會的頻率變高,如何有效率的開會就變的更重要,特別是有時候你自己就是會議的主辦人。希望大家看完這篇文章未來能更有效率的開會,也歡迎再下方留言討論,感謝閱讀。

p.s. 覺得看不夠想要了解更多?原文後半部還有更多關於讓會議更有效率的討論,想要看更多請按這裡繼續閱讀


古典與搖滾原來可以這樣結合

演員合照(取自官方粉絲團 https://www.facebook.com/MOROfficiel

上禮拜剛看完【搖滾莫札特】音樂劇位於臺北和平籃球館的演出,趁自己記憶猶新把對這齣戲的想法記錄下來。

音樂劇簡介

以音樂神童莫札特一生為基礎,把其中幾個經典經歷改編後,重新詮釋成大眾喜愛的劇本。音樂的部分則依照改編過的劇本,用流行音樂的技巧編曲,並在其中穿插莫札特的經典作品。舞台以及服飾的風格則加入十八世紀後期歐洲宮廷的元素,與舞臺之外現代氛圍產生強烈對比。

帶入感強烈的劇情

這齣戲劇情相當飽滿,並且起伏的很有節奏感。每個演員的台詞雖然不多,但都精準地帶出每個角色在當下情境的想法,搭配適合的旋律唱出來,整個氛圍的帶入感非常強。

我最有感覺的兩段之一,是當莫札特亦敵亦友的夥伴薩里耶里到莫札特家探望病重的莫札特時,惺惺相惜的兩人一起合唱的【Vivre à en crever】,彷彿自己就是舞台上站在莫札特對面的薩里耶里。

Vivre à en crever 官方 MV
Tatoue-moi 官方 MV


邊吃優格邊寫部落格療癒你的身心靈

大腦風暴遺址 the ruins of brainstorming

受夠每天一成不變的生活,想要認識新朋友?

生活步調太快失去節奏感,想要找回自己的節奏?

想加薪只能靠加班,想知道如何透過寫部落格精進自己的專業?

超市的優格吃膩了,想吃特別的優格?

這些問題的答案你都可以在【格格 BLUE】每兩週一次的聚會裡面找到。兩個半小時的時間裡,我們將從討論一篇文章,分享想要紀錄的主題並設定文章的對象,然後嘗試架構出文章的段落,最後從段落延伸出草稿。當然還有最重要的部分,一起動手製作並享用特調優格!


去年年中 Dan Abramov 在 React 部落格發表的文章提到,隨著 React codebase 的持續演化,mixins 已經漸漸不符合團隊的期待,正式宣告 ES6 的語法不再支援。以下節錄部分相關段落:

To ease the initial adoption and learning, we included certain escape hatches into React. The mixin system was one of those escape hatches, and its goal was to give you a way to reuse code between components when you aren’t sure how to solve …


這是一篇實作記錄,記錄前陣子透過 Google 的 PageSpeed Tools 發現清除前幾行內容中的禁止轉譯 JavaScript 和 CSS這項被扣分,遵循 Google 官方的建議,用 loadCSS 搭配 critical-path-css-rails 順利把分數找回來。接下來我會詳細描述問題和實作的過程。

Big CSS file block page render

一般來說用 Rails 開發網站,用 Sprocket 配上 Tilt 來做 asset pipeline 算是蠻常見的方式。在 http2 尚未普及的年代,透過 Sprocket 整併 assets 能夠大幅減少需要的 CSS/JS request 數量。不過隨著網站越來越大,CSS 的大小也隨之增加。等待下載 CSS 的時間變長,或是 一次解析過多 CSS 而造成不必要 …


自從愛料理 2013 年導入 ReactJS 以來,有一大部分新的前端功能都是透過 ReactJS 開發。而為了提高可維護性與降低程式複雜度,從去年開始,陸陸續續的把從前用 AngularJS 開發的程式用 ReactJS 改寫,也即將在最近全數改寫完成。不論是新開發的 ReactJS 專案,或是舊的 AngularJS 專案改寫,站上有越來越多的功能是透過 React component 來實踐,也讓我們開始考慮 server-render 的可能。剛好不久之前看到 Airbnb 開源的一套 Rails-friendly 的 server-render 框架 hypernova,在參考過官方範例之後,覺得或許值得一試。

Projects get involved in

在描寫實作的細節之前,先簡單介紹這次的專案們,這幾個專案都是於 20 …


自己用的 package 自己包

最近子網站時常需要重複使用與主網站相同的互動設計,於是就想要把幾個站共用的 jquery-tinyslide 拉出來成為一個獨立的 npm package,實踐 DRY(Don’t Repeat Yourself)精神。

開始實作之前

先簡單的列出這次主要的任務:

  • Make it compatible with both npm and bower
  • Write README
  • Create a simple demo project
  • Dependency
  • Usage
  • Options
  • Test
  • Demo
  • Contribute
  • Licence

開始動手做

包 npm package 的第一步,當然是先參考網路上大神們的各種作品。大 …


不知不覺做網站開發也過了一年,回想起自己剛進公司的第一項任務就是修補 iOS & Android API 的 Spec。那時候的我接觸有系統的軟體開發還不到半年,不理解如果一個產品要走的長遠,必須認真寫測試。因為不理解軟體開發的特性,以及開發經驗不足,所以只記得那一項任務做的有點心虛,那種感覺就好像在一個深三米的游泳池裡,從左游到右,再從右游到左,怎麼樣也搆不到地。

最近補完之前結帳頁面的測試之後,覺得自己好像比較能夠理解 Unit test 和 Integration test 分別是用的情境,就用這篇文章記錄下來。

下面會分成三個部分來討論

  • Unit test 與 Integration test 的特性
  • Unit test 與 Integration test 在不同維度的下的變化

如何分辨 Unit test 和 Integration test

假設我們現在手上有一隻手電筒,組成手電筒的有三個部分

  • 電池
  • 開關

Unit test 與 Integration test 的特性

看了上面關於如何分辨 Unit test 和 Integration test 的範例,應該能夠比較理解這兩種測試的情境。這個章節會用不同的角度,也就是兩種測試所擁有不同的特性條列式的切入。

首先是 Unit test

  • 測試的範圍比較小
  • 主要功能是給開發者更容易 debug
  • 測試的範圍比較廣
  • 主要功能是對人做整合性的展示

Unit test 與 Integration test 在不同維度下的變化

Unit test 跟 Integration test 在不同的維度下,有時候會互相轉換。舉例來說,如果今天我們的對像是一個手電筒,那麼測試行為就是打開手電筒的開關,而預測結果是手電筒指向的黑暗處被照亮,這樣算是一個 Integration test(在第一個章節有更詳細的討論)。但是如果現在對象從手電筒變成一台汽車,那麼測試行為是打開車燈的開關,而預測結果是車燈方向的黑暗處被照亮,這樣的一個測試只能算是 Unit test。

對使用者來說,車燈在汽車裡面扮演的角色只能算是相對重要,使用者更關心的會是車子能不能順利行駛到目的地。所以我認為在這個狀況下,測試行為是使用者拿到鑰匙,而預測結果是車子能夠順利啟動並且行駛至目的地,這樣的一個測試才能夠被成為 Integration test。

結論

開發 Unit test 和 Integration test 雖然要花上甚至比開發軟體更多的時間,不過對於提升軟體的穩定度很有幫助。如果資源有限只能選一種的話,建議從 Unit test 開始。

frozenfung

OUR LIVES ARE NOT OUR OWN. WE ARE BOUND TO OTHERS, PAST AND PRESENT, AND BY EACH CRIME AND EVERY KINDNESS, WE BIRTH OUR FUTURE. Email: frozenfung@gmail.com

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store