[圖解] 台灣手機品牌市佔率
年初要制定年度計畫，我期待公司產品可以繼續成長，於是會有一些我認為可以讓用戶增加的功能與服務。
老闆這時候說，2020年的數據統計，我們家iOS App的用戶有持續成長，當然也就帶動營收增加；不過Android App的用戶卻變得比較少，營收也因此減少。原因是什麼呢？🤔
廣告
身為成長駭客的我，想必有我自己一套解讀，比如：App下載的門面與手機系統用戶的分佈。
（繼續閱讀…）Posts tagged ‘growth’
[圖解] 2020年台中人口與台灣各縣市人口
身為台中人，無意間看到台中地圖，原來是在呈現2020台中市人口分佈，讓我很好奇，這十多年來，台中人口成長多少？🧐
紅色代表遷出大於遷入，綠色代表嵌入大於遷出，可以清楚看到，我的故鄉大甲，在2020年人口減少！
看來台中市中心，移入還是大於移出！12/19才去北屯的薇格國際會議廳吃喜酒，看到富麗堂皇的廳院讚嘆不已，我想應是發展的還不錯！
2010年台中縣市合併，至今已滿十周年，台中成長大致上已超越甚至海放高雄，從人口變化結構就可以得知～其實還滿期待韓國瑜市長帶領高雄市。
2020年末回顧年度App成長
2020年～新冠肺炎疫情瀰漫全球一整年，終於來到最後倒數計時，總是要來回顧這一年來的收穫，看我們在哪個地方成長多少。
我在公司負責產品已超過一年，經過我一手「調教」之後的App，在品質與用戶是否有成長呢？透過Google後台統計，可輕易檢索各式各樣的指標。首先就以「事件數」和「用戶數」來看成長幅度。
整個時間軸我調整一年來做比較，期間2019/12/15-2020/12/15對比2018/12/16-2019/12/17。可見圖表有藍色實線與虛線，實線代表最近一年，虛線代表前一年，可清楚看到最近一年成長幅度相當大！
[圖解] 軟體工程師離職後
去年還在健康科技公司上班時看到這張圖解軟體工程師離職後，還覺得是個開玩笑的狀況，沒想到終於被我遇到啦⋯⋯
曾經有聽說過，某新創公司的產品是由超強老闆寫出來，上線營運後發現市場接受度相當高，有意擴張規模而雇用幾個工程師來承接他之前寫的產品，這是我朋友吉米的前公司做博弈軟體的故事。
產品創始人把心中的想法迅速時做出來，透過雛形來測試市場接受度有多高，開發軟體過程想必不會寫得很有彈性，因為「彈性」是需要大規模超仔細地想各種可能發生的情況。比如若我當初只想要搞定80%的狀況，大概一個月就能做出來；若我要再觸及剩下的20%，可能要再多花兩個月才能完工。於是乎我會選擇前者！
當驗證市場可行後，接下來就來補剩下的20%。然而儘管只是20%，想要在既有的架構上可就不太容易擴展，而老闆僱用來的工程師肯定不可能全盤了解當初寫的架構與流程，因為裡頭包含各種Features、Bugs、User Cases、Work Flows、Workarounds等。加上老闆所展現的Coding Style和Logic，與雇用來的工程師所使用的並不一致，導致剩下的20%由老闆來寫只要兩個月，而若讓雇用來的工程師來寫的話就高達半年⋯⋯
回想我還在健康科技公司時，是如此呼風喚雨，iOS App由我一個人獨自從無打造出來，後進來的Android工程師都要仿照我的方式來實現，畢竟小而美的創業公司資源不多，要盡可能使用最少資源來達成目標。對比現在港商的工作狀況，產品已經由資深同事開發10個月，架構是由他建立起來的「樂高系統」，MVC架構非常分明，就好比我當初使用MVP架構寫HiLife App，然而相對的所花費的時間變多。
過去一個大功能我能在一天內完工，現在一個小功能我可能一天內還無法安心動手，落差非常大啊⋯⋯有時候真的想要不管既有架構，把可運行的Code塞進去，馬上就可以有正確的效果，只是長久來看，只會不斷增加「技術債」，這我在圖解理想與實際的軟體架構有提過。
想起我偉大的前同事德叔說：
要Refactor他人寫的Code需要很大的氣度。
我在下方回答笑說：
我寧願寫Code給別人Refactor，也不要別人寫Code給我Refactor！
對我來說，加入新創公司就是想快速成長，要像個成長駭客一樣跟著產品進化，來盡可能獲得較多的成就感！最終實現自我～
於是乎，之後若要我選擇的話，我肯定會選擇從「無」開始打造產品，因為我可以根據當時的規格（畫面、功能、流程等）來決定架構，可以很快就把既定的藍圖實現出來。
我心中有好多Idea要實現啊⋯⋯
Google Analytics 行為流程
身為行銷人對於Google Analytics是個非常熟悉的數據分析平台，若同時又是個開發者，就能在App中修改調整功能，來觀察使用者的行為流程，以改善App的使用度（含新使用者、活躍使用者、即時使用者等等）。
我發現Google Analytics 行為流程功能非常有趣，可以知道使用者的陸續進入哪個畫面，甚至知道有多少比例的使用者會離開App。身為成長駭客(Growth Hacker)的我，對此相當感興趣，因為我可以修改App功能，來提升使用者黏著度，知道哪些功能特別受到使用者的青睞，來強化該功能！
來介紹一下我所開發的兩個App，以畫面為基礎來觀察使用者的行為流程！
第一個App是知名車廠（一個月數據）：
第二個App是知名超商（半個月數據）：
未來我開發自己的產品，肯定要不斷優化畫面與功能！
Fabric Crashlytics 崩潰紀錄
身為成長駭客(Growth Hacker)的我，除了觀察Google Analytics 行為流程之外，還可以查看Fabric Crashlytics 崩潰紀錄，根據重要程度優先來對非常重要的崩潰進行除錯(debug)。一般在開發的時候，不太可能完全地偵測出問題，此時就可透過使用者的實際操作狀況來了解潛在的問題。
於是乎，在專案開發之初我就會整合Fabric，此平台除了像Google Analytics可統計使用者數、活躍者數、線上人數等之外，還有可給開發者了解的Crashlytics 崩潰紀錄，基本上很適合開發經營維護產品的成長駭客。
第一個是知名超商APP：
我發現在商品兌換的時候容易崩潰！猜測是產生QR code要給櫃檯人員掃描，使用者在這過程太快點擊「取消兌換」或「離開」，使得API撈回來的資料有誤而沒處理到就發生崩潰。
第二個是知名車廠APP：
我發現在刻意阻擋使用者操作時，很容易崩潰ＸＤ～那是我要破解第三方套件所使用的撇步。
它可以選擇版本、事件、期間來篩選出何時發生的崩潰(crash)。
之前我也介紹過Fabric App，可視覺化觀察Fabric 活躍使用者 (Fabric Activity User)，在乎iOS版本普及狀況的話可透過Fabric Answers 觀察 iOS 升級狀況。
2014年成長紀錄
2015年已經過了6個月，才來貼2014年成長紀錄，好像有點晚ＸＤ⋯⋯原本是期望能將這張心智圖完整地呈現，甚至會想要每個主題都寫成一篇文章。可是呢⋯⋯自從我脫離學生的身份，我的生活居然變得更加複雜多采多姿！似乎是因為我能夠賺取所需，進而能夠去參與每個我感興趣的活動事件，以至於沒多餘的時間來記錄精彩的過程，是幸運也是可惜哪～
我是使用過去介紹的Coggle心智圖平台來寫下關鍵字，期待未來的我能看到這些關鍵字，就能想起當時的林林種種點點滴滴。其它有寫成文章的部分能夠分享的都在我部落格上頭，要是能幫助有緣人我肯定是感到欣慰。
剛看了「借屍還魂」的報導，是關於半個世紀前一個金門少女的故事。看完之後更加深認為，一個生命的結束是另一個生命的開始。總會期望能意會到前世的我想留給現在的我什麼「遺產」，讓我可以不必重新學習做人處事，而有更多的時間來完成這輩子的人生任務。
接下來要開始記錄2015年成長紀錄囉～
參考：Coggle。
逍遙文工作室 
HappyMan・迴響