<bdo id="2umnn"><optgroup id="2umnn"><dd id="2umnn"></dd></optgroup></bdo>
  • <option id="2umnn"></option>
    <option id="2umnn"><source id="2umnn"><ruby id="2umnn"></ruby></source></option>

        <div id="2umnn"></div>

          <option id="2umnn"></option>
          首頁 > 資訊 > 行業

          有贊微盟繼續虧,電商SaaS的邏輯該變了

          2022/08/16 15:56      微信公眾號:真探AlphaSeeker 真探  


            今年,電商SaaS整體“入冬”。

            國內,有贊、微盟等頭部玩家的股價持續下跌,市值處于低谷,裁員消息頻出,且虧損問題始終未解。海外,諸多明星SaaS公司也在經歷震蕩和下跌,Salesforce一季度營收下降九成,近期中國區業務也折戟;Shopify二季度虧損,隨之而來的是裁員,一年下來,其市值已蒸發1700億美元。

            近期,有贊和微盟都發布了2022年上半年財報。不出所料,兩家仍處于虧損狀態,有贊的經營虧損同比擴大5.5%,達到了4.74億元;微盟則更為嚴重,其經營虧損同比擴大285.2%至6.31億元,經調整凈虧損更是同比擴大499.2%。

            從前兩年名聲大噪、人人看好的風口到如今這般,我們該如何看待電商SaaS當下的境遇?在跌跌不休的股價之外,電商SaaS問題出在哪,前路又在哪?

            有贊:

            業務均下滑,

            虧損收窄靠“降本”

            2022年上半年,有贊總營收為7.29億元,較去年同期減少了9.2%。具體來看,其三項業務收入同比也均有減少:

            營收占比超五成的核心業務訂閱解決方案,在今年上半年收入為4.39億元,與去年同期相比減少了13.5%,財報解釋稱是SaaS產品訂閱費和云服務費有所減少。

            商家解決方案今年上半年收入2.84億元,同比減少1.9%,主要因為有贊推廣及有贊客的收益減少;

            其他業務收入0.06億元,同比下降1.7%,主要由于停止餐飲服務導致收益減少。

            快手斷鏈的影響在今年上半年仍清晰可見。電話會上,有贊CFO俞韜將SaaS收入的減少歸結為快手業務的流失,導致云服務費從去年同期5917萬元減少至2386萬元,也使得有贊客戶收入的下降。同時,今年上半年有贊非快手GMV同比增長約為25%,但整體來看479億元的GMV與去年同期相比還是略有下滑。

            盈利方面,有贊在今年上半年的毛利潤同比減少9.4%,為4.41億元;毛利率為60.5%,相比去年基本持平。對此,有贊CFO俞韜解釋主要是由于大客定制收入占比提升,但大客定制項目的毛利率低于訂閱收入毛利率,因此拉低了整體訂閱解決方案的毛利率。

            再看凈利潤,有贊上半年整體的經營虧損達到了4.74億元,且較去年同期增加5.5%;期內虧損4.82億元,同比增加30.2%。

            此外,半年期內有贊的存量付費商家為91005家,新增付費商家數量為19989家,與去年同期相比分別增長了4%、5%。如果拉長視線來看,這兩項數據較2020年有所減少。在2022年半年度業績交流會中,有贊也披露2022年上半年ACV(平均合同金額)為12399元,這一數據在2021年為12666元,對比來看也有所下降。

            不過特別的是,分季度來看,有贊在*季度的經營虧損收窄了48.9%。

            這背后主要得益于有贊的“組織架構優化”。

            從今年年初開始,有贊的裁員行動就多次引發了行業關注。半年期財報顯示,有贊今年上半年人工開支同比減少3.8%,公司目前的雇員為2633名,對比去年年末來看已經裁掉了1861名。

            不只是人力,財報顯示有贊上半年的交易成本、銷售貨品成本、訂閱客戶服務成本等均有減少,就連研發支出也比去年同期減少了28.14%。同時分季度看,有贊在二季度的銷售開支和行政開支也分別減少了4.33%和8.51%。

            圖源:有贊財報

            降本的同時,有贊也在找新增量。

            其一是私域運營。有贊在這一方向上投入頗多,比如2021年年底戰投了企業微信SCRM服務商小裂變,強調將重點做私域經營一體化解決方案;MENLO 2022 發布會上將“開店營銷解決方案”升級為“私域運營解決方案”,推出基于私域運營場景的人工智能引擎產品有贊Jarvis等等。此次財報中,有贊也強調了私域運營產生的收益有所增長。

            其二是門店業務。此前在發布會上,有贊公開門店商家的GMV約為90億,同比增長約70%。此次財報數據也顯示,今年上半年新增付費商家增長5%,這其中門店Saas的新增付費商家占比達到了50%。存量付費商家同比增長4%,其中訂閱門店Saas產品的商家占比約40%,同比翻倍增長。

            另外,有贊在去年12月宣布與小紅書全面打通,這是繼有贊與微信、快手“分手”后,獲得的又一個值得期待的“合作伙伴”。同時,有贊創始人兼CEO白鴉在今年的MENLO發布會上還特別提到了微信視頻號將會是有贊新的結構性機會。

            在開源節流、降本增效的行動之下,有贊業績略有起色,包括*季度的GMV同比略有增長2%,以及*季度的虧損收窄。不過就整體來看,有贊還很難稱得上是重回增長快車道。

            微盟:

            營收受廣告市場拖累,

            加碼研發虧損擴大

            今年微盟在業務結構上進行了調整,意圖更聚焦于SaaS主業。

            此前微盟的主營業務有兩項:數字商業和數字媒介,其中數字商業包括訂閱解決方案和商家解決方案,數字媒介則主要是為商家提供效果承諾的廣告服務。從今年開始,微盟終止了數字媒介業務,只剩數字商業部分的收入為9.00億元。

            這一收入水平對比去年同期13.83億元的總收入,自然是有明顯下降。僅對比訂閱解決方案和商家解決方案兩項來看,微盟的成績單也不算太好看。

            其中,訂閱解決方案業務在今年上半年收入5.81億元,與去年同期相比略增5.70%。雖然每用戶平均收入相比去年同期增長213元,但付費商家整體增長較少:今年上半年付費商家為103616名,從去年年中到今年年中這一年時間里,付費商家增加1749名,而今年上半年只增加了803名。微盟在財報中稱公司上半年受到疫情影響,獲得這一成績已屬相當不易的“逆勢增長”。

            另一部分業務——商家服務方案則出現了下滑。今年上半年其收入達5.81億元,同比下降22.30%。該業務的付費商家數量為26770名,同比減少2.60%;每用戶平均收入為11899元,同比也減少了20.20%。財報中明確解釋該業務主要包括精準營銷服務和智慧增長解決方案TSO服務,而下滑的主因在于今年上半年商家廣告預算的削減。

            圖源:微盟財報

            盈利方面,今年上半年,微盟毛利潤為5.98億元,同比減少21.36%,毛利率為66.44%,對比去年同期79.22%的毛利率也有明顯減少。在財報中,微盟主要強調是商家服務方案業務拖累了毛利水平。

            此外,微盟不僅是在虧損狀態,其虧損還在擴大。今年上半年,微盟的經營虧損同比擴大285.2%至6.31億元;凈虧損6.09億元,虧損同比擴大9.1%;經調整凈虧損為5.67億元,同比擴大499.2%。

            圖源:微盟財報

            事實上,微盟明顯擴大的虧損不僅是因為營收中有一部分的下滑,同樣也受到了銷售成本增長的影響。

            今年上半年,微盟的銷售成本達到3.02億元,同比增加51.5%。其中占大頭的是無形資產攤銷,財報稱是由于投資研發WOS新商業操作系統并升級SaaS產品所致。對應來看微盟的研發支出確實有明顯提升:在今年上半年研發支出4.69億元,同比增長54.28%,研發支出占收入比也從去年上半年的31.7%提升至52.2%。另外微盟的運營服務成本也有明顯上升,財報解釋是因為針對大客商戶的運營服務增長。

            圖源:微盟財報

            業務增長慢,需要更具優勢的產品提振;而研發新產品、加碼大客戶,又在提升成本,導致虧損擴大。電商SaaS這門“慢生意”的難做之處,在微盟身上體現的*。而在財報中,微盟明確提到加碼大客、提升產品力、加強私域投入等等都是今年下半年要主要投入的方向,這也意味著何時盈利仍是未知數。

            電商SaaS短期難盈利,

            有贊微盟找相似出路

            微盟和有贊同屬電商SaaS賽道,今年微盟在去掉數字媒介業務后,兩家在業務構成上也幾乎完全相同。

            不過對比來看,目前微盟在營收、毛利水平上要比有贊更高,整體付費商家數量也相對更多。

            而當下兩家在盈利上的差異,主要是因為今年上半年的發力點不同:有贊重點在做組織優化,降低了成本和費用,但微盟在產品開發上投入更大。其實整體上,有贊和微盟還都在持續虧損,這也足以證實電商SaaS這個行業在短期內想要盈利還不現實。

            電商SaaS究竟為何如此難賺錢?

            一方面,電商SaaS確實需要持續投入于產品和系統的升級迭代,以及通過投資和收購來更快拓展業務領域形成壁壘,這就需要耗費大量的資金成本,也使得內部虧損問題更為嚴重。

            而另一方面,更嚴峻的問題是國內中小企業普遍付費意愿低、客單價低、留存率低。從目前披露過的數據看,微盟2022上半年SaaS產品的付費商家流失率為12.1%,有贊2021年上半年流失率29.6%,而美國SaaS企業客戶年流失率的中值為7%,對比之下顯然要高出不少。這也就直接導致SaaS服務商要在獲客成本上投入更多,所以賺錢也就更難。

            此外,國內電商SaaS業績在近幾年有明顯波動,這背后不得不提的是“依附巨頭”的問題。

            在海外,Shopify所做的是為中小商家提供建立DTC平臺的SaaS操作系統,而不是幫助商家將其店鋪建在亞馬遜等大平臺上。但在國內,做電商離不開大流量平臺,而平臺之間又互相屏蔽,所以電商SaaS才有了“生意”——即幫助商家去到各個平臺生態內搭建店鋪、獲取流量。在大流量平臺電商業務猛進之時,電商SaaS確實能乘風而起;但大流量平臺業務成熟后會斷開第三方工具自己做閉環,對電商SaaS而言幾乎就是致命打擊。

            比如有贊、微盟都是憑借微信生態起家,但2020年時微信小程序上線了小商店,對兩家都產生極大影響。2018年有贊與快手合作,借助短視頻的紅利再次實現高增長,但很快2021年雙十一斷鏈,對有贊的業績影響至今。如今,有贊和微盟又都對小紅書、視頻號寄予厚望,但很難說他們不會是下一個快手。

            另外,“互聯互通”成為大趨勢,對電商SaaS企業來說也是利空。簡單理解,原本商家是需要在淘寶、微信、小紅書等各個平臺上搭建自己的店鋪,但如果各大平臺之間原本封閉體系打開,用戶一鍵即可跳轉,自然是沒有了重復開店的必要。

            諸多問題擺在面前,電商SaaS都得找出路。

            針對中小商家留存難的問題,微盟和有贊的解決方法都是提升大客戶占比。大客戶發展穩定、抗風險能力強,續費意愿也強,SaaS公司由此能夠獲得的單客投資回報率自然會更高。比如微盟從2020年就確定了“大客化“戰略,有贊雖然此前更多是做中小商家,但2021年建立KA銷售團隊,也有大客化的意圖。

            由于國內始終無法繞開大流量平臺,所以針對依附平臺的問題,電商SaaS目前只能是先避免對單一平臺的高度依賴,以此來降低風險。比如有贊現在已打通了微信公眾號、視頻號、小紅書、QQ、陌陌、映客、愛逛等眾多平臺,微盟也是微信小程序、視頻號、小紅書、快手、支付寶、QQ、百度等多渠道布局。

            與此同時,微盟和有贊也都將視線投向了巨頭還無法控制、更偏向線下的新零售業務。去年有贊將零售業務的品牌名升級為“有贊新零售”,今年上半年其門店業務的增長就成為了為數不多的亮點。微盟的智慧零售收入在今年上半年同比增長了28.9%,已經占到了訂閱解決方案收入的40.7%。

            另外,電商SaaS更多是想要從簡單的“工具”,升級為陪伴式成長的“服務商”,以此來解決工具同質化問題突出、可替代性強,容易被巨頭“降維打擊”的問題。比如今年有贊的MENLO發布會上,白鴉表示要提供覆蓋多個行業、多個場景的全渠道生意解決方案。微盟在今年新推出的智慧增長解決方案TSO強調做全鏈路業務,同時財報中也強調其WOS新商業操作系統未來會上線更多針對不同行業的一體化解決方案。

            電商SaaS遠未到收獲期,但其業務儼然已經走到了深水區。雖然接入新平臺、新渠道仍是不會改變的商業模式,但簡單粗暴“蹭巨頭流量”的玩法早已結束。對電商SaaS來說,構建完善的商業閉環、提升自我造血能力,或許才是走出寒冬、盡快看到盈利的出路。

           

            榜單收錄、高管收錄、融資收錄、活動收錄可發送郵件至news#citmt.cn(把#換成@)。

          相關閱讀

            無相關信息
          极品粉嫩老师自慰网站APp
          <bdo id="2umnn"><optgroup id="2umnn"><dd id="2umnn"></dd></optgroup></bdo>
        1. <option id="2umnn"></option>
          <option id="2umnn"><source id="2umnn"><ruby id="2umnn"></ruby></source></option>

              <div id="2umnn"></div>

                <option id="2umnn"></option>