![]()
13,000人每天用它聊天,卻沒人知道對方是誰,甚至不需要注冊。Chatzyo的開發者用WebRTC做了一件聽起來很矛盾的事——把技術復雜度拉滿,把用戶體驗降到零。
這像什么?像自動售貨機。投幣,拿飲料,走人。沒人讓你填會員表。
大多數聊天應用的第一步是勸退用戶。郵箱驗證、手機號綁定、設置密碼、上傳頭像——還沒開始聊,耐心已經耗光。Chatzyo的開發者算過一筆賬:快速對話場景里,每多一步操作,流失率就跳一次。他的解法干脆利落:砍掉所有步驟,打開網頁直接連。
WebRTC的"作弊"用法
技術選型上,他沒走常規路線。WebRTC(網頁實時通信技術)通常被拿來做視頻通話,他用來搞文字聊天,屬于大材小用。但恰恰是這個"浪費",解決了兩個核心問題。
第一,延遲。消息不經過服務器中轉,瀏覽器之間直接建立點對點連接。第二,隱私。聊天內容不留存,服務器只干一件事——幫雙方找到彼此,然后退場。用開發者的原話:「No media is handled here.」
這套架構有個隱蔽的代價。WebRTC的直連成功率并非100%,防火墻和NAT(網絡地址轉換)會攔路。這時候需要TURN服務器兜底,把流量中繼一下。開發者沒回避這個坑,但也沒讓用戶感知到——連接慢了幾毫秒,總比連不上強。
瀏覽器的兼容性更麻煩。Chrome和Safari對WebRTC的實現細節有差異,Firefox偶爾抽風。他的測試清單很長,但用戶端永遠只看到同一個按鈕:「開始聊天」。
零注冊的流量悖論
沒投廣告,13K+點擊量從谷歌搜索自然流入。這個數據反直覺——匿名工具通常被認為"不好做SEO",因為沒有用戶生成內容,沒有社交鏈條,沒有留存數據可以優化。
他的解法是把內容當產品做。圍繞"匿名聊天""無需注冊"這些搜索意圖,做了大量場景化解答。用戶搜的是"怎么快速找人聊天",不是"Chatzyo是什么"。
這里有個產品經理的冷觀察:復雜系統的營銷成本,往往比簡單系統高一個數量級。你得教育用戶為什么需要這么多功能,而簡單系統的賣點自帶傳播性——"打開就能用"四個字,比任何廣告語都狠。
毫秒級的人心計算
開發者在復盤里提了一個細節:連接延遲對 engagement(用戶參與度)的影響,精確到毫秒級別。這不是抽象結論,是A/B測出來的。多等500毫秒,跳出率明顯上揚。
這個發現解釋了為什么他要死磕WebRTC的直連成功率。每多一次TURN中繼,都是用戶體驗的微小折損。技術債務在這里不是比喻,是字面意義上的債務——以毫秒為單位,復利計息。
平臺至今沒有消息記錄功能。用戶問過很多次,開發者的回應很克制:「No persistence.」 persistence(持久化存儲)是大多數聊天應用的默認設置,他主動放棄。代價是用戶沒法翻舊賬,收益是服務器不碰任何聊天內容——隱私承諾從技術架構層面就鎖死了。
這種設計選擇有代價。有用戶反饋想保存重要對話,開發者沒妥協。產品定位因此更清晰:這不是你的第二個微信,是特定場景下的工具——需要快速、匿名、不留痕跡的對話時,用它。
你現在打開Chatzyo,看到的界面和三年前幾乎一樣。沒有功能膨脹,沒有會員體系,沒有"你可能認識的人"。開發者把"不做"的清單列得比"做"的更長,這在功能競賽的社交賽道里,算是一種反向操作。
WebRTC的瀏覽器支持還在進化,TURN服務器的成本隨著用戶量線性增長。下一個技術決策可能是自建中繼網絡,也可能是探索WebTransport等新協議。但核心原則沒變:用戶不該為技術細節買單。
最后一個數據點:那13K日活里,平均會話時長4分32秒。足夠聊完一件事,不夠建立一段關系——這正是設計意圖。
如果讓你設計一個"反社交"的社交產品,你會先砍掉哪個功能?
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.