又开车了到站啦

去年的这个时候,发布了最近的一个创造-又开车了。简单讲,这是一个汽车评测视频聚合订阅工具,当UP主更新视频的时候,通过微信公众号向你推送更新通知。可以理解为这是一个以微信公众号作为主动推送通道的RSS聚合订阅工具。

这是一个完全个人兴趣推动的side project. 没有设定止损的基线,也没有盈利的目标。而现在来总结这个项目,源于几天前,微信提醒认证续费。结论很简单,不想续费了,准备关闭这个项目。当然,我承认有本能的反感这种“很微信”的恶心做法。项目层面本身的情况也是时候做一个总结和了断了。

因为只在早期在自己的微信车友群做过推广,因此可以认为没有什么运营结果,也谈不上亮眼的运营数据。用户量级较低,且很多都是友情订阅,没有什么值得分析的数据。在吸引早期用户和提高用户活跃上,个人的有限经验可以总结为:找到合适的池子捞鱼,舍得花本钱搞活动抽奖。

这是否是一个伪需求?即使抛开被推荐算法信息流淹没的时代背景,主动整理和聚合自己的订阅早在Google关闭RSS订阅产品Google Reader就说明这是一个非主流的产品。但这不是一个伪需求的产品。从用户视角看,信息的消费是有成本的,成本由小达到依次是:推荐,推送,订阅,搜索。而这个产品的初衷其实就是希望将订阅的消费成本拉低到解决推送的消费成本。从这点看,需求是客观存在的,产品逻辑也是自恰的。

这是一个商业闭环合格的产品吗?我这里说的商业闭环不等于账面盈利,而是整个商业逻辑闭环是否能够持续有效运转。从这个标准看,显然不是。账面上,零星有用户友情打赏,但是肯定是不够服务器以及微信的认证税开销。但是产品的定位是非常垂直的汽车评测领域。而这个领域但凡是稍微有点观察和思考,都能发现者这是一个车厂主动补贴评测博主(特指国内)的市场。你看到的绝大部分汽车评测都是评测博主拿了车厂的俸禄后的“软文”,行业也叫做“恰饭”。这里两个关键词我都加了引号,只是“客观中立”的陈述这样一个行业事实😂。因此,作为一个该领域的聚合订阅工具,面对的又是C端用户,其实就是联合这些评测博主提高软文的分发效率。我的盈利模式是来自于整车厂吗?我没有足够多用户的前提下,基本是不用想了。虽然汽车评测的门槛看起来和做起来非常低,但是跪舔的姿势不是每个人都愿意学并且学得会的。我的盈利模式是基于订阅用户做增值吗?很难。普通用户买车一般两个渠道,4S店和汽车经销商,如果不是强运营,很难通过一个订阅工具影响用户的购买行为,从中赚取“介绍费”。汽车后市场电商导购有一定的潜力,从过去一年搞过的一些活动及带货量看:

  1. 尽量避免比较长尾保养三滤系列,内容生产成本较高,且很难持续。
  2. 中国车主用户的心智基本还是被4S店洗脑的状态,DIY水平普遍很菜、很差,普遍抠门。因此不要被“改装”相对较大的喊声欺骗,当前阶段,如果你没有线下实体店,不要跟4S店抢生意。两个案例可以参考:老司机和大家car里面的机油销量。
  3. 因此,车型无关的车用品是个不错的选择。从数据看,我自己做过的最好的一个带货案例也是落在这个品类。而且在没有推广的情况下,都是自然流量转换为下单购买。进一步的,可以尝试与车用品厂家联名推出1~2款爆款的商品。很遗憾,自己没有时间来尝试这个想法了。

现在要关闭这个项目有遗憾吗?坦率讲,真没有。作为一个just for fun的side project, 其实非常感谢这个项目,尤其是做这个项目的过程。过去的一年家里发生了许多事,五味杂陈。但是,做这个项目的编码和运营过程可以将这些事情串起来:还记得跟媳妇、女儿回老家,动车上和酒店里写下的许多代码片段,有时候不禁在代码的注释里写下编写这段代码的此情此景;还记得在去年那趟一直魂不守舍的江西之行,一路上的焦虑、无奈、失落,但是却在那个时候写完了项目的最后几行代码,合上电脑的那一刻,内心变得平和;还记项目正式发布的那个特殊时间,有些人离开了,但是这个项目在我意料之外的时间上线了。感谢做这个project的过程,让我有了很多难忘而深刻的回忆和体验。

这个项目真的就这样关闭了吗?是的。但是,这个方向并不是一个错误的方向。近期看到即刻回归,还是挺为他们感到高兴的。而基于这个项目所沉淀的思考、技术底座将被我应用到另外一个项目,希望以后可以再次总结和复盘该项目。而这个期限是多久呢?也许又是一年,管它呢,just for fun!

2019年终总结

这是最后一个2019的周末,感慨有一年即将结束。

这应该是回成都以后,主观感受过去最快的一年。细细想来,似乎又没有什么特殊。坐在凳子上坐立不安的自己总归还是想不怀好意的看看过去,看看这未来十年最不景气的一年有什么东西能带给不那么糟糕的下一年。

最大的成长应该是开始学会在不确定中系统的思考出确定性的方案,开始要求自己深度思考。我以前挺反感这种方式,总觉得是一些自诩为具有思考能力的一小撮人比较作的方式。但是现实给了我深刻和沉重的教育。其实很多观点在没有深入思考之前,无论你对他的客观判断和主观喜好是怎样,其实一点都不重要,因为那都是基于你选择性阅读的随机掷色子罢了。时刻提醒自己从这种随机中走出来,剔除不确定性,逐步缩小和锁定确定性的范围。这其实远不是什么高明的做事方式,也许只是自己以前低头做事太久,突然抬头看天的时候,发现天空这时也挺美。

最大的不甘是今年在技术上没有尝试和探索太多有意思有趣的场景。工作的角色有了些许的变化,至今依然有些事必躬亲的事情放不下,但是重点主次在特定时间投入上还是要拿捏清楚的。但也有回头看感到温暖的代码,这段代码不多,甚至基本都是在业务碎片时间完成的,但是里面的注释我看到了6月份在达州酒店逗女儿跳舞,也看到了6月在江西三清山那个极度不安中又有不屈的自拍,当然还有婆婆去世时候,留在代码注释中的哀思。特定时期的代码有时候会在不经意间成为程序员的日记,不仅仅告诉机器如何工作,也记录自己如何成为更好的自己。

最大的遗憾应该是婆婆离开了。我至今很难接受这个事实。婆婆确诊是在今年2月14日,三姐跟我电话说了情况以后,直接去了华西,回来的路上在车里哭的稀里哗啦,那是我到目前为止唯一一次后悔没给车贴深色防爆膜。婆婆7月9日离开,7月14日下葬。上个月还去看了她,并且给了我一次好运气,我……就是没法接受。

最不知如何总结的是老家拆迁的事。亲身经历了以租代征下的各种荒唐事。但也因此很对上以前很多不熟悉的邻居真正相互认识。其实生活中有很多类似的事情从身边经过,很多时候我们只是需要多一点耐心,以及十年以后回首往事的心性。

最有意思的出游是带妞儿和女儿去了趟海螺沟。转眼8年过去了,在雪山当年跟妞儿两个人拍比心的位置拍了一个全家福。时间真是一个神奇东西。

今年想去做的几件事情都没有拿到满意的结果。倒是以前延续过来的事情不但带来了收益,也在有时候心烦意乱的时候如同一道道希望之光,让一切都变得没有那么不堪。感谢时间!

明年的压力会很现实,其实这也是一种幸运。因为并不是所有的事情都有耐心等你漫不经心准备好的时候给你递上台阶。既然已经看到前面是道坎,不如主动迎上去使劲向上爬。

2020年,有几个希冀特别希望自己能够以平和的心态实现。惟愿,感恩时间,希望至美!

时序异常数据检测从理论到落地

最近在解决一个挺有意思的问题,该问题可以抽象简化为:如何检测外部依赖接口发生异常。如果是在中小公司,那么这个问题其实是不需要解决的,从研发层面规范接口的格式,并规定依赖接口必须达到要求的可用性,只要调用成功率低于规范就进行告警。不幸的是,这个方法在当前的BU中是推不动的,是为背景。

简单的对接口调用失败量对齐时间轴看了一下,这是一个典型的时序数据异常检测问题。

从分类看,当前发展阶段的时序异常检测算法和模型可以分为一下几类:

  • 统计模型:优点是复杂度低,计算速度快,泛化能力强悍。因为没有训练过程,即使没有前期的数据积累,也可以快速的投入生产使用。缺点是准确率一般。但是这个其实是看场景的,并且也有简单的方法来提高业务层面的准确率。这个后面会提到。
  • 机器学习模型:鲁棒性较好,准确率较高。需要训练模型,泛化能力一般。
  • 深度学习模型:普遍需要喂大量的数据,计算复杂度高。整体看,准确性高,尤其是近段时间,强化学习的引入,进一步巩固其准确性方面的领先优势。

而我们希望在9月份就能够上线运行,并且没有历史数据,更不要提打标数据了。因此,只能选择统计模型作为一期落地的方案。而在统计模型中,twitter 在2015年发布的 AnomalyDetection 自然是翘楚。如果你正好使用 R 语言,那么直接上手就可以用。如果你需要 pure python 版本,推荐使用 Twitter’s Anomaly Detection in Pure Python.

S-H-ESD 原理

twitter 公开的异常检测算法的核心是使用了S-H-ESD异常检测算法。这种算法的思想是将时序数据使用 STL 分解,然后将分解的余项使用 Grubbs’ Test 进行异常点的检测(实际使用的算法考虑了极值异常点对整体的影响,实际使用的是的Grubbs’ Test变形)。关于算法的细节可以参看 twitter 发布的论文 Automatic Anomaly Detection in the Cloud Via Statistical Learning. 显然,这个算法之所以有效的两个关键就是 STL 和 Grubbs’ Test。

STL 将时序数据分解为 趋势 + 周期 + 余项:

直观上,可以将趋势项理解为时序数据的骨骼;周期数据是数据的振幅;余项是则是消除趋势和周期数据后,相对平滑稳定的“皮毛”。而这种皮毛数据是符合 Grubbs’ Test 假设中正常数据正态分布的。反之,则被 Grubbs’ Test 认为是异常数据。

因此,S-H-ESD 只适用于周期性数据。对于无周期性或数据变化特别剧烈的时序数据,S-H-ESD都不是好的选择。

S-H-ESD 用于生产环境

S-H-ESD 原理简单,理论效果也非常不错,基本起手能达到 40% ~ 60% 的准确率。但是实际应用中经常会遇到以下典型的误报情况:

而这种误报其实很难从算法本身消除,即使消除了其实也没有泛化性。一种简单的思路是引入更多数据和规则:

  • 上图中我们只是用的接口的报错量作为时序数据,单村在报错量上提高准确性在统计模型这个大前提下边际成本已经很高了。因此,可以考虑引入接口调用量和成功率来综合判断该点是否真正异常。
  • 结合实际业务,设定一些简单的规则减少误报量。对于我们的场景,可以设定的规则有报错量的基础阈值、报错点的持续时长等。

S-H-ESD 不是银弹,结合多维数据和业务规则以后,准确率基本达到了我们的预期。S-H-ESD 也不是终点,确切说是我们顺便解决当前问题,同时收集异常数据的手段。未来,我们会尝试结合深度学习模型提高异常检测点上的准确性,同时融合多维数据,将点上的异常检测逐步整合为线和面上的检测能力。

扩展阅读