【数据产品案例】有赞美业数据报表

2024-09-06 04:18

本文主要是介绍【数据产品案例】有赞美业数据报表,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

案例地址: https://www.youzan.com/intro/beauty

1. 有赞是新零售的软件服务商,为商户提供强大的微商城和完整的移动零售解决方案,帮助互联网时代的生意人管店、管货、管客、管钱。其自身定位是为商家提供的SaaS系统,提供零售的完整解决方案。与淘宝不同的是,淘宝是商业地产模式,淘宝引流导向商户;有赞不吸引流量,有赞服务的商家需要有自己产生流量的能力。

2. 线下美容美发行业信息化程度仍较低,基本的对账能力缺乏,过去主要靠纸笔来进行会员、员工的管理和统计。有赞美业是有赞对美容美发行业的互联网化解决方案,先提供订单管理、商品管理、会员管理能力,再提供数据分析功能。

3. 数据来源:管理端侧重于对订单、会员的管理,主要能收集到的数据有:
1)订单数据:从预约到最终达成交易
2)会员数据:
a. 会员基本信息:包括生日、微信等
b. 会员价值信息:RFM信息包括客单、消费频数、最近一次消费,会员积分与会员等级
c. 获客来源:获客门店,以及是从线上预约来的还是线下入店的
d. 会员画像:可自定义会员标签
e. 会员消费信息:包括消费记录、剩余卡金等

4. 首页工作台包括三大模块:基本数据看板、常用功能和待办事项。其中基本数据部分包括:
1)业绩相关:主营收入、充值金额、耗卡金额、赠送消耗
2)订单相关:预约单数、完成订单数
3)客流相关:到店人数、新增会员数

5. 数据概览:整体概览部分关心收入、卡、会员、客单和退款。
目前仅支持往期任意一天的日报表。主要模块按从上到下顺序排序如下:
1)订单:关心订单金额和订单量,其中订单金额根据美容行业的特别,将卡金也算入,总共包括“充值金额、卡项金额、售卡金额”
2)预约:同样是关心预约金额和预约次数两个指标,同时也关心取消和超时的预约单数
3)会员卡:同样关心售卡收入和售卡次数两个指标。额外关心当日售卡中的次数与服务消耗掉的次数,因为售卡本身是透支将来消费金额的行为。
4)客户:关心散客和会员,其中散客关心三个点:
a. 散客预约:判断预约功能是不是能引流
b. 散客办卡:关心散客转化率
c. 添加会员:关心散客转化率
5)付款方式:同样是关心金额和次数两个部分。付款方式包括 充值金额、现金、支付宝、微信、刷卡

6. 数据报表
1)销售统计报表:关心收入和订单数。收入细分为“服务收入、产品收入、次卡收入、折扣卡收入、充值收入、直接收款、店铺收款码收入”,订单数包括“服务订单数、产品订单数、次卡订单数、折扣卡订单数、充值订单数、直接收款订单数、店铺收款码订单数”
2)订单报表:分为待付款、待发货、已付款、已发货几种类型订单,然后得到订单的宽表,具体的分析由商家自己完成
3)退款订单报表:退款订单的宽表,具体分析由商家自己完成
4)消耗统计报表:关心卡的消费,包括卡余额消费和卡次数消费

————————————————————————————————
思考:
1. 目前美容美发行业信息化程度低,所以当前还处于数据的积累阶段,先让商家用上了信息化系统,留存了数据,再考虑下一步数据产品的设计

2. 美业商家的数据应用能力处于初级阶段,因此应该分成两步走的方式进行,第一步现将商家线下的数据行为搬到线上,比如说统计各个渠道的会员转化率等,这类行为商家本来就能做,但是有了数据产品后会更方便;第二步做商家想做、但是过去做不到的功能,比如说分析各渠道转化成会员的顾客画像,分析转化原因,在渠道推广时更有针对性,提高转化效果

3. 目前有赞美业提供了最基础的数据能力,主要是各维度(如会员、订单、商品品类)的金额和次数,有助于商家管理者了解店铺现状,但对于决策和行为的影响我认为不大

4. 有赞美业的报表功能挺有趣,为商家提供宽表,基本上等同于系统所收集的商家运营信息。“数据概览”为商家决策提供的价值不够大,“数据报表”理论上可以让商家做非常多的分析,但考虑到美业商家的数据敏感性和数据能力,可能对于大多数商家而言宽表的使用是有难度的。
但是宽表给了我们启发,当我们设计数据产品时,如果还未能了解使用者对于数据会有哪些使用用途,可以先把尽量多的数据给使用者,观察那些使用了该功能的使用者,我们就能了解这些数据应该怎么加工成数据产品。这里我认为可以加个步骤,用户在下载数据宽表时,让用户勾选他们所需要的字段,这样的好处是:
1)用户下载的EXCEL文件字段少了,使用更为简便
2)通过打点,我们可以知道用户关心哪些字段数据,根据字段的组合,我们可以大致判断出用户关心哪些指标

5. 有赞美业的用户标签功能也值得思考。对于数据的白盒应用,最常见并且有效的就是打标签了,运营、销售、广告主等都可以直接受益于已经标注的用户标签。这里可以思考下,如果我们能从其它数据源找到与美业相关的用户标签信息,两者打通,是不是能非常直接地帮助到商家?比如一个无历史记录信息的会员,我们从其它数据源能了解该会员 化妆品消费高、初中老师、旅游频率高 等,是否能做针对不同场景提供护肤护发商品,如老师日常对化妆的需求不大,对快捷程度要求高;旅游场景关心阳光、风、汗、补妆频率等因素。

6. 美发商家的经营模式有个特点,如果卡金增长控制不当,可能对将来的经营造成巨大影响,能否进行预警?

7. 理想情况,为使用者提供端到端的数据产品,即输入端为数据,输出端为行为,数据分析包含在两端之间的黑盒中。当前场景下的问题是多主体、每个主体的数据量少,那么建模时用所有商家的数据+商家ID输入,不一定能抽取有效特征,对于单一商家的指导性不够强。
另外,目前美业商家最核心的问题是什么,能不能用端到端的方式先解决一个核心问题?如进行广告活动时,直接提出参考的单价、套餐组合,以及目标潜客画像。


这篇关于【数据产品案例】有赞美业数据报表的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1140974

相关文章

大模型研发全揭秘:客服工单数据标注的完整攻略

在人工智能(AI)领域,数据标注是模型训练过程中至关重要的一步。无论你是新手还是有经验的从业者,掌握数据标注的技术细节和常见问题的解决方案都能为你的AI项目增添不少价值。在电信运营商的客服系统中,工单数据是客户问题和解决方案的重要记录。通过对这些工单数据进行有效标注,不仅能够帮助提升客服自动化系统的智能化水平,还能优化客户服务流程,提高客户满意度。本文将详细介绍如何在电信运营商客服工单的背景下进行

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展,我们的业务数据越来越多,单纯使用 MySQL 已经不能满足我们的数据查询需求,例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后,随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步,我们目前的解决方案是建立数据中间表。把需要检索的业务数据,统一放到一张M

关于数据埋点,你需要了解这些基本知识

产品汪每天都在和数据打交道,你知道数据来自哪里吗? 移动app端内的用户行为数据大多来自埋点,了解一些埋点知识,能和数据分析师、技术侃大山,参与到前期的数据采集,更重要是让最终的埋点数据能为我所用,否则可怜巴巴等上几个月是常有的事。   埋点类型 根据埋点方式,可以区分为: 手动埋点半自动埋点全自动埋点 秉承“任何事物都有两面性”的道理:自动程度高的,能解决通用统计,便于统一化管理,但个性化定

Hadoop企业开发案例调优场景

需求 (1)需求:从1G数据中,统计每个单词出现次数。服务器3台,每台配置4G内存,4核CPU,4线程。 (2)需求分析: 1G / 128m = 8个MapTask;1个ReduceTask;1个mrAppMaster 平均每个节点运行10个 / 3台 ≈ 3个任务(4    3    3) HDFS参数调优 (1)修改:hadoop-env.sh export HDFS_NAMENOD

使用SecondaryNameNode恢复NameNode的数据

1)需求: NameNode进程挂了并且存储的数据也丢失了,如何恢复NameNode 此种方式恢复的数据可能存在小部分数据的丢失。 2)故障模拟 (1)kill -9 NameNode进程 [lytfly@hadoop102 current]$ kill -9 19886 (2)删除NameNode存储的数据(/opt/module/hadoop-3.1.4/data/tmp/dfs/na

异构存储(冷热数据分离)

异构存储主要解决不同的数据,存储在不同类型的硬盘中,达到最佳性能的问题。 异构存储Shell操作 (1)查看当前有哪些存储策略可以用 [lytfly@hadoop102 hadoop-3.1.4]$ hdfs storagepolicies -listPolicies (2)为指定路径(数据存储目录)设置指定的存储策略 hdfs storagepolicies -setStoragePo

Hadoop集群数据均衡之磁盘间数据均衡

生产环境,由于硬盘空间不足,往往需要增加一块硬盘。刚加载的硬盘没有数据时,可以执行磁盘数据均衡命令。(Hadoop3.x新特性) plan后面带的节点的名字必须是已经存在的,并且是需要均衡的节点。 如果节点不存在,会报如下错误: 如果节点只有一个硬盘的话,不会创建均衡计划: (1)生成均衡计划 hdfs diskbalancer -plan hadoop102 (2)执行均衡计划 hd

性能分析之MySQL索引实战案例

文章目录 一、前言二、准备三、MySQL索引优化四、MySQL 索引知识回顾五、总结 一、前言 在上一讲性能工具之 JProfiler 简单登录案例分析实战中已经发现SQL没有建立索引问题,本文将一起从代码层去分析为什么没有建立索引? 开源ERP项目地址:https://gitee.com/jishenghua/JSH_ERP 二、准备 打开IDEA找到登录请求资源路径位置

深入探索协同过滤:从原理到推荐模块案例

文章目录 前言一、协同过滤1. 基于用户的协同过滤(UserCF)2. 基于物品的协同过滤(ItemCF)3. 相似度计算方法 二、相似度计算方法1. 欧氏距离2. 皮尔逊相关系数3. 杰卡德相似系数4. 余弦相似度 三、推荐模块案例1.基于文章的协同过滤推荐功能2.基于用户的协同过滤推荐功能 前言     在信息过载的时代,推荐系统成为连接用户与内容的桥梁。本文聚焦于

【Prometheus】PromQL向量匹配实现不同标签的向量数据进行运算

✨✨ 欢迎大家来到景天科技苑✨✨ 🎈🎈 养成好习惯,先赞后看哦~🎈🎈 🏆 作者简介:景天科技苑 🏆《头衔》:大厂架构师,华为云开发者社区专家博主,阿里云开发者社区专家博主,CSDN全栈领域优质创作者,掘金优秀博主,51CTO博客专家等。 🏆《博客》:Python全栈,前后端开发,小程序开发,人工智能,js逆向,App逆向,网络系统安全,数据分析,Django,fastapi