白加黑

js的优化写法

2023-02-10T14:49:20.000Z

记录下js的几种优秀写法

// 多条件判断的精简写法 
const options ['si','xue','tang'];
if (options.includes(value)){
  return ;
}

// 如果条件不满足，则直接返回
function handleFun(event)
  if (!event || !event.target){
    return
  }
}

1 2	// es6新增语法，可以避免null值无属性的报错 const value reponse?.data?.text // 链式运算符，无则返回undefined

1 2	// 取数组最后一位 const value = arr.at(-1)

// 判断赋值，如果foo为 null/undefined/0/false等用||，如果foo为null/undefined用??
// 具体见：https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Operators/Nullish_coalescing
const value = foo || bat
const value = foo ?? bat

1 2	// 三目运算符赋值 const value = a ? b : c

1 2	// 数组去重 const value = (arr)=> [... new Set(arr)]

1
2
3

//去除数组空项
let arr=[1,2,,4,5];
arr.flat(arr)

const a = 3;
const c = null

// a||c,输出第一个不为Falsy的值
// falsy有false、0、-0、0n、""、null、undefined 和 NaN
console.log(a || c);
// Expected output: 3

// a&&c,输出第一个不为Truthy的值
// 除 false、0、-0、0n、""、null、undefined 和 NaN 以外的皆为Truthy
console.log(a && c);
// Expected output: null

流量归因模型

2021-11-27T16:00:00.000Z

流量的归因存在多种模型，比如首次归因、末次归因、平均归因、马尔科夫链流量归因等等，在电商场景下对流量的归因主要应用于流量入口归因，以及具体页面的转化归因，主要解决的问题是以下两个：

首屏放置了多个不同板块的流量入口，需要评估具体的流量效率，哪个入口的流量转化率最高
整个app上有非常多的页面，每个页面都会涉及到流量的转化，那每个页面的转化率如何计算

对于归因而言，可以只在考虑当前状态的基础上考虑归因，如下图的几种归因方式，但是在营销领域，存在流量作弊的情况，所以就应运而生了马尔科夫链流量归因这种从全局角度出发进行归因的方案，这里做一个详细的拆解。

未完待续

web界面设计

2021-06-21T16:00:00.000Z

依据《用户体验的要素》这本书对产品设计层级的划分，框架层和界面层对应的就是我们所理解的产品界面设计。

一直在找一本书，能够把所有的界面设计全部纳入其中，也就是《用户体验的要素》中的框架层和界面层，比如导航布局，交互方式，错误提醒，表格展示等等的设计逻辑？
《简约至上》，《点石成金》算是这种类型的书，但是有没有更细粒度的拆分，比如按钮，为什么用这个按钮，表格，如何展示表格数据等原则依然是一头雾水，《web界面设计》算是一本书，但是过于枯燥，例子也太古老。直到我看到了Ant Design和AntV的设计文档，立即觉得这就是我要找的。所以，这里对二者的文档结合书籍进行拆解，整理为自己需要的设计系统。

由于涉及的内容过多，所以单独做了个文档网站。

文档地址点这里

埋点的spm和scm模型

2021-04-23T16:00:00.000Z

spm和scm是埋点中定义传入参数的一种模型，其本质还是埋点的属性通过一定的规范进行传输，只是一种传参模式。那么如何搭建SPM方案呢？以及如何更有效的体现其业务价值呢？

从百度统计上看到有很多人访问了我这篇文章，说明还是有一定数量的人在关注这块儿，以前写的过于随意，所以就更新了下。

updated 2021-11-03
updated 2021-12-04

背景

首先引入一个问题，如何用一句话描述app的所有内容？简单来说，就是用户+物品+事件的集合体，这也是神策分析底层的数据模型，user+item+event模型，这里的事件指的就是用户的行为，我们对事件的追踪也叫用户行为采集，就是我们常说的埋点，那么如何描述用户的行为？4w1h的逻辑

具体来讲，what代表的是event，where代表位置，在app的初始阶段，我们可能只需要关注到页面粒度，即event发生在某个page，但是随着业务的发展以及对精细化分析能力的要求，where的关注粒度可能需要进一步下沉，在app上，体现的就是不仅仅要知道event发生的page，还要细化到改page下具体的楼层和具体的点位，也就是具体的评估指标从页面级精细化到楼层和坑位级别，这也是我们引入spm这一套方案的目的。

在查阅spm资料的过程中，发现阿里推出过一款数据产品Quick Analytics Plus（现已改名Quick Tracking），这款产品的文档里有对应的埋点管理模型描述，如下图。其内部的埋点管理逻辑是位置 > 事件，我称之为位置优先的埋点模型，在该模型下，事件是限定在位置下的事件，意味着其内部可能有着成千上万的埋点事件……

两种模型的对比如下表：

对比维度	事件优先	位置优先
主要使用方	神策	淘宝
主要差异点	事件优先，即事件是位置的上一层级，同一事件可以多位置复用	位置优先，即位置是事件的上一层级，不同位置的相同事件，其埋点事件可能不同
结构对比
事件量对比	少	多多多多多
使用上对比	基于统一的事件逻辑，使用方不用频繁参考不同的事件文档	每个埋点的参数其字段和格式可能都是不同的，需要case by case，阿里用了spm和scm进行了一定的规范

当然，也有可能是由于埋点模型的不同，阿里当年做spm的目的可能仅仅只是做一套位置规范化，将散落于how中的位置参数统一，并不是我说的只到页面粒度的问题。

一、spm是什么

做过埋点的应该都了解过阿里的那套spm模型，全称超级位置模型(Super Position Model)，之前一直觉得这套规范应该极其深奥，毕竟是能够支撑亿级别DAU的埋点规范。在我之前公司的业务场景下，DAU有限，并且业务对用户行为数据的分析还并未深入到点位的粒度，所以也仅仅只是了解，并未深入研究。

目前阶段主要做数据产品，在当前业务场景下终于有机会能够深入研究这块儿的内容。深入了解之后，发现spm模型的本质还是通过参数来区分位置信息，只不过是通过一套统一的规范约束楼层、点位的命名与上报。

spm叫超级位置模型，最早是受到土地户籍制度启发而设计的位置系统，目的应用于页面的统计、追踪页面的来源等场景，通常在埋点时作为埋点参数上报到数据后台。其编码形式采用A.B.C.D四层级进行组合，分别代表了业务、页面、页面区块、区块内的点位。

以上其实还少了个E参数，通常取值是行为发生的时间戳，用来区分同一用户在同一位置的点击行为。

阿里在使用时spm时，通过spm-pre来标识上级来源页面的上级页面，通过spm-url来标识上级来源页面，通过spm-cnt来标识当前页面，其关系见下图，使用该逻辑在不进行join的情况下可以追踪用户当前行为的前2级页面具体点击位置，通常而言，追踪前一级页面就能够满足绝大多数的使用场景。

二、为什么要做spm

从技术角度而言，其最重要的价值就是统一数据采集的规范和认知，减少上下游的沟通和开发使用成本，产品和研发能够快速get到需要的数据怎么埋，下游能够快速获取到所需要的正确合理的数据。

在精细化运营及算法推荐等应用场景下，需要非常精确掌握行为发生的位置场所。如果每个业务都自定义一套标识方式，那么每次分析及埋点工作都需要重新开发，无法复用逻辑，这将极大的浪费开发资源，因此需要制定出统一的位置规范。

但是从业务角度，其能够实现流量的统一标记和管理：

流量实现精准定位
位置和内容分离，使得二者可以分开评估，且位置的评估可以到具体点位级别（这条在事件模型中，二者本身就是分离的）
建立以资源位为中心的数据体系和运营体系

以上第3条是业务方更加关注的点，也是spm这套体系对业务最终的价值点，所以如果要推动spm规范，其核心产出应当明确为建立以资源位为中心的数据运营体系。

其对业务方可感知的产出应当如下：

基于位置的流量及转化评估模型，告知业务方，每个页面及页面下坑位的流量效率具体是多少
一个以资源位为中心的管理运营平台

三、如何实现spm

3.1 具体流程

首先进行spm的边界限定，spm只做位置的追踪，不进行该位置下展示内容的追踪。

2个我总结的关于埋点采集的原则：

1.业务最小侵入原则，比如utm链路，比如归因，比如spm，都要尽可能少的减少业务侵入

2.埋点参数最小化满足原则，只有必要的数据才需要进行获取

目前业界常用的埋点体系大多是基于事件的埋点体系，在该埋点体系下，传输参数只需要放在ext字段中即可，但是spm模型规范中最重要的部分是对位置体系的划分，站点->页面->区块->点位，如何在不过多侵入业务的基础上低成本的实现这套位置体系才是重点，但是看了下相关文章，spm肯定会侵入到页面发布的相关流程。

设计的具体流程：位置划分 —> 客户端埋点上报 —> 流量归因模型处理 —> 资源位数据运营体系

3.2 位置划分平台

通常而言，app上的页面会随着版本逐步变化，所以区块和点位的划分也会随着版本逐渐变化，如果每个区块和点位的划分都通过文档之类的更新势必会造成混乱，所以需要一个完善的平台来对区块和点位进行划分，这种划分应当是可视化的形式。

3.3 区块信息同步到埋点中

这一步其实也是我非常困惑的一步，简单来说，如果每一个坑位的spm信息都需要通过研发使用代码进行埋点，那这套方案的ROI就实在是太低，所以一直在想是否有更加低成本的同步方式。

比如，能否通过技术手段，关联spm的位置划分系统，将定义的位置信息自动同步到对应代码里，然后事件上报时获取对应的位置信息即可。

四、如何划分spm

通常而言，app页面的搭建我们可以理解为搭积木，再复杂的页面都可以拆解为一个个控件和元素，其内的可能性总归是有限的，我们只需要进行层层拆解，就可以实现这套位置追踪模型。

元素：设计的最小层级，通常是图片、文字、几何元素和图标
控件：由最基础的设计元素组合而成，是执行特定操作和功能的单位，使用app时最基础的操作组件
组件：由控件+元素组合而成，包含相对独立且完整的功能和信息的app模块
区块：由多个组件+控件组合而成的区域
页面：由区块拼接成的页面，理论上只由区块内的组件组成

基于以上认知，我们可以考虑进行spm层级的划分。

4.1 站点(app)的划分

站点就是我们通常意义上说的app名称，可以用id，也可以用包名，还可以唯一写定一个固定值。

4.2 页面(page)的划分

页面是站点的下一级，常规的埋点体系中，对位置的追踪只做到了该级别。

在原先的基础上，考虑到页面的迭代更新、AB测试，我们还应当引入页面版本(pageVersion)和页面状态(pageStatus)这两个参数来区分该页面的具体版本以及逻辑判断下的具体状态。

pageVersion：主要针对页面的更新迭代来做数据回溯，不同于app版本，此处的页面版本仅代该页面的历史更新。不同页面版本间的页面区块展示可能是完全不同的，比如2018年的淘宝首页和2021年的淘宝首页虽然都是同一个页面，但是里面的区块分布有着非常大的差异。

pageStatus：针对逻辑判断场景下的不同页面展示数据不同，例如登录页面，未登录状态、会员状态、普通用户状态三种状态下展示的区块内容会有差异，也可能会现在动态推荐场景下，人群a和人群b看到的页面区块分布存在差异，所以用该字段来区分不同的页面状态。

基于pageVersion和pageStatus两个参数才能唯一确定当前区块(area)的分布。

4.3 区块(area)的划分

以淘宝首页为例，此时已经明确app=淘宝，page=淘宝首页，那么接下来，需要对页面中的区块(area)进行划分，area包含2部分组成，前1部分代表区块名称，后1一部分代表区块顺序，用@进行分隔，如图，从上到下分别划分区块为搜索区块(search@1)、banner楼层(banner@2)、金刚位区块(kingkong@3)、瓷片区区块(porcelain@4)、猜你喜欢区块(recommend@5)，注意，这里区块的划分依据是从上到下按照区块划分。

考虑到即使是同一版本同一状态的同一页面，也会有针对其内的某个区块(floor)进行更新修改，所以引入区块版本(floorVersion)变量，考虑到某个区块(floor)的逻辑判断场景，所以还需要引入区块状态(floorStatus)。

~~pageVersion和floorVersion的关系：pageVersion>=floorVersion，~~

~~pageStatus和floorStatus的关系：pageStatus>=floorStatus，~~

~~那么在实际应用中，什么时候选择区块，什么时候选择页面呢？依据最小化原则，能用区块进行版本和状态划分的，就不要用页面。~~

对floor进行version和status的管理，会和page重复，并且无法在产品设计上进行有效收拢，故删除floor的version和status管理，只要floor进行修改就更新pageVersion，如果floor存在逻辑判断的场景，那么通过业务参数区分不同的场景，SPM不涉及到业务参数，只做位置的划分。

4.4 点位(component)的划分

当区块划分完成之后，接下来就需要继续对区块内的点位进行划分，点位依然是两部分组成，前1部分代表元素名称，后1一部分代表元素位置，通过@区分。

考虑到较为复杂的情况，如淘宝首页瓷片区聚划算点位，下方带了2个图片，为了区分哪个图片的点击，我们需要用「.」符号来将element字段一层一层标识到最细粒度，如下方聚划算的「划算好货」的点位element=”porcelain@1.img@2”，如果某区块下的点位还能往下细分，那么可以继续追加「.」，直至到最小粒度的元素。

注意：在某些场景下，如瓷片区区块，会存在动态推荐的情况，虽然用户a和用户b点击的都是位置2，element=porcelain@1.img@2的瓷片，但是他们实际上点击的可能一个是聚划算，一个是淘宝直播，SPM在这里是不区分的，具体点击内容会放在业务参数中。这样既能够对SPM和业务参数做交叉验证，还能够解耦SPM与业务参数采集。

4.5 spm埋点采集的数据

在埋点采集时，参考阿里的做法，预留3个字段给到spm，分别是spm_pre，spm_ref，spm_cnt，分别代表上级来源页面的上级页面点击点位，上级来源页面的点击点位，当前页面(如无点击则为null值)，每个字段用「_」连接app标识(app)、页面标识(page)、区块(floor)和点位(element)标识不同的位置，如果不涉及到某个字段则用0填充，如「从淘宝首页聚划算进入到聚划算主页再进入到商品详情页」此时在商品详情页上报的典型事件数据如下：

event	spm_pre	spm_ref	spm_cnt	ext
click	app1_home_porcelainFloor@4_porcelain@1.img@2	app1_jhs_itemRecFloor@5_itemCard@1	app1_itemDetail_itemOpeFloor@12_addCart@4	{业务参数}
expo	app1_home_porcelainFloor@4_porcelain@1.img@2	app1_jhs_itemRecFloor@5_itemCard@1	app1_itemDetail_0_0	{业务参数}
pageShow	app1_home_porcelainFloor@4_porcelain@1.img@2	app1_jhs_itemRecFloor@5_itemCard@1	app1_itemDetail_0_0	{业务参数}

当然，如果当前阶段数据分析的粒度没有那么细，不准备采用spm这一套规范，那么数据只需要上报到页面级别即可：

event	app_id	spm_pre	spm_ref	spm_cnt	ext
click	app1	home	jhs	itemDetail	{业务参数}
expo	app1	home	jhs	itemDetail	{业务参数}
pageShow	app1	home	jhs	itemDetail	{业务参数}

五、spm点位可视化

spm的主要目的还是为了方便下游的使用，那么在做好元数据管理的基础上，一个完善的点位查询平台就是非常必要的了，能够统一上下游认知，减少沟通成本，压缩花费在查找具体埋点上的时间。

从功能上来说，应当由两个主要功能，第一是页面可视化，期望达到的效果是在网页端展示一个app页面，用户可以选择页面进入，来查看该页面的具体floor及element分布，以及当前页面存在的具体埋点，其次是通过spm点位以及具体的事件名称来搜索到对应的页面。

下面随便画了2个demo：

demo1:淘宝首页的搜索框

demo2:淘宝首页的金刚位第4个icon

六、流量归因模型

具体参考另一篇文章，主要目的就是在数仓层面建立一套统一的流量归因模型，统一口径，为下一级的资源位管理平台提供有力支撑。

流量归因模型

七、以资源位为中心的数据运营体系

还没想好，待定。

理想产出应当是一套资源位管理平台。

八、扩展–scm模型

scm叫超级内容模型，用来标识唯一一块内容的模型，在埋点时scm模型的数据作为埋点参数上报到数据后台，其编码形式和spm一样也是通过A.B.C.D四个层级进行编码，只不过四个层级记录的信息与spm有所差别，分别是：内容来源、投放算法、算法版本以及对应的人群，还以上面的内容为例：
内容来源(content_source)：shop
投放算法(algorithm)：cf
算法版本(version)：3.3
对应人群（crowd）：woman

spm针对的是用户位置分析，而scm针对的是内容分析，通过内容来源、投放算法、算法版本、对应人群四个参数标识当前用户的feed流推荐内容来源，再针对性的计算不同类型的CTR就能够做到数据追踪与复盘。

以上查阅到的资料应该少了具体的内容id参数。

九、最后

spm、scm其本质还是一套埋点规范，将分析需要用到的信息通过参数上报，其难点是在页面区块及元素的统一标识上，需要一套完善的元数据管理系统来支撑。

这套方案太侵入页面发布流程了，和之前的埋点成本最小化原则其实是相悖的，在做这套方案的时候，还是需要考虑到实际的ROI，去评估这套方案是否能够真正的带来价值。

数据产品经理jd分析

2021-04-10T16:00:00.000Z

最近要考虑彻底转向数据产品的工作了，

又到了新的一年了，今年想要到一个更高的平台去实现价值，所以，是时候换工作了。金三银四，不能错过4月份了，换工作第一步是什么？当然是了解下市场需求。

一、目的

由于之前从事的是数据产品、数据分析、离线数据开发的综合性角色，不太清楚市场对数据产品的要求是什么，这里需要把一些大厂的jd拿出来分析一波，抽离出共性的要求，看自己是否满足，如果满足的话需要在简历里面体现出来。

二、典型jd

这里选择杭州要求3-5年经验的数据产品的jd，先从大厂的jd看。

1.阿里
- 薪资范围：25-50K·16薪
- 职位描述
  1、负责淘宝内容生态数据体系搭建，基于对业务理解，搭建出可全面衡量内容生态健康的数据指标体系，且将数据体系产品化、工具化，构建数据驱动内容生态发展的核心能力；
  2、负责阿里内容中台下数据平台建设，整合各内容业务线的数据，帮助提升数据分析效率；同时根据反馈，不断优化数据平台的产品体验；
  3、对新零售下内容业务及内容场景下的用户、内容进行分析，构建用户画像、内容画像，进行产品化与平台化，并应用于下游内容业务；
  4、负责淘宝直播、逛逛、点淘等最热风口的内容行业数据产品体系搭建。
- 职位要求
  1、3年以上数据产品或数据分析经验，对数据产品定位、发展方向有深入的理解和认识，有内容领域数据分析工作经历优先；
  2、具备良好的数据敏感度和业务视野，能够敏锐的捕获数据价值和产品机会；
  3、了解底层数据的架构技术以及应用层数据分析和算法的基本概念，能够运用数据作为产品解决业务方运营及决策问题。
- 分析
  职位描述的核心关键词是数据体系搭建、数据驱动、提升数据分析效率，优化产品体验，产品化与平台化，要求上核心的是两点，一是拥有数据敏感度和业务视野，能够发现数据产品的机会，二是运用数据作为产品解决业务方运营及决策问题。
2.滴滴
- 薪资范围：30-40K·15薪
- 岗位职责：
  1、负责业务线数据应用及分析产品的建设；
  2、深入理解业务战略和策略，拓展数据应用场景和数据维度，落地数据指标体系、数据分析框架等，提高业务线的数据分析效率；
  3、把握数据应用痛点，帮助需求方准确高效地理解业务，并及时发现风险和机会；
  4、作为产品owner，负责从需求收集、产品规划、项目推进、效果验收、线上问题跟进、用户反馈等全过程；
- 任职资格：
  1、3年及以上数据产品、数据分析或策略产品相关经验
  2、参与数据体系或数据产品的搭建，有较好的需求抽象能力和产品设计能力；
  3、对数据敏感，对数据问题定位和数据可视化有自己的认识；
  3、具备良好的沟通协调能力、抗压能力和和团队精神，善于拿结果。
- 分析
  岗位职责还是突出理解业务，然后能够发现数据的应用场景和价值，去解决业务的问题或者提升数据分析效率。要求上除了经验以为，突出的是注重结果，以及需求抽象和产品的设计能力。
3.饿了么
- 薪资范围：25-50K
- 岗位职责：
  1 贴近业务主动思考业务应用场景，基于对于销售网络的业务理解设计产品；
  2 独立承担产品设计、推进、落地、上线、推动等一系列工作，同时做好产品的数据分析工作；
  3 推动产品上线推广，并与产品用户保持有效沟通，定期收集用户反馈，有效提升产品的使用效果。
- 职位要求
  1、有至少5年以上的数据产品或数据分析项目经验，能够熟练使用原型设计工具进行产品的原型设计；
  2、具有数据分析报告的撰写能力，并且能够熟练使用SQL进行取数工作；
  3、熟悉数据仓库、商业智能基本理论，对于DW数据底层、数据集市等有一定了解；
  4、良好的项目管理经验，根据产品的生命周期理论推进产品的迭代优化；
  5、对于常用数据挖掘模型及其工具有使用经验者优先考虑；
  6、强烈责任心，开放的性格，良好的沟通能力。
- 分析
  岗位职责写的有点敷衍，重点还是对业务+数据的结合，然后设计数据产品，还有产品的推进流程，也比较注重结果。职位要求上除了经验以外，就是数仓、数据分析、产品相关的要求了。
4.网易
- 薪资范围：15-30K
- 职位介绍：
  1、负责数据产品设计，推进产品设计的实现；
  2、负责数据产品的运营，完成数据产品培训、咨询与推广；
  3、负责数据服务需求的对接、梳理与跟进；
  4、负责数据产品设计、用户手册等相关文档的编写。
- 职位要求：
  1、对业务有深入的洞察力，具有良好的抽象能力，能够洞察业务本质，抽象业务模型。
  2、熟练使用Axure RP等工具梳理业务流程和设计产品原型；
  3、了解数据分析，思维逻辑清晰，良好的自我学习及驱动力，有创造性；
  4、对数据存储、计算、可视化有基本的了解；
  5、具备良好的沟通能力和文字表达能力，有较强的团队协作能力，沟通能力强，耐心、有责任心。
- 分析
  网易的描述类似，职位介绍上突出了产品的运营和推广工作，以及相关文档的撰写。职位要求上还是要求对业务有深入洞察力，能发现并解决业务痛点，沟通能力强，有责任心。
5.吉利科技
- 薪资范围：20-40K
- 职位描述
  1、负责数据产品的规划设计，推进数据产品的建设，包含不限于：BI系统、数据大屏、指标管理系统、数据监控、数据中台等；
  2、负责各业务线、产品线、项目的数据服务需求的对接、梳理和对接，抽象出标准通用化的数据产品服务能力；
  3、负责数据产品的运营、产品的相关培训、用户手册编写、咨询和推广；
- 任职要求：
  1、5年以上数据产品设计经验；
  2、熟悉数据的采集、清洗、分析、可视化等工作原理，输出数据产品的能力、应用和收益，赋能业务；
  3、熟悉了解数据平台技术架构、技术选项的原理，Hadoop、Kafka、Spark等，会写SQL语句；
  4、对业务有深入的洞察力，具有良好的抽象能力，洞悉业务本质、抽象业务模型；
  5、跨部门/团队沟通协作，良好的沟通和文字表达能力，有较强的自我驱动、项目推动能力，做产品的owner；
- 分析：
  传统汽车行业的数据产品经理，职位描述上可能是属于从0-1的阶段，任职要求上依然重点是对业务有深入洞察，赋能业务。
6.涂鸦智能
- 薪资范围：15-30K
- 工作职责：
  1. 负责各业务线、产品线以及项目等数据服务的需求梳理和对接，抽象出标准通用化的数据产品服务能力，推进数据产品的建设，包括不限于BI系统、数据大屏等；
  2. 推动可视化相关能力建设，包括发展方向、技术探索、组件体系建设、项目管理、流程标准化等；
  3. 推进产品数据化运营体系，推动产品不断迭代；
  4. 对数据产品生命周期负责，对业务进行数据产品的使用培训和推广，推进数据化驱动在业务中的应用和落地；
- 岗位要求：
  1. 本科以上学历，5年以上的数据产品设计经验，具备独立产品规划及落地能力；
  2. 数据sense强，具备较强数据分析能力和数据分析产品经验；
  3. 有阿里DataV、腾讯RayData、Tableau或其他数据可视化项目经验优先；
  4. 具有跨团队沟通协调能力及抗压能力，良好的自我驱动和创新意识，推动团队拿结果。
- 分析：
  应该是可视化相关的数据产品，重点是需求梳理和对接，对业务理解的要求没这么高，比较重视结果。
7.曹操出行
- 薪资范围：18-35K·14薪
- 工作职责
  1 负责大数据部产品建设，包括权限管理平台、埋点管理平台、元数据管理平台、数据血缘管理平台等；
  2 负责产品项目的需求整理、功能设计、推动落地及线上效果验收等；
  3 根据部门中长期的目标，对数据产品进行整体规划，并逐步落实到各个迭代版本，完成产品系统化建设；
  4 对接业务需求，收集需求，深入理解业务需求，并结合业务痛点提出合理、可行的解决方案。
- 任职要求
  1 本科及以上学历，计算机、信息管理等相关专业优先；
  2 三年以上数据产品经理或中后台产品经理工作经验，独立负责过一个系统产品的从0到1的建设；
  3 具备较强数据意识，关注产品上线后使用效果，并通过数据反馈驱动产品迭代；
  4 良好的沟通能力，跨团队协作能力；责任心强，工作中遇到困难能竭力推动解决问题；
  5 自驱力强，工作积极性高，能够积极主动地承担工作；
  6 熟悉大数据领域，了解 Hadoop 相关技术，熟悉数据采集、数据加工、数据消费、数据应用者优先。
- 分析
  典型的基建类数据产品的岗位。
8.浮云科技
- 薪资范围：20-40K
- 职位描述：
  1、负责游戏数据应用体系建设，负责开发和维护标注系统，完善用户画像。
  2、负责深入调研和理解业务场景，梳理业务活动效果的指标体系并结合海量数据，为游戏运营及用户增长提供产品能力支撑；
  3、为业务的迭代方向提供高效数据分析产品工具（包括但不仅限于用户行为分析系统、AB试验系统、投放归因系统、游戏DMP等）
- 职位要求：
  1、本科以上学历，统计学、应用数学、计算机等理工科专业背景优先。
  2-5年数据产品工作经验，熟练掌握Axure等原型工具，有实际数据产品项目经验，熟悉用户画像，特征工程和标注平台建设；
  2、有较好的技术和算法理解能力，有营销、搜索、推荐、风控等产品系统相关经验；
  3、热爱大数据+AI方向，了解相关算法
- 分析：
  游戏相关的数据产品，看职位描述也是基建类数据产品的搭建工作。

三、核心关键词

数据产品和数据分析相关的工作经验，
深入理解业务，能够发现数据产品的价值点，也就是能够用数据解决业务方的问题，或者提升数据分析效率
良好的产品抽象能力，洞察业务本质，然后设计数据产品
产品owner意识
结果为先，要拿出成果

四、总结

以上只是简单选取了几个jd分析下，并不能代表整体，数据产品还可以细分为数据开发平台的产品、机器学习的产品、可视化的产品等等。如果想去大厂的话，重点要突出的是深入了解业务解决问题的能力，而不是基建产品的搭建能力。所以，还得好好改下简历啊…

魔术技巧

2021-03-27T16:00:00.000Z

最近看到了一些简单易懂的小魔术，所以收藏一下，哪天可以给喜欢的人表演一下。

2个皮筋小魔术

皮筋瞬间转移

皮筋穿越

橡皮筋神奇穿透

数据产品经理实战进阶读书笔记

2020-10-02T15:23:59.000Z

这本书目前对我作用最大的点：

1.数据分析的目的是为了得到有价值的数据结论

2.什么是有价值的数据结论：增加收益或者减少损失

以下是书中作者总结的常用数据分析方法，确实抽象总结出了我目前工作中常用的分析模式，结合目前流量分析中常用的漏斗、留存、分布、归因等分析方法，让我在数据分析的术方面，又有了提升。

全链路分析
- 类比于漏斗分析，就是把整个核心的转化链路串起来
- 第一步：梳理链路关键节点，确定每个节点指标
- 第二步：进行节点洞察，分析每个节点的数据，查看问题点和增长点
组成因子分解
- 把整体指标数据按照某种分类标准分成不同因子的过程，成为组成因子分析，整体目标等于所有的组成因子之和。
- 例如：gmv=uv X 转化率 X 客单价，广告平台总收入=信息流收入+搜索广告收入+其他类型广告收入
- 注意：如何进行组成因子分解代表着思考问题的第一维度，直接影响能否得到有用的结论，要尝试多种方式，试验出最好的因子分解方式
影响因子拆解
- 很多情况，因子对结论的影响是定性的，并不能简单的相加
- 使用时列出所有影响因子，逐步尝试
枚举法
- 使用步骤
  - 第一步：数据列举
  - 第二步：逐个解读
  - 第三步：汇总问题，给出解决建议和优先级
- 应用的两种思维
  - 排序思维：就是二八法则
  - 随机抽样：分层抽样等等，样本估算整体
实际分析案例：图表的表现形式可以好好参考下

读书笔记见幕布：https://mubu.com/doc/4Q1IOb0P7p

数据平台的权限设计

2020-10-01T14:02:46.000Z

如何为数据平台做权限控制？

一、基础

数据权限管理对于一个数据平台的重要性自不必多说，通常而言，对于一个数据平台，权限体系可以分为如下两类：功能权限与数据权限两部分。

功能权限指的是在系统中的功能可否使用，通常我们将功能权限分为查看、编辑、删除等，同时编辑、删除权限又包含了查看。通过小的权限点拆分更精细的赋予了员工能否进入某个页面查看信息、编辑信息的能力。
数据权限指数据中存在的数据是否能查看，是一个更细粒度的权限。比如一个页面，不同角色查看不同的数据就需要通过数据权限控制。在RBAC模型中通过定义资源进行控制，在ABAC模型中通过资源及限定具体策略进行控制

二、常用的权限管控模型

ACL（Access Control List）：基于用户级别的权限控制。
将系统的各种权限直接授予具体的用户。抽象来说，为每个用户维护了单独的权限列表，当需要分配权限、收回权限时，需要修改对应用户的权限信息。
RBAC（Role Base Access Control）：基于角色级别的权限控制。
与 ACL 对比，RBAC不用给用户单个分配权限，权限与用户之前通过角色关联。通过给不同的角色分配不同的权限，只需要将用户指向对应的角色就会有对应的权限。分配权限、收回权限只需要通过修改用户的角色即可。
用户：你的终端用户；
角色：角色是一个逻辑集合，你可以授权一个角色某些操作权限，然后将角色授予给用户，该用户将会继承这个角色中的所有权限；
资源：你可以把你应用系统中的实体对象定义为资源，比如订单、商品、文档、书籍等等，每种资源都可以定义多个操作，比如文档有阅读、编辑、删除操作；
操作：操作是用户试图对资源进行的操作。常见的操作包括“读取”，“写入”，“编辑”，“复制”和“删除”；
授权：把某类（个）资源的某些（个）操作授权给角色或者用户。
通过用户、角色、资源、操作、授权的组合，就可以轻松直观地实现灵活、细粒度的权限模型。
ABAC（Attribute Base Access Control）：基于属性级别的权限控制。
不同于常见的将用户通过某种方式直接关联到权限的方式，ABAC 是通过动态计算一个或一组属性来是否满足某种条件来进行权限判断,你可以细粒度地授权在何种情况下对某个资源具备某个特定的权限。ABAC授权模型理论上能够实现非常灵活的权限控制，几乎能满足所有类型的需求。从使用场景来说比较适用于用户数量多并且授权比较复杂的场景。简单的场景也是可以使用ABAC的，但是使用基础的ACL或者RBAC也能满足需求。
在 ABAC 中，一个操作是否被允许是基于对象、资源、操作和环境信息共同动态计算决定的。
对象：对象是当前请求访问资源的用户。用户的属性包括ID，个人资源，角色，部门和组织成员身份等；
资源：资源是当前访问用户要访问的资产或对象（例如文件，数据，服务器，甚至API）。资源属性包含文件的创建日期，文件所有者，文件名和类型以及数据敏感性等等；
操作：操作是用户试图对资源进行的操作。常见的操作包括“读取”，“写入”，“编辑”，“复制”和“删除”；
环境：环境是每个访问请求的上下文。环境属性包含访问尝试的时间和位置，对象的设备，通信协议和加密强度等。

ABAC对于RBAC有以下优点:

对于大型组织，基于RBCA的控制模型需要维护大量的角色和授权关系，相比而言，ABAC更加灵活；对于中小型组织，维护角色和授权关系的工作量不大，反而定制各种策略相对麻烦，更容易接受RBAC授权模型。
新增资源时，ABAC仅需要维护较少的资源。而RBAC需要维护所有相关的角色。ABAC可扩展性更强、更方便。
RBAC支持带有动态参数的授权规则，RBAC只能基于静态的参数进行判断。
ABAC权限控制的粒度比RBAC更细。

三、数据平台的权限设计

3.1 RBAC下的权限设计

通常使用业界通用的RBAC权限模型，基于角色进行用户的权限控制。

在权限设计时，通常抽离出以下四个实体进行设计

用户：最终拥有权限的一个个用户
角色：对资源进行权限授权的集合体
资源：要操作的目标对象，在不同的场景下指代的对象不同，既可以是数据，也可以是功能
操作：一般分为三种，查看、编辑、删除，在设计具体的权限时可以结合资源定义具体的操作事件进行授权，比如查看某菜单，使用某功能的权限

他们之间的关系用一句话描述：基于“用户-角色-资源-操作”的权限控制，将“XX资源(菜单、数据)”的“XX操作(增删改查等)”授权给“XX角色”，然后将“XX角色”授权给“XX用户”。

RBAC模型下需要将资源划分为功能和数据两种，功能权限的划分是常规的页面功能逻辑，如下图：

对于数据产品而言，数据权限的管理才是其中最重要的内容，通常而言，RBAC模型下，会采用组织机构树进行数据权限的控制，这种方式比较复杂，但是非常灵活，能够支撑多种复杂的业务数据权限诉求。

3.2 ABAC下的权限设计

采用ABAC模型的描述：基于“对象-资源-操作-环境”的权限控制，描述了“XX对象（人/应用/组织/角色等）对 XX资源（页面/菜单/按钮/数据等）在 XX环境/因素（城市=北京等）下拥有 XX操作类型（增删改查等）的权限”。

四、扩展

在可能的情况下，建议使用ABAC模型进行权限管理，即使当前状况下使用较为繁琐，但是提前预留了扩展，能减少后续重构的成本和时间。

天池-工业蒸汽量预测

2020-09-05T14:47:02.000Z

最近买了阿里云天池大赛赛题解析这本书，跟着这本书开始深入学习机器学习，这是第一个题目：工业蒸汽量预测。

比赛地址：https://tianchi.aliyun.com/competition/entrance/231693/introduction

一、赛题理解

（一）数据概览

1.数据说明

2.评估指标

MSE

（二）塞题模型

这是一道典型的预测题，属于机器学习中的监督学习，常用的预测模型主要有回归预测模型和分类预测模型。

1.回归预测模型

回归预测模型的预测结果是一个连续值域上的任意值，回归可以具有实值或离散的输入变量，通常把多个输入变量的回归问题成为多元回归问题，输入变量按时间排序的回归问题称为时间序列预测问题。

2.分类预测模型

典型的：泰坦尼克号，预测的结果分为生或者死。

主要分为二分类及多分类。

本赛题中预测值为连续性数值变量，故为回归预测求解。

回归预测模型使用的算法：

1.线性回归

2.岭回归

3.LASSO回归

4.决策树回归

5.梯度提升树回归

二、数据探索

三、特征工程

四、模型训练

五、模型验证

六、特征优化

七、模型融合

八、业务应用及平台化开发

主要解决业务问题：我们通过历史数据对下单/未下单的用户的行为进行建模，利用逻辑回归模型预测用户下单意愿，并提高用户下单率，如下图：

文章地址：https://mp.weixin.qq.com/s/cdTNRFFJcKrpWgOtuFzYFw

平台化方案：

前端：vue

后端：阿里云函数计算

主要界面：上传文件格式

userid	v1变量	…	vn变量

输出文件格式：

userid	v1变量	…	vn变量	是否下单

页面停留时长的处理

2020-08-08T16:00:00.000Z

埋点日志中对于页面停留时长的处理。

页面访问时长为右偏分布（均值在高峰的右侧），对这种分布来说，总是有均值 > 中位数 > 众数，从这个角度上来讲，如果想用一个数字来了解这种偏态分布的大体状况，中位数可能比均值具有更大的参考价值。

使用时不能简单的看均值，应当参考中位数和众数。且由于埋点方案的固有缺陷，会产生一定比例的异常值，所以需要通过一定的统计学方式进行处理。

为计算更加合理的均值，这里提供2种方案：

~~1.采用Q3+1.5(Q3-Q1)排除异常大值~~

~~2.将异常大值使用中位数替换~~

3.凭经验，将大于1000s的单次访问行为替换为中位数，进行计算

4.类比于去除最小值，去除最大值，计算平均值的方法，去除前10%，后10%时长的pv行为，再计算平均值，即取截尾平均值，改计算方法能够很好的消除极端值对算术平均数的影响，建议用该种方式。

用户行为分析平台

2020-08-02T08:10:37.000Z

一般而言，数据分析依赖于专业的BI人员先进行报表产出，运营再依据产出的报表进行分析，对于长期稳定的业务，报表总会慢慢覆盖尽可能多的维度，但是依然会存在多种组合维度指标的追加。如果在业务经常变化的情况下，报表覆盖的维度就没法做到及时有效，报表产出周期动辄几天，且数据口径方面会存在运营和BI人员之间的理解误差，数据准确性依赖于报表产出人员的水平，这样会严重影响数据驱动的时效性和顺畅性。并且该种方案不利于培养运营人员的数据意识，试问，如果一个简单的数据分布查看都要提需求等排期，那么谁还愿意到处拿数据说话呢？

数据产品的价值就在于此，降低数据的使用门槛，让数据能更加方便、快捷、准确的为业务人员使用。

一、需求背景

之前写过构建数据指标体系，在文章中，数据指标体系搭建好之后就需要通过ETL过程进行数据开发，然后通过ads层输出数据，再经由superset进行报表展示，开发周期长不说，预定义的维度还有限，没法一次覆盖所有的分析场景，且业务处于快速迭代期，经常需要进行报表的调整，只能按照需求管理的方式慢慢添加报表，更加致命的是，由于口径和维度的调整，往往需要经常修改报表逻辑，耗费时间长，技术含量低，响应周期慢。

基于此种情况，构建一套人人可用，简单高效的用户行为分析平台就非常有必要了。

为什么叫用户行为分析平台？因为在当前的电商场景下，我们分析的对象绝大多数都是用户的行为，比如下单、支付、留存等等，所以叫做用户行为平台。

用户行为分析与B分析有哪些区别?
分析对象不一样:用户行为分析,顾名思义,主要分析对象是用户,是运营部门最关心的对象;BI可以分析商品、销售、供应链、会员、财务等场景,也包含用户。
数据来源不一样:用户行为分析通过在App、Web、小程序等进行埋点获取用户生命周期中的行为数据;B是通过接入各个部门信息系统中的数据再进行分析,包含支付、会员、供应链、进销存、CRM、
财务等等。
作用价值不一样:用户行为分析通过数据洞察用户行为,从而提高拉新、转化、留存等各个环节的RO,B是通过数据融合、分析、可视化为公司搭建自上而下的数据分析体系,最终目标是提高各个层级决策的科学性和实时性。

二、解决的问题

主要解决的问题应该分为两部分：

对于分析师而言
- 提升写报表效率，常规需求可通过点选快速产出报表
- 固化分析模型，将一些成熟的分析模型产品化之后赋能给业务人员
- 可以进行一部分探索性的分析工作
对于业务人员
- 降低数据需求的响应周期
- 部分常规需求可以自主完成，不用通过分析师
- 部分高阶用户可以进行多种维度的组合分析用来探索性的数据分析

核心而言，解决的就2个问题，第一，提高数据需求的效率，第二，固化分析模型进行业务赋能。

三、产品目标及抓手

针对要解决的核心问题，我们定下的目标是能够覆盖60%的常规数据需求。

通过数据分析模型的覆盖，事件的覆盖度。

四、产品调研及分析

目前市场上该类产品其实有很多，这里选择两家典型的产品进行分析。

主线问题是，他们是如何快速实现数据分析需求的？

五、产品实现思路

5.1 底层数据模型

这里的数据采集，本质上就是把用户的行为抽象为一个个的事件，或者说将业务过程合并到一张行为表event中。

事件模型是目前数据分析的基础，用来描述用户的一次行为，该模型用以规范并结构化用户的行为日志。

通过事件模型，我们可以这样来描述用户的一次行为：

简单来说，事件模型 = 谁在什么时间在哪里做了什么事，基于事件模型，通过app上的埋点技术，我们可以采集结构化的用户行为日志，并存储在数据库中用以分析。

使用4w来描述用户的一次行为，这里所说的行为就是事件，事件可以是多种多样的，比如用户的访问是一种事件，出价、下单、支付同样是一种类型的事件，埋点采集的就是我们所定义的事件，我们所分析的也是用户所做的每一种事件。

数据结构采用event-user-item模型

• 单边，双边用户

单双边是针对产品有多个身份使用用户时才会进行区分。单边用户，即仅有一类用户的产品，如健身产品Keep，聊天工具 QQ 等 ; 双边用户如 O2O 产品，用户可能是普通消费者，也可能是商家用户。需要根据产品的不同，提前对用户识别和相应属性进行设计。

• 缓慢变化维

如果遇到一些会发生变化的属性，比如用户的 VIP 等级，不能只作为用户属性传进用户表中，还需在事件表中，记录一个 “当前发生事件 VIP 等级” 这个属性。因为当前会员等级的统计，和发生事件时用户的会员等级统计是两种情况。

5.2 分析模型

数据分析常用思路

相关的分析模型主要通过sql拼接的最小成本方式实现，为此牺牲了一定的功能，待后续产品使用量提升之后会继续推进优化。

5.3 产品易用性逻辑

初期未考虑太多产品易用性的设计，后期参照简约至上，对产品的易用性进行了一些改进。

5.4 其他

是一款数据分析产品，其主要作用是让运营、产品等非专业人员能够通过点选的方式进行自助式的数据分析，让每个人都能够及时、准确且便捷的进行业务数据分析。

其次，提供的并不仅仅是分析工具，还提供分析模型，比如日常工作中常用的分析思路如留存、复购、漏斗、用户行为路径等固化为模型，使用者只需要选定对应的分析模型，再通过点选所需内容，即可快速得出所需结果。

六、产品结果评估

产品目前的结果评估并不理想，主要原因

在项目的推进过程中，犯了很多的错误，

错失项目推进加速器
未考虑不同人群的易用性设计，初期推广错了人群
错失关键窗口期

七、后续规划

需求池：

虚拟事件
事件和属性的注释
底层数据模型优化，使用ck的大宽表模型
场景库
新的分析模型

路线图：

用户行为路径，分布分析，场景库，事件和属性的注释

八、总结

总的来说，这款产品是在技术思维主导下设计的一款数据产品，初期的不顺利主要是产品的易用性上设计的不够好，切入场景不够，所以，产品的推广和定位一定一定要明确。

最后，数据产品首先是一款产品，然后才是数据的属性，万不可本末倒置。

数据分析模型

2020-06-13T15:01:04.000Z

在数据分析的技能方面，优秀的数据产品已经将常用的数据分析思路抽象为了几种分析模式，结合日常工作种的内容，这里分别写下我对这几种分析模式的想法与实践。

数据分析的器术道，这里是术。

在数据分析的思路方面，业界领先的数据产品已经将常用的数据分析思路抽象为了几种分析模式，结合日常工作种的内容，这里分别写下我对这几种分析模式的看法与实践。

常用分析思路：事件、留存、漏斗、分布、归因、用户分群，在日常工作中的大部分分析内容无非是以上几种分析思路的组合。

一、事件分析

二、留存分析

三、漏斗分析

四、分布分析

五、归因分析

近期涉及到了归因分析这个场景，运营需要知道最后的成交是不是由于访问了某个活动页造成的，基于此，我们需要明确归因逻辑与归因的计算方式。

参考神策的归因分析，

https://www.sensorsdata.cn/blog/20190528/

两种实现方案：第一种关联后rownumber()

第二种将下单时间统一为event事件中

六、用户分群

七、用户行为路径

八、用户重合度分析

九、session分析

其他

看到的一些关于数据分析方面的好文章。

一文解答了我很多的迷惑：为什么我认为魔法数字有坑

漏斗分析究竟能够给业务人员带来什么？（上篇）

漏斗分析究竟能够给业务人员带来什么？（下篇）

数据分析必知必会 | TGI指数分析实战

numpy使用

2020-06-13T14:49:20.000Z

python数据分析三大模块，pandas、numpy、matplotlib，这里是numpy。

numpy中的日期操作：

import numpy as np 
# 获取两个日期之间对应的日期，左闭右开区间
np.arange('2016-07-01', '2016-07-05', dtype='datetime64[D]')

#输出：
array(['2016-07-01', '2016-07-02', '2016-07-03', '2016-07-04'],
      dtype='datetime64[D]')

# 获取当前日期
np.datetime64('today', 'D')

#输出：
numpy.datetime64('2020-06-14')

# 日期相加减
yesterday = np.datetime64('2016-07-01', 'D') - np.timedelta64(1, 'D')
today     = np.datetime64('today', 'D')
tomorrow  = np.datetime64('today', 'D') + np.timedelta64(1, 'D')
print ("2016-07-01的Yesterday is " + str(yesterday))
print ("Today is " + str(today))
print ("Tomorrow is "+ str(tomorrow))

#输出：
2016-07-01的Yesterday is 2016-06-30
Today is 2020-06-14
Tomorrow is 2020-06-15

内容见以下附件

8.numpy生成随机数.html

utm参数追踪

2020-05-09T03:24:47.000Z

以前在追踪用户来源的时候，只是简单的在链接上添加source=xx这个参数，全靠这一个参数来标识来源，虽然当时也了解到了utm参数，但是由于不懂其含义且当时场景有限，觉得source参数就足够了，直到最近，才真正了解了这套标识框架的含义，瞬间觉得这套标识框架太好用了，这里把知乎上GrowingIO的文章记录下。

utm最早是Google analytics用来定义链接来源媒介等使用的参数以方便在分析用户站内行为时分析用户来源的效果，现在可以把它放在各个内容、活动、推广中，监控渠道的流量情况。

一、utm 参数

目的：把投放在不同渠道的链接打上特定的标记，以监控各个链接的流量情况。

二、utm举例

当这条链接用于付费推广时，可以这样定义：

当这条链接用于内容文章时，可以这样定义：

当这条链接用于活动时，可以这样定义：

Event-User模型

2020-05-03T16:45:03.000Z

数据驱动四个步骤，数据采集、数据建模、数据分析、指标体系，这里对应的是数据建模。目前数据开发中最常用的数据建模其实就是维度建模，本文中所参考的神策分析的数据建模也不例外，其架构就是简化了的维度建模，其中event表存储的是用户的一个个行为，是一张事实表，user表和item表是维度表，存储的是事实表中user对象和item对象的扩展信息，在进行分析时通过join进行关联查询分析。

神策分析的数据模型设计

在介绍数据导入模块与数据存储模块之前，我们需要先讨论一下神策分析的数据模型设计。
前面已经提到，神策分析主要解决的是用户行为分析这么一个特定领域的数据分析需求，并且期望尽量简化数据模型以降低 ETL 代价。最终，我们选择了业内非常流行的 Event + User 模型，可以覆盖客户的绝大部分分析需求，并且对于采集到的数据不需要有太多的 ETL 工作。
Event 主要是描述用户做了什么事情。每一条 Event 数据对应用户的一次事件，由用户 ID、Event 名称、自定义属性三部分组成。Event 名称主要是对 Event 的一个分类，例如“PageView”、“Search”、“PayOrder”等等。我们在客户端会默认采集设备 ID 或者 Cookie ID 作为用户 ID，客户也可以自己设置一个合理的用户 ID。而我们最多可以支持一万个自定义属性，并且开发者并不需要事先告之系统，系统会自动从接收的数据中解析发现新的字段并且进行相应的处理。Event 数据以追加为主，不可修改，这也符合事件这一概念的实际物理意义。不过，为了方便后续系统的运维以及客户的使用，我们特别为 Event 数据提供了有限的数据删除能力，这一点会在后续存储部分更详尽地描述。
User 则主要描述用户是个什么样的人。它由用户 ID 与自定义属性两部分组成。自定义属性是年龄、所在地、Tag等。在神策分析中，它的来源主要有三类，一类是使用者自己采集并且通过接口告之系统的，例如用户的注册信息；一类是基于使用者的第一方数据挖掘得到的用户画像数据；还有一类则是通过第三方供应商得到的用户在第三方行为所体现出来的属性和特质。在神策分析中，User 数据，是每一行对应一个用户，并且可以任意修改的。

模型扩展：从 Event-User 到 Event-Item-User

所有的数据模型本质上都是对现实世界的抽象，而在抽象之后必然会损失一些对现实世界的还原能力。
所以 Event-User 模型虽然在电商、金融、在线教育、互联网娱乐、企业服务等不同的行业上都发挥了很好的价值，但是随着客户需求的不断深入，尤其是在和具体行业业务的深入融合中，我们也逐渐发现了这个模型的一些缺点。
例如在 Event-User 模型中，出于性能和可解释性等各方面的考虑，Event 是被设计为不可变的。从逻辑上看似乎没有问题，因为 Event 代表的是历史上已经发生过的事件，一般来说不应该需要进行更新。
但是，在实际的应用过程中，并不一定是这么理想的状态。
为了满足上述需求，我们在新版的神策分析中对 Event-User 模型进行了扩展，引入了 Item 的概念。这里的所谓 Item，在严格意义上是指一个和用户行为相关联的实体，可能是一个商品、一个视频剧集、一部小说等等。
如果不严格约束的话，理论上它也可以存储其它任意的扩展维度信息。

扩展

其中值得注意的是，event表的所有变量都是横向扩展到的，即埋点中每增加一个对象，event表就要扩张一列，这样做是为了方便后续自助式分析场景下event和user、item的关联，减少复杂度。

对于user表，由于涉及到用户画像的人群圈选与保存，我们注意到神策是将画像新建的每一个人群存储为一张表，并不存储在user表中，大大减少了user表关联的复杂度。

数据驱动读书笔记

2020-05-02T15:23:59.000Z

神策数据创始人桑文锋的《数据驱动：从方法到实践》读书笔记，每读一个章节，都能有所收获，特别是作者还穿插了大量的案例，结合案例，相信你会对书中所讲内容有更加深入的思考。如果你工作中恰好有着类似疑问、遇到类似问题，那么，这本书能够带来的，就不仅仅是收获，还有实实在在的问题解决方案。强烈推荐！！！

读书笔记见幕布：https://mubu.com/doc/s8Lsztgg3N

再谈埋点

2020-04-18T12:02:21.000Z

埋点是数据的来源，埋点数据是分析的原材料，无论从哪方面来看，确保埋点的准确性合理性都至关重要。

一、埋点采集框架

这里直接推荐神策开源的sdk，数据模型就是event模型，简单来说就是who、when、where、how、what模型，用来描述event发生时的具体场景和内容。

WHO：即参与这个事件的用户是谁。用户进入一个功能页面，我们要知道进来的用户是谁，并且同一个用户以不同身份状态在不同的端操作时，都能是识别出来就是同一个人，一套合适且完备的ID-mapping解决方案，对于提高用户行为分析的准确性、完整性有非常大的影响，对用户数量的统计、以及漏斗、留存、路径等期望用户行为流相关的分析尤其明显。同一用户的识别出现断层，会导致以上分析数据不准确或不可用。因此，我们在进行任何数据接入之前，都应当先确定如何来标识用户。以APP的页面浏览为例，在互联网时代，用户都以设备为载体，因此可通过设备旧来记录；具体业务场景下，用户自身也带着业务属性，可通过user_id、 login_id等类似的业务身份标识来记录，确保单个用户在多设备之间的行为可以打通。总之，关于who，大家要想清楚要如何准确地标识客户，一个项目的旧机制要在项目开始时特别慎重地进行确认，之后技术人员需要遵循这个规范来埋点，否则后期修改旧机制、清洗旧错误都是一个非常麻烦的事情。
WHEN:即这个事件发生的时间，神策分析通过自动采集的时间戳属性来记录。
WHAT:WHAT描述了一个事件具体是什么，这里就是神策事件设计模型的一个独特的地方。在这里场景下，按照神策的事件设计规范，事件是‘’APP页面浏览”，而不是“首页的浏览”，通过增加『页面名称』这个属性来区分究竟浏览的是哪个具体的页面，大家可以思考下，为什么是这种设计思路呢？实际上，一般一个产品会有N多个不同的页面，如果将每个页面都单独定义为一个事件，那么后台的事件将会有几百上千个，业务人员在使用时会非常的麻烦，筛选事件的成本也会非常大。神策分析在做埋点需求设计时，针对所有类似的触发机制和场景的事件，都会做聚合处理，因此企业的事件量通常会维持在30-50个左右，配以神策的归类机制，极大方便企业进行事件管理，给业务人员带来极强的易用性。
HOW：即用户从事这个事件的方式，HOW关联的是与事件强相关的属性内容。这是企业在事件梳理过程中非常容易出纰漏的地方。比如在APP页面浏览或者APP的点击事件上，经常会出现找不到按钮，或者无法定位页面的情况，原因就是研发的规范性较差，比如对页面标题的定义不规范等。神策针对页面标题做了自定义和规范，主要包括两方面：一是所有页面本身都有名字，并且与APP的页面是同一个名字，如此保证业务同学定位该页面时很容易找到；一是针对lOS与安卓经常出现两个同样的页面命名不一样的情况，神策分析会做维度字典的规整，如此，其可用性能够满足绝大多数的应用场景。 .
WHERE: IP、国家、省、市区等用户的操作属性，神策分析都是会在基础信息采集上做加工衍生，可以做到自动采集。端口、应用版本、操作系统、操作系统版本、设备制造商、设备型号、屏幕高度、屏幕宽度这些前端维度与属性，神策分析的采集也是默认获取的。对于后端自定义采集来说，则需要根据分析需求进行判断和梳理，确认是否需要通过接口透传等方式获取到对应这些前端属性，否则将会影响后续的多维分析。

神策开源的埋点SDK http://opensource.sensorsdata.cn/

二、埋点采集的数据源

通常而言，包括三项数据源，分别是：

前端操作和业务数据是我们最常使用的埋点数据，分析时所使用的大部分数据也是这两个来源的数据，我们会比较容易忽略后端日志来源的数据，有些前后端交互的行为，比如点赞这个动作，既有前端采集的动作，又有后端的数据库记录，但是后端数据库记录的时候往往是从业务的角度决定记录什么字段，但是在分析的角度，可能就没有我们需要分析的维度了，所以，此时可以再增加一个步骤，将点赞的日志数据采集下来，日志数据上可以很方便的带上我们需要分析的维度，且对业务方没太大影响。

三、前端埋点和后端埋点

有篇文档写的非常详细，这里直接copy过来，重点是能后端记录的优先后端记录。

前端埋点：收集数据在客户端进行，用户在客户端浏笕页面、点击按钮、滑动界面等均可采集。一般在用户动作发生时，采集数据后端埋点：收集数据在服务器端进行，收集的是http请求发生时的数据，更多的是数据层，业务逻辑层的数据。一般在http请求触发、或结果返回时采集数据
前端埋点
优势：直接了断，贴近用户在产品中的行为
劣势：
App迭代更新有变化时，需要重新埋点
埋点更新需要伴随App更新，用户不更新App时，采集不到相应数据
涉及到本地缓存和公网传输，数据丢失率高于后端埋点，数据准确性低于后端埋点
事件发生时间使用客户端时间，时间记录存在与标准时间不同步的情况
数据经过公网传输，需要考虑安全性问题
数据时效性差
后端埋点
优势：
埋点的新增和修改均不受客户端发版的限制
数据仅在内网传输，时效性、安全性、可靠性问题迎刃而解
日志变更可以直接在服务端变更，不依赖客户端的发版与更新
劣势：
部分行为或者字段，一般情况下在后端采集不到，需要客户端传递给后端，如设备信息、网络信息等
与后端服务耦合，代码不合理时可能影响业务稳定性
如何选择
纯前端交互行为，如：下拉框选择、按钮点击等，选择前端埋点
业务行为多选择在后端埋点；如评论、点赞、购买、提交订单、支付等行为
前端、后端都可以获取数据时，优先后端接入数据

也可以参考这篇文章：客户端埋点 or 服务端埋点

四、埋点方案设计的四要素

数据采集方式

1. 确认事件与变量
事件：指产品中的操作
变量：指描述事件的属性
2. 明确事件的触发时机
3. 规范命名
4. 明确优先级

五、埋点采集方式、触发时机、同步策略

前端触发就上报：点击“去支付”按钮就触发，这是最常见的前端采集方式，如果业务方是想了解的是“用户是否有意愿支付”，那么当用户点击“支付订单”这个按钮时或者发出支付请求就触发采集即可。这是时机埋点采集时最常用的一种方式。
前端获取后端结果后上报：这种方式一般是由于除了记录用户操作外，还需要获取用户操作的结果，比如需要收到后端结果的返回，以判断用户是否支付成功，以及失败情况下具体的报错原因，那么其触发机制必须等到前端拿到后端服务器处理结果后，再进行上报。
后端触发就上报：这种方式是指后端处理后直接上报，比如后端处理付款请求出结果时直接后端触发上报。采用这种方式的主要好处是数据不会出现漏报，但也由于是直接后端上报，基本是拿不到用户的设备终端及软硬件环境属性的，比如用户在支付时用的是什么设备、网络环境是什么等信息。
后端获取前端属性且触发后上报：这种情况就是为了解决后端埋点的软硬件环境属性问题，让前端在用户点击“去支付”时，将相应的属性一并传回服务器，服务器发生“支付成功”时，带上相应的前端属性上报数据。当然这种方式理论上是数据准确度、完备性最高的，但同时这种方式的采集成本会比较高，意味着所有端的前后端接口需要做变更，建议是只在数据准确性、前端属性获取两个需求都非常强时采用。

通过以上的描述大家也能看得出来，每种触发时机有各自的优劣势，在具体设计触发时机中，决定具体采用哪种方式的因素，特别值得关注：业务含义、旧识别机制、前端软硬件环境属性获取、业务处理结果获取、数据准确性要求。神策团队在给企业做事件设计时也会格外关注这些点；在后续企业自己做事件设计时候，企业也应该从这几个方面给研发同学讲解清楚，以保证采集的数据更符合场景诉求。

为了最大限度的保证数据的完整性和准确性，SDK 采集的数据，一般会先缓存到本地，待符合一定条件之后再同步。

常见的数据同步策略：

事件先缓存到本地 sqlite3
本地缓存一定条数量的事件会同步（默认 100 条）
固定时间间隔同步（默认 15 秒）
核心事件发生同步（trackInstallation、login 等）
APP 退出尝试同步
本地缓存太多事件时的处理

在 APP 退出时尝试同步数据，是为了防止用户之后长时间不启动 APP、不再启动 APP 或者直接卸载 APP。

六、埋点工作流程

七、如何标识用户与设备

在 Android 如何准确标识设备？各个方案有什么优缺点？
常用的设备唯一标识符有：UUID、MAC 地址、IMEI、AndroidId。
各自的优缺点
UUID：UUID 一般会配合 SharedPreferences 使用来标识一个设备，它的优点是不需要任何权限，也不会有任何机构认为 UUID 有过度窃取用户隐私的嫌疑，缺点在于如果用户卸载重装 App ，存储的 UUID 就会被抹掉。
MAC 地址：MAC 地址就是设备网卡的唯一识别码，它的优点是 MAC 地址值不会改变并且值唯一，缺点在于需要获取权限并且在 Android 6.0 之后任何手机通过 getMacAddress() 都只能获取到 “02:00:00:00:00:00” 这个值，虽然有其他途径获取但很容易触犯到隐私条款。
IMEI：IMEI 是国际移动设备身份码，它的优点同样是值不会改变并且值唯一，缺点在于需要获取权限，并且在 Android 10 版本系统层面禁止了 IMEI 的获取，IMEI 同样也容易触犯到隐私条款。
AndroidId：AndroidId 是设备首次运行的时候，系统随机生成的一串 16 进制的数字，它的优点是不需要任何权限、每个设备值唯一且值也不像 UUID 那样容易变，缺点就是在用户恢复出厂设置的时候 AndroidId 会重新生成。在 Android 8 之前不同 App 对于同一设备取到的 AndroidId 甚至是相同的，在 Android 8 后 AndroidId 的生成开始与包名有关，不同包名的 App 对于同一个设备取到的 AndroidId 开始不同。
神策 Android SDK 默认正是采用了 AndroidId 来标识一个设备，如果 AndroidId 获取不到则获取随机的 UUID。

ios中的用户标识方案可以看这篇文章：iOS获取设备唯一标识的8种方法
现在苹果主推 IDFA 和 IDFV 这两种方法，分别对外和对内，但是 IDFV 在 APP 重新安装时会更改，所以我的方法是通过第一次生成的 IDFV 存储到 keychain 中，以后每次获取标识符都从 keychain 中获取。
如果开启 IDFA ，神策 SDK 会优先获取 IDFA，如果获取失败再尝试获取 IDFV。使用 IDFA 能避免用户在重装 App 后设备 ID 发生变化的情况。

这里其实还涉及到了oneid的内容，理想状态下是我们能够通过一个id准确的标识用户，但是实际情况会比较复杂，这块儿没什么特别完美的方案，oneid的实施方案可以参照oneid实现。

八、时长、时间戳采集方案

1、时长的采集方案

Android 和 iOS，都有一个 boot time 的概念，即手机启动了多长时间。可以理解为系统里有一个定时器，每次手机启动后，这个定时器就从零开始计时，与客户端时间无关，如果使用这个 time 来计算间隔，就是 100% 准确的，之后再在服务器端进行数据纠正。

2、时间戳的纠正

神策的时间纠正策略：

用户在手机时间戳 T1 时触发了一个事件（比如登录事件），然后事件存入本地缓存。数据采集 SDK 在用户手机时间戳 T2 时开始同步事件数据（包含登录事件），然后服务端通过 HTTP(S) 的 Request Header Date 可以获取到数据采集 SDK 发起 Request 时用户手机时间戳 T2 。

如果 T2 与当前服务端的时间戳 T3 的误差在一定的可接受范围之内（比如 30s，这是因为网络请求也需要一定的时间），就可以说明当前用户手机的时间戳是准确的（我们假设服务端时间戳是准确的，绝大部分情况下也都是准确的），同时说明登录事件发生时的时间戳 T1 也是准确的，服务端在接收到登录事件时无需做任何的特殊处理。

如果 T2 与 T3 相差比较大（比如上图中的 T2 为 15:00，T3 为 16:00），我们可以确定当前用户手机的时间戳 T2 是不准确的，即比服务端的时间戳晚了一个小时（16:00 - 15:00 = 一个小时），从而就可以假设登录事件发生时的时间戳 T1 也比服务端晚了一个小时，即 14:00 加上一个小时应该为 15:00。

因此，服务端在接收到事件时会把登录事件的时间戳 T1 再加上一个小时，变成 15:00，从而就达到了“时间纠正”的效果。

当然，“时间纠正”策略，也无法确保可以 100% 解决所有和时间戳相关的问题。比如，还是以上图为例，如果在时间戳 T1 和 T2 之间，用户手机的时间戳再次发生了人为变更，那么，该方案就无法正确的进行时间纠正了，这是因为时间戳 T2 和 T3 之间的误差额，与时间戳 T1 和当时服务端对应时间戳的差额就不相等了。

但从实际情况来看，由于数据采集 SDK 一般都会以较短的固定时间间隔同步数据（比如 15s），所以时间戳 T1 和 T2 之间的时间间隔会比较短，本身发生时间戳变更的可能性就比较小，即使真正发生变更了，影响到的事件数量也比较少（15s 内可能只会触发几条事件）。因此，“时间纠正”策略可以解决 99% 以上的和事件时间戳相关的问题。

九、解决埋点问题的根源性解决方案

把埋点采集当成独立的研发业务来对待。

实际上，造成埋点成本高、效率低下的真正原因，就在于没有找到合适的埋点管理和落地方法，埋点的全面性和复用性太低，导致整个埋点体系持续陷入拆东墙补西墙、每个采集的需求都要单独走完整的采集业务流程，沟通、验证的成本高，对团队的整体消耗过大。

matplotlib可视化基础

2020-04-12T14:49:20.000Z

matplotlib制作可视化图表是python数据分析中的一个非常重要的模块，这个模块我之前一直没怎么使用过，这里重新练习下matplotlib模块的使用，数据源来自天池比赛中的二手车交易价格预测数据。

一、matplotlib基础

1、matplotlib图形的基本构成部分

# 一般在jupyter notebook中导入matplotlib的方式
import matplotlib as mpl
import matplotlib.pyplot as plt
%matplotlib inline #在notebook中嵌入画图

基础 (primitives) 类：线 (line), 点 (marker), 文字 (text), 图例 (legend), 网格 (grid), 标题 (title), 图片 (image) 等。
容器 (containers) 类：图 (figure), 坐标系 (axes), 坐标轴 (axis) 和刻度 (tick)

基础类元素是我们想画出的标准对象，而容器类元素是基础类元素的寄居出，它们也有层级结构。

图 → 坐标系 → 坐标轴 → 刻度→绘制图型

如下图所示，主要元素及结构：figure(图形)、axes(子图形)、title(标题)、legend(图例)、Major tick(大标尺刻度)、Minor tick(小标尺刻度)、Major tick label(大标尺刻度数值)、Minor tick label(小标尺刻度数值)、Y axis label(y轴指标说明)、X axis label(x轴指标说明)、Line(线型图)、Markers(数据标注点)、Grid(格子)等。

2、matplotlib图形的几个容器类：

2.1 Figure对象（图）

整个图形即是一个Figure对象。
Figure对象至少包含一个子图，也就是Axes对象。
Figure对象包含一些特殊的Artist对象，如title标题、图例legend。
Figure对象包含画布canvas对象。 canvas对象一般不可见，通常无需直接操作该对象，matplotlib程序实际绘图时需要调用该对象。

figure对象上可以添加各种元素：文字、图片、折线等，接下来实际操作下：

# 在figure中显示文本并自定义位置
plt.figure()
plt.text(x=0.5,y=0.5,s='Figure',ha='center',va='center',size=20,alpha=0.5)
# 第一、二个参数是指横轴和纵轴坐标
# 第三个参数字符是指要显示的内容
# ha, va 是横向和纵向位置
# size 设置字体大小
# alpha 设置字体透明度 (0.5 是半透明)

# 用 Image.open() 将图片转成像素存在 ndarray 中，再用 plt.imshow() 展示。
from PIL import Image #导入图片处理模块
plt.figure()
plt.xticks([]) #将x、y的刻度置为null
plt.yticks([])
im = np.array(Image.open('111.png'))
plt.imshow(im)
plt.show()

2.2 Subplot对象（子图）

常用方法set_xlim()以及set_ylim()：设置子图x轴和y轴对应的数据范围。

set_xticks()以及set_yticks()：设置子图的x轴和y轴刻度标签

set_title()：设置子图的标题。

set_xlabel()以及set_ylable()：设置子图x轴和y轴指标的描述说明

# subplot(rows, columns, i-th plots) 
plt.figure()
plt.subplot(2,1,1)
plt.xticks([])
plt.yticks([])
plt.text(x=0.5,y=0.5,s='subplot(2,1,1)',ha='center',va='center',size=20,alpha=0.5)
plt.subplot(2,1,2)
plt.xticks([])
plt.yticks([])
plt.text(x=0.5,y=0.5,s='subplot(2,1,2)',ha='center',va='center',size=20,alpha=0.5)
plt.show()
# 声明完子图后，下面所有代码就只在这幅子图上生效，直到声明下一幅子图

# 循环绘制子图
fig,axes = plt.subplots(nrows=2,ncols=2)
# enumerate() 函数用于将一个可遍历的数据对象(如列表、元组或字符串)
# 组合为一个索引序列，同时列出数据和数据下标，一般用在 for 循环当中。
for i,ax in enumerate(axes.flat): 
    ax.set(xticks=[],yticks=[])
    s = 'subplot(2,2' + str(i) + ')'
    ax.text(0.5,0.5,s,size=20,alpha=0.5,ha='center',va='center')

2.3 Axes对象（坐标系）

字面上理解，Axes是数据轴Axis的复数，但它并不是指数据轴，而是子图对象，可以这样理解，每一个子图都有x和y轴，Axes则用于代表这两个数据轴所对应的一个子图坐标系对象，我们每次画图看起来是在图（Figure）中进行，实际是绘制在Axes坐标系对象中的，一个Figure对象能有多个Axes对象。

一幅图 (Figure) 中可以有多个坐标系 (Axes)，说一幅图中有多幅子图 (Subplot)，因此坐标系和子图是不是同样的概念？
在绝大多数情况下是的，两者有一点细微差别：
子图在母图中的网格结构一定是规则的
坐标系在母图中的网格结构可以是不规则的
子图是坐标系的一个特例。

坐标系比子图更通用，有两种生成方式

用 gridspec 包加上 subplot()
用 plt.axes()

# 不规则网格
import matplotlib.gridspec as gridspec
G = gridspec.GridSpec(3,3)

ax1 = plt.subplot(G[0:1,:3])  #类似于numpy的选取方式，选取矩阵数据
plt.xticks([]),plt.yticks([])
plt.text(x=0.5,y=0.5,s='Axes 1',ha='center',va='center',size=20,alpha=0.5)

ax2 = plt.subplot(G[1:2,0:2])  #类似于numpy的选取方式，选取矩阵数据
plt.xticks([]),plt.yticks([])
plt.text(x=0.5,y=0.5,s='Axes 2',ha='center',va='center',size=20,alpha=0.5)

ax3 = plt.subplot(G[1:3,2:3])  #类似于numpy的选取方式，选取矩阵数据
plt.xticks([]),plt.yticks([])
plt.text(x=0.5,y=0.5,s='Axes 3',ha='center',va='center',size=20,alpha=0.5)

ax4 = plt.subplot(G[2:3,0:1])  #类似于numpy的选取方式，选取矩阵数据
plt.xticks([]),plt.yticks([])
plt.text(x=0.5,y=0.5,s='Axes 4',ha='center',va='center',size=20,alpha=0.5)

ax5 = plt.subplot(G[2:3,1:2])  #类似于numpy的选取方式，选取矩阵数据
plt.xticks([]),plt.yticks([])
plt.text(x=0.5,y=0.5,s='Axes 5',ha='center',va='center',size=20,alpha=0.5)

plt.show()

# 大图套小图
plt.axes([0.1,0.1,0.8,0.8])
# plt.xticks([]),plt.yticks([])
plt.text(x=0.6,y=0.6,s='axes([0.1,0.1,0.8,0.8])',va='center',ha='center',size=20,alpha=0.5)

plt.axes([0.2,0.2,0.3,0.3])
plt.text(x=0.5,y=0.5,s='axes([0.2,0.2,0.3,0.3])',va='center',ha='center',size=10,alpha=0.5)

plt.show()
# 此时的axes对象的坐标和xticks刻度上的坐标并不一致
# plt.axes([l,b,w,h]) 
# 其中 [l, b, w, h] 可以定义坐标系

# l 代表坐标系左边到 Figure 左边的水平距离
# b 代表坐标系底边到 Figure 底边的垂直距离
# w 代表坐标系的宽度
# h 代表坐标系的高度
# 如果 l, b, w, h 都小于 1，那它们是标准化 (normalized) 后的距离。比如 Figure 底边长度为 10， 坐标系底边到它的垂直距离是 2，那么 b = 2/10 = 0.2。

两种生成坐标系的推荐代码：

第一种，同时生成图和坐标系：

fig,ax = plt.subplots()
ax.set(xticks=[],yticks=[])
s='xxx'
ax.text(x=0.5,y=0.5,s=s,ha='center',va='center',size=20,alpha=0.5)
plt.show()

第二种，先生成图，再添加坐标系

fig=plt.figure()
ax = fig.add_subplot(1,1,1)
ax.set(xticks=[],yticks=[])
s='xxx'
ax.text(x=0.5,y=0.5,s=s,ha='center',va='center',size=20,alpha=0.5)
plt.show()

2.4 Axis对象（坐标轴）

Axis是数据轴对象，主要用于控制数据轴上刻度位置和显示数值，通常是二维的，有两条坐标轴

横轴：XAxis
纵轴：YAxis

每个坐标轴包含两个元素

容器类元素「刻度」，该对象里还包含刻度本身和刻度标签
基础类元素「标签」，该对象包含的是坐标轴标签

fig, ax = plt.subplots()
ax.set_xlabel('x label',size=20,color='red',rotation=30) 
#所有的文本对象都可以调整文字和颜色以及角度
ax.set_ylabel('t label')


for label in ax.xaxis.get_ticklabels():
    # x轴的label是文本对象，都可以调整相关文本的参数，y轴同样
    label.set_color('blue')
    label.set_rotation(45)
    label.set_fontsize(20)
    

for line in ax.yaxis.get_ticklines():
    # y轴的line对象进行调整，线条的对象同样有类似的属性
    line.set_color('green')
    line.set_markersize(500)
    line.set_markeredgewidth(30)

2.5 Tick对象（刻度）

2.6 Artist对象

基本上所有的对象都是一个Artist对象，包括Figure对象、Axes对象和Axis对象，可以将Artist理解为一个基本类。当提交代码，图像最终呈现时，所有的artist对象都会绘制于canvas画布上，这个对象其实大部分时间用不上。

3、matplotlib图形的基础元素：

要画出一幅有内容的图，还需要在容器里添加基础元素比如线 (line), 点 (marker), 文字 (text), 图例 (legend), 网格 (grid), 标题 (title), 图片 (image) 等，具体来说

画一条线，用 plt.plot() 或 ax.plot()
画个记号，用 plt.scatter() 或 ax.scatter()
添加文字，用 plt.text() 或 ax.text()
添加图例，用 plt.legend() 或 ax.legend()
添加图片，用 plt.imshow() 或 ax.imshow()

二、实例绘图

本实例绘图数据依据天池比赛零基础入门数据挖掘 - 二手车交易价格预测的数据源进行绘制，探索该部分数据结构。

首先读取数据

# 读取天池二手车交易价格预测的训练数据
import pandas as pd
import numpy as np 
import matplotlib.pyplot as plt
dftrain = pd.read_csv(r'.\\天池二手车交易交额预测\\used_car_train_20200313.csv',sep=' ')
dftrain.head()

	SaleID	name	regDate	model	brand	bodyType	gearbox	power	kilometer	…	v_5	v_6	v_7	v_8	v_9	v_10	v_11	v_12	v_13	v_14
0	0	736	20040402	30.0	6	1.0	0.0	60	12.5	…	0.235676	0.101988	0.129549	0.022816	0.097462	-2.881803	2.804097	-2.420821	0.795292	0.914762
1	1	2262	20030301	40.0	1	2.0	0.0	0	15.0	…	0.264777	0.121004	0.135731	0.026597	0.020582	-4.900482	2.096338	-1.030483	-1.722674	0.245522
2	2	14874	20040403	115.0	15	1.0	0.0	163	12.5	…	0.251410	0.114912	0.165147	0.062173	0.027075	-4.846749	1.803559	1.565330	-0.832687	-0.229963
3	3	71865	19960908	109.0	10	0.0	1.0	193	15.0	…	0.274293	0.110300	0.121964	0.033395	0.000000	-4.509599	1.285940	-0.501868	-2.438353	-0.478699
4	4	111080	20120103	110.0	5	1.0	0.0	68	5.0	…	0.228036	0.073205	0.091880	0.078819	0.121534	-1.896240	0.910783	0.931110	2.834518	1.923482

5 rows × 31 columns

主要指标含义如下：

train.csv

SaleID - 销售样本ID
name - 汽车编码
regDate - 汽车注册时间
model - 车型编码
brand - 品牌
bodyType - 车身类型
fuelType - 燃油类型
gearbox - 变速箱
power - 汽车功率
kilometer - 汽车行驶公里
notRepairedDamage - 汽车有尚未修复的损坏
regionCode - 看车地区编码
seller - 销售方
offerType - 报价类型
creatDate - 广告发布时间
price - 汽车价格
v_0’, ‘v_1’, ‘v_2’, ‘v_3’, ‘v_4’, ‘v_5’, ‘v_6’, ‘v_7’, ‘v_8’, ‘v_9’, ‘v_10’, ‘v_11’, ‘v_12’, ‘v_13’,’v_14’ 【匿名特征，包含v0-14在内15个匿名特征】

数字全都脱敏处理，都为label encoding形式，即数字形式。

首先对数据进行常规解读：

dftrain.info()
# 输出：
<class 'pandas.core.frame.DataFrame'>
RangeIndex: 150000 entries, 0 to 149999
Data columns (total 31 columns):
SaleID               150000 non-null int64
name                 150000 non-null int64
regDate              150000 non-null int64
model                149999 non-null float64
brand                150000 non-null int64
bodyType             145494 non-null float64
fuelType             141320 non-null float64
gearbox              144019 non-null float64
power                150000 non-null int64
kilometer            150000 non-null float64
notRepairedDamage    150000 non-null object
regionCode           150000 non-null int64
seller               150000 non-null int64
offerType            150000 non-null int64
creatDate            150000 non-null int64
price                150000 non-null int64
v_0                  150000 non-null float64
v_1                  150000 non-null float64
v_2                  150000 non-null float64
v_3                  150000 non-null float64
v_4                  150000 non-null float64
v_5                  150000 non-null float64
v_6                  150000 non-null float64
v_7                  150000 non-null float64
v_8                  150000 non-null float64
v_9                  150000 non-null float64
v_10                 150000 non-null float64
v_11                 150000 non-null float64
v_12                 150000 non-null float64
v_13                 150000 non-null float64
v_14                 150000 non-null float64
dtypes: float64(20), int64(10), object(1)
memory usage: 35.5+ MB

1 2	dftrain.describe().round(2) # 输出

	SaleID	name	regDate	model	brand	bodyType	fuelType	gearbox	power	kilometer	…	v_5	v_6	v_7	v_8	v_9	v_10	v_11	v_12	v_13	v_14
count	150000.00	150000.00	150000.00	149999.00	150000.00	145494.00	141320.00	144019.00	150000.00	150000.00	…	150000.00	150000.00	150000.00	150000.00	150000.00	150000.00	150000.00	150000.00	150000.00	150000.00
mean	74999.50	68349.17	20034170.51	47.13	8.05	1.79	0.38	0.22	119.32	12.60	…	0.25	0.04	0.12	0.06	0.06	-0.00	0.01	0.00	0.00	-0.00
std	43301.41	61103.88	53649.88	49.54	7.86	1.76	0.55	0.42	177.17	3.92	…	0.05	0.05	0.20	0.03	0.04	3.77	3.29	2.52	1.29	1.04
min	0.00	0.00	19910001.00	0.00	0.00	0.00	0.00	0.00	0.00	0.50	…	0.00	0.00	0.00	0.00	0.00	-9.17	-5.56	-9.64	-4.15	-6.55
25%	37499.75	11156.00	19990912.00	10.00	1.00	0.00	0.00	0.00	75.00	12.50	…	0.24	0.00	0.06	0.04	0.03	-3.72	-1.95	-1.87	-1.06	-0.44
50%	74999.50	51638.00	20030912.00	30.00	6.00	1.00	0.00	0.00	110.00	15.00	…	0.26	0.00	0.10	0.06	0.06	1.62	-0.36	-0.13	-0.04	0.14
75%	112499.25	118841.25	20071109.00	66.00	13.00	3.00	1.00	0.00	150.00	15.00	…	0.27	0.10	0.13	0.08	0.09	2.84	1.26	1.78	0.94	0.68
max	149999.00	196812.00	20151212.00	247.00	39.00	7.00	6.00	1.00	19312.00	15.00	…	0.29	0.15	1.40	0.16	0.22	12.36	18.82	13.85	11.15	8.66

8 rows × 30 columns

三、基础参数

参照这个GitHub地址总结的：https://github.com/rougier/matplotlib-cheatsheet

最后

给出以上实例的jupyter notebook文件：

matplotlib基础.html

给出matplotlib的预定义格式

# 可视化显示在页面，包含3种
# %matplotlib inline
# %matplotlib notebook
# %matplotlib qt5 


#%config InlineBackend.figure_format = 'svg' #输出矢量图，放大不失真
#原始风格
#%config InlineBackend.figure_format='retina'

# 导入所有使用到的模块，并设定matplotlib的绘图基础格式
import matplotlib.pyplot as plt
import pandas as pd
import numpy as np
%matplotlib inline

# 统一绘图格式
large = 22; med = 16; small = 12 #其余字体大小统一设置为14
params = {'axes.titlesize': large,
          'legend.fontsize': med,
          'figure.figsize': (15, 8),
          'axes.labelsize': med,
          'axes.titlesize': med,
          'xtick.labelsize': med,
          'ytick.labelsize': med,
          'figure.titlesize': large}
plt.rcParams.update(params)
plt.style.use('seaborn-whitegrid') #更改模块风格

plt.rcParams['font.sans-serif']=['SimHei'] #用来正常显示中文标签 plt.rcParam
plt.rcParams['axes.unicode_minus']=False #用来正常显示负号
# plt.rcParams['savefig.dpi'] = 300 #保存图片像素
# plt.rcParams['figure.dpi'] = 300 #显示分辨率
# plt.rcParams['animation.embed_limit' ] = 100 #限定animation模块的最大mb


#百度 Echarts 里面的一组颜色卡
r_hex = '#dc2624'     # red,       RGB = 220,38,36
dt_hex = '#2b4750'    # dark teal, RGB = 43,71,80
tl_hex = '#45a0a2'    # teal,      RGB = 69,160,162
r1_hex = '#e87a59'    # red,       RGB = 232,122,89
tl1_hex = '#7dcaa9'   # teal,      RGB = 125,202,169
g_hex = '#649E7D'     # green,     RGB = 100,158,125
o_hex = '#dc8018'     # orange,    RGB = 220,128,24
tn_hex = '#C89F91'    # tan,       RGB = 200,159,145
g50_hex = '#6c6d6c'   # grey-50,   RGB = 108,109,108
bg_hex = '#4f6268'    # blue grey, RGB = 79,98,104
g25_hex = '#c7cccf'   # grey-25,   RGB = 199,204,207

# 第二组色卡，从左往右
zhong_gray = '#8C8EA1' #RGB=140，142，161 
qian_gray = '#959EC3' #RGB=149，158，195 
dan_gray ='#D9DBF5' #RGB=217，219，245 
qian_blue = '#3B4F88' #RGB=59，79，136 
shen_black = '#0A0D1E' #RGB=10，13，30 
shen_gray = '#786B7A' #RGB=120，107，122

数据分析报告怎么写？

2020-04-12T06:58:22.000Z

最近太注重于工程实现，忽略了作为一个分析师最重要的职责：分析业务，so，在此重新整理下分析报告的写作逻辑，开始深入参与业务，分析业务。

一、分析报告的目的

解答业务问题
展示分析结果
验证分析质量
为决策提供参考依据

简单来说，分析报告最后的结果一定只有2个，增加收益或者减少损失。

二、分析报告类型

问题分析型：有明确的问题需要分析解答
要牢记：先问是不是，再问为什么。因为：脱离概率谈个案、脱离整体谈细节、脱离数据谈现状、脱离标准谈判断，统统都是耍流氓
数据解读型：无明确问题，需要从常规数据中解读

三、数据分析报告的6个步骤

目标确定、数据获取、数据清洗、数据整理、描述分析、洞察结论，撰写数据分析报告。

四、分析报告的整体逻辑

S（Situation）情景——熟悉的情景、场景。

此处可以对业务场景进行描述，阐述，描述你要做这个数据分析目的、目标和期望对业务上有什么帮助。

C（Complication）冲突——实际情况往往和我们的要求有冲突。

对于分析的数据结果进行阐述，描述预测的数据情况

Q（Question）疑问——怎么办？

描述该种数据表现的状况对业务的影响，探究产生这样数据结果的原因

A（Answer）回答——解决方案

给出应对方案及下一步的业务调整计划及数据跟踪计划。。

五、分析报告的核心

1.结构清晰，主次分明

2.每个分析都有结论，结论一定要明确

3.分析结论不要太多，要精

4.分析结论一定要基于紧密严禁的数据分析推导过程，要有论点、论据、论证过程

5.图表化、易读化，务必注明数据单位和特殊指标计算方法

6.讲故事的讲述过程

7.给出业务解决方案及跟踪计划

六、思维导图格式

分析类型：问题分析or数据解读
问题or数据是什么
结论
数据来源
数据论证
结论
解决方案

七、分析报告的输出形式

思维导图

ppt

markdown

考虑到对思路的梳理，我比较倾向于使用markdown形式的文章来输出结论，这样稍微会显得有点啰嗦，但是思路上会比较连贯清洗。

你在跟谁沟通？

你希望受众了解哪些内容或者做什么？

如何用数据表达自己的观点？

pandas基础操作笔记

2020-04-04T14:49:20.000Z

记录下常用的pandas的操作代码。

Jupyter Notebook环境配置：https://www.zhihu.com/question/40012144/answer/363009024

不推荐使用jupyter-themes，页面越改越丑，我只想改个里面的字体。

# python的pandas模块获取日期间隔
import pandas as pd
date_list = [d.strftime("%Y%m%d") for d in pd.date_range('2020-05-25', end='2020-06-07', freq="d")]
date_list

# pandas计算唯一值个数
dferr.groupby(by=['ds']).userid.nunique()
dferr.pivot_table(index=['ds'],columns=['user_level'],values=['userid'],aggfunc=lambda x:len(x.unique()),margins=True)

# pandas按照百分比展示
df2.div(df2.iloc[-1,-1],axis=0).applymap(lambda x:format(x,'.1%'))
df3.div(df3.iloc[:,-1],axis=0).applymap(lambda x:format(x,'.1%'))

Jupyter Notebook笔记

最后再来个pandas官方出的速查图：

github地址：Pandas_Cheat_Sheet