Flurry

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 的數據,發現每次進行推播通知皆能有效的提高活躍度和提高留存率的成效。

2014Q1 工作心得 (3)

我們主要開發內容為主的 App 開發,所以需要進行資料的分析,然而市面上已經有許多免費的第三方工具就能夠以最短的時間產生初步的分析報表,像是 Google Analytics、Flurry、Facebook Developer、App Annie 、… 等,不同的分析工具皆有最適合的用途。

Google Analytics 分析工具主要適合觀看即時總覽的資訊,以及透過事件定義就能透過類別 (Category)、事件 (Event)、動作 (Action) 和價值 (Value) 等參數就能滿足最基本的客制事件追蹤。

Flurry 分析工具主要適合查看留存率,在行動應用中使用者在某段時間內開始使用,經過一段時間之後,仍然繼續使用的用戶被認作為留存;這部份的使用者佔當時新增用戶的比例即是留存率,留存率相關計算公式請參考公式一和公式二。

  • 公式一: 留存率 = 使用的用戶數 / 新增用戶數 * 100%

  • 公式二: 第七天留存率留存率 = ( 新增用戶在第七天還有持續使用的用戶數) / 第一天新增用戶數 * 100%

Facebook Developer 分析工具主要適合觀查男女和年齡的分佈比例,找出 APP 的目標族群。

App Annie 分析工具主要適合觀查 App 實際下載數 (註: Google Analytics 的新使用者定義為七天內未登入的使用者,所以無法用來當下載數。) 與 App Store 與 Google Play 的歷史排名,更進一步整合廣告聯播網的收益情況 (eCPM)。

最後我們主要分析 2014 年第一季的男女看劇行為和不同年齡層看劇行為的數據,匯整報告提供給第三方公開使用。