当然,我们是社区团购第一!月流水早已过亿

本文转载自公众号见实

现在如火如荼的社区团购大战,最早起自长沙,最火时一度达到200多家。到现在,一个小区内有7、8个创业团队在拼抢都很常见。这股热潮最终卷入资本,不完全统计,仅今年11月就至少有5家团购宣告完成新融资,金额全部在千万美元级别,有的甚至过亿。

如果资本不是问题,那么竞争的核心会在哪里?或者说,左右胜局的关键点会在哪里?这些社区拼团团队会像过去的“千团大战”那样,最后只剩下美团一家独大吗?

这些问题都在不断撩拨着我们的好奇。其实还有更多好玩的问题,比如,为什么所有的社区团购都以水果切入?

正好,见实约到“你我您”联合创始人刘振洋深聊——这个团队也是发源于长沙,今天在社区拼团这个市场中是必然提及的对象之一。早在2011年,“你我您”早期团队就开始在QQ群卖水果,2017年3月,年净利润达到1000万,目前已在全国布局20多个城市,1万多个小区,月销售额过亿,其中单月突破1000万的城市就有5个。他认为,“你我您”是行业第一。

刘振洋之前就职腾讯、京东,并在腾讯系投资机构微光创投投过每日优鲜、每日一淘、有好东西等。因此,我们的话题侧重在社区团购下一步跃升空间,及真正的核心壁垒是什么?刘振洋认为,伴随着资本的入场加持,明年行业会有一个大洗牌。这意味着,对核心壁垒理解越透,未来成就的空间越大。

那么,他们是怎么看待这个市场的?

如下,Enjoy:

图:你我您联合创始人 刘振洋

社区团购为什么是今天爆发

从2011年开始,“你我您”就围绕水果直采在QQ群、天涯论坛、微博等等渠道做团购,直到2016年才正式确立了现在社区团购的运作模式。

后来很多同行开始借鉴我们的模式,坦白说这个行业的进入门槛比较低,几十个群加上一批供应链资源,就可能区域性地把小区服务做的非常好。这也是为什么长沙曾经有200多家社区团购公司,全国最多。

 

社区团购的集中爆发我觉得有几个原因。

 

首先,集团化的管理解决了最后一公里的成本,中间所有可能去掉的成本都去掉了,没有店租,没有太多人工,整个商业模型的成本结构允许低毛利和高性价比的商品进入,同时高周转的形式也帮助社区团购在水果生鲜品类上可以很快做大做强。

 

第二,小程序的出现,确实进一步推动了社区团购的进程。

 

之前因为没有系统支撑,每天推送的商品比较少,只有一两款,多了很难做到信息有效处理。而且团长也需要花大量时间解答用户各种各样的问题,经常要24小时维护群。

 

小程序带来了标准高效的解决方式,可以承载商品信息、下单购买、物流进展包括售后体验等等功能。团长从大量的基础工作中释放,花更多精力维护客群,推荐商品,最终为规模化奠定了基础。

 

第三,优秀的团队开始全国性拓展,资本的涌入也助推了赛道的成长。

 

这里面小程序只是其中一个基础设施的技术因素,还有很多其它的宏观因素。

 

可能从有小区开始,就有了在小区做团购这件事。比如某个业主刚好有一批家乡特产,在小区群里招呼团购,大家也都知道一起买东西会便宜。只不过以前社区团购的路径过于分散,过于非标准。每个人能够接触的供应链非常有限,能够支撑的服务也非常有限,所以一直是一个小而分散的市场。

 

随着你我您和其他同行一起发现了社区团购的流量价值之后,大家开始小规模集约化的管理,分散的市场出现了整合的机会。所以从宏观上来讲有一个发展的历程,从分散到小规模集约化,再到资本进入出现全国性的整合机会。

 

再往深度想,以生鲜为例,最近几年农业种植的标准化一直在提升,干线物流、储存方式、相关配套基础设施也非常成熟,供应链响应速度提升了好几倍。同时配合消费升级,大家也希望买到一些高品质、差异化的好水果。几个因素叠加,让生鲜在全国范围内得以高效率、高周转的调配,最终出现一个明显的爆发。

 

社区团购真正的门槛在哪

社区团购行业准入门槛低,核心壁垒在于规模化之后的管理运作。

 

首先,如果是一个或者几个城市,供应链的组织方式是点到点,从基地直接运到城市仓库,相对比较简单。规模化之后,全国可能有几万、几十万个小区,这时候就近采购和跨区域调拨的逻辑变得非常复杂,需要强大的供应链搭建和管理调配能力。

 

第二,城市密度足够高了,不同模式之间的效率也会不一样。小区少单量不大,无论怎么配送时间都可以保障。但如果有上千个小区,每个点位都有几百单,分检和配送的难度就非常大。

 

第三,规模起来后供货商越来越多,货端管理要求也会越来越难。如果一天卖1吨水果,用人检的方式就能解决品控,但今天有10吨、100吨的水果要在你的渠道销售,怎么做好品控是一个很难逾越的障碍。

 

第四,在团长端,每个人都是非标准化。全国有几十万个团长需要管理,不可能完全通过人力手段搭建好。

 

所有这些门槛都非常关键。

 

无论是区域性的还是全国性的对手,很多时候都是自己做死的。比如商品出现假货或者严重次品,就可能导致一个企业瞬间坍塌。

 

所以我们一直很关注后端的投入,供应链、品控体系、仓储物流,包括对团长的管理培训方式也在不断升级,如果把问题放在最后的交货环节解决,出现的问题就会非常大,而且规模越大,问题就会越多。

 

保证商品品质和平台服务的稳定,这样用户长时间跟你我您建立起来的购买关系,可以进而形成很强的信任和依赖,这才是真正安身立命的一点。

 

所以这几年我们每天都是如履薄冰,细心做好每一个细节,细节就是竞争力。甚至,水果采购已经分散在全国各个生产基地的源头,我们能知道每个月份什么水果更好卖,哪一个基地哪一片果园甚至哪一棵树的果子最好。采摘和抽检都有严格标准。

 

而且为了能够最短时间内把商品从基地送到用户手上,我们会提前开卖。货品还在途中,商品已经开卖,这样既可以保证时效,也可以规避我们自己想冲订单对品质上的影响。

 

即便售卖出去的产品,只要用户觉得不满意想退货,我们随时给他退掉,保证用户售后不会出现任何障碍。对一些品牌性的商品或者标品,我们甚至打出假一赔十的承诺。

社区团购的跃升空间

跃升空间包括横向市场、纵向产品两个维度。开拓新市场最大的挑战,在于不同省份的用户购买习惯会有较大差异。

 

比如广东吃东西喜好清淡,而在成都、重庆、长沙可能是另外一种商品纬度,所以口味本身就有很明显的差异。

 

不同区域用户的可支配收入也不太一样,沿海消费升级比较明显,主要是高单价高品质的商品。西北、西南经济相对欠发达,商品就要多打折。就连品牌偏好,不同的省份也有非常大差异,同样是纸巾,广东用维达,四川就喜欢别的。

 

所以,覆盖跨省份市场,既要有标准化的流程支撑,又要同时具备本地团队的本地化运作能力,只有这样才能真正把一个市场打下来。

 

具体到一个小区时,我们是和团长共同去开拓用户,毕竟团长在小区里认识的人有限,不能保证一定把群拉满。小区根本上还是一种弱社交,大家并没有真正熟到彼此都有微信。

 

一般我们会先发传单、发信息,吸引有意向团长。再邀请大家到公司试吃试用,快速了解商品服务,让大家尽放心签约。

 

签约之后,我们会配合团长举办试吃试用的小型活动,做引流物料,在小区里做传播和裂变。一般1个群到100个人才会开团,之后团长会有一个考核,三个月之内销售额要达到一个量级,否则会被新团长替换。

 

所以,我们是公司控群,群不是团长私有的。团长跟用户建立关系,提高用户的购买转化,这是肯定的。但对用户而言,他真正的需求是买到高性价比、高品质的商品,关心自己的购买体验,这才是最核心的因素。

 

团长其实也会纠结这个群是由谁来建,但归根结底还是收入的考量。所以我们在运转过程中,非常关心团长层级的利益价值,尽可能标准化、流程化支撑他,让他的生意变得简单。

 

社区团购本质上是一个流量生意,以前聚焦卖水果,是因为水果是一个高频、收益足够高、试错成本非常低的品类。通过水果,可以低成本让用户完成首单,培育大家的长期购买行为和信任,这时候再扩张品类就会更顺理成章。

 

现在你我您的用户以女性为主,30岁到49岁占到60%,宝妈群体居多,用户复购率非常高。行业水平大概一个老用户月购买频次不低于6次,新用户半个月1、2次,像你我您新用户大约是3次,老用户是9次。

 

从长远来看,社区团购未来的可持续性和响应速度非常大。无论是货架式的品类还是虚拟服务类的商品都可以有很好的转化。比如我们曾经1个小时卖出100万金额的体检卡。同样教育类、家政服务、空调、抽油烟机清洗服务等产品的转化率也非常高。

 

所以只要把流量获取和管理的能力建立,后续什么都可以做。但早期在战略选择上一定是即兴的,先从水果切入,逐渐做商超场景品类扩张,再到百货公司和线上电商场景,逐渐覆盖全部需求。

 

明年会大洗牌 

有些团长已经开始自发线下建门店,我们负责输出统一的装修标准,目前有100多家,马上官方也要开几个更标准的样板店。

 

团长带着客流开店,所以从开店第一天,他就有足够的收入把握,这样开店的动力非常强。基于销售预期,未来可能逐渐演变出自己囤货卖货的模式。

 

实体店反向做线上团购的逻辑本质上和我们不同。他首先需要把店开到周边区域,把区域的渗透率做起来。但传统零售有一个最大的问题,就是门店需要相应的服务落地,涉及选址、装修、请人,开门店的效率没有纯线上的方式快。

反向做线上团购可能在核心城市比较强,但从全国来看没有哪家公司能覆盖这么大的市场,做不到每个区县都有自己的门店,这个负重太重。

 

另外传统零售其实存在一个左右手互搏的矛盾,因为实体店的价格体系相对固定,如果社区团购的价格比本地还低,这个店就开不下去。

 

到家业务虽然会降低库存,提高单店周转率和流量渗透率,但并不会降低成本,因为到家业务及时性强,人工成本费用会很大。而二三四线城市用户的时间成本非常低,所以在下沉市场打“快”这个点,不一定能真的切中要害。

其实我们有很多机会可以跟传统零售合作,比如说切割生鲜猪肉常常因人而异,需要和行业里优秀的人员合作,把他的商品和服务嫁接到你我您 的程序上,再通过我们落地服务。

 

未来的竞争态势应该是一个两极分化的格局,短期看,又会出现两三个寡头,同时在当地又存在一些小团队运作。寡头规模越来越大,会把小团队慢慢收编。

现在,整个行业布局的人已经很多了,资本也在不断涌入站队,我觉得今年都加持好之后,明年会有一个明显洗牌。

运维厨房创始人兼CEO覃健翔先生来访十二赞

作者:欧阳

2018年10月19日,运维厨房创始人兼CEO覃健翔先生来访十二赞,和十二赞CEO黄滚就技术问题做了深入探讨。覃健翔,曾任阿里巴巴搜索技术专家,香江集团电商总经理,2015年创立运维厨房。

十二赞,成立于2017年12月,由上市公司北京酷炫投资。创始人黄滚曾为阿里巴巴搜索技术专家,在阿里巴巴工作了七年。

两位同为前阿里巴巴的搜索领域专家,在一起交流后,又将会撞出什么样的火花呢?

运维厨房CEO覃健翔和十二赞CEO黄滚探讨技术

覃健翔,很多对于互联网行业不熟悉的人,也许没有听过这个名字;但相信很多人都知道苹果应用商店。而覃健祥先生就是立志要把运维厨房打造成:一款属于中国IT运维界的苹果应用商店!

而且目前已经和途牛、大华股份、浙江智啪、二维火等一线的运维界团队有了密切的合作。

而这位运维领域的开拓者,这次选择了十二赞作为技术交流对象,不但是看中了十二赞拥有独有的行业优势,更是看中了十二赞团队不断挑战自我,把一个个看似不可思议的目标,转为现实的精神!

2017年12月至2018年3月,十二赞打造了多款轰动业界的小程序,其中娱乐休闲小程序“寻找像素眼”被知名媒体爱范儿报导,不少玩家在网上写出多篇破解攻略。

从2018年4月开始,十二赞开始全力打造电商零售小程序。今年中秋前夕,十二赞深度合作伙伴一坐一忘丽江主题餐厅上线,月饼上线当日即出现供不应求的场面。

目前十二赞已有电商零售、餐饮点餐、美业丽人、酒店零售等多场景小程序SaaS工具,全力提高商家获客效率。

在获得一系列成功后,十二赞创始人黄滚先生没有满足现状,曾直言:“十二赞的存在,就是要让更多的客户得到最优质的服务。”

为了实现这个承诺,开始在市场上开放免费试用功能,让所有客户都能体验到最新技术成果的同时,获得了大量的客户好评。

凭借着这支年轻优秀的团队,十二赞团队可以最快速的了解到年轻市场的传播风向,以最契合的市场的角度,及时的调整小程序的功能,实现一直走在行业前端的目标。

在本次技术交流中,运维CEO覃健祥先生,也进一步肯定了十二赞团队以客户为先的公司文化。

在十二赞中,始终坚持着“客户第一、拥抱变化、团队协作、激情敬业、诚实守信”为最高准则。

我们需要机会,我们更懂得不断积蓄力量,把握一切机会,客户的要求就是我们需要承载的使命,以为最高的执行力助力达成。

小程序关注公众号组件安排上了!吸粉拉新走起!

最近微信小程序又放大招啦

宣布:小程序新增公众号关注组件

十二赞的程序猿们也按捺不住内心的兴奋了

立马夜以继日为大家开发出来了呢

“一码两用”,体验与留存并存

在以往的情况下,用户在小程序里是不支持识别二维码的。如果用户需要关注公众号,一般要跳转到小程序客服,在里面回复相应的关键词才能获取公众号二维码识别关注,路径多,用户流失严重。

现在这个问题得到解决了,用户扫码进入小程序后,直接在小程序里即可触发公众号关注按钮,一键关注公众号。实现“一码两用”,体验小程序的同时也能让这些用户留存下来了,提高了用户的留存率。

线下复购率将得到提升
      提升了用户留存率,也就意味着用户的复购率也将进一步得到提升。例如餐饮行业,虽然小程序扫码点餐的体验很美好,但真的是“用完即走”。

现在小程序支持关注公众号了,用户扫码点餐的同时也关注了公众号。商家随时可以以公众号消息的形式给顾客推送活动信息,将吸引这批用户再次消费,提升了线下复购率。

  配置流程  

第一步:公众号平台关联小程序
(1)登录【服务号】点击左侧快捷导航栏中的【小程序管理】

在点击【添加】点击【绑定小程序】即可

ps:设置的服务号需要与小程序主体一致。

如已绑定对应的【小程序】跳过此步,继续操作第二步

第二步:开启公众号关注组件

(1)登录【公众号小程序后台】点击【设置】选择【接口设置】 
点击【关注公众号组件】选择【对应的服务号】即可
Tips
配置好了的小程序店铺

只有用户扫描小程序菊花码进入

(直接进入是无法显示的呢)

方可查看到关注公众号小程序的组件。

Golang 在十二赞的深度应用

作者为黄滚,十二赞小程序开店平台创始人。2007年至2016年在阿里巴巴任职,曾担任中国雅虎平台技术主管、淘宝搜索研发专家。

我们是“十二赞”,一个致力于帮助电商卖家进入小程序的小团队,我们的主页是http://www.12zan.cn/。在实际运行中,我们使用了大量由golang写就的小工具,几乎每一个工具代码量都超短,一般在200行左右就完成了一个独立的功能,同时担当了相当重要的角色;像代理服务器,代码量一共500行多一点点,却是我们的核心支柱,压测时QPS也直追nginx,表现优异。

基于Docker的基础结构

做为基础架构,我介绍一下我们的机器架构。
我们的整个业务构建于阿里云之上,有5台server,每一对都有独立的外网IP,同时也在同一个内网之中。在每一台机器上都跑了一个我们自己用golang写的守护进程,这个进程负责监听一些业务重启、新增域名等类似的指令并执行(这些指令最后都传递给了docker)。同时,每台机器上都有一个consul进程,这些consul都join到了一起。另外,我们每一台机器上,都用docker跑了一个nginx来做80端口的服务,同时跑了一个用golang自己写的HTTP代理。nginx做做日志啊基础的功能之后就把请求丢给这个http代理 ,HTTP代理会到consul里去查应该将请求转发到哪个IP的哪个端口上。

400行Golang代码写的HTTP Proxy

在架构选型的第一天,我们就决定,我们会服务化,会大量使用http 接口来提供服务,并使用自己的http proxy来分发请求、添加自有的一些业务逻辑比如API的权限验证等逻辑。我们限定,所有业务,域名都是*.app.12zan.net,比如我们要上一个聊天服务,请求的接口就会是chat.app.12zan.net,哪天再上个评论服务,请求的接口就是comment.app.12zan.net。
确定域名后我第一件事情,就是拿golang自己写了一个非常简单的基于consul的http proxy server;感谢Golang这完善的HTTP库,我们只用了几百行代码就完成了所有功能。每当有http请求过来时,这个proxy server就会根据HTTP请求中HTTP_HOST 字段去consul去查,有哪些后端是用这个域名名称来注册服务的,并根据指定的算法,取出一台后端来,把这个HTTP请求Proxy过去。每个具体的业务,可能运行在我们5台机器中的任何一台之中的docker上,也可能是多个docker实例上。所以这里有一个机制,选择哪个实际的docker实例来服务这个请求的问题。我们现在支持随机选取、按客户端IP地址做hash之后选取、按URL做Hash选取、按负载选取几种方式。

WEB服务的服务注册

基于php+laralel和nodejs+koajs两种场景,我们制作了自己的docker镜像。这个镜像除开可以将php+nginx和nodejs构建的web服务运行起来之外,还包含一个golang写的consul客户端。在docker容器里,这个客户端随着php+nginx或是nodejs的web服务一起启动,启动之后会向宿主机的consul 进程注册自己这个服务,注册的时候会通知说,某某应用,在某某IP某某端口提供服务啦,如果前面有到**.app.12zan.net的请求你可以转发给我;同时会每隔一秒上报自己的进程数、当前机器CPU占用、内存占用情况。也是一样的简单,几百行golang代码,就鼓捣出了这个consul客户端。为什么使用golang呢?第一个原因当然是因为consul天生是golang阵营,第二个,是因为我们的docker容器种类较多,所以这个客户端直接就是在Mac上跨平台编译出来的在linux64平台上运行的,不管docker容器是python为基准的还是ruby为基准的,还是nodejs的,只要把这个二进制文件拷贝进去就能正确运行,不像别的语言需要解决依赖问题。

我们还开发了一个web console界面,在这里,我们可以注册app,也可以为app新增实例。注册app时,我们要指定代码仓库的地址(对了,我们的代码管理是用的golang写的gogs),指定对外服务的域名,指定是nodejs应用还是php+laravel应用。添加应用之后,可以在这个应用下新建实例,让系统在指定的IP上去跑这个实例。实例运行的过程实际就是下发一个通知到某个机器上,去执行一个docker实例启动的过程。docker启动的时候带了一些环境变量,比如当前内网IP、docker监听的端口、对外提供服务时是用何域名提供服务。

日志和存储

前面这种架构有一个问题,就是后端可能是在任何一台机器上运行的,今天可能是A,明天可能是B,那我要是把文件存在A上了是不是让B来提供服务的时候就挂掉了?所以我们想了这么一个办法(也是因为穷。。。。),我们把所有的文件都挪到阿里云的OSS服务上。同时为了不管是Nodejs应用还是php应用 还是python写的应用都能做到把用户上传的文件或是系统生成的文件存到oss上面,我们很省事地写了一个ossUploader,编译好的可执行文件发布,只需要执行它,传进来本地路径和oss上的目标路径,就保证给你上传到oss上去就完整,不需要再在nodejs、php、python、ruby、java各种平台下都琢磨一遍oss的SDK。

对日志的处理是一样的, 所有的日志文件的内容,都会被一个golang写的工具gtail监听着(就像linux 的tail -f命令一样),所有新产生的内容都会被gtail挪到oss上去存储。当然,也是可执行文件发布的。

这个实现之后, 我们的实际业务就真正可以在5台机器上之间任意腾挪了。

消息广播

得益于golang的一些开源仓库,我们还做了一些好玩的东西。
比如,看到https://github.com/gorilla/websocket这个东东,我们忍不住撸了一个websocket server,或是说叫群聊服务器更好一点。
接下来,我们看到有一个golang的库叫go-mysql-elasticsearch,伪装了一个mysql的slave,去MySQL的master机器上去读binlog,读到binlog以后就将MySQL里的数据发送给ElasticSearch去索引数据。
我们就结合了一个,把这两个结合起来,修改了一下go-mysql-elastichsearch,让它监听到MySQL的数据变更之后,在WebSocket server的某个群聊里推送出来,形成一个数据变更的广播。
再接下来我们就可以用nodejs写一个应用,连上这个websocket server,加入特定的某个群聊,就源源不断地收听到数据变更的消息。这个nodejs端的代码就非常简洁了,只需要不到100行代码可以做各种好玩的事情,比如监听到用户留言表有新增,可以发邮件让运营马上去审核。还有比如说,每当订单表有成交的时候,我们某个小小的nodejs应用因为监听了数据库消息,第一时间就知道了,马上就去追溯用户来源,来计算返利;同时这个nodejs的代码更新是和订单主逻辑完全不相关的,写这个业务的开发人员只需要知道订单表的结构,不需要了解订单应用后台代码。