用户流失分析：两层模型：细分用户、产品、渠道，看到底是哪里用户流失了。注意由于是用户流失问题，所以这里细分用户时可以细分用户处在生命周期的哪个阶段。指标拆解：用户流失数量 = 该群体用户数量*流失率。拆解，看是因为到了这个阶段的用户数量多了（比如说大部分用户到了衰退期），还是这个用户群体的流失率比较高内外部分析：a. 内部：新手上手难度大、收费不合理、产品服务出现重大问题、活动质量低、缺少留存手段
18192654262
2021-01-31
首先要定位到现象真正发生的位置，到底是谁的销售额变低了？这里划分的维度有：a. 用户（画像、来源地区、新老、渠道等）b. 产品或栏目c. 访问时段定位到发生未知后，进行问题拆解，关注目标群体中哪个指标下降导致网站销售额下降：a. 销售额=入站流量x下单率x客单价b. 入站流量 = Σ各来源流量x转化率c. 下单率 = 页面访问量x转化率d. 客单价 = 商品数量x商品价格确定问题源头后，对问题原因
18192654262
2021-01-31
分类问题用机器学习方法建模解决，我想到的特征有：（1）商家特征：商家历史销量、信用、产品类别、发货快递公司等（2）用户行为特征：用户信用、下单量、转化率、下单路径、浏览店铺行为、支付账号（3）环境特征（主要是避免机器刷单）：地区、ip、手机型号等（4）异常检测：ip地址经常变动、经常清空cookie信息、账号近期交易成功率上升等（5）评论文本检测：刷单的评论文本可能套路较为一致，计算与已标注评论文
18192654262
2021-01-31
分类问题可以用机器学习的方法去解决，下面是我目前想到的特征：（1）渠道特征：渠道、渠道次日留存率、渠道流量以及各种比率特征（2）环境特征：设备（一般伪造假用户的工作坊以低端机为主）、系统（刷量工作坊一般系统更新较慢）、wifi使用情况、使用时间、来源地区、ip是否进过黑名单（3）用户行为特征：访问时长、访问页面、使用间隔、次日留存、活跃时间、页面跳转行为（假用户的行为要么过于一致，要么过于随机）、
18192654262
2021-01-31
采用技术接受模型（TAM）来分析，影响用户接受选择属性这件事的主要因素有：技术接受模型提出了两个主要的决定因素：①感知的有用性(perceived usefulness)，反映一个人认为使用一个具体的系统对他工作业绩提高的程度；②感知的易用性(perceived ease of use)，反映一个人认为容易使用一个具体的系统的程度。（1）感知有用性：a. 文案告知用户选择属性能给用户带来的好处（2
18192654262
2021-01-31
如果渠道使用时间较长，认为渠道的app激活量满足一个分布，比较可能是正态分布。求平均值和标准差，对于今日数值与均值差大于3/2/1个标准差的渠道进行预警。对于短期的新渠道，直接与均值进行对比。
18192654262
2021-01-31
收益 = 出价x流量x点击率x有效转化率，放广告的数量会提高流量，但会降低匹配程度，因此降低点击率。最大收益是找到这个乘积的最大值，是一个有约束条件的最优化问题。同时参考价格歧视方案，可以对不同的用户投放不同数量的广告。
18192654262
2021-01-31
收益 = 单价*销售量，那么我们的策略是提高单位溢价或者提高销售规模。提高单位溢价的方法：（1）品牌打造获得长期溢价，但缺陷是需要大量前期营销投入；（2）加工商品占据价值链更多环节，如熟玉米、玉米汁、玉米蛋白粉；重定位商品，如礼品化等；（3）价格歧视，根据价格敏感度对不同用户采用不同定价。销售量=流量x转化率，上述提高单位溢价的方法可能对流量产生影响，也可能对转化率产生影响。收益 = 单价x流量x
18192654262
2021-01-31
首先采用“两层模型”分析：对用户进行细分，包括新老、渠道、活动、画像等多个维度，然后分别计算每个维度下不同用户的次日留存率。通过这种方法定位到导致留存率下降的用户群体是谁。对于目标群体次日留存下降问题，具体情况具体分析。具体分析可以采用“内部-外部”因素考虑。a. 内部因素分为获客（渠道质量低、活动获取非目标用户）、满足需求（新功能改动引发某类用户不满）、提活手段（签到等提活手段没达成目标、产品自
18192654262
2021-01-31
采用两层模型（人群画像x人群转化）：新生儿出生数=Σ各年龄层育龄女性数量*各年龄层生育比率（一般面试中采用这种方法，即费米估计问题，可以参考《这也能想到?——巧妙解答无厘头问题》）从数字到数字：如果有前几年新生儿出生数量数据，建立时间序列模型（需要考虑到二胎放开的突变事件）进行预测找先兆指标，如婴儿类用品的新增活跃用户数量X表示新生儿家庭用户。Xn/新生儿n为该年新生儿家庭用户的转化率，如X200
18192654262
2021-01-31
第一范式: 每个列都不可以再拆分.第二范式: 非主键列完全依赖于主键,而不能是依赖于主键的一部分.第三范式: 非主键列只依赖于主键,不依赖于其他非主键.在设计数据库结构的时候,要尽量遵守三范式,如果不遵守,必须有足够的理由.比如性能. 事实上我们经常会为了性能而妥协数据库的设计.
18192654262
2021-01-31
横向分表是按行分表.假设我们有一张用户表,主键是自增ID且同时是用户的ID. 数据量较大,有1亿多条,那么此时放在一张表里的查询效果就不太理想.我们可以根据主键ID进行分表, 无论是按尾号分, 或者按ID的区间分都是可以的. 假设按照尾号0-99分为100个表,那么每张表中的数据就仅有100w.这时的查询效率无疑是可以满足要求的.纵向分表是按列分表.假设我们现在有一张文章表. 包含字段id-摘要-
18192654262
2021-01-31
在业务系统中,除了使用主键进行的查询,其他的我都会在测试库上测试其耗时,慢查询的统计主要由运维在做,会定期将业务中的慢查询反馈给我们.慢查询的优化首先要搞明白慢的原因是什么? 是查询条件没有命中索引?是load了不需要的数据列?还是数据量太大?所以优化也是针对这三个方向来的,首先分析语句,看看是否load了额外的数据,可能是查询了多余的行并且抛弃掉了,可能是加载了许多结果中并不需要的列,对语句进行
18192654262
2021-01-31
超大的分页一般从两个方向上来解决.数据库层面,这也是我们主要集中关注的(虽然收效没那么大),类似于select * from table where age > 20 limit 1000000,10这种查询其实也是有可以优化的余地的. 这条语句需要load1000000数据然后基本上全部丢弃,只取10条当然比较慢. 当时我们可以修改为select * from table where id
18192654262
2021-01-31
有三种格式,statement,row和mixed.statement模式下,记录单元为语句.即每一个sql造成的影响会记录.由于sql的执行是有上下文的,因此在保存的时候需要保存相关的信息,同时还有一些使用了函数之类的语句无法被记录复制.row级别下,记录单元为每一行的改动,基本是可以全部记下来但是由于很多操作,会导致大量行的改动(比如alter table),因此这种模式的文件保存的信息太多,
18192654262
2021-01-31
varchar的10代表了申请的空间长度, 也是可以存储的数据的最大长度, 而int的10只是代表了展示的长度, 不足10位以0填充. 也就是说,int(1)和int(10)所能存储的数字大小以及占用的空间都是相同的,只是在展示时按照长度展示.
18192654262
2021-01-31
char是一个固定长度字段, 假如申请了char(10)的空间, 那么无论实际存储多少内容.该字段都占用10个字符,而varchar是变长的,也就是说申请的只是最大长度,占用的空间为实际字符长度+1,最后一个字符存储使用了多长的空间.在检索效率上来讲,char > varchar,因此在使用中,如果确定某个字段的值的长度,可以使用char,应该尽量使用varchar.例如存储用户MD5加密后的密码
18192654262
2021-01-31
InnoDB支持事物，而MyISAM不支持事物InnoDB支持行级锁，而MyISAM支持表级锁InnoDB支持MVCC, 而MyISAM不支持InnoDB支持外键，而MyISAM不支持InnoDB不支持全文索引，而MyISAM支持。
18192654262
2021-01-31
MySQL支持多种存储引擎, 比如InnoDB, MyISAM, Memory, Archive等等.在大多数的情况下,直接选择使用InnoDB引擎都是最合适的, InnoDB也是MySQL的默认存储引擎.
18192654262
2021-01-31
密码散列,用户身份证号等固定长度的字符串应该使用char而不是varchar来存储, 这样可以节省空间且提高检索效率.
18192654262
2021-01-31
