电商后台功能模块的详细拆解和整理，与独孤九剑相关。思维导图模板

这是模板水印，可删除

1 用户、角色、权限管理（RBAC）

用户

角色

角色状态

子主题

进阶-停用、使用

角色操作

查询

创建角色

角色基本信息

权限

所有的权限都在员工页面内展示，树状形态展示【最多三级】

权限列表取决于项目本身所涉及功能

特别注意：权限不可以随意添加

了解误区

RBAC和"员工组织架构”or“员工部门”有啥关系

不要混淆，无关联

备注

RBAC是所有管理后台产品的【基础】模块

RBAC是人类社会组织方式的IT手段映射

可延展知识

RBAC-1

RBAC-2

2 用户管理

用户管理-页面构成要素

筛选条件

手机号

性别

注册日期

会员等级

最后一次消费时间

.........

列表规则

显示字段【根据公司实际业务场景而定】

普通用户-显示所有必要字段

强调体验的产品-后台用户可以根据自己的需求展示/隐藏相关字段

列表页排序规则【通常为倒序-最新注册/最近消费的用户排前】

明确表格锁定区域【表头锁定or锁定某几列】

列表中字段，可隐藏；可此再展示（类似Excel的列隐藏/列显示操作）

操作项

备注：操作必须位于表格最右侧
【基于用户体验，通常固定】

加入黑名单

解除黑名单

冻结

解冻

凡状态，必

查看用户画像

重置密码

查看历史订单

查看用户详细信息

...........

tips

1.表格方式呈现，更加友好（提供思路）

2.关于用户数据安全

初阶：列表中显示的的手机号，展示的前3后4，中4用*

高阶：数据库储存的手机号，做加密处理【技术细节由研发同学落实】

黑盒【解密&加密】

！！！！等级及权益设置

等级名称

名称

金-银-铜-铁

1-2-3-4

状态

已启用

未启用

禁用

操作

可编辑？

可删除？

可？

升级条件

按订单（消费金额）

身份统计周期

最近**天订单

360/720

xx个自然月

eg：优衣库会员等级-以自然月为单位
每月1号统计上个自然月积分变动

每个月一号统计上个自然月积分变动

xx个自然周

........

数据更新频次

常见做法：消费后，用户等级即时更新

其他做法：每日【23:59:59】后更新

身份有效期

终身有效

固定有效期

计算周期:{自然日-周-月-季度-年}

eg：北京地铁优惠权益
按【自然月计算】当月消费金额
100-150打八折
150-400打五折
超过400恢复原价

滚动有效期

自生效*日起，持续**天

eg1-次日生效：
2020.8.18日消费，8.19日生效，有效期持续365天
常见做法：即时生效{0日生效}

eg：跨年夜老板买表

eg:某奢侈品手表店
场景;某老板进店消费，购买一块奢侈品手表，价值38万，成为该店铂金会员
会员有效期设计：
方案1-固定有效期【按自然年计算】
方案2-滚动有效期【按365天计算】

降级条件

触发计算规则：每xx天计算一次
商业实例：运营商积分、航空里程、优衣库U值、京东会员值等【不花钱就下降】。。。。
下发短信：您当前等级****，将于月底回退至***，请尽快消费

口诀-升级即时刷新，降级按月统计

以优衣库U值为例：
分为三档：0-800-200
统计【过往12个自然月】，如无继续消费，减去相应U值（可能会造成等级回退）
根据当前剩余积分决定等级
某会员，U值2100分，其中900分将于2020.6.25日过期
2020.6.25日起，该会员剩余积分1200分{800-2000档位}

降级规则

case1：当前等级到期后，直接回到初始状态

星巴克

支付宝黄金会员

case2：当前等级到期后，回退至上一等级

优衣库

等级权益

等级对应积分

积分系数：如x1,x1.2,x1.3.......

过期设定

积分永久有效

积分定期失效【较为常见】

等级对应折扣

对应服务

eg：京东plus-每月6张免运券

美团外卖会员-每月6张￥5优惠券

可进行编辑、修改、删除、添加等操作

小结

等级 - 根据订单计算
等级带有效期
升降级规则
等级对应权益

产品案例

普通会员：根据订单消费金额计算

超级会员：完成“资格购买”

肯德基-￥38--90天

滴滴

京东

携程

滴滴

黄金会员
超级会员
超级会员需“购买”
普通会员根据订单计算：黄金-铂金-砖石

携程

黄金贵宾
超级会员

京东

衍生；数据看板

会员占比

会员数/注册有用户数

用户总数（及趋势）

会员增幅（趋势）

用户积分&用户等级

等级→积分，积分→消费
【每笔】积分都带【有效期】-eg；运营商积分/航空里程

积分消费【不影响】当前所在等级

当前等级维持→继续消费

当前剩余积分有效期

备注

简单模型：运营商积分

复杂模型：航空公司里程

可扩展方向：积分商城

风控相关功能

每次登陆设备记录及对比分析

eg1:视频APP，会员权益可以在5台设备共享（腾讯视频5，爱奇艺3）

eg2：得到APP，同一账号可以分别登陆一部手机+一部平板

eg3：某支付宝用户
经常使用苹果手机，白天使用支付宝付费
某天-该账户夜间出现，在PC端Android模拟器
so-蚂蚁金服判定为【风险用户】

可采集信息

系统维度，对设备进行划分

ios

Android

PC/Mac

可采集数据项

iOS-IDFA

Android-IMEI

Mac地址

操作手机版本

手机手机厂商

网络制式

3G

4G

5G

WiFi

IP地址

所在位置

。。。。。

比对规则

时间维度

同一时间

同一时间，只能允许1个设备，1个账号在线

eg :游戏

不同时间

该行为是否发生在该用户“往常习惯”发生的时间

eg：支付类APP

账号维度

通常仅限1个账号

设备维度

允许*个设备同时登陆

系统维度

iOS用户-已越狱

Android用户-已root

登陆地点

上次登录地点

常用登陆地点

本次登陆地点

网络

上次使用网络

常用网络

本次网络

处理思路

冻结账号--发起申诉--申诉处理

3 商品管理

1 分类管理
【亦称类目】

原则

前台类目【“我的”】、后台类目【“官方的”】分开管理，而非前后台共用一套类目

后台类目

官方指定

卖家/自营的所有商品，必须有一个分属归类

前台类目

卖家可以自定义

平台运营方，可以自行定义

通过“映射”进行关联

映射是一种技术实现手段，产品经理可不必关注过多细节

类目级别一般最多【三级】

备注：【务必理解】为什么“前后台类目分开”

原因

分类可动态管理，是【业务驱动产品】的实际体现

天猫，淘宝，京东等电商平台越来越多的SKU，
导致类目树的层级越来越深、条目越来越多，
不便于【更不可能直接开放给C端用户使用-因为过于复杂】

解决方案

后台类目面向商家或供应链人员，商品属性

前台类目

前台类目主要面向用户，方便用户筛选查找商品。

[可参见京东、天猫、淘宝的前台类目]

前台类目可根据运营需要，随意调整

后台类目

后台类目主要面向平台商家，用于管理商品和属性

后台类目相对固定，确定之后不会轻易变更或删除

理解

后台前台不是从属关系

平台、卖家、官方。每个角色的可以设置一套标签系统

前台的类目的不归属后台类目，但该商品的后台类目依然是存在的

后台的类目比较固定，前台的类目必须归属后台类目，但更具灵活性，为了推广可设定不同标签，

后台类目是底层逻辑，全线统一标准分类，前台类目是灵活机动的，配合各类运营玩法，彼此互不影响

2 品牌管理

参数

logo

中文名

英文名

原产地

归属方

归属方公司信息

备注

。。。。。。。。

状态

已启用

未启用

操作

创建

编辑

删除

启用

禁用

记录【操作人/操作项/操作时间】

备注

品牌可与类目关联

品牌可以和商品关联

可一对一、一对多、多对一

由平台工作人员维护

3 【SKU+SPU】关键属性

决定SKU，SPU【最重要属性】

基本概念

SKU

库存量单位，库存控制的最小可用单位。
SKU是商品【物理上】不可再分割的最小存货单元
【实体商品】库存管理，仓库管理，采购进货都是以SKU为记录单元

SPU

标准化产品单元，是一组标准化信息的集合

记忆小窍门：自己的手机

虚拟商品

SKU:薛兆丰的经济学课【库存无限】

所属后台类目：经济学

前台类目：可根据运营自定义

在线旅游类产品

SPU方式展示，具体SKU需到店后确认

下单：选择户型
到店：确认房间

在线预订：豪华标间（SPU既房型）
到达酒店后安排至301房间（SKU）

教育类产品

SKU1：小学数学--三年级--李老师
SKU2：小学数学--四年级--李老师

SPU:李老师的数学课

备注：有SKU，可以不用有 SPU, 用 SPU 时，SPU 下面必须细分一些 SKU

典型产品展现方式

JD

SPU方式呈现商品

设计目的：便于用户搜索+引流

TB

SKU方式呈现商品

设计目的：便于用户购买

特别备注：这种“泾渭分明”的呈现方式仅存在于产品早期，随着行业竞争加剧，
两者设计风格，产品功能，用户体验越来越近。

单规格单选

JDV男士休闲商务中袖西装SMS9176GRN绿色，规格S-M-L-XL,对应4个SKU

多规格单选

迪卡侬跑步速干T恤，
颜色（红色，蓝色，黑色）
尺码（S-M-L-XL-XXL）
3x5=15，对应15个SKU

iPhoneXS
存储空间 [64-256-512]
颜色[黑-白-灰-金-玫瑰金]
3x5=15，对应15个SKU

apple官网定制电脑配置：
颜色[灰色+银色]
CPU[i5-i7-M1]
内存[8G-16G-32G]
硬盘[256G-512G-1T]
2x3x3x3，对应54个SKU

4 属性库
【规格详情】

展示商品详细信息

不同类型商品会有不同参数

理解备注

参数对应商品

商品有对应条目

商品有归属商家

eg：实物商品佳能ESO【在类目“数码”-摄影摄像-单反相机】

特别备注:
类似于“公共信息”
基础描述信息由【平台】维护

可套用Axure组件

卖家可自定义维护【其他】信息

功能备注

属性库用于维护公用信息

Axure 元件库

不同品类【标准品】

5 平台参与方

平台运营部门【淘宝，天猫，京东等。。。运营团队】

卖家

品牌商

品牌商可以修改商品品牌信息，商品描述性信息

经销商

6商品管理

商品字段

所属类目

前台类目
【某些产品将该功能放在“门店装修”模块下】

后台类目

标题-输入框

注：字数限制

品牌-选择框

商品属性-描述性属性

选择【如：相机，手机标准产品】

录入【如衣服，商品非标产品】

规格【决定SKU库存】

价格

库存

报警比例

商品图片

商品描述

小视频

商品条码【69码】

实体商品必备

虚拟商品无此条目

计件单位

场景举例----便利店买水

多少瓶=1箱

每瓶多少钱

表现方式----有赞

运费模板【可设置多个运费模板】

城市维度

江浙沪包邮地区

主流城市

边远城市

公司维度

4通1达

顺丰

JD

日常维护

上架

人工上架

定时上架

【可复选】批量上架

下架

售罄自动下架

手工设置下架

【可复选】批量下架

基础风控点

若发生“不正常操作”，触发审批

【修改后的】价格比例

限购数量

商品标签
【并不是之前的标签】

运营手工添加

eg：店长推荐，火热上新

库存提醒

库存可设置自动提醒功能，SKU低于**触发提醒

提醒方式：向指定人员发送短信

该功能可放置于“通用设置”模块下

有赞-通用设置-参考

“通用设置”模块中其他配置项，需根据项目具体情况酌情设计

凡状态必对应操作

参考微店

7 商品评论

评论是否可以删除？

评论内容过滤

衍生功能：敏感词库、敏感词管理

敏感词管理相关功能可放入【通用设置】中

可扩展至：昵称、商品名称、商品描述。。。。。。

评论内容

文字

图片+短视频

标签选择

用户选择标签

子主题

商户or平台管理标签

评论分级

打星:1-5星

好-中-差评

自动好评

签收后，无退换货

超过* 天自动生成好评

买家：追加评论

卖家：评论回复

8 商品搜索

分词

以黑盒方式理解

NLP-自然语言处理

阿里云NLP

https://ai.aliyun.com/nlp?spm=5176.19720258.J_8058803260.247.e9392c4ajZ9jAM

算法驱动

建立搜索词库：根据用户的搜索日志、品牌名称、属性、类目建立关键词搜索词库，需要定期维护和更新，
系统会根据这个关键词库对用户的搜索进行才分关键词，保证查全率拆分关键词：用户输入的关键词可能
包含有很多关键词，比如蓝色牛仔短裤，拆分成蓝色、牛仔短裤，在搜索过程中，同一个关键词可能对应
多个不同的类目，这个时候就需要根据用户的搜索行为数据设置第一展现类目

自动纠错

产品经理可介入，设计相应规则

如：错别字，谐音字，拼音

nuojiya/挪鸡鸭/诺鸡鸭/Nokai ………………对应诺基亚

数据查询

按名称（SKU\SPU）搜索

按品牌搜索

按类目搜索

描述属性

评价

...........

搜索排序

工作性质:数据+算法驱动

基本原理：
1-对搜索结果中SKU进行“分数计算”
2-对搜索结果排序

加权计算项

商品名称

所在类目

所属品牌

销量

价格

评论数

好评率

时效性

历史购买记录

浏览记录

收藏记录

分享记录

搜索数据库缓存

偏技术原理，产品经理可暂时放入“黑盒”

对降低服务器端工作压力有帮助

同一原理应用

商品搜索

应用搜索

游戏搜索

课程搜索

9 商品推荐

判定依据

用户行为

搜索

浏览

购买

停留时长

用户喜好

收藏夹

点赞/关注。。。。

商品标签

根据判定依据-推荐相关商品

商品筛选

基本原理：加权打分，按打分结果展示

打分要素

参数

权重

可阅读相关书籍自行拓展

“不要重新发明轮子”

神策数据

https://www.sensorsdata.cn/product/recommend.html

4 订单管理

1 订单流程

根据已有产品拆解下单流程

根据公司业务/优化现有下单流程

2 订单信息

下单用户信息（C端下单用户）

下单用户ID

下单时间

通过用户ID可关联用户信息表

订单ID【主订单】

订单ID编码规则

核心：

订单ID注意事项

B避免通过订单ID泄露公司订单规模

避免他人反推出订单规则

商品ID

商品管理

至少包含信息

SKU

数量

价格

所属商户【商户ID】

所属门店【门店ID】

优惠信息

From【促销优惠】

From【会员权益】

订单金额计算

初始金额

实际结算金额

eg:先减券、再打折

eg:先打折、再减券

支付信息【调用第三方】

支付渠道

支付宝

微信

中国银联

第四方：聚合支付

海外产品-PayPal

支付流水号

可理解为“支付平台的订单ID”

时间戳

支付发起时间

收到支付成功时间

支付金额

支付状态

需理解：为什么支付状态和订单状态【有时候】不一致

需理解：什么是“掉单”、“系统自动补单”、“人工补单”

子主题

物流信息【调用第三方】

物流/快递单ID

物流公司

物流方式

物流单号

状态变更

时间戳

备注：物流公司提供API-快递单ID

订单状态【详情参见下文】

收货信息

有收获信息

无收获信息

收件人姓名

收件人电话

收件人地址

其他信息

发票【可暂时不拆解】

分销渠道

买家备注

3 订单状态

交易状态

待付款

挂单时间：订单取消规则-**分钟or**小时

待发货

待收货

交易成功

已取消

售后中

待审核

审核通过

售后服务中

交易关闭

售后状态

待审核

待退货入库

待退款

待换货入库

换货出库中

售后成功

4 订单拆单

拆单因素

所属卖家（商家）不同

所在仓库不同

所属品类不同

eg：同一订单-手机+电冰箱

物流因素不同

eg：薯条+牛奶

eg：纸质书+洗衣机

商品价值不同

等。。。。。。

订单ID

主订单ID

子1订单ID

子订单关联物流单ID

子2订单ID

eg：一次性购买多个商品分开发

5 订单数据分析

交易分析

统计周期订单量

天

截止昨天【23:59:59】

周

自然周

月

自然月

自定义时间段

通常不超过**天【180天or360天】

销售额GMV

客单价

下单/支付用户数

新老用户比例

订单金额分布

地域分布

商品分析

下单商品数

支付商品数

被访问商品数

商品收藏数

品类/店铺数量

加购物车数量

........

用户分析

【标签相关】

【用户生命周期相关】

6 ！！！工作【面试可能涉及】要点

订单管理

订单生成规则

订单管理后台设计

！！！订单退款处理

满减退

问题：一个订单包括两个SKU，分别为100元和60元，优惠规则：满百减十【仅限一次】，实付150。

退60和退100分别退多少钱

答案：

问题3：一个订单包括两个SKU，分别为140元和120元，优惠规则：每百减10【仅限一次】，
实付金额250，退140和退120分别退多少钱？
【设置不合理，实际场景下，用户可以分开购买，获取更大优惠】

问题：一个订单包括两个SKU，分别为140元和120元，优惠规则：每百减10【可累加使用】，
实付金额？退140和退120分别退多少钱？

包邮加满减退

问题：订单内有两个商品，分别为11元和19元，合计30元，优惠：满30减10，邮费10元
实付金额30元，请考虑两种情况，第一种：付了钱没发货，第二种：已发货

付了钱+未发货

第一种未发货情况，是可以退邮费的。
当退第一件商品11元时，因为退完不满足满减，所以应退11-10=1；
退第二个商品19元时，因为退完也不满足满减，
但退第一件时已经把抵扣金额减去了，所以应退19+10（邮费）=29。
全部退货-退30元

付了钱+已发货

退19元商品，实付30元，退9元

退11元商品，实付30元，退1元

退全部商品，实付30元退20元

结论：联系客服协商解决

有规则券+满减退

问题：满减优惠券150减10，无门槛优惠券100减10。
订单内有两个商品，分别为100元和70元，
所以实付为：170-10（满减优惠）-10（无门槛优惠券）=150元。

子主题

无门槛优惠券

子主题

无门槛券+满减退

7发货、退款、对账

1 订单列表页

1.1 搜索条件-商品可通过下拉菜单筛选，而非“输入商品ID”查找

1.2 来自第三方的定单（JD,天猫，淘宝等）处理

可通过API方式对接，通过API更新状态【可阅读天猫相关API文档】

沟通工具必须使用对方规定工具（如：阿里旺旺）

1.3 支付方式-【涉及独立模块-支付相关】

微信支付

支付宝

银联

1.4 订单备注

订单备注的使用场景？卖家不太可能对订单【逐个】进行备注

卖家可能存在的需求场景:对买家进行加星

衍生功能：加星之后可否取消？如何操作？

1.5 订单导出

导出前需预览【需设计一个预览页】

导出格式限定

常见支持格式

.csv

.txt

不太常见的格式

.xls

.xlsx

导出数据条数限定

在何种情况下，导出操作触发审核确认？
【实际工作中如遇到该场景，用户可分多次导出而避免审核】
该需求--伪需求
or换一个解决方案：所有导出必须审核

PM需设计文件模板

2 发货及批量发货功能
【基于有赞系统】

2.1 上传

上传文件格式限定

常见支持格式

.csv

.txt

不太常见的格式

.xls

.xlsx

需设计规则：上传后各种异常情况处理

数据条数超限？

上传文件大小超限？

数据识别有误？

一次操作仅限一个文件

........其他情况

2.2 识别

需设计规则：识别后各种异常情况处理

数据反馈：成功条数，失败条数

有重复数据？

怎么操作?

有错误的数据？

怎么操作？

2.3 API对接

备注：发货操作使用手机端更为便捷
【手机端可直接调用摄像头扫描条形码，更新状态】

3 退款及对账功能

场景规定

用户在官方APP内下单，因对商品不满意发起退款

注：在天猫，京东等渠道下单，需进入对应后台完成相应操作

基本流程

用户发起-客服审核-财务处理【线下处理】-退款操作【登录支付宝微信等对应后台】
-下载对账文件-上传对账文件至公司管理后台-改订单状态更新为“已退款”

注:有研发团队的公司可进行API方式对接，但仍需保留【对账】功能

API对接

4 对账

发生场景：支付渠道的订单数可能会比自有APP订单数多【需理解其中原故】

涉及后续工作：手工平账

支付宝账单下载

对账原理

对比要素1：公司订单中的订单ID，支付渠道，支付金额，支付流水号，支付状态，支付时间等信息

对比要素2：来自支付渠道的支付流水号，支付金额，支付状态，支付时间等信息

8 下单风控相关

收货地址

同一收货地址，相对应多个订单ID

相近【距离】收货地址，对应多个订单ID

地址不同，姓名不同，但收件手机同一个

下单人手机号和设备内手机号是否对应

下单设备

同一设备号，对应多个订单ID

同一设备，同一账号，重复下单

网络信息

同一WiFi，多个设备登录

历史羊毛党WiFi，开始出现登录

付款账号

某账户集中完成“代付”行为

用户行为

新用户-领券-【无浏览行为】-对指定商品下单

N久不登录的用户-批量出现-领券-【无浏览行为】-对指定商品下单

时间判定

子主题

复杂一些

交叉地址，互相下单

5 促销管理

1 优惠券【2019.12.18】

券类型

代金券

满XX元

减XX元

！折扣券

！优惠/奖励要有封顶

消费金额满XX元触发

折扣率

封顶优惠数

券名称

需考虑使用场景

eg：微信卡包内的优惠券，名字一般7字以内

需考虑前台展示要素【不能折行不能出.....】

描述信息

！to外部用户

to内部用户

券库存

单批次，固定库存【微信公众号管理平台-优惠券管理规定】

多批次，可追加库存【自有业务后台】

券码【code】

处理方式1：发券及运营人员券码不可见

处理方式2 ：需记录每一步操作人员

某些场景下，需设计卡号+密码

eg

大众点评代金券

中国移动充值卡

游戏点卡

有效期

固定有效期

formXX日 to XX日

滚动有效期

生效时间节点

设定方式：可自定义X天后生效

默认领取后自动生效【领取后0天生效】

设定方式：到指定日期生效

有效期

领取后XX天有效

eg：新用户注册后，自动获取优惠券，有效期：X天【自注册之日起】

适用范围

制定商户？

注：平台发券

指定品类？

eg：仅限书籍，仅限玩具

指定商品？

指定门店？

eg：天猫旗舰店领券，线下指定门店消费

指定人群？

领取方式

用户主动领取

单次领取【通常默认值1】

领取上限

直接塞入用户卡包【仅限自有小程序/APP】

使用时间限制

默认：无限制

限制条件

工作日及非工作日

节假日

时间段

监控

数量监控

举措：券库存报警，补发优惠券

核销

线上核销

购买行为发生于线上，如小程序、APP、网页

线下核销

购买行为发生于线下实体店

1 出示会员码【需会员码和优惠券绑定】，等待店员扫码/

2 出示微信/支付宝付款码

瑞幸咖啡

会员码和优惠券绑定的案例-星巴克

延展一步：为什么星巴克

券包

券包-券X库存数

有效期

2 活动

促销形式

代金券

活动

促销形式

折扣券

定金膨胀

单品促销

引流品-商品管理

套装促销

和商品管理相关

赠品促销

和商品管理相关

买多优惠

活动管理目的

以活动为单位，统计数据

基本公式：创建活动-选择活动

活动模板

基础设置

活动名称

活动起止时间

！促销目标用户人群【非必选项】

全站通用类

针对特定人群

推广相关

二维码工具

短连接生成工具
【注：暗藏收费服务】

备注：统计截止时间

促销规则

关联商品

促销品库存

关联优惠券

3 数据统计

效果沙漏

发券数量

活动页曝光数量

券领取数量

券核销数量

活动页（落地页）分享数量

case1：
如何建立沙漏模型 - 我们抓到了每一步的数据 —— 每一步的数据怎么来 ——通过第三方API接入【eg：微信优惠券】
case2
使用成熟的第三方统计工具

用什么统计沙漏

类别1

growingIO

神策数据

类别2

友盟

TD

4 微信生态相关产品

5 拼团

业务要素

最大团员数

每SKU，限用户发起拼团数上限

多个节点，判定库存【详情页，开团页，参团页】

6 秒杀

业务要素

场次信息

显示规则

显示当日全部场次

显示最近*场【已结束的置灰】

只显示当前+下一场

模块素材：标题+配图+说明文字

参见秒杀SKU

倒计时

参与进度条（库存）

原价+活动价

活动发起方

平台

商户

6 会员关怀系统
【2019.12.24】

参数设置

关怀名称

可根据运营要求自定义

关怀触发条件

eg：生日

eg：优惠券到期前*天

eg：会员等级变化

eg：积分变化

送什么

优惠券

积分X倍

。。。。

送给谁

默认：全体用户

进阶操作：可根据各种条件筛选

eg：根据注册日筛选

eg：根据消费金额筛选

eg：根据最近一次消费时间筛选

。。。。。。

取决于业务部门or产品经理

怎么送

短信

邮件

APPor微信小程序站内消息

微信消息通知

APP推送

备注

在有赞的系统中，被称为场景营销

在阿里系某些产品系统中，被称为忠诚度管理

内容管理（CMS）

位置

首页

位置1

位置2

列表页

组件

轮播图片

小视频

实现步骤

确定位置

首页

列表页

客户端可见位置

可使用组件

单图/轮播图

视频

音频

文字

跳转至-素材

内容素材

sku

spu

文章

攻略

........

理解CMS的最小必要知识

自己能绘制一个关于CMS管理的MVP版

落地页【MVP】

用户手动设置相关素材

页面名称

描述信息

banner素材

内容素材

sku

spu

文章

攻略

。。。。

状态

使用

停用

删除

系统自动记录

操作人

操作时间

涉及各种流【添加审核】

内容创建后不可直接发布，需审核

审核后方可显示，审核后更新，循环此流程

7 商户管理
【2019.12.25】

平台端对商户端的审核

资质审核

日常运营要素审核

eg：点评-价格、描述文字、照片变更

eg：美团外卖-价格变更

营业流水提现

！账期管理

提款日期

服务费扣点、分成

和商户可关联的数据项

物料信息

eg：资质信息

eg：商铺、门店信息

商品管理

订单管理

eg-【京东自营】

“京东”也是一个商户

券管理

活动管理

客户管理

所有客户最终归属为平台方

平台方不可以向商户透露手机号

手机号可脱敏后显示
173****1233

。。。。。。。。

商户管理可拓展功能

开发者管理

eg：小米开发者平台

开发者资质管理

开发者应用管理

广告主管理

eg：抖音、快手、微视平台

账户（资金）管理

投放计划管理

素材管理

已经学完的
最开始学完的-商品管理 - SKU SPU ……
今天刚写完的商户管理
so 可以 get到的知识点 = 商户 + 商品管理
继续拓展一下
稍微变形
商户 = 开发者
商品 = 软件/游戏
核心要点：版本 + 发布状态
可以理解 = 软件应用商店 + 软件发布

理解商户管理的2个阶段：
第一阶段必须达到的 - 商户管理可以关联过往所有知识模块

第二阶段可以尝试拓展的 - 商户管理可以拓展成开发者管理、广告主管理

风控相关功能点

提现账户变更-需走审核流程

提现行为-需进行二次确认及历史记录对比

数据统计分析

如何植入第三方统计工具

step1：成为该平台的开发者

step2:植入该平台的SDK

子主题

重点务必需要理解：
1.第三方统计工具提供哪些数据？
2.我家自己的后台提供哪些数据？

1.第三方统计工具提供的是行为数据
2.我家自己的后台提供的是交易数据

用户行为数据 + 交易数据能产生什么效果？

eg：某商业银行，有大量的交易数据和用户基础数据【证件信息、存贷款信息 - 值钱】

but 银行木有 - 用户行为数据【这个人喜欢什么app 总用什么app 】

什么是数据开放平台？

双方拿出自己的数据 “碰一下” 得出想要的结论

1 数据开放平台的基本工作商业模式理解

1.1- 交易角色
需求方 - 某商业银行
供给方 - 某数据平台

1.2-交易方式
需求方出一个设备号清单 —— 问供给方：这些人都喜欢用啥app，都有啥特征
—— 供给方说：我给你查查啊 —— 行，这些都有，你看下

1.3-结算方式
需求方：我这有十万个设备号，你给我查查呗？
供给方：你找我查的十万个设备号，其中有八万能对上。我把数据给你看下
需求方:恩，我按着这8万给你结算费用
【核心：设备号比对，而不是手机号或者身份证号比对】
需求方:恩，我按着这8万给你结算费用
注意核心 —— 全程没有透露用户的手机号，需求方知道用户的手机号和身份证号，
供给方知道用户的设备号。所以谁也没违规，大家都是合理合法的

case1 ：银行
需求方：我这有十万个设备号，你给我查查呗？
供给方：你找我查的十万个设备号，其中有八万能对上。我把数据给你看下
【核心：设备号比对，而不是手机号或者身份证号比对】
需求方:恩，我按着这8万给你结算费用
case2：某拍照软件
拍照软件的特别之处：
用户不注册也可以使用、用户不交钱也可以使用

2.怎么实现的呢？
联系咱们讲过的一个知识点
2.1 - 手机APP 可以获取用户的手机系统、手机型号、设备号、mac地址、当前网络等 ……

2.2 - 手机APP怎么知道用户装了多少个APP ？因为这个用户的手机上
多个APP都使用了【同一家的SDK-比如友盟、TD等】
还有谁知道用户的手机上装了多少个app - 手机制造商

——如何实现——
2.3-大数据平台作为供给方，根据设备号【IMEI号】，需求方根据自己用户的【设备号】获取相应数据
2.4-需求方能拿到什么？这个【设备号】的手机，都喜欢用什么app，有哪些互联网使用习惯等等【各种互联网数据】

2.5 - 设备号对友盟意味着什么？数据平台使用设备号来标注用户ID
为什么使用【设备号】 - 目前中国法律体系下，交易手机号是犯法的，but 设备号没事

友盟埋点

埋点：
app开屏页
-注册登录页【注册/登录游客身份访问】
-首页
-我的
-发现
每个页面都会有相应的触发事件，记录用户的操作路径，就是根据这些触发事件来看，而且能明白用户的事件转发率

已知：我有了这么个埋点，我可以做一个沙漏

埋点你需要 get到的：
埋点应该不是什么技术，关键是通过埋点要分析什么是要PM想的？
PM如何输出埋点需求？
埋点还有什么别的实现方式？

友盟特长：全流程 + 全域 +全周期 - 数据跟踪及汇总
什么是全流程：用户看到广告 - 下载app - 注册app -进入app充值/下单 - 通过社交媒体分享该app的内容
【理解要点：套入一个游戏，更容易理解】
eg【为方便理解，全部使用阿里系产品】
1.某app，嵌入了友盟SDK
2.老板决定做推广，在微博做了信息流投放，在优酷做了映前贴片广告
3.友盟可以采集全流程【除去app自己的，还包括上文2 】数据，汇总分析
- 微博广告曝光次数、点击次数、优酷广告曝光次数、点击次数、app被安装的次数

友盟不知道用户的交易数据，那友盟怎么知道用户 “充过值”呢？

知道你点击充值按钮

1.对于数据平台，会用一个xxID来标识用户
2.平台会知道这个用户都点击过是啥按钮