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

2014Q2 工作心得 (3)

我們進行資料的分析主要是為了提供使用者更優質的使用者體驗,所以我們需要藉由推薦機制以縮短使用者操作時間,讓使用者快速找到有興趣的主題。

透過 BigQuery 進行即時反應的推薦機制和 R 語言進行統計之後的推薦機制,主要皆以 Apriori 演算法為基礎進行資料分析,至於要如何與 Node.js 進行整合應用,最簡單的方式就是將篩選結果匯出成 csv 檔案,再進行解析,透過 API 的方式進行應用。

最後不論是將第三方工具所收集的資料,轉存至 Google BigQuery 中,再透過查詢,將資料透過 R 語言進行統計分析應用至 App 之中。

2014Q2 工作心得 (2)

Facebook 公司在 2014 年 4 月底的 F8 大會中發表新服務,其中之一就是行動廣告網路 ( Facebook Audience Network ) ,主要目的在幫助其它行動開發商行銷行動廣告,行動廣告主要會利用 Facebook 收集的使用者資料,幫助行銷人員更加精準地的投放廣告,廣告類型主要就分為橫幅廣告 (Banner)、插頁廣告 (Interstitial) 和原生廣告 (Native)。

當時我們主要原生廣告投放 API,再搭配透過 Google Analytics 工具追蹤原生廣告的成效,主要是記錄使用者觀看和點擊原生廣告的數據,透過原生廣告觀看和點擊的數據計算出原生廣告的點擊率,透過點擊率來衡量目標式原生廣告成效。

最後在 2014 年第二季開始與內容相關的 Facebook 粉絲團進行合作,例如: 推薦觀看韓劇的使用者可能會喜歡韓劇相關的粉絲頁,實測的成效平均點擊率高達 5.35%。 (註: 透過 Facebook 目標式廣告機制進行廣告的投放,當廣告組合適當時點擊率平均為 1.5% ~ 2.5%,Facebook 行動廣告網路進行廣告的投放,原生廣告點擊率平均為 2% ~ 3% )

2014Q2 工作心得 (1)

目前只要談到巨量資料分析,幾乎都會想到 Hadoop 的完整的生態環境,可是對於新創公司的我們資料量的確還未到達立即需要使用 Hadoop 分散式處理的程度,因為透過 Google Analytics 中的事件定義就能滿足我們當時對於資料的營運需求。

此外 Google BigQuery 雲端服務剛剛推出沒多久,並且有提供新創公司的試用方案,更重要的是 Hadoop 主要是基於 Google 在 2004 年所提出的 MapReduce 軟體架構進行分析,然而 Google BigQuery 主要是基於 Google 在 2010 年所提出的 Dremel 分散式資料分析系統,根據 Google 官方的研究報告,我們可以很清楚的了解 Dremel 的確比 MapReduce 擁有更快的處理效能。

所以我們就決定投入時間將 Amazon RDS 中 2014 年第二季資料匯入至 Google BigQuery 之中,接著透過 SQL 查詢指令將原本需要花費數三十分鐘以上才能完成的工作縮短至不到五分鐘皆能完成,最後再搭配 Google Spreedsheet 試算表中的 Script 腳本指令,就能夠透過資料以圖表呈現的方式讓行銷人員進行參考。

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 年第一季的男女看劇行為和不同年齡層看劇行為的數據,匯整報告提供給第三方公開使用。