算法与运营之间的战争

栏目: 编程工具 · 发布时间: 6年前

内容简介:偷偷的瞄了一把,上次文章的更新是8月3号,现在是12月3号,刚好4个月,再停更下去,这个公号就可以当作死号了。如果说这个时间里很忙,这个是肯定的,但不更新的终究原因还是懒惰使然。再偷偷的看了下后台,发现还是还有不少订阅的朋友,愧疚难当,所以,懒癌得治治了。今天我们要聊的话题是,电商领域里,算法与运营之间的“战争”。

算法与运营之间的战争

文 | 黄崇远

偷偷的瞄了一把,上次文章的更新是8月3号,现在是12月3号,刚好4个月,再停更下去,这个公号就可以当作死号了。如果说这个时间里很忙,这个是肯定的,但不更新的终究原因还是懒惰使然。再偷偷的看了下后台,发现还是还有不少订阅的朋友,愧疚难当,所以,懒癌得治治了。

今天我们要聊的话题是,电商领域里,算法与运营之间的“战争”。

作为一个相对标准的电商公司,双十一刚过去,双十二马上又要来临了。是的,都是忙成狗的大活动日子。

双十一每天甚至是每个小时,不同的活动商品都会带来大量的成交订单,然后对应商品的相关数据也会快速的调整。

对于大运营的同志们来说,进行货架的快速调整,意味着他们需要随时的观测着BI的反馈数据,然后根据丰富的运营经验,进行货架的更新,商品的上下架,顺序的调整,以便带来更大的运营效果。but,商品量过多,货架栏位不少,需要观测的数据又变动过于频繁,这种人肉逻辑如果对于经验丰富的运营来说是具有一定效果的,但妥妥的是会累死人的。

身处大数据部门,本着数据价值输出的原则,想象着反正推荐系统都上了,商品货架为什么不敢接管?基于推荐的底层逻辑,直接就接手了,解决用户特征获取的问题,解决货架访问量并发的问题,沿用推荐分流的基础架构,搭建数据回收的通道,千人千面货架就这么上了。

于是就有了类似的对话。

兄弟,你们这货架 排序 的规则是什么?怎么瞅着排在前头的都是一些冷门的商品,那些大爆品咋都没有排在前头呢?

俺们这是千人千面,根据用户的行为反馈以及兴趣爱好进行个性化的排序,每个人看到的可能都是不一样的。

那你能看下我的账号兴趣爱好是啥不,咋给我排在前头的都不是我喜欢的呢?

...(一脸懵逼)

你看我们运营B的也是,他排在前面的都是什么XX,也都不是他喜欢的东西,感觉是不是有问题。

没问题的,我们底层通过XX算法,计算XX,然后实现的千人千面,每个人看到是不同的。

...(一脸懵逼)

而且我们后台做了分流实验,原来的傻瓜排序(按销量/时间)肯定是差于现在。

但我现在看到就是不是我喜欢的呀,你看,他们几个也是,说明就是排序的不准吗,那些热门的爆品都没有排在前面,感觉就是不准。

一两个人不能代表所有呀,你看这个数据流量回收的数据就知道,这种算法效果肯定是优于之前的那个简单排序的。

但之前的排序,那个爆品我都能看到排在前面,现在的我都翻了好几页都没有找到。

...

其实类似的情景,我相信在推进算法落地的过程中,一定是会发生的,当然,不一定是原原本本的剧本,但是一定意义上的相互不理解一定是会存在的。

因为,两者,或者说两个群体,其思考的方式是完全不一样的。

首先,作为数据或者算法人员,他们一般情况下不会过度的关注个体的具体表现,更多的是数据意识导向,通过整理流量数据的回收数据来衡量其推荐或者排序的有效性,评估的过程中通常会忽略用户的直观感受问题,如果真的有,只会当成一个badcase而已。

而运营不同,在过往的经历中,大多还是依靠电商运营的经验做出判断,所以会下意识的去做经验判断,而过往,优质商品总是能得到他们更多的关注,所以,一旦有体系打破了这个逻辑,会让他们感到很不适应。并且,他们对于效果的判断会更加的直观一些,并且并不能很好的理解底层所谓的XX算法,所以更多会强调为什么他们认为好的品没有呈现出来。

这便是二者的冲突所在,衡量的标准不同,虽然双方都是想要把这个事情做的更好。

还有一个其实是BUG的问题,那就是对于运营人员来说,走个性化的推荐实际上是有问题的,这个点可以给所有做类似的情况的同行做个参考。

那就是运营由于其职责所在,所以必然在商城上的操作和行为都不是其真实的行为,即是工作职责导向,即他需要大量的翻看货架,做一些工作上的行为动作,而特征层如果把他所有的行为当成特征进行处理,那必然意味着他的特征是失真的,如果基于其特征进行个性化的推荐或者排序,那么结论自然不容乐观了。

在解决双方冲突的角度上,首先要做的是加强双方的沟通,算法人员多听取业务人员的经验之谈,尝试可以将业务的一些专家建议融入到模型中去,更重要的是要逐渐的让业务人员接受数据回收进行好坏判断的思维逻辑,如果这个做不到,后续任何调整都将难以进行,最后就是要将算法逻辑以常人更容易理解的方式与业务人员沟通,让他们了解基本的算法逻辑。

还有一个比较好的思路就是,策略层的融入,策略层的价值在于能让业务人员的经验结论落地,但核心点还是需要能够进行流量的分流,可以把专家意见当成一个策略进行流量测试,如果是好的经验,我们就需要不断的融入到模型中去。

所以,算法与运营之间实际上是可以和谐一点共存的,毕竟都是奔着同一个目标去的,算法人员需要把数据回收做到最大化,这是他们的成就所在,而业务人员更希望转化最大化了,这是他们的KPI。

所以,并没有“战争”,而在于多沟通协作,相互借鉴有用的东西,一同推进算法的落地。

在我一直的认知中,数据的核心价值不仅体现在BI的商业智能决策上,更多的是如何提升业务的效率和效果。

所谓效率,那就是如果通过数据和算法解决扩增人头而解决不掉的事,显然,在所有业务规模化的时候,必然需要更多依赖于一些智能或者自动化的系统来替代人做事,而所谓的自动化也好,智能也好,实际上都是数据加算法的价值输出。

而对于效果,就更好理解了,就是转化。就以推荐来说,在我看来,一个牛逼经验丰富的业务人员要干败一个算法是完全说的过去的。

但是需要明确的几个点就是,第一牛逼的人毕竟不可能太多,这是铁律;第二你无法确保牛逼的人不会离职,万一下次换了个蠢蛋来运营怎么办;第三,牛逼的人也有失误错判的时候。

所以,通过数据和算法解决效果转化的问题,实际上追求的是稳定可持续迭代的转化,即算法模型是可以不断的调优的,并且其效果在一定的周期内是相对稳定的。基于这两个点,在业务规模化的时候,就更加需要考虑通过算法来解决掉人那一层效果不够稳定,无法持续稳定迭代的问题。

在规模越来越大的时候,谁的数据算法效率高,谁做的越准,谁就赢了。在未来,数据和算法一定会更加的重要,也是构建壁垒的重要利器。

所以,就算你们现在的算法效果不够好,但是也不要放弃治疗,加油,未来一定是你的!


以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

敏捷软件开发

敏捷软件开发

马丁 / 邓辉、孙鸣 / 人民邮电出版社 / 2008-01-01 / 69.00元

《敏捷软件开发:原则模式和实践(C#版)》不仅是一部深入浅出、生动易懂的面向对象原则与设计模式著作。而且还是一部通俗的敏捷方法导引书和快速实用的LJML教程。通过《敏捷软件开发:原则模式和实践(C#版)》你会发现,许多以前看起来非常枯燥费解的概念,忽然间都豁然开朗。变得鲜活生动起来。 C#版与此前的Java版相比,主要的更新包括加强了UML的介绍章节。使其更加贴近实战;增加了对MVP模式的介......一起来看看 《敏捷软件开发》 这本书的介绍吧!

Base64 编码/解码
Base64 编码/解码

Base64 编码/解码

Markdown 在线编辑器
Markdown 在线编辑器

Markdown 在线编辑器

HSV CMYK 转换工具
HSV CMYK 转换工具

HSV CMYK互换工具