神策对接QA

3个月 4.17 第二次沟通 4.28 最终业务需求确定 5.4 开发

5月底用户行为报表第一版

1. 打点数据，用户行为树不推给我们？ 两套系统， 分析系统， hive落地 算法和

2. http接口？数据如何落地？

3. 效果评估

4. 埋点对接事项

   • 埋点上报的整个流程
   • js sdk 使用方式
   • 打点数据格式(schema) (用户id, 设备id, 设备型号,浏览器,事件 , itemId, 时间戳,itemInfo, orderInfo, position )
   • 数据最终流向, 如何给到我们(接口&kafka) ———
   • 埋点对接周期(时间规划安排) +++++

5. 是否也对接搜索&推荐

   • 搜索/推荐服务接口方式(http/grpc)
   • 服务耗时(平均/p90/p95)
   • 对接周期(时间规划安排)

6. 效果评估

   • 如果对接搜索推荐, 那如何评估效果 (uv 转化 ? GMV ?)
   • AB 实验分流 (AAB 33% ?, AB 50%?)
   • 实验报表哪边出(他们出, 自己也要有一份)
   • 效果指标达到多少 可以推全

7. 算法?

   • 搜索:
     • 搜索存储依赖Es?
     • 搜索query 词 处理方式: 归一化(词干提取&词形还原), 丢词
     • 有没有做类目预测: 用的是啥模型(fasttext? tensor flow ?)
     • 有没有用到clip模型, query->标题的向量, query->主图的向量
     • clip模型与正常词召回的分数如何融合的?
   • 推荐:
     • i2i 数据的产出模型是啥? swing?
     • 一般是做几路召回?
   • 排序
     • 用的啥模型: 规则? xbg? TensorFlow?
     • 规则的话, 主要是销量 , 还是销量+点击融合
     • xgb 模型的话, 主要的优化目标是什么

A

    * 用户数据从埋点出用户行为模型
    * 个性化使用u2i,详情页使用i2i
    * 按历史用户数据召回，价格标签召回，深度学习召回等多路

1. 首先，复查代码，检查是否有不合理的请求逻辑或异常处理

   • 如果请求的是内部服务，可以采用降级策略，根据服务的可用性和重要性，动态调整请求的频率和超时时间。例如，当服务超时或不可用时，可以将请求的间隔从固定频率逐步延长为3秒，5秒，60秒等

2. 其次，复查日志，分析是否有恶意的请求行为或攻击行为

   • 如果请求的是外部服务，可以采用防御策略，根据请求的特征，如URI，UA，IP等，进行限流或拦截。

3. 最后，如果以上措施都无法解决问题，可以考虑从发布策略上做调整

   • 如果无法调整， 从将PHP发布策略做变更 ①可以从业务层面降低发布的频率和范围，尽量避免在高峰期或敏感期发布②可以采用递进发布，分批次、分流量发布，这样有问题及时监控和回滚

4. im测试环境

   1. 老的IM测试服关闭端口和外网

5. im02服务去除，删掉番号，改为纯api服务

6. 新IM服务

   1. test04是测试环境
   2. im03是正式环境
   3. im04是正式环境

7. 哪个环境可以做oss测试

   1. 下周可以

8. jk的自动部署

9. 灰度

10. etcd

11. apisix日志服务

12. hf的性能分析