2014Q3 工作心得 (1)

剛開始我們主要採用 Parse.com 雲端服務完成行動 App 推播的功能,當每週發一次推播,一個月最多也只能發四次就會超過付費額度,此時目標式推播的功能將會是行動 App 的應用重點,看似簡單的推播通知系統,對於行銷部門而言,最需要有排程推播的需求,此時我們主要設計開發操作介面讓行銷人員進行排程的設定。

iOS 主要是透過 Apple Push Notification Service (APNs) 伺服器進行推播通知的服務,此時我們的角色為提供者 (Provider),當需要發送推播通知時,會傳送指令訊息至 APNs 伺服器,接著 APNs 伺服器就會在適當的 Client App 進行推播通知。

APNs 伺服器主要根據 deviceToken 進行不同行動裝置的 App 推播通知,因此我們主要是透過 Sails.js 儲存不同行動裝置的 App 專屬的 deviceToken 至推播伺服器的資料庫中,接著推播伺服器會根據排程時間從資料庫中取得 deviceToken 資料,再透過 Node.js 所撰寫的 API 進行客制化的推播通知。

Android 主要是透過 Google Cloud Messaging 連線伺服器 (GCM Connection Servers) 進行推播通知的服務,此時我們的角色為第三方 App 伺服器 (3rd-Party App Server),當需要發送推播通知時,會傳送指令訊息至 GCM Connection Servers 伺服器,接著 GCM Connection Servers 伺服器就會在適當的 Client App 進行推播通知。

GCM 連線伺服器主要根據 registration IDs 進行不同行動裝置的 App 推播通知,因此我們主要是透過 Sails.js 儲存不同行動裝置的 App 專屬的 deviceToken 至推播伺服器的資料庫中,接著推播伺服器會根據排程時間從資料庫中取得 registration IDs 資料,再透過 Node.js 所撰寫的 API 進行客制化的推播通知,相較於 APNs 伺服器有許多客制化的設定參數才能確保不同行動裝置在不同情況下也能正常接收推播通知。

最後行動應用的生命週期中有五個主要的重要環節,分別為獲取使用者 (Acquisition)、提高活躍度 (Activation)、提高留存率 (Retention) 、獲取收入 (Revenue) 和傳播擴散 (Refer) ,此時針對行動裝置進行推播通知,根據這幾個月以來的 Google Analytics 和 Flurry 的數據,發現每次進行推播通知皆能有效的提高活躍度和提高留存率的成效。