日志处理实战:一个外卖网站解决方案(持续更新中)

本文涉及的产品
对象存储 OSS,20GB 3个月
云备份 Cloud Backup,100GB 3个月
对象存储 OSS,恶意文件检测 1000次 1年
简介: “我要点外卖“是一个平台型电商网站,用户、餐厅、配送员等。用户可以在网页、App、微信、支付宝等进行下单点菜;商家拿到订单后开始加工,并自动通知周围的快递员;快递员将外卖送到用户手中。我们希望通过该网站的案例,教会大家如何通过日志进行商业运营与决策。

背景

“我要点外卖“是一个平台型电商网站,用户、餐厅、配送员等。用户可以在网页、App、微信、支付宝等进行下单点菜;商家拿到订单后开始加工,并自动通知周围的快递员;快递员将外卖送到用户手中。

screenshot

在运营的过程中,发现了如下的问题:

  1. 获取用户难,投放一笔不小的广告费对到渠道(网页、微信推送),收货了一些用户,但无法评判各渠道的效果
  2. 用户经常抱怨送货慢,但慢在什么环节,接单、配送、加工?如何优化?
  3. 用户运营,经常搞一些优惠活动
  4. 调度问题,如何帮助商家在高峰时提前备货?如何调度更多的快递员到指定区域?

我们希望通过该网站的案例,教会大家如何通过日志进行商业运营与决策。

挑战是什么?

  1. 日志散落在外部

    1. 多渠道:例如广告商、地推等
    2. 多终端:网页版、公众账号、手机、浏览器等
    3. 异构网络:VPC、用户自建IDC,ECS等
  2. 各业务系统标准不统一,需要分别对几个平台

第一步是什么?日志收集统一

我们需要把散落在外部、内部日志收集起来,统一进行管理。在过去这块需要大量的工作,现在可以通过日志服务统一完成接入。

  • 通过WebTracking解决推广页面H5埋点问题
  • 通过移动端SDK解决用户端数据收集问题
  • 微信Web服务器:PHP/Java SDK 写入日志
  • 业务服务器:Logtail收集

screenshot

这里举一些例子:

微信服务端日志

2017-06-20 18:00:00, openID, opt, target, latency, status,location, network

字段 含义
time 用户操作时间段
openID
opt
target url
latency
location 地理位置信息
network 网络类型

可以用PHP SDK 或直接写到服务器硬盘中,通过Logtail收走。

新用户推广日志

2016-06-20 19:00:00 $md5_session, providerID, status

字段 含义
time 时间
$md5_session 用户Session,和注册ID关联
providerID 来源ID
params 其他参数

我们可以把h5页面中埋入providerID, paramsID 等参数,但用户扫描该页面注册时,就知道用户通过特定来源进入

客户端点击日志

2016-06-20 19:00:00 user, read, url, screen, android mi-ui, latency, status

点击日志可以从客户端收集,也能够从服务端收集,对于一些滚屏,退出等事件直接从客户端收集

其他

服务端、业务系统等日志

日志处理实战

运营活动中心

《未完待续》

反欺诈小组

《未完待续》

客服中心

《未完待续》

商业逻辑小组

《未完待续》

算法小组

《未完待续》

商家小组

《未完待续》

运维小组

《未完待续》

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
3月前
|
JSON Java fastjson
Java日志通关(五) - 最佳实践
作者日常在与其他同学合作时,经常发现不合理的日志配置以及五花八门的日志记录方式,后续作者打算在团队内做一次Java日志的分享,本文是整理出的系列文章第五篇。
|
5月前
|
前端开发 数据安全/隐私保护 容器
程序与技术分享:DirectUI的初步分析
程序与技术分享:DirectUI的初步分析
31 0
|
6月前
|
小程序 前端开发 JavaScript
【经验分享】如何实现在支付宝小程序中开发营销组件
【经验分享】如何实现在支付宝小程序中开发营销组件
79 0
|
消息中间件 运维 监控
消息队列和应用工具产品体系-完美日记电商业务案例
消息队列和应用工具产品体系-完美日记电商业务案例
消息队列和应用工具产品体系-完美日记电商业务案例
|
消息中间件 缓存 分布式计算
真牛!阿里最新发布这份《亿级高并发系统设计手册》涵盖所有操作
前言 我们知道,高并发代表着大流量,高并发系统设计的魅力就在于我们能够凭借自己的聪明才智设计巧妙的方案,从而抵抗巨大流量的冲击,带给用户更好的使用体验。这些方案好似能操纵流量,让流量更加平稳得被系统中的服务和组件处理。 那我们改如何应对大流量的三种方式? 第一种方法:Scale-out。 第二种方法:使用缓存提升性能 第三种方法:异步处理 面试京东,阿里这些大厂遇到这些问题改怎么办? 秒杀时如何处理每秒上万次的下单请求? 如何保证消息仅仅被消费一次? 如何降低消息队列系统中消息的延迟?
|
Apache 流计算
Flink CEP 在抖音电商的业务实践|电商行业实践专栏上线
Flink-learning 学训平台和电商行业实践专栏来啦!
6469 0
Flink CEP 在抖音电商的业务实践|电商行业实践专栏上线
京东T9纯手打688页神笔记,SSM框架整合Redis搭建高效互联网应用
Spring框架是Java应用最广的框架。它的成功来源于理念,而不是技术本身,它的理念包括loC (Inversion of Control,控制反转)和AOP (Aspect Oriented Programming,面向切面编程)。
|
消息中间件 数据采集 Java
开发神技!阿里消息中间件进阶手册限时开源,请接住我的下巴
相信大家在实际工作中都用过消息中间件进行系统间数据交换,解决应用解耦、异步消息、流量削峰等问题,由此消息中间件的强大功能想必也不用我多说了!目前业界上关于消息中间件的实现多达好几十种,可谓百花齐放,所用的实现语言同样也五花八门。不管使用哪一个消息中间件,我们的目的都是实现高性能、高可用、可伸缩和最终一致性架构。
|
消息中间件 存储 监控
超详细:这份全网首发的Kafka技术手册,从基础到实战一应俱全
Kafka正在爆炸式增长。超过三分之一的财富500强企业都使用Kafka。这些公司包括十大旅游公司,十大银行中的七家,十大保险公司中的八家,十大电信公司中的九家,以及更多。LinkedIn,微软和Netflix每天使用Kafka(1,000,000,000,000)处理万亿级的消息。Kafka用于实时数据流,收集大数据或进行实时分析(或两者兼而有之)。Kafka与内存微服务一起使用以提供可靠性,它可用于向 CEP(复杂事件流系统)和IoT / IFTTT式自动化系统提供事件。
实战:第四章:java后端日志埋点实现
实战:第四章:java后端日志埋点实现
1245 0
实战:第四章:java后端日志埋点实现

相关产品

  • 日志服务
  • 下一篇
    无影云桌面