Side Project 紀錄 — Instagram Lucky Draw
身為一個工程師，大家多少都有做一些 side project 的經驗，因為陸陸續續其實也做了不少 side project，這個 Instagram Lucky Draw 也關閉服務有一陣子了，團隊討論過後未來也不會再重新開啟，覺得可以整理一下做個紀錄，算是他有存活過的一個證明(?)
緣起
會做這個抽獎小工具其實不是我想出來的 idea，一開始是剛好朋友找我說，他跟另一個他的朋友有個想法想要實作試試看，但他們對前端不是很熟，問我有沒有興趣加入可以一起當作個小 side project 玩一玩，聽完覺得還蠻有趣，而且 effort 也不會太大，就加入一起來完成這個專案。
我加入的時候基本上原本成員已經找到 Target User 與定義出使用的情境，這裡就讓我回推來簡單介紹這個服務的背景。
Identifying user pain points
由於許多自營媒體、instagram 商家帳號，或是創作者帳號，吸引並接觸更多使用者最基本的手段，就是辦一場抽獎。先不論吸引到的粉絲有沒有用(絕大多數是無用粉絲)，但實質上倒是真的會增加不少觸及率。
抽獎方式不外乎就是要使用者先追蹤，然後分享 or 留言 tag 好友，最後從這些留言中間抽出得獎者。
但要怎麼抽出這些人？在沒有任何工具的時候，當然就是透過工人智慧，一筆一筆輸入到 excel 或是其他線上亂數抽獎程式，然後抽出得獎者。
後來出現了第一代的 Instagram 抽獎服務，俗稱「IG 抽獎神器」，陽春簡易使用的介面，馬上就成為各大帳號愛用款。不過架服務也是要費用的，過了一陣子 IG 抽獎神器就開始收費，雖然使用者付費很合理，但大部分的使用者就開始到處尋找有沒有替代方案。
再者他的介面很陽春，很像工程師做出來的 POC 版本，許多自營媒體其實都會希望有一個有質感一點點的介面，他們可以錄影分享到自己的限時動態。
我們目標想符合幾個簡單需求：
- 簡單好用，讓大家都能很直覺的使用
- 介面簡樸有質感，適合網美們錄影抽獎結果
- 不跟使用者收費，另外找尋 business model
團隊成員
大家可能會想說做一個 side project 會不會需要很多人力？其實還好，許多網路小服務都只要少少的人力&少少的時間就可以快速完成了。
我們團隊其實也才三個人，兩個工程師+一個行銷兼設計：
- 2 Engineers
- 1 Marketer/ Designer
服務簡介
其實概念很簡單，主要讓大家可以放入自己的貼文網址，並且設定你要的抽獎規則，不管是要抽出的人數或是限定留言都沒有問題，成品就如以下的影片所示：
系統架構
由於我們想要能夠快速的建起來這個服務，就挑了手邊比較熟的工具，最後選擇 Google Cloud 作為我們的雲端架構。
前端
Instagram Lucky Draw 總共有兩個頁面，一個是主要的抽獎頁面，作為讓一般使用者抽獎的入口。另一個是給我們使用的 Admin Console，這裡記錄了抽獎的 log，讓我們可以在使用者有問題的時候，做快速的查詢，並且有圖形化的 Dashboard 讓我們可以看每個月使用者的使用趨勢。
至於在技術面，我們是使用 React 來開發，並且搭配 Firebase Hosting 來作靜態部署。
延伸閱讀：可以看我另一篇紀錄的 React+Firebase Hosting
後端服務
我們採用 Serverless 的架構，使用 python 作為開發語言，只透過 Google functions 來做唯一的服務。
我們的 Serverless functions 有幾個功能：
- /instagramdraw: 收到前端來的 request 後，針對 URL 再去呼叫 instagram API，拿到結果後把根據條件的留言篩掉，最後亂數抽獎，把結果送回前端。
- /saveSearchData: 這隻 API 會專門把我們要的 log 做簡單正規劃之後，寫入 realtime database。這隻 API 會被前一隻主要的 instagramdraw 呼叫。
- /getSearchData: 另外還有一隻 API 是專門給 admin console 用的，會根據條件來讀取資料庫的資料，回來顯示在 console 上。
成效
上線後我們有做一些行銷行為，包含向網美或是商家推薦使用，當然也碰了很多壁，也有網美直接和我們說要我們付費的。另外也有透過下 Google 廣告，或是論壇分享的不同方式，經過一陣時間後，其實成效還算可以接受。
Popdaily 主動分享
GA 成效
大約巔峰期，每天可以有300~400 使用者在使用，也可以看到使用者來源從蠻多不同地方進來，也有被不少有名氣的 IG 自營媒體或是網美們做抽獎分享，當時隨便滑滑 IG 都蠻有機會看到別人在用我們抽獎的工具。
遇到的問題
當時經營到後期，遇到的問題其實有三個：
客服成本很高
由於我們秉持著想要給大家不錯的服務，所以另外開了個帳號來當客服 @igrandomdraw，解決大家的疑難雜症，但這成本實在太高，尤其當大部分人的問題都是很莫名其妙的時候，可能他們都不知道自己在問什麼。
一開始遇到很多人的問題是不知道怎麼使用，一個一個回的成本實在太高，因此我們過了一段時間後，多了一個頁面是非常詳細的圖解使用者手冊，但最後發現其實根本大家還是不看…，再者，後來一天會有5則以上新訊息出現的時候，這時候花的時間已經遠遠超過開發維護的成本。
成本的出現，服務不好兌現
由於使用者增加，加上我們有購買網域，以及一些行銷費用，一開始或許還可以算體驗玩玩，這些小錢自己可以負擔，可是當使用者越來越多，Google Cloud 也面臨超過免費額度需要開始收費的時候，這時候就要思考是不是要認真來找尋金流，把這個 sideproject 認真的做下去。
Instagram API 不給亂 call 了
大家都知道呼叫 Instagram API 有一套自己的玩法，要使用 Instagram Graph API ，透過拿金鑰才能呼叫一些抓取資料的 API，在這之前其實透過一些方式，可以繞過這段直接拿到公開頁面使用者的留言，我們透過這方式可以簡單地達成我們的目的。
然而在某一天開始，Instagram 在這塊有調整了機制，對於 API request 都會需要做 Auth 的認證機制，導致一下子檯面上只要是不需要使用者登入 Instagram 帳號的抽獎工具，全部都死一片。
結果？
經過種種遇到的問題，後來在團隊一起評估之下，覺得要更改成本有點大，再加上沒有很明確的獲利模式，最後還是很可惜的在 2021 年 3 月我們就把服務關掉了，未來也不會再投注心力在這個專案上，現在轉去做別的東西。
結語
整個 sideproject 歷經大約 1 年多，過程雖然沒有什麼實質的收入，又花了很多下班時間在寫程式與充當客服人員，但其實過程是很有趣的。
以前還在學生時期，參加了許多創業活動與競賽，ex: 有名的 YEF，而畢業工作後其實與這些東西就越來越遠，而這次的 side project，某些程度比較接近以前參加創業競賽想專案以及實作的感覺。
在這過程也發現了一些有趣的事情來分享給大家，由於我們有把每一筆抽獎的 log 都記錄下來(去識別化，只知道抽獎人的抽獎網址與下的條件)，有發現其實線上大家在抽獎的錄影，其實都是抽了很多次，直到挑到自己喜歡的中獎者，才會錄起來公布名單。
當然不能說大家都這樣做，但根據我們上限這段期間的 log 分析，至少有八成的抽獎者，扣掉先前的測試使用，在公佈抽獎當天，都是平均一篇貼文會抽超過 30次，最後才會公布結果，所以說抽獎公布不公平呢？大家可以自己評斷 😏
