本篇將圍繞推送著陸頁的設計、著陸頁的用戶行為、消息中心等幾個方面為大家介紹。enjoy~

上一篇為大家介紹了推送消息在傳輸過程中出現丟失的情況，并講述了消息丟失的幾個原因及建議，沒看過的小伙伴可以看下 ?推送系統從0到1（五）：推送消息如何丟失的。從第二章開始圍繞著推送的整個流程進行介紹，從推送服務的接入、推送消息的建立、消息傳輸、消息到達等階段都進行了講述。

本篇來到了推送流程的最后一個階段，用戶點擊推送消息后進入到著路頁。這個是用戶使用推送系統的最后一個環節，也是整個推送的最終目的：把用戶帶入到著陸頁。所以本篇將圍繞推送著陸頁的設計、著陸頁的用戶行為、消息中心等幾個方面為大家介紹。本章將會是最后一篇講述推送流程的文章，從下一章開始會深入從運營層面（如個性化推送）、數據層面（如用戶畫像、提高推送點擊率、數據監控等）為大家介紹。

1. 著陸頁的設計

用戶收到推送消息后，若對推送的文案及內容產生興趣，便會點開推送內容瀏覽詳情。這與列表頁似乎有些相似，通過標題、摘要或圖片吸引用戶進行瀏覽，只不過推送具有及時性、定向性。用戶不需要處于應用內的列表頁中，便也可以看到摘要的內容。能否吸引用戶點開是推送消息內容的責任；而用戶點開之后能否達成運營目的，則是著陸頁的責任。

1.1 著陸頁的類型

根據推送目的的需要，著陸頁可以是APP中的原生頁面、活動網頁等。像是以促成APP內部流程轉化的，如電商類網站的下單、發貨、簽收等；又如社交類軟件的聊天消息；亦或者資訊類平臺的文章內容等。這些類型的推送大多是跳轉至APP內的原生頁面，對于這類頁面有2個好處：

1. 原生頁面加載快，減少點擊消息到著陸過程中的用戶流失
2. 原生頁面用戶熟悉，了解該頁面的出入口位置

但是該類型的頁面也有局限性，用戶對于這些頁面過于熟悉，以至于后續再次點開的幾率會減少。例如電商網站的發貨提醒，你前幾次點進去之后會發現就是一個訂單發貨狀態。后續再次收到發貨提醒的推送之后，根據通知消息知曉發貨狀態就完成了解進度的需求，不再需要點進去瀏覽了。

而活動類頁面多使用H5等網頁形式，由于其形式靈活多變所以使用網頁的概率極高。相較于原生頁面，其加載速度略微不暫優勢（當然一些大廠的APP中這個差距可以忽視）。這個將有可能導致用戶在等待過程中離開。但是活動類推送由于其蘊含的運營策略在其中，同時樣式并非用戶常見頁面，對用戶比較有吸引力。

綜上所述，著陸頁的設計最終還是根據推送需求所決定，只不過由于選擇的頁面類型不同，會有一定程度的數據表現差異，在進行設計的時候有這個預期便可。而著陸頁的類型對于用戶轉化的影響并沒有特別大，更大的在于用戶對通知消息的預期與著陸頁實際結果的差異。下面為大家介紹著陸頁的用戶預期。

1.2 著陸頁的用戶預期

與大多數公眾號及列表頁的用戶預期相似，用戶在瀏覽推送消息時也會產生一定的預期效應。用戶可能會被所謂的“標題黨”所吸引，也可能會對消息中的“誘惑”充滿興趣。但是在用戶點擊的那一刻，他的心里已對著陸頁內容有所預期。也許你曾遇到過這樣的場面，收到一條電商網站的關于優惠活動的推送：參與活動，立減XXX；你在被價格所吸引點后點開推送并在活動頁中翻來覆去都無法找到優惠的地方，此時你一定會直接關掉APP。從推送的傳播的角度來說這是成功的，用戶成功被標題吸引并抵達著陸頁。從本次推送的商業化轉化效果則有待考量，但是毋庸置疑用戶的預期是著陸頁確實有優惠信息并且應當一進入便可找到。由于預期與著陸頁不符，很可能用戶下次根本不再會點開通知消息，或者用戶會直接關閉通知權限。

所以在推送消息與著陸頁的設計上需要考慮用戶預期，相比于公眾號或者列表頁，標題黨真的需要慎用再慎用，不然少則無法達到后續的轉化目的，多則直接損失一個用戶。畢竟像列表頁點開發現不符合預期返回之后仍是列表，并且那是用戶主動點開的行為。而對于推送消息是首先從外部進入到APP的，再者并非用戶主動找到的，若著陸頁不符合用戶的預期，用戶極大概率直接關掉。

所以在推送消息和著陸頁的設計上，盡量考慮用戶的預期效應，不要消息和著陸頁文不對題，即便一些商業化運營手法，請不要放在著陸頁上，可以考慮放在后續的行為頁面上。

1.3 著陸頁的設計目的

上面有講述到，由于著陸頁的設計目的不同，設計類型及推送消息均會有不同的展示方式。那么在著陸頁的設計上，需要根據目的進行設計。需要記住的是，與用戶正常瀏覽行為不同的是，推送是從應用外部直接進入著陸頁的，并且是平臺方/第三方發起的行為。不同的用戶行徑自然與正常瀏覽的用戶產生差異，從推送進來的用戶相較于普通瀏覽的用戶來說，耐心（瀏覽時間）、瀏覽量以及轉化效果都可能與正常瀏覽的用戶不同，所以在著陸頁的設計上需要更考慮目的。

（1）若設計目的是實現轉化/過程銜接

那么在著陸頁的設計上，更突出吸引用戶轉化的點。最好直接放在第一屏，轉化的核心入口請顯著突出，減少用戶翻找的成本。同時在內容的設計上盡量符合用戶需求或者完成過程的銜接。如電商類平臺希望實現用戶的購買，若該頁面為用戶需求的商品優惠頁，則轉化的可行性非常高。若此頁面為用戶轉化過程中的銜接頁面，請告訴用戶在處于的過程或狀態，因為用戶不是正常流程走下來的，而是從外部進來的。

（2）若設計目的是增加瀏覽

從推送進來的用戶瀏覽量從理論上講是不如正常瀏覽用戶的瀏覽量。這是因為用戶主動和被動產生的差異化效果。當然也不排除推送的內容非常貼合用戶需求，并且在著陸頁的設計上能引導用戶一步步深入瀏覽。所以目的是增加瀏覽量的著陸頁設計需要考慮的是，用戶不是從首頁/列表頁進來的，根據正常的返回習慣，從哪來就回到哪去，那么用戶很可能在瀏覽完當前頁后離開APP。所以在著陸頁出口的設計上就需要更加注意，想要增加瀏覽量就需要更多的頁面出口，更需要強化引導瀏覽的通道。如果你觀察天貓的推送你就會發現，它的猜你喜歡推送大多數著陸頁中都是放置大量商品入口，給予用戶深入繼續瀏覽的入口。減少用戶瀏覽完當前頁由于習慣性返回而離開APP。

（2）若設計目的是滿足用戶需求

若是為了滿足用戶需求，像是滿足用戶獲取消息的提醒類推送，滿足用戶獲取最新資訊的新聞類推送，滿足用戶興趣的文章類推送。這些推送的目的更多在于滿足用戶需求，那么著陸頁的設計應當直接展示需求內容，這類推送會更簡單純粹，因為競爭力在于內容本身，推送只是作為觸達用戶的途徑。

2. 著陸頁的用戶行為

上面已經介紹過了從推送進來的用戶行為可能會與從正常路徑進來的用戶行為有所差異，所以需要監控該部分的用戶行為，若是帶有商業化轉化目的的，就更需要針對用戶著陸后的行為進行監控和分析，從而挖掘和調整轉化的關鍵誘因。此處推薦2種用戶行為的數據采集方式：

1. 沙漏模型：從用戶點擊推送進入著陸頁到實際轉化與正常用戶的轉化沙漏進行對比
2. 喜好度模型：從用戶停留、瀏覽深度、關鍵交互（收藏、分享、轉化）等進行分析對比

第一種方式多運用在活動類的著陸頁，根據用戶轉化效果不斷調整頁面的設計，力求實現最高的商業化價值。第二種多運用在個性化精準推送，而使用戶在點擊推送并著陸后的數據表現反過來修正用戶畫像，這個將在后面的章節進行詳細介紹。對比用戶行為與設計目的，我們可以與原設計時預定的用戶行為路徑進行比對分析，不斷調整著陸頁讓其更好的與設計目的一致。

3. 推送消息的存儲—?消息中心的設計

在用戶瀏覽完著陸頁后，也有可能點擊左上角的返回，此時應當返回哪里呢？按理說從哪來就返回哪里，但是推送是從系統通知欄點擊進來的，難道返回手機主屏幕？有些APP的做法會返回APP的首頁，或者著陸頁的入口頁面。但是當著陸頁是特殊的活動頁面，沒有常規入口怎么辦？或者說用戶不小心離開了，再想看剛剛推送著陸頁怎么找？這個時候很多APP就會通過消息中心解決消息的存儲問題。

3.1 消息中心的作用

消息中心作為推送消息的存儲中心，提供了再次造訪推送著陸頁的機會。不僅如此消息中心還承擔了離線消息的作用。若用戶并未點開推送消息或清除了推送消息，在其啟動APP時，消息中心仍然提供用戶訪問消息著陸頁的機會。許多APP會單獨把消息中心放置在重要的tab標簽頁上，并加上小紅點提醒；若用戶已經點開推送消息并瀏覽，不小心離開著陸頁或者下次還想瀏覽，則消息中心提供長期訪問著陸頁的入口。

對于社交類APP來說，消息中心才是最為主要的聊天列表，推送反倒是次要的，僅僅作為提醒的功能。該類型的APP會把消息中心作為最主要的頁面進行放置，既然消息中心這么重要，那么又該如何設計呢？

3.2 消息中心的設計

按照消息中心的作用中描述，消息中心是把推送消息保存下來并提供再次造訪的入口，那么消息中心的實現就是把通知直接保存在APP里面嗎？其實不是的，下面將為大家介紹消息中心的設計原理。

（1）消息的傳送

消息中心的消息傳送其實與推送消息為兩套消息傳送機制。消息中心的消息更類似于離線推送。由于不需要實現用戶在關閉APP時的及時提醒（交給推送完成），所以消息中心的消息多為啟動APP后進行數據拉取的。雖然是兩套數據傳輸的方式，但是兩者又是相互關聯的。消息中心需要了解推送消息的內容，讀取狀態等相關信息，所以推送消息的狀態及內容需要反饋給服務器，并展示在消息中心。

（2）消息的存儲

消息的存儲主要分為兩種方式：一種是需要登陸的方式，跟隨用戶賬號遷移，該方式涉及數據同步問題，由于成本過高，使用場景較少。另一種是保存在客戶端本地，卸載或遷移后數據均會丟失，大多數APP運用該方式。消息的存儲難點在于，每個人的消息是不同的，需要單獨存儲，這個存儲量相對較大，相當于每個人有自己的一套消息中心，因此大多數消息建議存儲在客戶端，而服務端多負責新消息的傳遞和消息的讀取狀態（此處需要與研發多進行探討，尋求較好的存儲和實現方式）。

（3）消息中心的展示

由于消息的類型不同，消息中心呈現方式有很大的差異化。例如電商類網站，由于消息種類不同光消息中心內容頁就有很多種的展示方式。如消息列表形式的、如微信公眾號形式的、如即時通訊對話框等等。不管消息中心長什么樣，其最終解決的問題就是消息的展示和存儲。為用戶提供消息著陸頁的入口。

由于本章主要講述推送著陸頁的設計及進入方式，而消息中心作為著陸頁的存儲和入口在此進行簡單的介紹，關于消息中心如何具體設計與實現，后續有機會再進行詳細的介紹，在此就簡單介紹其用途即可。

本篇總結

本篇主要為大家介紹了推送著陸頁的設計及消息中心的作用和原理，總結下來會是以下幾點：

1. 根據著陸頁設計需求決定著陸頁的類型
2. 推送消息和著陸頁需要給予用戶預期一致性
3. 推送進入著陸頁的用戶行為與正常用戶瀏覽有所差異
4. 觀察用戶在著陸頁的行為與設計目的的差異，能更好的優化著陸頁
5. 消息中心承擔消息存儲和著陸頁入口的重要任務

至此基本完成對推送流程的介紹，在流程介紹中有許多不足或者不準確的地方，也期待各位看官能提出修改建議，非常感謝您的支持。下一篇將會是個性化精準推送的開端，介紹如何獲取用戶行為，分析用戶的喜好度，建立用戶畫像。盡請期待。

相關閱讀

推送系統從0到1（一）：是系統不是工具

推送系統從0到1（二）：了解你的用戶

推送系統從0到1（三）：推送任務的建立

推送系統從0到1（四）：消息如何到達用戶設備

推送系統從0到1（五）：推送消息如何丟失的

本文由 @番茄那只羊 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自Pexels，基于CC0協議