Intercom 移动端用户识别避坑指南：为什么 User 不一定代表已登录用户？

发布时间：2026年05月29日 | 作者：优阅达-小优

带你看懂 Intercom 移动端用户状态识别的常见误区，以及如何通过 Workflow + Procedure 降低流程误判风险。

很多团队在上线 Intercom Messenger、Fin AI Agent 或自动化 Workflow 时，都会默认一个前提：只要 Intercom 里显示的是 User，那这个用户应该就是已经登录 App 的用户。但在实际项目里，这往往并不成立。

不少移动端团队都遇到过类似问题：

- 用户明明还没有登录 App，为什么在 Intercom 里却看起来像是一个 User？

- 为什么 AI 客服会把未登录用户带入已登录用户流程？

- 为什么某些 Workflow 或 Procedure 会被误触发？

这些问题在 Web 场景中不一定明显，但在移动端 App SDK 场景下却非常常见。原因其实很简单：Intercom 里的 User，本质上是 Intercom 侧的联系人对象，并不等于业务系统里的“当前真实登录用户”。

💡 移动端用户识别的关键，不是 Intercom 如何称呼这个联系人，而是当前 App 会话是否真实登录、是否能关联到真实业务用户。

常见误区：只用 Contact Type 判断用户身份

在 Workflow 配置中，很多团队会直接使用类似规则：“如果 Contact Type = User，就进入已登录用户流程。”这个逻辑在简单场景里可能没有问题，但在移动端业务里风险其实很高。

因为移动端用户状态，通常会受到多个因素共同影响：

💡 也就是说：Intercom 显示的是 User，并不代表这个用户此刻真的处于登录状态。如果只依赖 Contact Type 做判断，就很容易出现流程误触发、身份误判，甚至错误调用个性化数据的问题。

图 1：Intercom User 和 App 真实登录状态的区别

相比只依赖 User / Lead / Visitor 这样的联系人类型，更推荐采用“业务状态 + 身份关联”的组合判断机制。其中，最关键的字段其实是 login_status。它决定的，是当前 App 会话是否真实登录。

字段 / 维度	建议定位	说明
login_status	主判断	判断当前 App 会话是否真实登录，是移动端用户状态识别的核心字段。
user_id / member_id	身份关联	判断是否能关联到真实业务用户，是进入个性化服务前的重要条件。
user_level / tier	辅助过滤	可用于客户分层或用户属性判断，但不应替代登录状态。
platform	来源识别	区分 iOS、Android、Web，便于分流、排查和报表分析。
last_login_at	排查辅助	用于判断是否存在旧会话、状态延迟或异常状态残留。

💡 这类设计的核心思路是：不要只看“联系人是谁”，而要看“当前会话真实处于什么状态”。只有这样，AI 客服、Workflow 和自动化服务流程，才能真正稳定运行。

在移动端 Intercom 项目里，更推荐采用“双层防护”设计：第一层由 Workflow Audience 负责入口分流，第二层由 Procedure Guardrail 在执行前再次校验。

图 2：移动端用户状态识别推荐架构

Workflow 路由的关键是：先判断真实状态，再进入合适路径。避免未登录用户误进入个性化服务流程，也避免 AI 流程无效调用。

图 3：Workflow 根据真实登录状态进行路由分流

下面列出了不同用户路径的建议条件及适合内容，帮助你更清晰地设计 Workflow 分流规则：

路径	建议条件	适合内容
已登录用户路径	Contact Type = User + login_status = logged_in + user_id/member_id 有值	个性化服务进度查询会员权益等
未登录 / 匿名路径	login_status = anonymous / 空，或 user_id/member_id 为空	通用 FAQ 产品介绍登录引导帮助中心 / 人工转接

即使 Workflow 已经做了分流，也不建议完全依赖第一层判断。对于涉及个人资料、订单记录、服务进度、会员权益等个性化信息的 Procedure，建议在执行前再次检查：

💡 简单来说：Workflow 决定“用户进入哪条路径”，Procedure 决定“是否允许继续执行”。

图 4：Workflow 和 Procedure 的双层防护关系

在移动端 App 中，用户点击“退出登录”后，业务系统里的登录状态可能已经清空了。但如果没有同步清理 Intercom 侧的会话状态，Messenger 仍可能保留上一位用户的上下文或用户属性。

这会导致一系列问题：

💡 因此，移动端 Logout 不只是“退出 App”。更重要的是：同步清理 Intercom 侧的会话、缓存和用户属性。

图 5：移动端 logout 和会话清理机制

为了避免旧会话残留、账号错配等问题，移动端 App 场景下建议针对不同状态执行对应动作，并明确处理目标：

App 场景	建议动作	目标
用户未登录打开 App	传入 anonymous / 未登录状态；不传或清空业务用户 ID。	进入未登录路径
用户成功登录	传入 logged_in 状态；同步 user_id/member_id；如有则同步用户等级。	进入已登录路径
用户退出登录	调用 logout / reset 机制，并清理本地缓存与用户属性。	避免旧会话沿用
用户切换账号	清理旧身份；初始化新用户。	避免账号资料残留或错配

很多团队只关注技术实现，但实际上，客服团队同样需要理解用户状态机制。因为在 Intercom Inbox 里看到 User，并不代表这个用户此刻真的登录了 App。

💡 因此，建议在 Inbox 用户侧栏中展示几个关键字段，让客服能够快速判断当前用户状态，而不是依赖经验猜测。

Inbox 建议展示字段	主要用途
login_status_text	最直观地判断当前会话是 logged_in 还是 anonymous。
user_id / member_id	判断是否可以关联真实业务用户。
user_level / tier	辅助判断用户分层、会员等级或服务优先级。
platform	判断问题是否来自 iOS、Android 或 Web。
last_login_at	排查是否为旧会话、状态延迟或异常残留。