逆向破解競業情報書

從應用程式商店頁判讀競品動向時,最常見的七個誤判盤點

首頁 / 案例 / 從應用程式商店頁判讀競品動向時,最常見的七個誤判盤點

七個誤判裡,有五個是我們在委託方內部簡報上親眼看過的,另外兩個是我們自己早期踩過的。按照出現頻率由高到低排列,第一個幾乎每個團隊都犯過。

應用程式商店頁上的資料,能拿來判讀競品到什麼程度?

商店頁能可靠告訴你的事有三件:對手怎麼向新用戶介紹自己、多久更新一次、以及用戶公開抱怨什麼。評分、排名與下載級距只能看方向,不能當成用戶數或營收的替代指標。把後者當成前者來用,是多數誤判的來源。

應用程式商店頁,指的是行動應用程式在官方商店上的公開介紹頁,包含名稱、說明、截圖、評分、評論、版本紀錄與開發者資訊。任何人不需登入特殊身分就能查看。

示例的委託方是一家做健身房預約系統的團隊,產品有一個給會員用的行動應用程式。他們每個月會整理一份競品動態,資料幾乎全部來自商店頁。以下七項誤判,都對照這份月報說明。

誤判一:把評分高低當成產品好壞的排名

月報的第一頁是一張評分排行。對手甲四點多星,委託方略低,結論寫著「甲的產品體驗領先」。

評分受太多產品以外的因素影響。有些應用程式會在用戶完成一次順利操作後才跳出評分邀請,這時候留下的分數自然偏高。有些則從不邀請,只有不滿的人會主動去留言。兩種做法下的平均分數不能直接比較。

修正做法是不比平均分,改讀評論內容。把近期的低分評論逐則分類,看抱怨集中在哪些功能。同時觀察對手是否有邀請評分的機制,這可以從評論的用語看出一些端倪,例如大量簡短而相似的五星留言集中在某段期間。這只是跡象,報告裡要寫成跡象。

誤判二:把下載級距當成活躍用戶數

部分商店會顯示下載次數的級距。月報直接把它寫成「對手乙擁有十萬以上用戶」。

下載級距是歷史累計的安裝次數,而且只是一個區間。它不扣除已經卸載的人,也不區分裝了從沒打開的人。同一個人換手機重裝,也可能再算一次。另外,並非每個商店都公開這項資訊,只看得到一個商店的數字時,連完整的下載量都稱不上。

對預約系統這類產品來說還有一層問題。會員端應用程式的下載量,主要取決於簽約的健身房有多少會員,與產品本身的吸引力關係不大。一家對手簽下一間大型連鎖場館,下載量就會跳一級。

修正做法是把這個數字降級為背景資訊,只在級距發生變動時記錄日期。用戶規模的問題,改從對手公開的合作場館名單與案例頁去看。

誤判三:把分類排名的升降當成成長或衰退

月報有一張折線圖,追蹤對手在「健康與健身」分類的排名。某個月對手丙的排名上升了不少,月報寫「丙成長加速」。

分類排名反映的是短期的下載動能,計算方式並未完全公開,而且會受到同分類其他應用程式的影響。一月份很多人立下運動計畫,整個分類的下載都在動,排名變化很大一部分是季節因素。別人下滑,你不動也會上升。

更麻煩的是,免費的排名查詢工具通常只提供有限的歷史資料與有限的地區。月報拿三個月的資料畫趨勢線,樣本太短。

修正做法是排名只記錄異常跳動,並且一定要找對應的事件。丙那個月在官方社群公告了與一家連鎖場館的合作上線。排名跳動有了解釋,它是一次性的導入,稱不上成長加速。

誤判四:把版本更新頻率當成研發實力

對手甲幾乎每兩週更新一次,委託方大約每月一次。月報的結論是「甲的研發資源較充足」。

更新頻率反映的是發版節奏,這是工程流程的選擇。有的團隊習慣小步快跑,每次只改一點。有的團隊習慣累積成較大的版本。頻繁更新也可能是因為問題多,一直在修。

修正做法是讀版本紀錄的內容,把每一次更新分成三類:新功能、既有功能調整、問題修正。分完類再看比例。示例中,甲過去半年的更新紀錄裡,寫明新功能的次數很少,大部分只寫著「修正問題與提升效能」。這句話幾乎沒有資訊量,只能如實記錄為內容不明。

這裡要承認限制。版本紀錄寫得多詳細,各家習慣差很多。寫得含糊的對手,這項來源能提供的資訊就很有限,不要硬擠結論。

誤判五:把商店截圖上的功能當成已經上線且好用

對手乙的商店截圖出現了一個「智慧排課」畫面。月報寫「乙已推出智慧排課功能」,產品經理因此在規劃會議上要求跟進。

商店截圖是行銷素材。它可能展示理想狀態、只對部分方案開放的功能、甚至是尚在分批釋出的功能。截圖上有,不等於所有用戶手上都有,更不等於好用。

修正做法是找旁證。查對手的公開說明文件有沒有這項功能的操作說明。查近期評論有沒有用戶提到它。查官網的方案頁是否把它列為特定方案的項目。示例中,說明文件沒有對應條目,評論裡也沒有人提到,方案頁則把它標示為進階方案的項目。報告的寫法是:對手已公開宣傳此功能,適用於進階方案,實際可用範圍與使用情況無公開資料可確認。

這個修正讓委託方把「立刻跟進」改成「列入觀察」,並設定三個月後重查評論。

誤判六:把負評數量增加當成對手出了大問題

某個月對手丙的一星評論明顯變多。月報的標題是「丙遭遇用戶反彈」,業務團隊拿這個去跟潛在客戶說。

負評暴增最常見的原因是單一事件。一次改版出錯、一次登入故障、一家合作場館調整了規則而會員把氣出在應用程式上。這類事件造成的負評集中在幾天之內,問題修好後就停了。

修正做法是看負評的日期分布與內容集中度。示例中,那批負評集中在四天內,內容幾乎都在抱怨同一件事:某次更新後無法取消預約。對手兩天後發了修正版本,版本紀錄有對應說明,之後負評回到平常水準。這是一次事故,處理速度還算快。

業務拿競品的負評去向客戶說嘴,本身也有風險。對外陳述競爭對手的狀況,若與事實不符或已經過時,可能引發爭議,相關界線要請當地持牌的法律專業人士確認。情報書的內容預設供內部決策使用。

誤判七:只看一個商店、一個地區、一種語言

這是我們自己早期犯過的錯。查證時只看了其中一個商店的本地版本,就下了結論。

不同商店的用戶組成不同,評分與評論的樣貌會差很多。同一個應用程式在不同地區的商店頁,說明文字與截圖也可能不一樣。對手如果正在準備進入新市場,往往會先出現其他語言的商店說明,本地頁面上完全看不出來。

修正做法是在來源索引表上明寫查閱的商店、地區與語言,並且至少覆蓋兩個主要商店。示例中補查之後發現,對手甲的商店頁新增了另一種語言的完整說明與截圖。這是一條值得追蹤的擴張線索,原本的月報完全沒有看到。

修正之後,這份競品月報長什麼樣子?

委託方後來把月報的結構改成四個區塊,取代原本的排行榜。

  1. 對手如何介紹自己:商店說明與截圖的文字變化,附前後對照與日期
  2. 對手改了什麼:版本紀錄分類統計,內容不明者如實標示
  3. 用戶公開抱怨什麼:低分評論的主題分類,區分單次事件與反覆出現的問題
  4. 異常事件:評分、排名或下載級距的跳動,附上找到或找不到的對應事件

評分與排名從第一頁移到最後一個區塊,而且只在有異常時才出現。月報從八頁縮成三頁。產品經理說,以前看完月報會焦慮,現在看完知道要去查哪一件事。

這份盤點不適用於哪些情況?

產品沒有行動應用程式,或應用程式只是附屬管道時,商店頁的參考價值很低。有些企業用軟體的應用程式只給既有客戶的員工使用,商店頁刻意寫得很簡略,評論也很少。這時候不要勉強從少量評論裡歸納主題。

需要用戶數、留存或營收這類數字的決策,商店頁幫不上忙。這些數字在對手內部,合法公開來源多半查不到。市面上有工具提供這類推估,其可靠度的問題與流量估算類似,使用前要先用自己的真實數據校準,並且明確標示為估算。

最後,七個誤判是依我們接觸過的案例排序的,各產業的情況不同,順序不代表普遍的發生機率。

← 回到案例總覽