冒險的一手— — 如何運用 In-App Review 客製化流程，提升 App 商店評價
閱讀時間約 8 分鐘
小小備註：寫在文章前頭，由於負責的產品有機敏性，以下內容僅會說明，站在產品經理角度，如何透過流程設計，讓 In-App Review 達到最大效益（白話一點就是如何有效提升你的App在商店的評分囉）。
那麼，我們開始吧！
我手上所負責的 App 屬 to B 性質，且 2020 年初剛進行過翻新，包含介面設計、程式架構，整體 App 不論是穩定度或使用者流程，都比去年釋出的版本優化許多。然而我入職接手後，發覺商店評論與評分都還是留在去年的用戶歷史— — 可以想見，是很慘烈的負評；也因此，我便著手進行「如何提升商店評價與評分」的研究。
以下我會分成 4 個階段說明：
- 前期研究
- 流程設計
- 條件設定
- 實作上線與成效
1. 前期研究
我必須承認，這是我第一次負責 App 的產品，過去並沒有類似的產品開發經驗可以參考，所以前期花了不少時間研讀相關的文章，包含 In-App Review 的風險、iOS/Android 用戶在評價行為上的差異、用戶對於 App 穩定度的感受….等等，前後零散時間加起來，至少花掉我一週左右。
之所以砸下這不短的時間成本，是因為在我認知中，「主動要求用戶給予正評」這件事本身是有相當的風險存在，而我手上負責的這個 App 沒有太多承受負評的本錢。試想在現實生活，你記得你最近一次在 Google 或是 Facebook 給商家評論是在什麼狀況嗎？我想，有一部份是在你感受不好時留下的評價吧。
當時 Apptentive 所做的一系列 App Case Studies 給我蠻大幫助的。它整理的 Yearly Benchmark Report，裡面提供了雙平台（iOS & Android）在不同 App 類型的評分取向— — 例如，同樣是 Food & Drink 的分類，iOS 用戶超過 78% 用戶給予五星正評，但是 Android 用戶卻銳減到只剩 56%，1 星負評則提高到 23%。（延伸閱讀：2020 Mobile App Engagement Benchmark Report by Apptentive）
裡面我得到一個很重要的資訊：以統計數據來看，不論正評或負評，Android 的評論數量都遠大於 iOS 。
當然，這其中主要原因是地域性平台用戶基數就不同（註：台灣平台用戶比例 Android：iOS 約為 54：45。資料來源）。根據 Apptentive 報告說明，Android 用戶年齡層較年輕，且更容易傾向給予負面評價。
有了手機用戶對於「商店評價」的基本認知後，我便開始著手進行第二階段：流程設計。
2. 流程設計
In-App Review 流程目前主要有 2 種做法：(1) 使用官方提供的樣版 (2) 自刻畫面。
我們先來看看 iOS 官方提供的 In-App Review 樣版：
Android 官方樣版在我設計流程期間仍在測試階段，直至2020 年 8 月正式釋出：
使用官方樣版的好處在於設定好觸發條件後，用戶直接點擊彈窗上的星等，送出後便直接將評分送至平台，等於完成評價流程；對於用戶的評價成本相對而言很低，因為用戶不需離開你的 App 到 Play Store 或 App Store 幫你評分。
但是這簡潔的流程也伴隨著風險— —代表用戶很輕易可以送給你一星評等。加上官方樣版無法調整畫面與用字遣詞，當時我在心裡其實很快就決定不採用官方提供的評價機制，而改走自定義的流程。
對於自定義流程，我初步的構想是：盡可能在評價過程中擋下可能會給予負評的機率，同時也要能吸引願意給我高星等的用戶。
流程簡化說明大致如下（適用雙系統）：
- 第一步驟：最重要的一步！這步驟是幫助你篩選出「目前對你產品有明確看法(Like or Dislike)」、「目前沒有評價意願(Maybe Next Time)」、「別拿評價煩我(Dismiss)」的 3 種用戶類型。透過這個流程，你可以引導願意給予評價的用戶去到應該去的地方。
- 第二步驟：在第一步驟選擇「喜歡」的用戶，這時候再詢問是否願意至商店評分。由於在一開始用戶已經是對產品抱持正向態度，這時給予高星等評價的機率會很高；用戶點擊至商店後，iOS 預設開啟評價頁面並 default 在五星（如下圖），Android 用戶則會到 Play Store 你的 App 頁面。
- 反之，第一步驟選擇「不喜歡」的用戶，就不必冒險引導此類用戶到商店，而是透過意見蒐集的方式，讓願意給你評價（即便是負評）的用戶得到另一種 Positive Feedback；身為 PM 的你也能得到 End User 的意見。
而在第一步驟剩下的另外 2 種用戶類型，則是另外標記：選擇 Dismiss 的用戶，暫定為「不希望在使用 App 過程中被評價機制打擾到的用戶」，故之後任何 In-App Review 都會跳過他們。選擇 Maybe Next Time 的用戶則歸類在「未來有機會再次詢問評價」，就待之後新的評價規劃再把他們放回 Pool 裡。
3. 條件設定
那麼，進到 Trigger Review 的條件— — 沒有人喜歡被打斷使用、瀏覽產品的感覺（想想手機瀏覽器惱人的蓋版廣告），所以觸發評價視窗的時間點必須得特別注意：別讓用戶不開心！
條件設定會根據你的產品類型、用戶行為而有很大的差別，並沒有一套成功的準則。你得站在產品經理（產品負責人）的角度深入觀察你的用戶：他們在你的產品上最常做那些事？完成他們想做的事情得經過哪些流程？平均花費多少時間？完成哪些事情會讓他們當下是感到愉悅、滿足的？
根據這些觀察結果，決定出一條最佳路徑，在路徑的終點就是你的 Trigger Point。
4. 實作上線與成效
這是我們團隊第一次嘗試做 In-App Review，其實身為產品經理的我心裡是很忐忑的（XD），如同先前提到的：我們沒有承受大量負評的風險。
開發完成到測試階段時，我自己列出好幾個 User Test Case 並進行實際測試，確保用戶在滿足特定條件下會跳出評價、已經選擇拒絕的用戶，無論再滿足幾次相對應條件後都不會再看到評價視窗等等。
很幸運地，評價觸發機制上線後，我們在短短 3 週內從雙系統獲得超過 34 個五星評分；雖然在商店上看起來並沒有巨幅的評分跳升（這會牽涉到雙系統計算評分的條件，這邊不多贅述），然而比起之前我們平均 1 個月才能獲得 1 顆 5 星比起來，已經是很大的突破。後續將成果表現分享給團隊工程師與其他成員，可以很明顯感受到大家對產品的信心度又大增了— — 這是我覺得最大的收穫！
最後補充一個小小插曲：我們產品用戶 Android 占比約 3 成左右，不過貢獻了超過一半的五星評分，這也算是驗證 Apptentive 的使用者報告：Android 用戶的確較願意給予 App 產品評價 :)
文章同步發表於 Medium。
留言0
查看全部