Apple Push Notification Service

雲端服務 Push Notification (1)

基本介紹

教學目標

了解各家雲端公司所提供推播服務的功能與費率,以及自建推播通知的服務需要處理的項目。

重點概念

免費方案

雲端公司 Facebook IBM Microsoft Amazon
推播服務 Parse Push Push for Bluemix Azure Notification Hubs Simple Notification Service
每月推播則數 100 萬 100 萬 100 萬 100 萬
每次推播則數 N/A N/A 10 萬 N/A

管理功能

雲端公司 Facebook IBM Microsoft Amazon
推播服務 Parse Push Push for Bluemix Azure Notification Hubs Simple Notification Service
群組功能 有 ( 頻道 ) 有 ( 標籤 ) 有 ( 標籤 ) 有 ( 主題 )
進階條件 N/A N/A N/A
排程推播管理 N/A 有 ( $200 / 月 ) N/A
註冊查詢 N/A 有 ( $200 / 月 )
A/B 測試 N/A N/A 有 ( A/B 測試服務 )

超額付費

雲端公司 Facebook IBM Microsoft Amazon
推播服務 Parse Push Push for Bluemix Azure Notification Hubs Simple Notification Service
萬則推播計價 $0.5 $0.2 $0.01 $0.005

(註: 以上相關資料截至 2014 年 10 月。)

自建服務

自建推播通知的服務需要處理的項目。

  1. 儲存裝置推播識別碼的服務。
  2. 排程推播條件篩選管理的服務。
  3. 提供推播訊息至對應推播伺服器的服務。
    (註: 篩選目標裝置進行即時推播將會是效能處理最主要的瓶頸。)

至於推播服務架構規劃可以參考 「Orchestrating iOS Push Notifications on Google Cloud Platform」 文章。

相關資源

Node.js 推播處理 (1)

基本介紹

教學目標

透過 apn 套件進行 iOS 的推播服務。

前置作業

  1. 準備個別 App 開發階段與產品階段給推播服務專用的金鑰檔案與憑證檔案。
  2. 準備開發中行動裝置對應個別 App 的推播專用之 Device Token 。

套件安裝

1
npm install apn --save

使用教學

建立

建立 iOS 推播服務需要設定基本參數。

1
2
3
4
5
6
7
8
9
var apn = require("apn");
var notification = new apns.Notification();
notification.expiry = Math.floor(Date.now() / 1000) + 3600;
notification.alert = "Alert!";
notification.badge = 1;
notification.sound = "default";
notification.payload = {
id: 1
};

準備

建立準備發送播放的 Device Token 清單,實務上會從資料庫中取得特定 App 發送推播的清單。

1
2
var device_tokens = [];
device_tokens.push("推播專用之 Device Token");

發送

發送之前必須使用開發階段的金鑰檔案和憑證檔案,以及設定正確的參數,接著將相關資訊傳送至 iOS 專用的推播伺服器 (APNs) ,就能進行推播服務。

1
2
3
4
5
6
7
8
9
10
11
var options = { 
cert: "cert_dev.pem",
key: "key_dev.pem",
gateway: "gateway.sandbox.push.apple.com",
port: 2195,
errorCallback: throw err
};
var apn_connection = new apns.Connection(options);
for (var n=0; n<device_tokens.length; n++) {
apn_connection.pushNotification(notification,new apn.Device(device_tokens[n]));
}

此外,對於產品階段的 App ,若要進行推播服務,則必需要使用產品階段的金鑰檔案和憑證檔案,以及設定正確的參數。

1
2
3
4
5
6
7
var options = { 
cert: "data/cert_dev.pem",
key: "data/key_dev.pem",
gateway: "gateway.push.apple.com",
port: 2195,
errorCallback: throw err
};

相關資源

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