如何選有價值人群進行推送

推送（Push）越來越成為 App 運營的必備手段，成為 App 開發中必備的功能。

但是，推送給誰？是個問題。

本文以極光推送作為範例，重點說說推送人群（Audience）選擇的技術問題。其他推送雲服務也或多或少有些類似。

極光推送（JPush）在推送人群的選擇上，支援如下幾種方式：

1. 廣播（所有人）

2. 註冊ID（RegistrationID）

3. 別名（alias）

4. 標籤（tag，分組）

5. 用戶分群（Segment）

推送人群可選類別

以下先分別解析以上幾個推送人群類型，及其具體用法。之後再談談他們的適用場景，以及如何區別使用。

註冊ID（RegistrationID）

RegistrationID 就是這台設備（以及當前這個 App），被推送伺服器分配的唯一 ID。不同的設備、不同的 App 這個 ID 肯定不同的。

SDK 在第一次啟動時會去伺服器端進行註冊並識別，伺服器端會分配一個 RegistrationID。SDK 會把這個 ID 通過廣播（或通知）的方式發給 App。SDK 也提供了獲取 RegistrationID 的介面。

如果一個 App 在這台設備上之前安裝過，然後被卸載掉。重新安裝時，其獲取到的 RegistrationID 有一定的可能性不變。這取決於平臺以及條件。

• Android 上 JPush 會綜合利用多個條件來判斷設備是否相同，從而 RegistrationID 不變的可能性很大。

• iOS 老版本上，因為 device token 重新安裝 App 時也不會變，從而 RegistrationID 也一般不會變。

• iOS8 以後重新安裝 App 會導致 device token 變更，iOS 上如果不啟用 IDFA 則沒有其他可用於識別設備的手段，從而 RegistrationID 一般會變化。或者說，伺服器端無法識別重新安裝。所以如果你的業務有需要，建議啟用 IDFA。

使用 RegistrationID 推送的關鍵于，App 開發者需要在開發 App 時，獲取到這個 RegistrationID，保存到 App 業務伺服器上去，並且與自己的使用者標識對應起來。

建議 App 開發者盡可能做這個保存動作。因為這是最精確地定位到設備的。

別名（alias）

別名可以理解為基於 RegistrationID，設置一個更容易理解的『別名』，比如直接設置為當前登錄用戶的 username。

一個設備（在一個 App 裡）只能設置一個別名。

別名的本質是，把 App 用戶體系裡的用戶ID與 RegistrationID 的對應關係，保存到推送伺服器上，而不是保存到 App 業務伺服器上去。（使用 RegistrationID 就是把對應關係保存到 App 業務伺服器上去。）

設置了別名後，推送時伺服器端指定別名即可。推送伺服器端來把別名轉化到 RegistrationID找到設備。

別名可以在用戶端設置，伺服器端也提供了 REST API 進行設置。但是，在一個 App 的生命週期中，強烈建議不要既在用戶端又在伺服器端進行設置，否則會導致混亂。

標籤（tag）

又或者稱為分組消息推送。對於大量的設置了同一個標籤的終端，可以一次推送到到達。一個應用裡一個標籤綁定到的設備數沒有限制。

一個設備（在一個 App裡）可以設置多個標籤。

標籤與別名類似，其對應關係也是保存在推送伺服器側的。

與別名類似，標籤也是可以在用戶端設置，伺服器端也開放了 REST API 進行設置。同樣，也是強烈建議，不要既在用戶端設置標籤，又在伺服器端設置標籤，以免造成混亂。

用戶分群（Segment）

這是相對高級的使用方式了，開發者可以根據一些已知的條件，任意組合，創建一個 SegmentID。然後基於這個 SegmentID 進行推送。

上面說到的可以用於用戶分群的條件有：tags，App 版本，SDK 版本，平臺版本，用戶註冊時間，用戶活躍時間，用戶所在城市等。

廣播（所有人）

技術上廣播很好理解，就是推送給所有安裝的 App 的設備終端。

極光推送對廣播有一個特殊的選項：延遲推送。這是個很有特色的功能，讓推送在一定時長內平均分配，而不是在太短時間內完成，以免對 App 業務伺服器造成太大的壓力。

根據業務場景選擇推送人群

以上以極光推送為例介紹了支持的推送人群類別。但是，任何技術都有一個使用場景的問題。開發者需要想清楚自己的使用場景，來選擇適當的類別。

舉一個比較極端的例子。極光推送曾經有一個開發者，其用戶場景是，小學生手裡有卡，小孩進學校門時需要刷卡。刷卡後，家長 App 上可以收到推送。我們注意到這個開發者是因為突然發現推送量暴增，這個推送量竟然來自於一個只有幾萬安裝量的 App。追查發現，這個應用每天推送大量的廣播。為什麼要推送那麼多廣播呢？與開發者一溝通，發現原來，他是每個學生有刷卡，都會做一次廣播推送給所有用 戶，然後在 App 側再去檢查看只有我自己家小孩的刷卡才展示，其他都被過濾掉。

上面這個特例裡，其實就是應該使用單設備推送時，錯誤選擇了使用廣播推送。

單設備推送

RegistrationID 與別名是設計用來單用戶推送的。

如果別名只是在一個設備上被設置，則其效果與 RegistrationID 是類似的。

不同的是，一個別名是可以被設置到多設備上的。一個常見的場景是，把 App 的用戶帳號 username 作為別名。一個 App使用者帳號可以在多設備上登錄（大多數這樣），就可以在多設備上綁定為別名。這樣推送給這個別名，多設備上都收到。

由於別名的綁定關係保存在推送伺服器上，App 業務上要做變更就不夠靈活。所以，別名更適合於簡單的使用場景，也是適合「懶」的開發者。而 App 想要有靈活性，建議使用 RegistrationID 的方式。

別名在使用時，有可能被誤使用為 tag，即大量的設備上都設置同一個別名，其實就是 tag 的使用方式。極光推送發現了不少 App 這樣子用。

用戶分群與標籤

標籤是個很靈活的分組方法，可以被用於業務強相關的各種場景。主要的種類有：訂閱，使用者屬性。

訂閱類，比如彩票 App 用於用戶訂閱不同彩票類型的最新開獎資訊，閱讀類 App 用於讓使用者訂閱多個頻道的最新資訊等。

用 tag 來標注使用者的屬性，比如性別、年齡段、喜好、關注等，也是個很常見的作法，這樣推送時就可以基於這些屬性來做。這也是精細化推送的基礎。

事實上，很多標籤被開發者定義為：App 版本，使用者城市，使用語言等等。現在很多這類的 tags 可以不要了，只需要直接使用用戶分群功能就可以了。

可能不是推送

其實還有一些場景，可能不是「推送」合適的場景，但很多開發者卻嘗試用 Push 來解決。

場景一：一個終端使用者，需要向另外一個終端使用者發消息。嗯，這是典型的 IM 場景，應該集成 IM SDK，極光推送現在也提供 JMessage 來滿足這個需求。

場景二：經常發生終端使用者與服務端一對一溝通，比如電商類 App 一方面有訂單狀態需要發通知給使用者，另一方面存在使用者要找服務方諮詢問題。這類對定位用戶要求高，用 IM 來做相對開發起來簡單。

總結來說，Push 更適合於服務方單方向發消息給終端使用者。如果想要雙方向溝通，用基於 IM 的模型更合適。

其實這裡邊有一個本質的問題，Push 本質是基於「設備」，而 IM 本質上是基於「用戶」。某些 Push 服務提供了雙向的能力（雖說這有點感覺怪怪的），但也是不太合適滿足雙向交流的需求的，或者說 App 用起來沒有那麼順手。這方面，以後專門另外寫文章來演繹得更清晰些。

相關資訊，請洽https://www.jpush.cn/?from=ithometw