如何设计电商站内信功能？

站内信是一个网站运营辅助工具，用于用户与用户之间的交流和平台管理员与用户之间的沟通，所以在进行具体设计时，不仅要考虑到用户操作体验，也需要考虑功能的拓展维护。

这篇文章是基于最近网站做站内信功能的一点思考，在此和大家分享交流。

站内信属于系统内消息，电商平台的站内信大多数时候服务于网站会员。

站内信有两个交流方式：

用户与用户之间的交流，用户之间主动沟通消息；平台管理员与用户之间的交流，用户被动接收消息。

目前所做的站内信功能是从管理员与用户之间的交流进行设计，将从以下几点简单说明如何设计站内信功能：

一、做站内信的目的和意义

任何功能的设计都离不开用户需求，本次的诉求主要是随着网站运营内容的丰富和完善，需要推送的用户的信息类型逐渐增多，如果全部通过邮件进行推送，会过度打扰用户，引起用户反感，用户也有可能遗漏邮件中的内容，同时，也希望通过站内信去唤醒激活沉默用户，活跃老用户。

所以本次站内信需要实现由平台管理员给用户推送消息，用户可对消息进行查看。

二、站内信要满足哪些需求

知道了做站内信的主要诉求，接下来需要将诉求进行细化，可以从用户和平台管理员方向进行分析。

2.1管理员

2.1.1 创建站内信

需支持配置消息发送的客户端（PC、APP、M移动端）、消息的主体内容（标题、图片、文案、链接等等）、定义发送的对象，最后设置触发的时间（如果为自动触发类型的消息，则不需要设置触发的时间）。

2.1.2 站内信管理

站内信在创建之后，管理员可对站内信进行查询筛选，还需要通过发送率、打开率和转化率等数据直观反映效果。

2.2 用户

2.2.1查看站内信

战内信发送给用户之后，需要给用户提供一个方面查看的入口和界面，使用户在登录网站之后快速查收消息。

2.2.2删除站内信

当站内信消息过多的时候，需要支持用户删除或者清空消息。

2.2.3 设置是否接收站内信

站内信的推送在一定程度上会打扰到用户，如果用户不想接收某些类型或者全部消息，用户可自行选择接收的内容。

三、功能设计

基于上述分析，对站内信功能进行构建设计，分为前端和后台。前端主要是用户查看站内信，要方便用户操作，添加必要的提示，并对不同类型的消息进行分类；后端主要管理站内信的类型、创建和统计。

3.1 前端

面向对象为用户，主要需要考虑功能的易用性、简洁性和交互界面的友好。

3.1.1 消息接收提醒

站内信是一种用户需打开网站并登录才能查看的消息，因此消息提示需要简洁醒目，入口简单易找。

有未读新消息时在消息入口处用醒目图标或者未读消息数量进行提示。

在进行数量提示时需要控制提示的最大限度，由于电商网站不似社交平台，站内信消息提示不宜数量过多，在未读消息超过10条时显示9+即可，太多的未读消息容易对用户造成消息过载的压力。

3.1.2 消息接收列表

用户的站内信接收之后会聚合在一个列表，用户进入消息页面进行信息查看。需要将信息的类型及状态进行处理。

信息类型：向用户发送站内信会基于不同的目的，可能是系统提示消息，例如交易订单状态通知，物流提示通知，会员权益类变动通知等等；可能会是营销通知；也有可能是网站公告类消息，所以我们在列表中需要区分不同的类型，以便用户分类查看。

消息状态：已读状态和未读状态的消息要有所区分，目前比较常见的处理方式是未读状态亮色显示或者红色圆点提示，已读状态置灰或者无其他提示。

消息排序：PC端常见排序为倒序，即最新消息展示在最上面，可向下翻看历史消息记录，移动端常见为顺序排列，即最新消息展示在最下方，向上滑动页面也翻看历史消息记录。

3.1.3 消息设置

推送的站内信并不一定是用户希望看到的，可以视实际情况考虑加上选择性设置消息提醒功能或者消息删除功能。

3.2 后台

面向对象为内部运营人员，主要考虑功能设计的可靠性和操作流程的简便性。

3.2.1 消息类型

从内部来看，消息可分为人工站内信和系统站内信，人工站内信即人为设定触发条件给用户发送站内信，系统站内信即在满足一定的规则和条件下，系统自动即时给用户发送站内信。

不定时营销推送、功能调整公告通知适合使用人工触发的站内信；订单交易消息、物流消息、账户权益变动等需实时反馈的消息等适合使用系统自动推送的站内信。基于两种类型的站内信不同的触发方式，最好对两种站内信分别进行管理。

3.2.2 消息创建

人工站内信和系统站内信的创建会有所区别，有不同的创建方式，在这里分开进行说明。

系统站内信：系统站内信一般情况下无须区分客户端，只要达到触发条件就发送消息，创建的基础是区分类别（订单状态更改消息、物流消息、账户权益变动消息等等）；明确各个细分类别站内信的触发的规则和逻辑；确定各细分类别站内信的格式及内容（系统站内信的内容往往是变动的，需根据每个用户的行为、状态和操作的状态进行匹配发送）；最后将确定好的规则交由技术人员写入程序。

人工站内信：人工站内信会预先设置一些可选择和配置的条件，然后由内部运营人员自定义选择条件创建站内信，然后设置触发的时间。目前人工站内信可做的选择和配置条件举以下几个例子进行说明：

客户端类型：PC、M移动端、APP（Android &IOS）；用户统计学特征：性别、年龄等；用户位置信息：国家、邮政编码、IP地址等；用户等级：铜牌用户、银牌用户、金牌用户、钻石用户等；用户状态：新用户、老用户、活跃用户、沉睡用户等；用户的购买偏好：电子产品、彩妆、服装、户外用品等。 3.3 站内信管理

站内信功能的目的在于提升网站的运营能力，需要有数据支撑和反馈才能知道当前功能是否有效以及存在的问题，因此需要支持快速查询查看数据。

3.3.1 数据筛查

支持运营人员通过筛选条件，快速找到发送的站内行，并可对站内信内容进行查看；

3.3.2 数据列表

数据列表应展示当前站内信的发送情况、接收情况，包括送达率（接收数/发送数）、打开率（打开数/接收数）、转化率等数据指标。

通过对功能设计的分析，可以总结为下图：

四、最后

站内信是一个网站运营辅助工具，在具体设计时不仅要考虑到用户操作体验，也需要考虑功能的拓展维护。站内信在运营时应本着克制的原理，不要对用户进行信息的狂轰乱炸，并且尽量给用户推送必要的和优质的内容。

上述内容只是简单介绍了如何设计一个简单的站内信功能，主要是基于公司现有业务和需求进行设计，不具备普适性，希望可以作为一个参考，如果不当之处，欢迎大家批评指正。

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

站内信设计思路

站内信可以实现两个基本功能：点到点的消息传送：用户给用户发送站内信，管理员给用户发送站内信；点到面的消息传送：管理员给用户群发消息。

消息通知的几种形式

消息通知，通常来说包括以下几种形式：

形式一：系统 PUSH，极高的曝光率&极低的打开率

IM 消息提醒、评论互动、运营通常采用这一方式。IM 消息提醒如微信、QQ、钉钉的聊天消息，对及时性的要求极高。互动评论常见于社交类应用，比如微博。

用户对这两者的容忍度相对较高，且 IM 消息 > 评论互动。

系统 PUSH 的优点在于它的到达率和曝光率，只要没有被关闭通知权限，几乎能够 100% 让用户看见。

这样的后果是打开率极低，并且一旦频繁推送，就面临着被用户关闭通知权限、甚至直接被卸载的后果。

形式二：应用内弹窗，重要的版本更新提示通常采用这种方式

京东的版本更新提示，饿了么每天首次打开时的红包，Uber 的活动推广……都会采用应用内弹窗。应用内弹窗的曝光率极高，但破坏性也极强，因为它打断了用户的正常使用流程，并且必须按关闭/确认才能关掉弹窗（更优雅的交互方式是点击屏幕空白处）。

方式三：站内信通知，取决产品本身的架构，通常由官方账号发出

站内信通知，是更为普遍的一种活动运营方式。

而 app 的日常运营，也是靠该账号推送内容，比如网易云音乐的小秘书、的团队/ Live 团队。

方式四：小红点+浅灰色文字，通常标记在入口处

在功能入口上加小红点，在列表式的功能入口上加小红点/右侧浅灰色文字，是更常见的一种方式，比如微信默认朋友后有更新时会在发现栏上出现红点提示，以及微信读书的版本更新会在相应的入口处都添加小红点。

其他：手机短信通知、邮件订阅

这两种方式不再赘述。

本文重点阐述站内信的前后端设计逻辑。

什么是站内信

站内信”不同于电子邮件，电子邮件通过专门的邮件服务器发送、保存，而站内信”是系统内的消息，其实就是通过数据库插入记录来实现的。站内信”有两个基本功能：

点到点的消息传送。用户给用户发送站内信，管理员给用户发送站内信。点到面的消息传送。管理员给用户（指定满足某一条件的用户群）群发消息。 站内信怎么设计1. 站内信

关于用户的资产信息，商品物流等动态更新通知。

如交易、物流、收发货等通知，一方面用户能及时知晓商品的第一动向，另外也能在一定程度上较少企业的短信成本;

如积分变动、优惠券到期前通知，凸显用户资产信息重要性的同时，又唤醒沉默用户进行消费优惠券，从而促进订单转化。

一般用户只有阅读和删除权限；发送是由系统设置的触发条件或者运营人员在用户营销时手动发送；只能用户自己看到；在WEB端在个人中心一般为站内信”形式；移动端个人中心页面的消息图标并附带未读的条数；站内信内容不多，点击标题下拉收缩展开。 2. 公告

应用场景较广，便捷性较强，当企业存在公告类内容，可及时进行全量或定量推送，让平台内的用户知悉。

一般放在网站首页顶部区域，游客模式下也可看；只有网站管理员才可删除；内容较多，点击跳转新页面。 3. 设计思路

我们希望用户收到个性化的营销信息，唤醒沉默用户，而有的信息我们希望有游客也可以看到，便于未注册用户的注册转化。

笔者在互金公司做产品狗时，平台的运营活动较多，每个月有一固定大活动，两三个小活动，并针对这些活动发布站内活动通告，针对待收少于**的用户做单独的活动推送，可否将两者的通知渠道整合一下，优化下空间资源。

之前在首页右侧有公告图标，点击打开是公告列表，在个人中心页面右侧有个人消息，点击为个人的信息变动情况。

笔者在改版过程中，将公告通知模块与站内信模块设计在一起。

消息中心板块

顶部导航栏公告与站内信在导航栏页面，点击相互切换；点击通知消息，为企业公告消息，可二级菜单可具体细分为公告与活动消息；底板标签栏为操作栏，在公告页面，都为禁用状态，只有管理员才可删除公告信息；顶部点击我的消息，为个人信息页面；必须要登录状态，未登录则登录页面；

底部标签栏三个操作按钮都可点击状态：

小红点表示未读，阅读之后，小红点消失，点击标题栏，可展开查看具体内容（如下图）：

选中某消息，点击底部标签栏已读或者删除，可进行对应的删除或者已查看操作。

4. 后台设计

后台在设计时，功能要区分开。

1. 公告或者重大通知，一般篇幅较大，类似发布文章功能，也可用文章模块配置发送，都为管理员发布，某些内容需要事前审核；

点击新增通知，进行公告内容的编写发布：

2. 站内信发送功能由系统触发后自动发送，或者管理员手动发送，内容较短；

一般为系统定好的规则执行，当需单独对某用户发送时，可点击手动添加按钮，按级别，类型或者其他条件筛选，并填写发送内容推送；

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