作者是一个半路出家的电商产品经理。之前他对电商的理解只停留在做马爸爸背后的女人身上，所以他在角色转换时遇到了很多困难。今天就和大家分享一下市面上的产品经理书籍中很少提及的产品需求写作要点，希望能从一些新的角度帮助到刚转行或者想入坑的伙伴们。
我在考拉购海APP上选择了一个非常简单的活动页面作为参考，给大家做一个分析。
考拉活动链接：https://dwz.cn/4e7v8x51
(非考拉产品经理，也不信任，只是选择了一个可以在微信打开的网页)
接下来，如果我是这个活动页面的产品经理，除了我们在一些书中看到的内容，我还会添加哪些产品需求供大家参考？
一、注册、登录
首先需要考虑的是用户的注册/登录功能，这将随着不同的运营需求和活动指标而变化。目前很多电商产品大多采用延迟登录的模式，即用户可以直接打开浏览器，然后在需要购买或获取优惠券时提示注册登录。当主要新载体来自H5，基于微信的小程序，特别是自有电商平台比较轻，不要求订单转换，但需要先熟悉新载体，思路可以稍微改变。
众所周知，微信授权登录还是挺方便的。有些平台会在活动页面进入时要求先授权登录，然后获取用户的openID、头像和昵称，这样会比没有登录的页面更加完善。
选择哪种方式主要看收到的项目情况。
微信授权登录提示页面(客户端)
二、页面展示和交互
考拉活动页面比较简单，主要分为四个活动专题页面，然后根据专题页面中的类别按照推广信息分为三个版块。
考拉活动页面结构浅析
关于页面设计的细节我就不在这里赘述了。上图展示了这个活动页面的三级分类，基本确定了页面的显示级别和对应的框架。
接下来，您需要在此页面上设置一些详细信息：
1. 商品是根据逻辑自动展示，还是运营手动后台配置
以前的产品需要提供展示产品的策略，前端写死，主要工作是产品和开发。优点是操作少，上线快，缺点是对产品策略和产品数据化程度要求较高。比如有些平台对产品和用户的标签较少，用户以这种方式展示时会觉得推荐的产品不尽如人意，从而影响产品购买的转化。后者需要重新设计相应的后台产品，并确定相应的维护人员进行运营，其主要工作是开发和运营。优点是可以通过人力(取决于操作能力)提高商品的购买和转化，缺点是操作会比较重，活动越多，手工作业越多，会影响操作的创造性和激情，后期能否达到效果很难保证。
目前有些平台采用了两者结合的方式，即建立商品模块，如自建热门榜、人气榜，然后对这类榜单进行后台配置操作，再根据活动调整展示规则，在减少工作量的基础上保证推荐的可靠性。
00-1010接下来，还有一些商品展示的细节。
(一)基本商品信息
(2)排序方法
如果排序是操作后台手动设置的，则不需要考虑。如果排序方式是自动/半自动，需要了解活动规则和用户体验。
比如一般用户会喜欢很多人买的产品。如果看平台购买的转化，按照多销少销的顺序进行产品排序是没有问题的。但这容易产生马太效应，对一些小企业不太友好。比如像淘宝这样的平台推出了竞价排名，在综合推荐的基础上，插入了几个竞价产品。
同时，在按单个维度排序时，需要考虑一些极端情况。比如有些产品做得特别好。如果分页列表按照日销量、周销量、月销量倒序排列，可以主导列表，对用户不太友好。他会看到，不管怎么切换，都是那些产品。
因此，需要增加其他排序维度，如类别、优惠率、采购数量等。也可以借助微博等新闻信息流增加一个时间衰减权重，或者在列表中插入几个新产品。具体操作可以根据实际情况进行调整，主要需要服从活动规则、操作要求、用户体验等多目标。
(3)加载模式
加载方式可以看作是CC踩过的一个大坑。在做产品之前，我以为产品每天都在做市场调研、用户画像等高端工作。做了之后发现每天首页打不开的问题解决了，说的都是眼泪。
比如活动页面上还是有很多像考拉这样的产品。如果所有产品进入页面后都加载显示，除非用户手机性能好，网络飞成那样，否则轻则加载慢，重则加载始终失败，所以什么都不要卖。
所以可以观察考拉的活动页面，采用的是懒加载，即优先显示前两行产品的商品名和价格，用默认地图显示产品地图，预加载后两行产品，然后在用户滑动时显示。
2行商品，对用户来说，可能只延迟了肉眼可见的不到1秒时间，还是可以接受的。还有些活动可能会做些商品预存，不是每次直接从商品库里面调，而是另外预存加载，这样商品展示时调用起数据来，速度会快很多。
毕竟对用户爸爸来说，超过2秒就要关页面了。
如果给用户一些有趣的加载提示，让用户内心不崩溃，也是个不错的方式。
此外，如果商品上展示标签、营销信息过多，因为涉及多张表，也会造成商品加载时间延长，这时候就需要和运营小伙伴商量，能不能把提升用户体验放在首位，或者找后端小伙伴处理这类情况，保证用户爸爸们能快速打开页面，开开心心shopping。
（4）页面提示
页面上的有效反馈可防止用户心态崩溃，具体需要根据用户的场景，在提需求之前尽可能的做好罗列，并撰写对应情况下的页面提示，引导用户进行相应的操作。
具体的案例就不举了，花瓣上有很多有意思的设计，可以自行搜索一下。
在此简单讲下前端需要注意的场景，比如说用户未登录状态下，怎么展示页面，用户点击某些元素时需要用户先授权，如何引导授权，断网的时候如何引导检查网络，加载失败情况下怎么提示用户刷新且不要心态爆炸，或者前端怎么做对应的检测，然后后台自动重连。
实际情况会比上面说的复杂很多，到时候被开发和用户吊打的时候大家就知道了。
三、数据统计
我发现每个产品经理说到数据模块都有种欲哭无泪的表情，其实我也是。
在此给大家简单介绍下一个活动页需要埋点的数据字段和维度，实际工作中需要的数据量可能更大一点。
根据CC目前的工作来说，运营比较关注的是拉新（渠道来源、转化）、促活（用户活跃数据、前后活跃量对比、某类用户的激活情况）和转化（活动相关的营销指标完成情况），而作为产品，还需要去了解下参与活动的用户设备、用户路径、用户人群等数据，帮助自己更好地迭代产品。
四、商品和媒体管理
除此之后，还有一些后台商品管理、媒体管理需求，如何做到和C端产品字段一一对应，如何在保证活动营销性和有效性的前提下，尽可能减少运营维护成本，防止他们内心崩溃，具体可以开个淘宝店铺、有赞店铺学习下。
需要注意的是，每个平台因为属性不同，对于产品形态的要求是不一样的，比如说淘宝商品上架所需要的信息是非常多的，有些商家甚至需要安排1-2个人专门做上新，那像笔者的导购小平台就大可不必做那么复杂，甚至直接写逻辑让开发从合作方那边调数据过来就好了。
因为笔者是C端、后台产品一起做的，不存在沟通问题，有些公司是分开的，就需要做好产品间的沟通，尤其是一些细节上保持一致，避免出现类似后台商品标题限制字数10字，C端限制15字，到时候就会出现诡异的情况了。
结语
关于产品需求文档的遗漏点就这样，欢迎大家留言补充，一起进步，写出更靠谱、落地的产品需求文档。
本文由 @ CC-Cynthia 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议