2021-02-13 关于用户分析的基本技术

今天终于喝到了咖啡,感谢当年埃塞尔比亚人的贡献,感谢巴西咖啡研究所在1930年跟雀巢公司的深度合作,感谢麦尔维尔的小说(不敢在技术文章里提及这么商业化品牌的名字,说到这就知道了)。
所有的系统,最重要的环节就是用户(特指用户的信息,从分类到分层,从定义到画像);用户就是我们最大价值化的资产,了解用户的过程,是一个利用连接载体不断试错的过程,你的链接载体的可触达性越好,对用户就越不构成骚扰,得到的结果就可以更好的帮助你去做真正意义的用户画像。
-第一:别指望用户画像一蹴而就(虽然用户就是静态属性和动态属性)
-第二:别在自己的想象中作用户分层和用户画像(先问问自己是否有相应的领域模型支撑你作用户分层)


今年非常有设计感的包包,个人很喜欢

用户分层:是用在最粗俗的眼光将用户分成三六九等,就是为了降低运营成本,进而用最经济的方式提升转化(当然如果你有的是钱,也可以不做这件事);而用户画像:是用最精准的方式找到用户的个性所在,然后利用产品力/有效的产品组织及产品特性去刺激用户的购买欲望。想想为什么小红书,花西子,完美日记,元气森林,包括拼多多都能做出这么的用户,道理太简单了,因为人们有欲望,又不愿意任何品类的购买都在淘宝/京东上完成,恰逢这些平台都各自构建了垂直领域中最能和消费者同频的产品力,于是流量就这么来了,需求就被创造出来了。(话说回来,下一波带货的能否集中在某些固定品类上,更专业,更垂直;当然这些跟我一毛钱关系没有)用户分层,RFM足够了,你一下子能找到你高UP值的用户,你可以把他们定位为你的KOC,他们也许不能成为你要的KOL,但确实是你重点运营的客户。怎么做,就两步(定义你的RFM值域,把所有的客户数据都filter一遍),当然,怎么定义取值范围,相当关键,这跟你的产品定价的中位数有关,而且如果你的产品是季节性的,或者围绕着营销活动进行波动,一定请你们自己的运营负责人帮你定这个值。

import org.apache.spark.rdd.RDD
import org.apache.spark.{SparkConf, SparkContext}
import org.apache.spark.sql.SQLContext

//Sales class map to sales table, which indicates users' historical purchasing records
case class Sales(cu_id: Int, price: Int, date: String, days_ago: Int)
case class RFM(cu_id: Int, r: Int, f: Int, m: Int)

object RFMOnSparkSQL {
  def main(args: Array[String]) {
    val conf = new SparkConf().setAppName("SQLOnSpark").setMaster("local")
    val sc = new SparkContext(conf)
    val sqlContext = new SQLContext(sc)

    // this is used to implicitly convert an RDD to a DataFrame.
    import sqlContext.implicits._

    //register table sales
    sc.textFile("/test/sales.csv").map(_.split(" "))
      .map(s => Sales(s(0).trim.toInt, s(1).trim.toInt, s(2), s(3).trim.toInt))
      .toDF().registerTempTable("sales")

    //register table rfm
    val rfm = sqlContext.sql("SELECT cu_id as cuid,min(days_ago) as r, count(price) as f,sum(price) as m FROM sales" +
      " group By cu_id").map(t => RFM(t(0).toString.toInt, t(1).toString.toInt, t(2).toString.toInt, t(3)
      .toString.toInt)).toDF()
    rfm.registerTempTable("rfm")

    //avgr avgf avgm
    val vls:Map[String,Double] = sqlContext.sql("select avg(r) as avgr,avg(f) as avgf,avg(m) as avgm from rfm ")
      .map(_.getValuesMap[Double](List("avgr", "avgf", "avgm"))).collect()(0)

    //sparksql udf:flag()
    sqlContext.udf.register("flag", (r: Int) => if(r>=vls("avgr")) "1" else "0")

    //show cu_id flag
    val vfmwithflag=sqlContext.sql("select cu_id as cuid,flag(r) as flagr,flag(f) as flagf,flag(m) as flagm " +
      "from rfm")
    vfmwithflag.show()  
        sc.stop()
  }
}

用户分层的值就这么来了。那么用户画像呢,在哪里。

网络上关于用户画像

用户画像基本内容

看上去用户画像就是打标签的过程,你的应用/营销触点是否充足,是否能有效跟用户产生交互,直接决定了你的用户画像带来的价值。
针对用户画像,一定要做到数据的统一,正确,及时。所谓的统一,就是大家的数据统计口径,数据字典的完备;所谓正确,不要因为人为的对生产数据库进行修改导致脏数据留存(系统可能不正确,但在生产数据库上作改动更不正确,当然有几个做技术的能回避这一点呢,业务领导告诉你,我现在统计个数据都不对,你改还是不改呢?这是个管理和机制问题,跟技术没有本质性关系,当初设计系统的时候,为啥技术团队不关注业务实践,业务需求为啥总是我要,我要,我还要....所以,真正的技术债,不是你对日后业务变化的不可预知性,进行错误的技术架构选型,是思想上的摸着石头过河)。关于标签体系的构建,我个人觉得HBase,Hive都可以胜任,就像前文讨论ALS的过程中,只要数据正确,有效,就能够满足业务上的需要。即使是用户的标签体系的构建,也是要进行分类的,并且WOE的过程会为这些分类属性提供不同的权重(建议参考 https://www.cnblogs.com/fengyouheng/p/11048386.html)当然,针对数据存储选型上,如果非要说个区别,我还是感觉,Hive是个数据仓库,还屏蔽MapReduce的操作,降低了编程的复杂度;HBase是个数据库,借助LSM树,屏蔽了对HDFS的操作,降低了部署及应用的复杂度。
LSM Tree

别着急说HBase因为太多随机读IO降低了性能,总得全表扫描,你要是有这么多猜测型场景,就去优化它(公司不好,你就去改变它;领导不好,你就加速成长,你来当领导;产品不好,你就自己构建个产品力强的产品;实在不行还能换工作不是么)看看你的Scan Cache设置的是否合理,你的JVM CMS的GC是否合适,你的BlockCache,BucketCache等等。当然,每次都有团队的伙伴问起来为什么不直接用Kudu(估计就是觉得技术栈老,虽然老,但是稳定有价值呀,跟我对自己的评价一致)。我也承认Kudu的确有优势所在,比如在Table下,提出了Tablet这样的概念(就是Segment,来源于Linux的文件管理方式,针对分布式文件有天生的优势,也是HTAP的一个很好的选择);HBase的确就是在HDFS基础上构建的(RegionServer->region->store-> memstore & storefile 底层是hfile)我个人的感觉还是因为团队的可接受程度,用了Kudu,因为不直接支持SQL,还要引入Impala,而且不支持跨行的ACID事务,且引入的越多运维复杂度就会越高。毕竟我们的团队还没有到大家有充足的时间把玩代码的程度。到此,基本的工具和数据我们都有了,给大家推荐篇文章,专门说怎么用的(https://new.qq.com/rain/a/20201204a01iuh00)因为一旦用户的标签体系和用户画像构建起来,下面要做的就是针对性的营销和用户运营。数据分析是过程,运营是我们永远的终极目标。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 194,457评论 5 459
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 81,837评论 2 371
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 141,696评论 0 319
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,183评论 1 263
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,057评论 4 355
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,105评论 1 272
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,520评论 3 381
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,211评论 0 253
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,482评论 1 290
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,574评论 2 309
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,353评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,213评论 3 312
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,576评论 3 298
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,897评论 0 17
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,174评论 1 250
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,489评论 2 341
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,683评论 2 335

推荐阅读更多精彩内容