2012年11月30日 星期五

中華電信 iPhone 費率方案吃到飽之釣魚理論

如果你最近有打算辦新手機 iPhone 5, iPhone 4S 或調整費率,建議您參考一下。


今天去調整費率發現中華電信在費率方案上的一些背後的規則,看起來好像是提供多種選擇讓使用者選,但其實不然。

你可能沒有想過... 中華電信其實有更多層級的 mPro 方案,但為什麼在 iPhone 費率方案上 mPro 只推出 mPro450 以及 mPro950 方案兩種方案? 而且還把 mPro150, mPro750 跟其他 mPro 方案隱藏起來?這幾種費率乍看之下價格好像正常,但是流量限制卻差相當多?


你可能也沒有想過,為什麼中華電信要在高費率的方案下增加許多優惠措施?他們若是單純提供多種費率給使用者參考,其實大可不需要加上這麼多名目上的優惠。


這些費率設定,其實是利用經濟學的釣魚理論,吸引大家使用高費率 mPro950 方案 (3G 吃到飽)。  因為硬體放著也放著,以相同的硬體架構,吸引大家用越高的費率,中華電信當然賺越多。





上面這個費率其實是障眼法,若你去查 mPro 的方案列表,你會發現其實 mPro 方案不只兩種。

再經過比較,你會發現 mPro150, mPro450, mPro750, mPro950 的計算方式相差很多,尤其是 mPro150 超過的部分計算特別貴。



mPro 系列方案底下,mPro750 提供 5G/Month 流量,mPro450 只有 500MB/Month,mPro150 更扯,只有 50MB 流量。

經過筆者用 iPhone 3GS/4S 試驗,在不調整通知中心的設定下,需要用 3G 的時候才開,就算只有看看網頁、Facebook,每天就至少需要 40MB 以上的流量,算起來至少要有 1.2G 的流量才夠,所以 500MB/Month 流量是一個相當容易超過的流量範圍。

mPro750 相對來說是比較划算,比 mPro950 月租便宜兩百,畢竟 5G 流量除非你每天都看很多影片,不然也是很難超過這個流量。

然後中華電信因為希望消費者直接選擇 mPro950 以上的方案,所以就把 mPro750 跟 mPro150 藏起來了。


iPhone 費率上只列出 mPro450, mPro950,消費者比較之下當然覺得 mPro450 不划算,進而選擇搭配 mPro950 的方案。原本用量偏多或是根本不知道自己用量多少的消費者,也會害怕因為超過 mPro450 的流量而超支,因此就會選擇使用 mPro950 方案吃到飽。  (註 2012/12/17: 中華電信 iPhone 費率後來改為 mPro450 贈送 1G 的 3G 流量)





以上面 iPhone 費率最前面三個方案來說,第一個方案的出現是為了吸引你上鉤使用第二種或第三種費率...


而這些費率的大原則,就是希望減少消費者想要省錢而只選擇最低月租費的方案,也因此,中華電信普遍會在最低月租費的部份,調高通話或網路費率,進而讓消費者選擇較高的費率方案。


為了吸引更多使用者選擇較高的費率方案,特別是月租 1349 (mPro950+大家講586),在表格下方增加了許多贈送簡訊、空機優惠、預繳月租費折抵或是贈送 MMS 等方案,很多人會因為這些優惠而選擇更高的費率方案。 方案費率越高,乍看之下的優惠越多,好像越划算,但實際上計算,如果你沒有真的打滿這個月租費或使用超過這個流量的話,其實並沒有因為這樣而讓你比較省。

以 iPhone 4S 16GB 超值方案為例,以兩年月租加空機計算:

mPro450+大家講 289 空機: 13900, 兩年月租: 649 * 24 = 15576 ,   共 $ 29476 元
mPro950+大家講 289 空機: 10900, 兩年月租: 1049 * 24 = 25176 , 共 $ 36076 元
mPro950+大家講 589 空機: 5400, 兩年月租: 1349 * 24 = 32376 , 共 $ 37776 元

你會發現高費率方案兩年下來其實第二種與第三種接近很多,只相差 1k 多,中華電信知道消費者也會這樣算,所以就把整體費率拉高,然後將第三種費率調降,讓消費者覺得選擇第三種吃到飽最划算。






消費者在選擇方案當然是成本計算,但是中華電信費率方案以釣魚理論設計,引誘消費者在成本計算下選擇較高費率的方案。

其實,若假設三套方案都以成本規劃,想要吸引消費者選擇最高費率,當然是增加前面兩套方案的價格,拉近與第三套方案的價格,製造高費率方案比較便宜的假象。

生意人是不可能把高費率的方案虧錢賣的,所以高費率方案看起來優惠特別多,其實只是因為整體價格都被往上調整,再將高費率方案提供優惠,讓高費率方案看起來比較划算的手段而已。







接著,還有一個陷阱: 申辦 iPhone 不一定要申請 "大家講589",消費者也可以申請一般的 583 方案 + mPro950大家講589就是向您收取 589 的月租費,給100分鐘加上40分鐘
但這個589的月租費是不能抵掉所有通話費用的 (市話,簡訊,mms),大家講 589 給的100分鐘只能用在打給大哥大上(網內及網外),打市話、簡訊及 MMS 要另外計費...

這些 iPhone 費率方案算是一種障眼法,這些 iPhone 方案看起來就好像只有這些方案可行,但是你其實可以自己選擇不同的費率方案做搭配。



所以若不使用上表提供的 iPhone 方案,使用中華電信全民共省方案的話 (mPro450+383),

加上該方案折扣,第一年每個月只要 291 元,第二年每個月582元,兩年約下來大概只有 $ 10476 ,再加上你另外買空機 iPhone 4S 的 $ 18800 其實全部加起來是 $ 29276。
這個費用可以比你選擇 mPro950+589 省下 8500,你剛好可以發現就跟上面第一種 mPro450+大家講289 兩年下來的 29476 差不多。



一般消費者會以為中華電信對舊用戶換新機搭方案會比較便宜,其實目前有換機優惠的資格標準都還蠻高的 (除非你真的打很多)。所以如果你合約已經到期,直接用 iPhone 方案反而比較虧。


順一提,如果你合約已經到期,不妨考慮看看別家電信業者吧。譬如 7-MOBILE 月流量 1G 只需月租 200 元,中華電信 mPro450 月租 450 流量才 500MB。

除此之外,最近看到的消息:
台灣大哥大表示,向來重視消費者需求,已提供各種級距的資費方案,讓民眾可依個人使用習慣,選擇最划算的上網資費。今年7月起更特別針對中等使用量用戶,推出199元使用1GB的超值上網包專案。

總之,電信業者為了混淆視聽,通常會提供多種複雜的費率選擇,但基本上,選擇費率只要以使用量只會超過一點的那個方案,反而會是比較省的。

以上只是我的一些推測和想法,給想換手機或換費率的客官參考。



相關新聞

取消吃到飽?蔡其昌:中華電行動年收千億元 投資僅69億
網路塞車與費率有關? 管碧玲批為補虧損取消上網吃到飽
看問題/無線網路與經濟相關 寬頻影響力有多大?




Larry Page: 只有速度才能為產品帶來成功

Google Founder Larry Page 認為, 只有速度才能為產品帶來成功。

在 Google 裡,Larry Page 可是會數你的 Latency, 就算是一兩個毫秒 Larry Page 都會數的。 Larry Page 甚至可以用感覺來算毫秒的差異,他曾對員工說「你自己回去看,這簡直慢得相當誇張,這 Latency 至少有 600 毫秒以上」

速度可以帶來用途, 因為如果你的速度本來還算勉強,之後又陸續新增許多功能,你的產品可能就會變成兩倍慢,使得這個產品的可用性大大降低。

由此看來,筆者思考,若採用 Rails 框架開發,雖然初期網站也許可以快速建立(當然前提是你已經花了二至三個月來熟悉 Rails Framework 之下)。

但,Rails 本身注重的是開發速度,而不是太注重本身的效能和記憶體用量,一旦你的應用程式功能要繼續加上,就會使得這個勉強的速度越來越慢,Memory Footprint 越來越大,最後,只好以其他方式重新實作這個網站。 如一開始採用 Rails 的 Twitter 一開始即遇到效能瓶頸,用戶越多就越容易 Crash ,使得用戶頻頻抱怨,後來 Twitter 只好以 Java/Scala 重寫來改善效能。

如果一開始就慢,再怎麼靠 Cache 來調校也是勉強而已,而且 tune 完應該就是單機效能極限了,接下來只能以加機器解決問題 (增加硬體開銷),倘若你的軟體在設計時,效能已經相當優秀,那麼你的效能開發空間就相當大,加上快取、平行架構,肯定是可以為你的網站效能加分。

千萬不要小看 100 毫秒的影響,據 Google 內部統計資料指出,就算只增加了 100~400 毫秒不等的延遲時間,也會使得使用者更不想更新關鍵字搜尋,也會使得使用者瀏覽資料變慢。

而當 Picasa 增加了三倍的照片瀏覽速度,甚至造成當日使用量明顯增加 40% ,速度的確是以毫秒之差影響著你的網站使用量呀!

當然全部都速度論不是很正確,但產品做正確,卻因為速度太慢導致用戶頻頻抱怨,對使用經驗也是大打折扣。

筆者也很認同 Gugod 的說法:
跟語言無關,是心態問題。不把速度放在心上,做出來的東西自然速度不好。沒有意識到 scalability,結果自然只能單機無限上綱。一心只注重外掛擴充性,其他兩項當然就甭提了。
開發你的網站之前,再三考慮一下吧!

2012年11月29日 星期四

Golang: gopprof

gopprof 真不賴, 這篇是來嗆  Hundt's benchmark programs 的? The C++ program runs in 27.47 seconds and uses 700 MB of memory,Hundt 寫的 Go 版演算法需 C++ 兩倍時間及空間,經過 profiling 過後,Go program 只需 3.84 seconds and  257 MB!

http://blog.golang.org/2011/06/profiling-go-programs.html

Blog for english posts

For better search engine optimisation and readers, I created another blog for my english posts. and here, will be all in chinese posts.

To visit my english blog, please click here:

Golang: Create your local environemnt

Generally, you can install Go from the package installer that Go provides.
But as you need to install packages, you need root permission to install packages into the default system GOROOT path (like /usr/local or /opt/local.. etc)
You can provide your own GOPATH to avoid this kind of problem.
First, you should create a directory structure like this:
  ~/mygo
  ~/mygo/pkg
  ~/mygo/src
  ~/mygo/bin
Then, export this path (~/mygo) to your GOPATH in your .bashrc or .zshrc file:
  export GOPATH=$HOME/mygo:$GOPATH
And the bin path of Go:
  export PATH=$HOME/mygo/bin:$PATH
Done. Now you can install packages into your own local go environment. for example:
  go get https://bitbucket.org/mikespook/gearman-go
which won't require you to sudo.
If you need to install packages from local, you need to move your package source to ~/mygo/src directory, then build the package there, or Go will complain about go install: no install location for ...

Golang: Installing Go PostgreSQL Driver

To install Go PostgreSQL driver (with CGO), you need to specify CGO_LDFLAGS and CGO_CFLAGS for your pg_config

CGO_CFLAGS="-I`pg_config --includedir`" CGO_LDFLAGS="-L`pg_config --libdir` -lpq" go get github.com/jbarham/gopgsqldriver

2012年11月20日 星期二

Golang: Go 初探


go-lang 實在是很快, 做了一些 Benchmark 後發現 go-lang 使用內建的 http module (包含 router) 的 requests per second 大概可落在 8k 上下,這個數字比 nodejs 直接用 http connection (without router) 的 5.6k 快上許多.. 而 nodejs 搭配 express.js (with router) 自然就比 go-lang http server 遜色。


Google 本身是以 Java 起家,而後加入了許多大量的 Python /C++ 應用,所以 go-lang 本身的設計,可以看出 Google 的野心


首先 data type 及 interface (非 Java 所謂的 Interface) 來取代類別的角色,解決了 Java 的類別繼承的效率問題,還帶來了 dynamic language 的優點,要做 duck typing 很容易;


多執行序方面,內建的 goroutine 解決了concurrency 問題,要做多執行序的程序相當簡易,程序溝通只要寫個箭頭符號即可解決


語法上則參考相當簡易的 Python,好學、開發效率也高


效能方面可接近 JVM 或 C++,編譯的速度更沒話說


套件方面,規格簡單,發佈、安裝也很容易; 要和 C/C++ library 做 binding ,超簡單的 FFI 介面,也可以很快速的跟 C/C++ library 結合。


大膽猜測 Google 想要擺脫 Java 的束縛,使用 Go 來取代 現有的 Java 及 Python code base ,這樣一來,只需使用 Go 就可以在各系統中通用,增進開發效率。




以下是筆者最近做的一個簡單的效能測試

http://c9s.github.com/BenchmarkTest/

以這個 Benchmark 來說 (其實應該分成兩張圖)

各位可以看到 Perl5 + Feersum (Plack HTTP Server 的一個實作) 效能 (Requests per second) 是最高的,該 Benchmark 的 sample code 是做很簡單的事情,開啟一個 HTTP Connection ,然後回傳 Hello World 字串。

同樣的 Node.js HTTP server 的部份也是開啟一個 HTTP Connection 然後回傳 Hello World。

以同樣的 Behavior 來說,可以互相比較的是 Feersum(Perl5) 以及 Node.js HTTP Server。

而 Perl5 + Feersum 的效能相當於 Node.js http server 的三倍。




若實際應用的話,則該參考使用 Route dispatch 下的效能,以 Route dispatch 來說,Express.js (Node.js), Tatsumaki (Perl) 以及 Go HTTP 是可互相比較的,Tatsumaki 的數據還是比 Express.js (Node.js) 高出一倍。

而 Go 內建的 HTTP Server 包含了 Route dispatch,又高出 Perl + Tatsumaki 的數據一倍。



另外筆者參考了其他 Go 相關的 benchmark results,最近這一版的 Go 的效能表現實在是相當優秀,不僅高於 Python ,也與 Java 不相上下。

Go 未來的發展實在指日可待。