GBDT和FTRL咋利用点击 下单，支付日志 建模 预测点击率呀
【GBDT和FTRL咋利用点击 下单，支付日志 建模 预测点击率呀】 如果只是打算根据ctr rerank，然后去预估ctr，那一般方案还是比较清晰的。
针对你的问题：
1）先要区分正负样本，预估点击率只需要用到曝光和点击日志即可，这部分一般在hadoop里做离线join，合并到一份日志。如果要做成实时模型，则需要在storm做实时join。全局标示你是指一次请求或查询的request id吧，肯定是需要的，否则无法把几份日志join起来。一般使用的时候还会对负样本做采样，然后在预估的时候再还原。贴一篇屈伟大大几年前pctr的入门文，关于如何join其中几幅图一看就知道了：广告点击率预测 - 推酷
2）特征工程部分是最耗时的，用户特征像你问的年龄性别这些基础属性都是离线计算好的，然后做成服务供预估的时候使用。而实际工程上还会用到实时特征，因为效果更好，这些一般会实现成session server，专门维护实时特征。至于用户id也是非常重要的特征，一般用在lr ftrl这种离散模型里，而不会用在gbdt这类树模型中。不过你提到了按照美团博客来的，应该可以知道他们在推荐上目前主要还是在用树模型，当然你也可以根据自己的应用场景和最终指标多加尝试。
■网友
主要想解决的问题是如何实时地计算用户偏好，从事对离线结果进行重排序，最后把重排序的结果推荐给用户。我们先来看问题：用户的离线推荐结果一般更新慢，如果预测错误，重新修正的周期比较久（比如一天），推荐效果不好。解决方法：利用用户的实时偏好对离线推荐结果重新排序，使得用户的实时推荐更加准确。我们先来看如何利用GBDT和FTRL来进行建模：1. 离线结果如何计算：利用用户的行为（点击，订单，坐标，etc.）计算活动得分（GBDT）。由于计算量大，每天更新。2. 实时偏好重排序：利用用户的实时行为对离线结果重新排序，利用FTRL。举个例子：1. 小A经常去选择一些中餐厅吃饭，离线结果计算出很多的符合条件的中餐厅，但其中也包含一些得分较低的其他餐厅（比如西餐厅）。2. 小A有在寻找新的餐厅，但是这次他更关注一些西餐厅，但是离线结果不能实时更新，给他推荐的只能是根据其“昨天”的行为推荐出来的大量的中餐厅，与其实时偏好不符合。但是如果加入实时的重排序逻辑，那么小A当前所浏览的西餐厅就会立即对之前的离线结果进行重排序。离线结果中一些得分较低的西餐厅通过实时偏好重排序之后的位置很可能会比较靠前，这样出来的结果更加符合小A当前的想法，推荐更有效果。
推荐阅读
- 河北承德危险废物综合利用处置率达100%
- 黄金时间■黄金时间丨打造海绵城市：节水从利用雨水开始
- |淮阴水政充分利用“双随机”平台 促进执法公平公正
- 司法所|川姜镇司法所盛赛飞利用父母偏心绝情，赶我出家门
- 计算机技术与科学专业怎样利用高中毕业的暑假
- 非计算机专业想要利用课余时间深入自学C++，想要找到比较体面的工作大概需要啥水平
- 可不可能利用网盘的秒传功能使用伪造的MD5（或其他信息）值进行文件分享
- 报告书|徐州诺恩固体废物处置有限公司废包装桶再生利用建设项目环境影响公示
- 一个利用量子纠缠实现超光速通讯的构想，可行吗
- 女子利用超市自助收银逃单，总额不足300元为何以盗窃罪判刑？