站内信可以实现两个基本功能：点到点的消息传送：用户给用户发送站内信，管理员给用户发送站内信；点到面的消息传送：管理员给用户群发消息。
消息通知的几种形式
消息通知，通常来说包括以下几种形式：
形式一：系统 PUSH，极高的曝光率&极低的打开率
IM 消息提醒、评论互动、运营通常采用这一方式。IM 消息提醒如微信、QQ、钉钉的聊天消息，对及时性的要求极高。互动评论常见于社交类应用，比如微博。
用户对这两者的容忍度相对较高，且 IM 消息 > 评论互动。
系统 PUSH 的优点在于它的到达率和曝光率，只要没有被关闭通知权限，几乎能够 100% 让用户看见。
这样的后果是打开率极低，并且一旦频繁推送，就面临着被用户关闭通知权限、甚至直接被卸载的后果。
形式二：应用内弹窗，重要的版本更新提示通常采用这种方式
京东的版本更新提示，饿了么每天首次打开时的红包，Uber 的活动推广……都会采用应用内弹窗。应用内弹窗的曝光率极高，但破坏性也极强，因为它打断了用户的正常使用流程，并且必须按关闭/确认才能关掉弹窗（更优雅的交互方式是点击屏幕空白处）。
方式三：站内信通知，取决产品本身的架构，通常由官方账号发出
站内信通知，是更为普遍的一种活动运营方式。
而 app 的日常运营，也是靠该账号推送内容，比如网易云音乐的小秘书、知乎的知乎团队/知乎 Live 团队。
方式四：小红点+浅灰色文字，通常标记在入口处
在功能入口上加小红点，在列表式的功能入口上加小红点/右侧浅灰色文字，是更常见的一种方式，比如微信默认朋友后有更新时会在发现栏上出现红点提示，以及微信读书的版本更新会在相应的入口处都添加小红点。
其他：手机短信通知、邮件订阅
这两种方式不再赘述。
本文重点阐述站内信的前后端设计逻辑。
什么是站内信
“站内信”不同于电子邮件，电子邮件通过专门的邮件服务器发送、保存，而“站内信”是系统内的消息，其实就是通过数据库插入记录来实现的。“站内信”有两个基本功能：
点到点的消息传送。用户给用户发送站内信，管理员给用户发送站内信。
点到面的消息传送。管理员给用户（指定满足某一条件的用户群）群发消息。
站内信怎么设计
1. 站内信
关于用户的资产信息，商品物流等动态更新通知。
如交易、物流、收发货等通知，一方面用户能及时知晓商品的第一动向，另外也能在一定程度上较少企业的短信成本;
如积分变动、优惠券到期前通知，凸显用户资产信息重要性的同时，又唤醒沉默用户进行消费优惠券，从而促进订单转化。
一般用户只有阅读和删除权限；
发送是由系统设置的触发条件或者运营人员在用户营销时手动发送；
只能用户自己看到；
在WEB端在个人中心一般为“站内信”形式；移动端个人中心页面的消息图标并附带未读的条数；
站内信内容不多，点击标题下拉收缩展开。
2. 公告
应用场景较广，便捷性较强，当企业存在公告类内容，可及时进行全量或定量推送，让平台内的用户知悉。
一般放在网站首页顶部区域，
游客模式下也可看；
只有网站管理员才可编辑删除；
内容较多，点击跳转新页面。
3. 设计思路
我们希望用户收到个性化的营销信息，唤醒沉默用户，而有的信息我们希望有游客也可以看到，便于未注册用户的注册转化。
笔者在互金公司做产品狗时，平台的运营活动较多，每个月有一固定大活动，两三个小活动，并针对这些活动发布站内活动通告，针对待收少于**的用户做单独的活动推送，可否将两者的通知渠道整合一下，优化下空间资源。
之前在首页右侧有公告图标，点击打开是公告列表，在个人中心页面右侧有个人消息，点击为个人的信息变动情况。
笔者在改版过程中，将公告通知模块与站内信模块设计在一起。
消息中心板块
顶部导航栏公告与站内信在导航栏页面，点击相互切换；
点击通知消息，为企业公告消息，可二级菜单可具体细分为公告与活动消息；
底板标签栏为操作栏，在公告页面，都为禁用状态，只有管理员才可删除公告信息；
顶部点击我的消息，为个人信息页面；
必须要登录状态，未登录则登录页面；
底部标签栏三个操作按钮都可点击状态：
小红点表示未读，阅读之后，小红点消失，点击标题栏，可展开查看具体内容（如下图）：
选中某消息，点击底部标签栏已读或者删除，可进行对应的删除或者已查看操作。
4. 后台设计
后台在设计时，功能要区分开。
1. 公告或者重大通知，一般篇幅较大，类似发布文章功能，也可用文章模块配置发送，都为管理员发布，某些内容需要事前审核；
点击新增通知，进行公告内容的编写发布：
2. 站内信发送功能由系统触发后自动发送，或者管理员手动发送，内容较短；
一般为系统定好的规则执行，当需单独对某用户发送时，可点击手动添加按钮，按级别，类型或者其他条件筛选，并填写发送内容推送；
