惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

V
Visual Studio Blog
博客园 - 司徒正美
Hugging Face - Blog
Hugging Face - Blog
博客园 - 叶小钗
The Cloudflare Blog
D
DataBreaches.Net
J
Java Code Geeks
G
Google Developers Blog
L
LangChain Blog
N
Netflix TechBlog - Medium
Stack Overflow Blog
Stack Overflow Blog
月光博客
月光博客
酷 壳 – CoolShell
酷 壳 – CoolShell
WordPress大学
WordPress大学
小众软件
小众软件
量子位
Apple Machine Learning Research
Apple Machine Learning Research
P
Proofpoint News Feed
博客园_首页
罗磊的独立博客
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
B
Blog
腾讯CDC

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
产品经理谈一谈:商品上架行为分析
我是产品张 · 2024-07-30 · via 人人都是产品经理

本文通过形象的比喻和详细的分析,深入探讨了产品经理的职责、挑战以及如何通过数据分析优化产品上架流程,提升用户体验。对于有志于成为或了解产品经理的人来说,这是一篇不容错过的精彩文章。

产品经理是干什么的?

一个比喻形象说明下,产品经理就是互联网行业的“粮食育种专家”,产品经理和技术团队协作通过“基因编码”技术编写某种植物种子各阶段生长的主信息,然后移植到土中培育,经过人工选择和优化最终培育出健壮高产的作物。

01 概述

种子要生长第一步是播种,不丢到土里或其他适宜生长的环境里是无法长出来,无法验证该品种是否优良。

同理互联网各行业繁荣的第一步也是“播种”,只有将“种子”播种到“土”里,才能带来丰收。不同的行业种子不同,播种方式也不同:

1.1. 自动化

对于交通系统而言,无论是地铁、高铁、汽车,销售的车票都是标准化的产品,车票本身的包含的信息属性较少,可以由计算机程序自动完成车票的上架和下架,无需人工干预。

对于搜索引擎,特别是不主导内容创作的业务模块,由自动化程序将互联网存在的各种内容爬取过来,在用户搜索的时候返回,信息的爬取也是自动化完成,无需人工干预。

1.2. 人工

对于商品系统,无论是衣服、食品、家电甚至房源,这些都是非标的产品,商品摆上货架,需要人工完成,并且在商品无法销售时,还需要主动下架。

对于内容平台,知乎、小红书等,平台上提供的知识内容也是非标产品,内容的创作和上架都需要作者主动完成。

1.3. 人工辅助

人工辅助是对人工上架的补充,虽然由于行业的限制,无法完全交给机器自动化完成,但是其中部分的流程是可以交给机器的。

比如:

  • 商品信息可以构建词典,协助填充部分商品的属性信息,包括自动生成宣传标题、自动美化风格等。
  • 商品的智能客服、物流追踪、自动下架可以由信息系统自动协助完成。

02 电商商品上货架

本文主要展开电商商品的上货架分析,期望通过分析商品上架的效率现状,制定合理的指标,并一步步实现商品上架环节的高效进行。

2.1. 物理世界的商品上架行为

在互联网以前的货架主要是物理货架,包括商场摆货、菜场摆菜等,销售方需要花费大量的时间安排专人理货,并需要定期下架不新鲜的货源。

笔者调研小区的菜篮子工程商贩,他们每次来小区摆摊七八个小时,摆货、收货环节就要花掉四个小时不止,可见商品上架占据日常工作的很大一部分时间。

2.2. 互联网世界的商品上架行为

互联网兴起后,线上商城包括淘宝、京东等成为最新型的货架,在这些平台上的商户需要花费大量的时间处理商品上架的工作,包括文本信息录入、图片制作上传、视频内容上传等。

商品上架效率的高低由两个参与方决定的:商户的信息录入人员和平台的软件产品及配套服务人员。

  • 如果信息录入员思路清晰,业务熟练,有耐心,在体验差的平台上也可以完成商品的上架
  • 如果平台智能,即使业务不熟练的新手也可以高效完成商品的上架。

这两者其中任一方的功能强大,都能弥补另一方的部分缺陷。

作为推向市场的产品,我们愿意相信产品在实验室环境中已经做了必要的调研和试验,虽然未经过大量客户的直接检验,至少是能够正常完成信息录入。

03 分析目标和思路

大部分平台需要上架的商品种类和字段会很多,我们期望分析当前使用用户在商品上架环节花费的时间情况,挖掘可以改进的空间。

3.1. 用户分群和排序

平台上的商户会很多,各种各样,数据分析第一步,对用户分群并排序,优先关注高优先级用户的需求。

该过程首次启动时,可以使用静态数据作为分群标准,后续随着系统迭代,可以逐步丰富分群指标。

产品经理谈一谈:商品上架行为分析

静态的信息,包括商户信息、员工信息、商品信息。

一般的平台可能会先选择以下指标:(实际场景各有不同,本处只是引子)

  • 信息完善度:比如工商信息、收款账户等,具体考虑考虑标准根据实际业务场景确定,本文抽象为0-1之间的数字。
  • 合同类型:免费用户、付费用户,肯定付费用户的优先级更高。本文抽象为两个类型:免费用户、付费用户。

3.2. 用户行为定义和分析

分析用户行为,首先要梳理用户动作的数据结构,根据行为动作定义状态事件。动态的信息,核心字段简化为:

  • 操作商户、操作人
  • 商品编号:用于唯一识别商品
  • 商品信息:商品信息内容较多,不同类别的商品要上传的信息数量不同,且会涵盖文字、图片、视频多个维度
  • 商品状态:用户的保存和提交动作会导致状态变化。比如保存失败、保存成功、上架失败、上架成功,这些状态都在影响行为的分析。

商品状态变化图为:

产品经理谈一谈:商品上架行为分析

实际业务可以再此基础上继续拓展。

04 分析实战

4.1. 信息收集

本文使用的数据都是随机模拟的数据。如需查看完整源代码可以在GitHub中,搜索”ImPmZhang”查看。四张信息表为:

产品经理谈一谈:商品上架行为分析

产品经理谈一谈:商品上架行为分析

产品经理谈一谈:商品上架行为分析

产品经理谈一谈:商品上架行为分析

4.2. 定义事件

商户操作上架,从任意选定的时间窗口观察,无非两种情况

  • 商品已成功上架
  • 商品未成功上架

无论哪种事件,都可能是由多个动作组合产生。所以第一步需要按照商品的维度将多个动作打标签,归为一类。

4.3. 事件编号

将商品已成功上架和未成功上架的N多个房源的N多个动作赋予唯一的编号。

4.4. 数据计算

数据计算关注点为:

  • 每个事件占用的总时间、平均时间、动作数量
  • 每类事件占用的总时间分布、平均时间分布、动作数量分布。

4.5. 数据可视化

4.5.1. 数据分布对比

产品经理谈一谈:商品上架行为分析图表解释:

  • 图表中绿色为“商品已成功上架”事件,横轴表示不同商品成功上架花费的时间,纵轴表示用户数。
  • 从图中可知用户最多要花费60个单位的时间才能成功上架,说明上架效率较低,也侧面反映商户认可平台的价值,愿意花时间做上架动作。
  • 图表中红色为“商品未成功上架”事件,横轴表示不同商品用户花费的时间,纵轴表示用户数。
  • 从图中可知一部分用户花费较少时间操作上架,上架失败后就没有继续操作。

另有一部分用户一直在坚持操作,随着时间的增加可能会变为商品上架成功状态。

从模拟数据中获得信息为:

  1. 该平台可能新上线不久,系统还在适应期,系统体验度不好。
  2. 平台的用户对平台认可度高,虽然系统难用但是愿意使用,说明这是一个价值风口。
  3. 平台从事的行业产品信息复杂,校验严格。

产品经理可以调研上架成功次数多且花费时间多的用户,了解失败原因,针对性提供优化建议。

4.5.2. 数据整体对比

产品经理谈一谈:商品上架行为分析

以上三个箱体图分别统计“商品已上架成功”“商品未上架成功”两类事件,每个事件尝试的次数、花费的总时间和平均时间。

从图中可知,“商品已成功上架”事件操作次数比“商品未上架成功”事件操作次数多、花费的总时间也多,但是平均每次花费时间少,说明商品成功上架的商户会集中处理上架问题,不会间隔太久。

4.6.部署实时监控系统

部署实施系统的目标是将上述分析实时化,通过动态系统可以动态观察指标变化,管理层可以通过该指标明确业务重点,并考核实际成果,提高效率。

此处指标为:平均上架花费时间、平均操作次数。

05 数据可应用方向

5.1.商户奖惩机制干预

上架效率高低,由两个变量决定:操作人和平台系统。

对商户的干预是分析本公司不同员工的操作效率。通过区分表现优异或表现较差的员工,采取奖惩机制。

5.2. 平台产品体验优化

如果整体的效率较低,说明不是人力所能为,需要平台着重从技术上解决问题。

本文由 @我是产品张 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。