基于websocket的简单广播系统

在年初的时候,我们有点儿小迷茫,于是也跟风去做了一些轻娱乐类的小游戏。
那时为了实战对战,想到需要一个实时性很强的技术实现,于是我去实现了一个websocket server,没想到后来这些小程序没有成,但是我们的这个web socket server 演化得无处不在。下面介绍一下这个技术实现。

看理论肯定会有点拗口是不是,我们直接上代码就得了。我们现在假设有这么一个用户付款的逻辑,在写用户付款事件时,我们事先并不知道以后还需要加什么逻辑,于是我们先把这个行为广播出去。以下是伪代码:

    req := httplib.Post("https://ws.app.12zan.net/eventcast/user/5905e89db43fec42e3055df05ff72afe")
    text, er := zanjson.Encode(order)
    if er != nil {  
        log.Println(ev)
        return
    }
    req.Param("data", string(text))
    resp,_ = req.Response()

好了,现在,每当有用户付款时,这个用户系统都会往/eventcast/user/5905e89db43fec42e3055df05ff72afe这个频道广播一条消息。但是很遗憾,目前没有客户端订阅这类消息,所有的消息都被丢弃了。

有一天,我们英明神武的老板决定要加一个通知,每当有一个新的用户付款时,都给公司的同胞们发一个邮件通知一下,我们获得了新的付费用户,好让大家小开心一把,尤其是第一个试用客户付费的时候,我们肯定都要开心地跳起来。这时我们如果去改线上运行好的付款系统,还是有点儿风险的,一旦有修改,我们就得走一下测试流程,不然万一有问题不是影响公司发财了吗。没关系,我们之前不是已经把付款事件广播出来了吗,我们现在用起来。写这么一段js,线上运行起来,就好了。

const webSocket = require('ws');
let ws = new webSocket("wss://ws.app.12zan.net/eventcast/user/5905e89db43fec42e3055df05ff72afe");
ws.on('open', function open() {
    console.log("connected");
});
ws.on('message', function incoming(data) {
    let user = JSON.parse(data);
    Mail.send("一个叫"+user.name+"的好心人支付了"+user.amount+"元,让主赞美他!");
});

好了,现在一旦有人付款,我们全公司都能收到一个邮件,及时得到这一好消息了。让我们小小地庆祝一下吧。

接下来又过了几天,我们想改进一下体验,用户一旦付款成功,就发送一条短信,告知用户他的有效期和我们的24小时客服电话;只需要这么一段代码部署起来运行就好了, 之前的任何代码都不用动:

const webSocket = require('ws');
let ws = new webSocket("wss://ws.app.12zan.net/eventcast/user/5905e89db43fec42e3055df05ff72afe");
ws.on('open', function open() {
    console.log("connected");
});
ws.on('message', function incoming(data) {
    let user = JSON.parse(data);
    let expiresAt = (zan.Date.now().add("+365 day").format("YYYY-mm-dd"));
    SMS.send(user.Mobile,"尊敬的"+user.name+",您成功购买了十二赞旗舰版,有效期至"+expiresAt+",请登陆:https://www.12zan.cn 查看,如有任何疑问,欢迎致电4006681102");
});

发送通知邮件和发送告知短信,都基于用户付款动作,但是发邮件和发短信的代码完全隔离,相互之间出完全不知道对方的存在。

是不是很赞?那我们接下来梳理一下逻辑。

概念及主要逻辑

也许我们来不及去翻看websocket的定义,但是我们可以简单地理解,Websocket是对HTTP协议的一个扩展升级,在发起连接时,HTTP部分都是有效的,只是连接成功以后,服务端和客户端的连接不断,双方可以双向数据传输,且服务端可以主动向客户端推送数据。

我们看一次Websocket发起连接的过程(来自维基百科):

客户端向服务端发起连接:

GET / HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Host: example.com
Origin: http://example.com
Sec-WebSocket-Key: sN9cRrP/n9NdMgdcy2VJFQ==
Sec-WebSocket-Version: 13

服务端的返回:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: fFBooB7FAkLlXgRSz0BT3v4hq5s=
Sec-WebSocket-Location: ws://example.com/

在HTTP协议中常见的字段,如Cookies,Host等,依然有效。

但是具体到我们的应用上,十二赞的这个websocket server实现了两个小目标【多遗憾了,并没有赚到两个亿】:
1. 我们实现的是一个广播系统,一个广播系统意味着一个地方去发送数据,n多个接受端来接受数据。要支持非常多的客户端同时连上数据来实时接受数据。我们最终的server端的实现,全内存实现,没有用redis或是MySQL类似的数据库,就是为了实现超多客户端的支持。
2. 我们希望采用最简单、最通用的文案,并且,非常高效,支持非常多的客户端同时连接,我们认为http协议更简单,所以在发送的时候,我们是走http协议来发送数据的。并且,没有任何安全上的设计,如果数据很重要,请自行加密之后发送。

当然我们也有一些遗憾:
1. 允许数据丢失。有得必有失,我们允许一个比例的信息丢失。产生数据丢失时,不影响主逻辑。就像刚才的例子,发送邮件通知我们有新付款的这个事件没有触发并没有关系,我们到下午才发现有新用户付款,这时再去开香槟也不迟:(。
2. 容忍时序错乱。像刚才的例子,有新用户付款时,是先告诉我们全体同事有新付款,还是先给用户发送一条短信,并不那么重要。

好了,回到我们的系统,我们给一点点总结。

我们定义,每个websocket的入口,都是一个URL;去掉协议和HOST部分,剩下的PATH部分代表了不同的频道。比如,发起websocket时连接到ws://ws.app.12zan.net/channel/hello,那么这个频道地址就是/channel/hello;所有连接到ws.app.12zan.net/channel/hello的websocket客户端,他们会收到一模一样的消息,我们称之为订阅。

同时,为了简化发起数据的过程,我们还在websocket server中定义:当一个http 的客户端,以POST方式请求某一个地址时,我们截取URL中的PATH部分,得到频道名,并取POST的数据中的data域,作为要广播的数据,将之广播到相应的频道。

在十二赞的应用:

这个广播系统,在十二赞的整个技术架构中,后来应用的特别广。
比如,我们的部署系统zeus,在网页端实现了一个客户端,当服务端有应用重启、关闭、启动时,都会弹出消息通知。任何在打开了这个系统的网页的人都能看到。比如我和同事小王都正在zeus的网页上,我新建了一个search系统的一个节点,启动完毕的时候,我和小王会收到通知,在第三号服务器上新启了一个search系统的节点。我在操作,很关心这个,所心这时我可以放心去继续我的工作。小王正要在三号机器上新部署一个系统,他收到这个通知后,觉得这个机器可能会很忙,于是把自己的新实例部署在了四号机器上。

再比如,我们的日志服务器,担负着收集所有服务器上日志的使命。但是如果它挂掉了呢?于是我们在这个日志服务器上跑了一个定时器,每5秒钟向某个频道广播一条心跳消息,告诉世界自己还活着。然后另行跑了一个进程,收听这个频道的广播,如果连续30秒没有收到这个心跳包,证明这个日志服务器挂掉了,就发一条报警短信,通知同学去看看这个服务。

再比如,我们在日志服务上的应用,参见这里:十二赞日志系统简介

十二赞的商品搜索实现

其实要说很惭愧,虽然我是搜索出身人士,但是十二赞的搜索功能其实在目前是做得非常弱鸡的。不过还是介绍一下这个弱鸡的系统。

十二赞的搜索是基于elasticsearch的。因为业务量较小,所以,到目前为止,还没有用上elasticsearch强大可怕的集群功能。之所以觉得可以拿出来分享一下,是因为这个文案的投入是比较小的,效果尚可接受。

对于在小程序上开店的商家来说,一般商品数不多,很少于超过200的,所以在召加回率和精度上,我们只需要满足召回率就行了。即便搜索结果不够精准,因为商品少,用户一眼扫一下也能找到他想要的商品,搜索只是帮他从原有的上百个商品中把范围缩小到十分之一,就已经很有效了。
另外,也是因为团队小,我们的方案也特别注重精简,能不自己去写代码实现的,就不自己去写代码实现。

好了,上方案。
我们的商品数据是存在MySQL数据库中的,就用的阿里云的RDS。我们运行了一个go-mysql-elasticsearch,这个程序启动时会运行一次mysql_dump,把数据导出进入elasticsearch,然后接下来就会作为MySQL的一个slave,不断地读取MySQL的binlog,同步进elastichsearch。跟我们其他的服务一样,我们把这个elasticsearch和go-mysql-elasticsearch也封装进了一个docker 之中,只对外暴露9200端口来提供服务。

我们之前的ppt介绍过,十二赞的各种内部业务都已经微服务化,这个elasticsearch的服务,也不例外,它工作在es-sec.z.12zan.net:3000上,后端的实例可以有多个es的实例,通过http接口来请求elastichsearch的http接口时,网关 server会自动定向到负载最低的elasticsearch实例来提供服务。

这个方案运行不久,我们就发现一个问题,当我们的MySQL数据库的商品表新增了字段时,所有的后续的数据更新都无法同步的elasticsearch中去了。因为MySQL表的字段比elasticsearch中的字段多了(字段减少啊变更什么的都会导致这个问题)。

谢天谢地,因为Docker化,我们可以轻而易举地解决这个问题。我们的方案,当MySQL的数据表schema变化时,老的elasticsearch实例不变,继续提供服务,但是有缺陷,因为新增的数据没有同步进来;同时,我们新启一个Docker实例,这个实例启动约1分钟之后就同步进来了所有的商品数据,这时是两个elasticsearch的实例都在es-sec.z.12zan.net:3000上对外提供http接口服务,其中一个的数据是老的,一个实例的数据是全的。这时候我们关掉老的Docker上的实例就好了,就实现了索引的切换。用户可能会感受到新商品没有马上在搜索结果里体现,感觉搜索里的商品更新有延迟,但是基本上发现这个延迟的概率很小。

其实,淘宝的搜索的索引切换也有这么一个过程,不过要复杂的多,每天夜里要生成一个全量的索引,切换掉前一天的索引;然后另外有一个实时的搜索引擎,数据全放在内存里,只同步当天的数据变更,对外提供服务的接口将两份数据合并。

十二赞日志收集与报警系统简介

先快速介绍一下十二赞的日志收集系统:十二赞的日志收集系统,分为两块,一块是线上系统的各种报错、异常的日志收集,主要是各种线上代码运行期间产生,我们称之为log-collect,一块是用户行为操作的日志收集,主要是由各个业务系统根据用户的行为来上报,比如用户A访问了xx页面,用户B收藏了某某商品等,我们称之为eventdb。

基于这两块的日志收集,我们实现了一些自己非常自豪的特性。比如,基于log-collect,我们做到了能够主动去发现问题,抢在大多数客户发现异常之前,就把问题处理掉,从而做到不断地提高Saas系统的可用率和稳定性;基于eventdb,我们能做到非常完善的行为收集,将我们的返利模块、分销模块的准确度、实时性大幅度提高。

下面我们介绍一下系统的架构。

从需求上,我们认为log-collect是为了及时发现问题,并马上解决掉。但是这些日志,在我们解决掉问题之后,是不需要再保留这个日志的。比如,举个例子,用户注册的时候,可能输了一个12012345678的号码,这个号码是不对的,导致我们的验证短信发不出去,短信模块就会报错。我们的log-collect会收集到这条报错日志,马上告警。开发同学收到告警通知时,就马上去处理这个问题,用户输入120这个号段时,提示用户该号段是不被支持的,以后就再也不需要处理这个了,因为这条告警日志,我们是不存的,只存档15天就丢弃掉。

但是对于eventdb,我们的目标是为了对这些数据做分析,这些行为一般会跟财务相关,比如用户A通过用户B分享的链接进到了系统,5分钟之后有户A购买了商品付款了200元,2天后用户A退掉了其中的80元。这些数据,会影响到商家给用户B结算cps款项。类似这些数据,我们是永久存储的,不会抛弃。同时,这类数据,我们是要在保证准确性的基础上不断提高实时性的。所以对这类数据,我们有两条线来处理,一条是在线实时,一条是离线的一个小时跑一次数据的。

log-Collect

基于这种差异,我们在架构上也有不同。下面是log-collect的架构图:
https://ylpicture.oss-cn-beijing.aliyuncs.com/201811/48370500.8048.png

我们每一台服务端机器上都有一个live tail,实时监控日志文件,一旦日志文件有新的写入,就立刻发送到http的一个日志网关。这个网关就立刻把这条件日志推送给一个广播服务器,并写入到一个数据库(数据库会清掉7天之前的数据。)这个数据丢给广播服务器了之后,会在特定的频道进行广播。我写了一些客户端,订阅广播,根据日志内容的不同,将日志发给倍洽上不同的告警频道。(关于bearychat/中文名倍洽,大家可以自行去其官网上了解)。手机上装了倍洽,就可以随时接受告警通知了:
https://ylpicture.oss-cn-beijing.aliyuncs.com/201811/82177300.jpeg

eventDB

下图是eventDB的架构图:
https://ylpicture.oss-cn-beijing.aliyuncs.com/201811/87788400.6795.png

与log-collect相同的,收到新的行为事件后,网关也会在一个特定的频道进行广播。不同的有两点,一点是另一条链路先把行为事件写入到阿里云的oss存储起来,然后写了crontab每小时、每天定期从oss文件里导入到eventDB这个数据库;另一点是广播客户端工作的事情也变成了实时写入到eventDB这个数据库。

在事件收集上,也不一样,log-collect是在所有的服务器上部署了LiveTail来从日志文件中读取,而eventDB是需要各个业务系统自己向日志网关来汇报事件的。

存入数据库之后,后续就是再对这些数据进行分析,查找用户的来源渠道,计算佣金等等操作了。

 

由「根据用户手机壳颜色变换APP皮肤主题」说起

转载自公众号:1鸣说。作者:一鸣十二赞产品经理。

前几天的某互联网公司产品经理和程序员打架事件引起热议,据传原因是产品经理提了需求,要求APP程序员可以做到根据用户的手机壳颜色来改变软件主题颜色。这个原因当然是假的,只是用老梗来增加趣味。同时网上了引起了一轮新的讨论,程序员吐槽遇到的「奇葩需求」。

实际上,就这个需求本身,并不是十分荒诞。

我先把结论放在前面:这个过程中,最大的问题是产品经理和程序员之间的沟通不畅。

在这个需求真实存在的情况下,我们可以大致来模拟一下整个需求的流程。

第一步:用户反馈提出,APP的主题颜色太单一了,像QQ有那么多的主题皮肤,希望这款APP也能多弄点好看的皮肤,最好能弄一款和自己手机壳颜色一样的的皮肤就更好了。

第二步:产品经理经过一定范围的用户调研,确认了需求确实存在,有非常多的用户确实希望能够让APP皮肤颜色和自己的手机壳一致。

第三步:产品经理确认了该需求,同时出于为了方便用户的考虑(让用户少操作的角度),提出需求「根据用户手机壳颜色变换APP皮肤主题」

第四步:程序员只关注到需求的前半句,「根据手机壳颜色」,认为自动识别手机壳颜色做不到,直接驳回需求。

第五步:产品经理认为「变更APP皮肤主题」是一件非常容易的事情,两者引发争议。

你能看出问题出在哪里吗?这个问题在绝大多数的互联网公司中经常出现,就是产品经理和开发团队之间的沟通不畅导致的信息不对称。这个需求的核心是,也就是产品需求的最终结果是什么?是「皮肤颜色和手机壳颜色一致」。整个需求流程有两步,第一步:获取手机壳颜色。第二步:将皮肤颜色变更为该颜色。在这个过程中,程序员认为第一步是重点,而实际上,重点是第二步。程序员认为自动识别手机壳颜色做不到,所以一直纠结在这个点。然而第一步的这个过程,换个方式完全不影响整个需求本身。

在传递需求过程中,最忌讳的双方不愿意沟通了。以下是我希望的沟通流程:

产品经理:这里有个需求,是「根据用户手机壳颜色变换APP皮肤主题」。

程序员:我总结这个需求可以分成两步,第一步:我们的APP自动识别手机壳颜色。第二步:将皮肤颜色设置为这个颜色。是吗?

产品经理:是滴。

程序员:这个需求第二步比较容易做到,至于第一步,有点困难……

产品经理:哪里困难?

程序员:自动识别手机壳颜色做不到,这个技术我们不具备。

产品经理:没事,这个是小问题,我们换个方式获取手机壳颜色就好了。

程序员:怎么获取手机壳颜色?这个无论怎么想,都是很困难啊。

产品经理:哈哈,你想复杂了,我们让用户自动输入就好了呀。

程序员:还能这样,我真没想到。

产品经理:所以在第一步获取用户手机壳颜色的环节,最好的方案当然是自动获取啦,这个做不到换个方案,让用户输入也是不错滴。这个需求核心是让皮肤颜色和手机壳颜色一致,至于怎么获取手机壳颜色,这是个小问题,关系不大。

程序员:明白了,那我们怎么做。

产品经理:这个简单,在用户打开APP的时候,让用户输入自己的手机壳颜色,然后确认后自动变换皮肤颜色。

程序员:明白了,这就开始做。

最差的沟通方式就是:

产品经理:这里有个需求,是「根据用户手机壳颜色变换APP皮肤主题」。

程序员:SB,滚粗。

这个问题在知乎上讨论的热火朝天,实际上打错了靶子。一方面是产品经理不够专业,另一方面是程序员关注错了重点,不具备产品思维同时拒绝沟通导致的误解。

一般比较有经验的程序员面对需求时,会问明白,这个需求的「产品目标」是什么?产品目标才是核心,不要纠结于产品经理的提出的怎么实现这个产品目标的过程,这个过程是完全可以协商的,对于产品目标而言是次要的。

这一次讨论就到这里了,晚安。

千人千面,漫谈「个性化推荐

转载自公众号:1鸣说。作者:一鸣十二赞产品经理。

摘要:
个性化推荐功能在资讯类、搜索类以及电商类应用中均有广泛应用,本文简单谈谈笔者对个性化推荐的看法,以及抛砖引玉地提出了一种简单但自认为可能有效的个性化推荐算法。

在上一篇文章中,我讲了社交电商的五个重点环节,本文就五个重点环节中的「导购」环节,谈谈个性化推荐的应用。

我在上一篇文章中已经提到,导购环节指的是买家从进入商城到进入商品详情页的过程,这一过程中最重要的是展现买家最感兴趣的商品并让他点击进入该商品的详情页中,如何展现买家最感兴趣的商品,这就是个性化推荐的使用场景。下面的内容不仅仅针对于电商,这些内容套在其他行业也完全通用。

什么是个性化推荐

个性化推荐,指的是通过一定的算法,向用户展现他感兴趣的内容。准确地讲,个性化推荐更高效的连接了人与信息,降低了人获取信息的成本。

以电商为例,我举一个简单的例子,小明是一个数码爱好者,买了一个CPU,实际上小明是想组装一台新电脑,他接下去要买主板、显卡等配件,系统根据以往的情况,推测了这种情况,同时根据小明的经济水平,向小明推荐了一款中档显卡,小明第二次进入商城,发现首页出现的这款商品刚好是自己考虑买的,然后小明直接查看该商品,下单付款完成整个流程。

实际上,以电商为例,并不能很准确地阐述,因为一个东西即便用户再喜欢,也不可能无限制地去购买。以资讯类应用为例,可能更容易理解。谈到个性化推荐,最有名的莫过于今日头条,通过做更精准的个性化推荐,让这款产品成功地成为了一个时间黑洞。还是以小明为例,新用户小明初次打开该应用,系统是不了解小明的,然后小明用了一段时间这个应用后,系统发现当推送数码类文章给小明的时候,小明的打开率非常高,系统就判定小明喜欢此类文章,后续就会增加此类文章的曝光率。

为什么要做个性化推荐

互联网发展从PC端到移动端,人们的时间越来碎片化,然而同时信息的爆炸式增长,增加了用户获取有价值的信息的难度。如果一款产品不能给用户带来价值,那么被卸载是可以被预料到的结果。

对于资讯类产品,想要增加用户驻留的时间。对于搜索类应用,想要更准确地展现用户搜索的内容。对于电商类应用,想要提升用户的转化率。这些都是客观存在的要求,大数据的诞生,也为个性化推荐提供了生存土壤。

从南到北,从东往西,我们面临的用户实在太多了,每个人的爱好和需求都不同,彼之蜜糖汝之砒霜,A用户特别感兴趣的内容,B用户可能闻所未闻。千人一面展现内容的旧互联网模式已经过去,新互联网模式要求千人千面,只有针对每个不同的用户,展现更精准的内容,才能给其提供价值。

个性化推荐的原理

个性化推荐就是更高效的连接匹配人和信息,这其中就两个因素,「人」和「信息」,用户A和用户B属于人,信息C和信息D属于信息:用户A对信息C感兴趣,用户B和用户A的相似度非常高,那么用户B极有可能也对信息C感兴趣。同时信息C和信息D的相似度非常高,那么用户A和B对信息D感兴趣的可能性也非常高。

其实个性化推荐的基本原理非常简单,就是基于相似度的基础上,这里面所有的东西都是「可能」,都存在概率。即便A和B有99%的相似度,也存在A非常感兴趣的信息,对于B来说非常讨厌的可能。我们做个性化推荐,就基于这个原则,我们认为相似的人,可能有相同的兴趣,如果抛开这个前提,那么个性化推荐就非常难做。

个性化推荐是一个非常依赖数据和算法的功能,离开数据,一切推测都是空中楼阁,离开算法,再多数据也难以派上用场。

一个简单的个性化推荐算法

从上面介绍的原理看出,算法的核心就是相似度的判定,而判定相似度的一个非常简单粗暴的方法就是「贴标签」。虽然每个人都是有血有肉的个体,无论用多少文字,都难以完整地阐释一个特定的人。但是为了这个算法的实现,我们假定两个标签完全一样的人相似度为 100% 。

举个简单的例子,小明的标签是:90后,中产家庭,月入2万,男性,数码爱好者,手机发烧友,狂热果粉。小明在刚出粪叉的时候第一时间买了,然后这时候有个小张,具有和小明同样的标签:90后,中产家庭,月入2万,男性,数码爱好者,手机发烧友,狂热果粉,那么我们系统判定小明和小张的相似度为 100% ,同时认定小张也会在这个时候买粪叉。如果这时候小张进入商城,给他推荐粪叉准没错。

为方便讨论,也为了更严谨地阐述这个算法,我们由定性到定量进行分析。

用数字来表示,用 V (Value) 来表示信息E (Information)(备注:防止大写字母I被误认为1,我用E表示)对用户 U(User)的价值。 其中

V越大表示用户对该条信息越感兴趣。我们假定 V=1=100% 表示用户的该条信息非常该兴趣,转换到资讯类应用就是用户必定会打开该条资讯,转换到电商类应用就是用户必定会买这件商品。上述情况下该件商品对小张的价值可以表述为

算法1.1

以上就是算法1.0版本,事实上,两个用户相似度为100%的情况非常少见,还是用上面这个例子,小明(U1)和小张(U2)每个人都有10个标签,他们前9个标签都完全一致,只有最后一个标签不一样。某个信息E对小明的价值是 1 ,即

那么我们认为 小明和小张的相似度为 90% ,也就是0.9,即

我们计算信息E对小张的价值为

算法1.2

用以上策略考虑相似度基本可行,但是忽略了特定标签的价值的影响。还是用上面的例子,小明和小张的其他所有9个标签完全一致,最后一个标签小明是狂热果粉,而小张是狂热果黑,那么信息E对小张的价值很可能是0而不是0.9,问题出在哪里?我们忽略特定标签对信息价值的影响,实际上我们应该给信息也贴上标签,然后再匹配用户和信息之间的关联度(用D表示)。我们给信息E贴上狂热果粉这个标签,那么小明匹配到这个标签,

小张没有匹配到这个标签,那么

后续算法

由于时间有限(我准备睡觉了(~﹃~)~zZ),先推理到这里,我们下一期再续。使用贴标签的方式,是一种简单粗暴但是有效的判定信息是否有价值的算法,后续我们再讨论以下几种情况(逐级递进):

(1)信息E存在多个标签

(2)用户U1和U2的标签数量不一样多

(3)标签增加权重W(Weight),以及动态变更的算法

(4)多个信息分别有不同标签,分别对用户的价值

(5)信息的标签增加权重,以及动态变更

最终达到的效果是,用户U和信息E的标签以及权重是会随着他的操作动态变更的,最后根据一个公式计算E对U的价值:

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

作者:欧阳

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

为什么电商平台都酷爱做活动?

问:每到618或双11各类电商平台早早地就开始造势做活动,很好奇这背后除了卖货外还有其他的意义吗?

答:

1 从用户来说,你不做活动,他家做活动,我就去他家买了。既然这样,到最后所有平台都会做活动。

2 打折其实是本性。商家希望打折来促进销量。但是不希望无缘无故打折,你得给商家一个借口打折。虽然打折,商家其实还是赚钱的。

3. 一些技术要求或是运营要求高的团队,是需要拿活动来锻炼和校验团队的。你说你技术好?搞个双十一试试。你说你运营牛卖货牛?搞个活动看看你能卖多少货。你能说资源广人脉好在行业里谁都熟?搞个活动,看看多少多少卖家买你的帐报你的活动。

5. 不搞活动,怎么发数据搞PR?你不见每年双十一,媒体都乐于跟风报道淘宝天猫京东又卖了多少货,多长时间破亿,谁家店是最早破亿?

4 难道一个卖货的平台,不就是应该追求卖货吗?还需要追求卖货之外的其他意义?

腾讯的电商发展是否可以依托小程序?

提问的标题是问电商是否可以依托小程序,正文却是新零售。。。。

如果是问新零售的话,我认为完全可以,可以有9成把握。

如果是问电商的话,我认为,就只有5成把握了。

新零售,更多是零售场景的一个变化。比如,我们在给一些酒店做的业务场景是,在房间的床头放一个小程序码,客人扫码付款,可以订购一些日常用品(比如安全套。。。掩面),也可以点一些酒店食堂的餐食,甚至是预订到机场的送机服务等等。但是这一块,对社交的依赖不是那么强,说微信小程序有机会,其实支付宝小程序也有机会呀。

但是电商的话,需要解决的事情很多,本质是是如何高效率地获取大量的流量并高效地变现。作为电商平台来讲,要解决的事情非常多,运营需要做的事情也特别多,小程序解决了一些点,但是还远远不够。小程序重在方便快捷、打通了支付、方便分享。但是电商的流量怎么来?在线客服咨询系统怎么做的?售后怎么办?物流信息怎么做的?太多需要解决的点了。举个例子,在我们平台开店的很多商家都遇到过这样一种情况,客人通过小程序下单后,填写的地址不清楚,手机号码是错的,这个时候,卖家居然没有任何办法能联系到客户,给客户留个言。淘宝上好歹还能旺旺给客人发个消息。。。

别看现在牛,我做小程序也被封无数回!和鉴锋细聊掉坑往事

转载自公众号:见实;作者:常丹 。

说起玩裂变,不得不提鉴锋,就是做“网易戏精课”、“三联生活周刊”等知识付费课程,刷爆朋友圈的那支团队。当他们从4月份开始决定all in小程序之后,也有许多被封的经历。

这些代表着他们尝试的很多个方向。如:

1.搞笑短视频类(点开欣赏);2.电商类(趣拍卖);3.步数商城类(运动步数换购商场);4.答题类(宝藏地图);5.测试类(运营王者);6.匿名社交聊天类(收信箱);7.名片类(零一人脉链);8.积分墙(程序试玩中心);等等更多。在鉴锋的理解中,积分墙类小程序最容易被封掉。

他给自己设置的战术是:灵感之下快速搞测试,探测小程序边界。快速试错是他不同于其他团队的地方:一个产品背后放大器足够大,机会的缺口才会快别人一步得知。

其实,见实团队和鉴锋陆续深聊了多次,最近更是长达近5个小时。这次话题内容极其丰富,由于篇幅受限,见实将内容一分为二,一个方向是他做过那些小程序被封的经历,另一个方向则在数日后发布。

走和见实一起,听听鉴锋他自从all in小程序后,被封的故事。

 

先从我们决定all in小程序开始说:

刚创业时,我们是给知识付费行业的公司(如网易云课堂、知乎、三联生活周刊)提供微信生态中的“群裂变”、“公众号裂变”、“朋友圈裂变”等等增长业务。陆续出了“网易戏精课”、“三联生活周刊”爆款后,这个行业基本上有钱能合作的客户都合作了。当时我们在思考公司的下一个业务增长点在哪里,恰好3月份小游戏的开放,小程序赛道被资本热潮推到最顶点,于是我们开始研究“小程序”这个载体能否有新的裂变玩法。

但我是不懂产品、不懂技术的,于是决定先找外包做做看,当时基于我自身的痛点出发,想到2个灵感:一是“公众号互推信息”的智能匹配名片(零一人脉链),一是“拍卖时间”的工具(趣拍卖)。趣拍卖是最快做出来的,当时自己画原型,设计师出图,找了2名兼职技术帮忙开发(7天上线,成本8000块),趣拍卖小程序的玩法很简单,就2个选项:“拍卖你的时间、拍卖你的晚餐”,因为其娱乐性,结果一下子就火了。

趣拍卖小程序,主要是针对互联网新媒体人群做的,因为“拍卖晚餐”这个比较有趣的“巴菲特”玩法,我们下午五点半才开始让几个KOL朋友发朋友圈测试,产品本身好玩,而且不是广告,它不low,大家更愿意去转发,当时新鲜感很强;也顺势影响到了投资圈的朋友进来玩“拍卖晚餐”。这种类型的产品形态,适合高势能打低势能。加上晚上8-10点是朋友圈的打开高峰期,很快就在小圈子里形成刷屏效应,逐步传播开了。

但马上就“乐极生悲”:由于外包的技术也是第一次开发小程序,小程序菊花码没有用参数,而是直接调用小程序不可再生的十万个固定二维码(详见小程序技术文档)。夜里9点的时候十万个二维码就被领完,后进来用户就生成的“拍卖海报”没有二维码了,整个裂变就终止了。只有4个小时,超百万人次访问,新增30万用户。我们赶紧又发了个版本补上这个功能,但是补上之后已经第二天上午。由于这个产品也在很多腾讯人的朋友圈传开了,朋友圈的二维码功能到中午被封掉。

这种营销型产品,只能火一波。后来微信新规针对拍卖类小程序制定了政策,需要补齐拍卖证才能行,同时拍卖证又很难搞定,必须找相关政府资源才能申请,这个产品就没再继续推了。

像名片类小程序也有尝试过,被封了。也去做区块链小程序相关的裂变:当时做的场景是,区块链智能匹配的概念,推区块链小程序是在五月份,都没有看到其他团队开发这个品类。

其实我们本想着是打“第一个区块链”小程序的噱头,结果没想到“小协议”小程序先推了。一两天我们也开始推“零一人脉链”小程序,推了一小时,只有两万多人访问的时候,整个小程序就被封掉,不只是二维码被封,是整个小程序封禁。因为区块链属于没有开放的类目,被封之后就再没更新。

其实趣拍卖和零一人脉链,都是同时找外包公司去试水,我也不知道哪个方向能成,就是把心里面的几个灵感做出来试一试。

我的理解当中,小程序其实雏形跟H5的思路和玩法,没有太大的差别和变化。就是我觉得还是用自己擅长在微信生态做裂变这一优势试试看,同时我也知道什么样的内容,或者什么样的产品形态用户更愿意分享。像拍卖晚餐这种产品,打的是用户的炫耀心理,用户想约朋友吃饭,但是又不想显得自己太孤独寂寞冷。

这个场景之下就会存在需求,用户发起一个拍卖我的晚餐活动,转到朋友圈,谁跟我一起来吃晚餐。很有意思的事情,用户背后的洞察也很微妙:发起活动的用户,越多人拍卖他,越能证明自己有影响力。好玩儿的同时又能满足他的虚荣心,猎奇感又强。

做裂变以来,经验告诉我:必须擅长抓住用户的需求点,才能够推动用户去分享、晒更多。那,我为什么能抓住这些?全都是平时刷朋友圈刷来的,我个人也比较喜欢过了十二点之后刷朋友圈,因为越到晚上大家就越空虚寂寞冷,这时候大家发的朋友圈就越真实,越代表自己。

心理学也有验证这些——人为什么到了晚上会更真实?随着天黑环境变暗,人的体内的激素分泌会变化,会让人的情绪属于比较低的状态,和白天状态完全不同。

平时刷朋友圈也是为捕捉用户的共性,哪些共性大家都在发生,哪些更能够打动他们,他们抒发的感情更多的是什么?又有哪些话题的内容,是寻找朋友认同感的?等等这些,都是触发我灵感的种子,及时用便签记录下来,成为素材库。我做产品的思路就是这么去搞,“快速验证”。

做的第三个的小程序产品是积分墙形态:“程序试玩中心”,用户只需要点一个小程序,停留体验20秒,可以赚五分钱;如果他发展朋友来玩,拉进来的用户赚五分钱,他还可以得四分钱;然后他的朋友再发展新用户进来玩,他还可得三分钱,他的朋友得四分钱。这种强诱导分享,速度很猛,当时也就一天时间,跑了近一百万用户

当时,因为想快速多尝试一些玩法,好积累经验,也就会踩一些红线做测试,所以这个小程序,设计了四级分销。

“程序试玩中心”小程序,当时是在微商的群体引爆,微商体系本身都是多级分销,他们也都特别熟悉玩法,多级分销就是满足了他们贪婪的欲望。为什么很多人会被云集卖代理的模式影响,也正是因为这个欲望。我们之前做电商分销,最多也是引入两级分销,也是卖的这个“欲望”。在行业内,大家都流行所谓“卡位”的概念。

(卡位:假如你先转发了,就算自己的能力不行,但如果影响到一些大V,那后面你就是躺着也可以赚钱。因为每个人都有躺着赚钱的贪婪幻想,所以项目一上线会尽其所能抢先推广。)

再说说,“程序试玩中心”小程序我们是怎样玩的测试?

我找了几位圈内的朋友,谈好大家分摊流量,因为我们自己没有这么多的小程序给用户点击,于是拉拢几个团队的小程序放在里面。那,为什么能够裂变这么快呢?

从用户端,用户攒够三毛钱就可以提现,刚开始也只是上了五个产品,就算用户玩出花,也只能得到两毛五。那么,用户想要提现的话,就必须分享给更多人来玩,才能凑够三毛钱,从而有权限提现。

积分墙这个玩法,当时就是利用微商人群去做的测试,它是违规的。我们也做好了被封的打算。这个产品也是很快做出来,一周不到。因为分销体系,之前做H5的时候已有很成熟的方案。当时现金流支出15万,让每一个合作的团队,都均摊到几十万用户。

也做了像答题类的小程序,宝藏地图小程序。用户答题得钱,当时我们也只是从自己群做的冷启动,这个产品有意思的地方是,它不是一夜爆红的,测试了两周,每一天的数据都比上一天高。为什么?

 

原因是我们做了三个功能,因为是开宝箱答题的玩法,基于用户的地理位置,初始值是给用户十个箱子,让他去开,如果他还想多开几个,必须召唤好友助力,帮自己扩大探测距离(初始值增大为十五)。

其次是宝箱出现时间是十分钟更新1个,邀请好友助力可以缩减更新时间,找一个朋友就会缩短一分钟,找两个朋友就会缩短二分钟,依此类推;就是这两个功能给产品带来了超级多的转发。

第三个是用户答错题目,就会提示他,分享给你的朋友,让你的朋友来帮你答,答对双方都得钱。当时,只设定几分钱,设置小数点后面的四位数,基本上是零点零零,然后三三,五五这样子。

这两个功能都没被封,后来我们自己贪心不足又多了一个功能:用户没有箱子开了,可以转发小程序到微信群,马上就可以得十个箱子,结果这个页面被别人截图举报了,于是整个转发功能都被限制。

数据掉的很惨,后来又新上了一个新产品,一模一样,只是改了名字,也没有去用那个违规的转发功能。如图是宝藏地图小程序(答题裂变玩法的思维导图)

我做产品的方法是:先把市面上该类型的所有小程序、APP、H5都体验一遍,把里面的亮点功能拆解记录成为自己的素材库,然后再根据自己对产品的理解,1.0版本只有核心功能+裂变玩法、快速上线验证功产品是否具备竞争力(开发周期控制在7天左右,如果超期则砍需求),产品具备自裂变获客能力活下来了,2.0往后的每个版本才会同时更新裂变玩法+留存玩法。

也是不断摸索,转发缩短时间是可以的,但是转发立即就得一个东西就是违规。微信的很多规则都是这样,只是定了大概,随着我们不断地测试,官方觉得太粗暴,最后就会把这个东西的规则写进去,明文规定不让做。

像配图转发出来的配图,最开始的时候效率最高的是什么呢?放在微信群里红包的图片截图放进去,这个点击率就会最高。后来规则里面就写明白了,就是完全不允许,配图不允许模仿微信UI,模仿就会被封掉。

后来又去做步数类小程序,叫运动步数换购商场。首页的一个签到红包的裂变玩法,累计给我们带来了一百多万用户:用户点签到领红包,开了一个之后,按钮提示“还可以再开四个”,用户点再开四个就会显示:只有转发给好友,好友领取红包后,他才可以立即领取,如果不想转发,就必须等好几个小时才能领取。

这里需要重点注意的是:如果你不把“不转发等几个小时也能开红包”这个标记上,那就变成了强制分享,就一定会被封。后来很多朋友问我们,包括我们的客户也问,哪个功能点好,我们就会推荐这个开红包的套路。

我们还摸索了很多模板消息也被封。因为要召回用户,运动步数换购商场小程序的七日活跃留存,现在都还可以做到50%以上,甚至60%。这款小程序8月份上线,两个月用户做到三百多万。因为有利益在,这里有意思的点是说,模板我们经常被封,上个星期模板消息又被封了,封到10月28号。

新增留存本来就比较难提升,没被封之前次日新增留存在25%左右,模板消息被封之后,立马就变成了12%。

被封之后,我甚至还去小程序社区里面去问,diss官方,我说我们小程序创业团队本身就很艰难,做各种各样的尝试,好不容易把留存做的这么高,现在这样一搞我的留存掉一半,我说这样玩下去,让我们很受伤啊。结果管理员回复:本来按照规则,封了4次以上就要永久封禁了,正是因为鼓励创新,所以你被封第六次了还只是封你半个月。

我们真是摸索了各种不同类型的模板,也都被封,测试期间我们会对比,什么样子的模板召回率最高呢?我们当时召回40%左右。其实我也问过微信那边的朋友,说没人举报他们也不会管,但只要有人举报就一定会处理。所以,这是让我们最蛋疼的。

呵呵,业内的人也是很有趣。“我问了一些举报别人的人,他说我就是举报一下,看一下你们会不会被封,不会被封我也这么干。”结果就导致我们经常被封,就很坑爹。你想啊,普通的用户肯定不会去想举报你一下子玩玩,肯定不会啊,提醒用户有钱取肯定很开心。而且我们都是冒着巨大的风险,提示用户让他来提现。

还有就是,比如一些进度通知,签到通知都不让做。之前这些并没有写进规则,现在微信都已经写到规则里去。如果你的产品不是打卡类的小程序,或订阅内容的小程序,都不允许推签到提醒,订阅提醒的模板消息(如果产品量级不大,做了只要没人举报就不会被封),官方也是不断地在完善自己的漏洞。

所以,我们真是费尽苦心,测试了好多,后来由于小程序服务通知太受限制,我们就想尽办法把流量导出来。比如提现必须得关注服务号,验证成功了才能够提现,还有就是关注公众号给你送步数,进群等等方法,这个小程序的七日留存才能做到60%。

小程序的服务通知很容易被封,但是服务号的模板消息它比较不容易被封。因为背后“举报的阈值”不一样,小程序举报人数不多就很容易被封。但随着服务号粉丝基数大了之后,举报的人数肯定会上升,所以,我们服务号也是注册了四五个,每个服务号粉丝控制在30万(我们测试的30万以上的粉丝,全量推模板消息容易被封),现在已经导到第三个号,粉丝也导出来快70万。召回用户效果就会很好,同时群里面我们也会及时推群,去触达用户。

 

我们一直在做微信生态的用户裂变,在我看来微信生态里面的流量其实就是四大流量池:个人号,微信群,服务号,小程序,其实很多人都没这个意识,都只是做其中一个。像我很多做步数类小程序的朋友,他们问我,怎么死活只能做到30%的留存,甚至好几个产品只做到20%的留存,问我,我们是如何做到50%以上的?

其实,他们只考虑做小程序,并没有考虑还可以做其它流量池矩阵。在我眼里小程序只是其中的一个载体而已。

这四个流量池各有优劣,比如个人号适合小企业冷启动做老带新、通过朋友圈建立人设、做付费转化率,具备高粘性高转化的特征。社群适合中型企业在个人号的基础上做:一方面可以做小规模裂变,另一方面可以把付费率在提升10%以上;而服务号则是拥有中心化裂变流量,再通过模板消息分配流量的能力。

但由于公众号生态已经趋于成熟:目前做服务号裂变一天涨粉3万就很容易违规,所以必须拥有矩阵,现在微信在扶持小程序,小程序一天裂变1百万的流量都不会被封禁,然后导流给其它流量池。充份利用各自的优点,以多点去触达用户,让用户和产品形成一个高频的印象。

意思是什么呢?不要只做小程序,做小程序很容易被封,我们也没办法,被封就很惨。

话说回来,为什么我们坚持短平快去做各种测试?你不去试怎么知道规则边界在哪里?你的裂变效率之所以能够比别人高,肯定是因为你是最接近规则边界的(甚至很多时候一开始是越界的),你掌握了别人不知道的高效率的方法。

总结下来,其实最不能碰的有两个方面:一个是多级分销,一个是转发送什么东西。但是要弄一个时间限制,其实转发就送什么东西,只不过是说两者的结合,判断上面会宽容一点而已。

继续说我们做产品的思路,一是凭感觉,去感觉产品的设计能不能打动用户,或者说设定的一些卡位环节能否驱动用户,让用户按照我设计路径去完成转发。第二个则是所有的产品一定要亲自去体验,其实这也是一种感觉。

趣拍卖小程序,完全靠灵感,可遇而不可求。但是如果你想稳定地保证裂变的效率,靠红包。像trytry小程序的送面膜的传播就极其简单,trytry和我们也有合作,我们小程序给trytry导流了非常多的面膜用户,帮忙优化裂变路径,上周trytry小程序已突破一千万用户。

微信很多时候也是看类目,有一些类目微信它的容忍度就会高。像很多线下场景式的裂变,如果是给线下商家进行裂变,容忍度就会更高一些。比如电商的场景容忍度就会相比其它就会高,同样是积分式的,让用户点小程序就给用户送钱,这个其实是属于破坏微信生态的行为。所以,纯线上的玩法微信官方就会判定:你是做了打扰用户的事情。

 

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

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

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

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

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

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

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

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

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

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

  配置流程  

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

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

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

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

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

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

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

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

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