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秒。足够聊完一件事，不够建立一段关系——这正是设计意图。
如果让你设计一个"反社交"的社交产品，你会先砍掉哪个功能？
热门跟贴