Kiven 墨西哥用户访谈研究｜管理工具方向与数据接入决策

Executive summary

研究摘要

管理价值与数据接入，是相互关联但必须分别验证的两个问题。

深度访谈用户

本次定性研究样本

10/12

能够给出管理功能有效排序

优先功能存在分散选择

10/12

读取金融数据时初始担忧或要求说明

不是邮箱 OAuth 拒绝率

核心判断：用户并不缺乏查看银行余额和账单的渠道，但要跨账户掌握未来付款责任，仍需在不同银行 App、日历和个人记录之间切换。 Kiven 最值得先验证的，是把未来应付款、到期提醒和资金安排放在一个可信的工具中。与此同时，账单是否能持续更新，取决于数据来源覆盖、权限信任及使用成本，而不能单凭 Gmail 技术原型决定最终产品路径。

Part 01 · Interview findings

第一部分｜用户访谈结论

围绕原始提纲中的管理工具、卡与账单、提醒、持续使用、数据授权及产品定位问题。

1. 管理功能的优先级与第一反应

(1)

10 位用户给出了有效的管理功能排序；需求并非集中于一种功能。

原题是先选出最想用的三项、再排序，因此需要同时看第一优先和进入前三的频次。

(2)

消费分析是第一优先的最多选项（3/10），但还款提醒、消费分析和余额不足预警在 Top 3 中各获 7/10 次选择。

第一优先排序反映最迫切的单一需求；Top 3 反映功能整体吸引力。

数据 1｜第一优先管理功能

10人有效回答

消费分析：3人（30.0%）

还款提醒：2人（20.0%）

余额不足预警：2人（20.0%）

下月付款预测：2人（20.0%）

储蓄目标：1人（10.0%）

N=10；第一优先是一人一个选项。另 2 人无有效排序，不作为某功能的反对票。

数据 2｜进入前三优先的管理功能

消费分析

7/10

还款提醒

7/10

余额不足预警

7/10

下月付款预测

5/10

储蓄目标

2/10

N=10；多选，合计可超过 100%。有的访谈只记录了两项明确排序。

2. 卡、账单与还款管理的现状

(1)

用户习惯在各家银行／发卡机构自己的 App 查看余额、交易和账单，同时使用日历、Excel 或笔记本跟踪还款。

银行 App 能管理本机构账户，不代表能够自动整合其他银行的账单。

(2)

付款困难需要区分“忘记付款”与“明知到期但资金不足”。

提醒有助于前一种问题；后一种问题更需要未来应付款可视化和资金安排。

(3)

用户关注金额、期限、最低还款、全额付款及融资成本等信息，而不仅是信用卡数量。

汇总不同账户的应付款与到期时间，比简单展示发卡行列表更接近管理任务。

3. 提醒、余额预警与持续使用

(1)

用户想要的提醒时间并不一致，既有临近还款日的提醒，也有更早的预算安排提醒。

需要可配置的提前天数，不能把所有提醒统一为固定天数。

(2)

资金不足的时点常与发薪、佣金入账或账单到期相互影响。

对这些用户来说，“下次进账前需要付多少”比孤立的历史消费记录更具有行动价值。

(3)

有价值的通知围绕明确的付款责任；频繁、催收式或营销式提醒可能造成反感。

持续使用不能仅由推送频次驱动。

4. 数据授权与隐私信任

(1)

10/12 的用户对第三方读取金融信息的初始反应是担忧或需要先了解。

涉及访问范围、数据用途、是否可能转钱或自动扣款，以及服务是否可信。

(2)

只读权限、银行合作背书、明确告知用途和用户自主确认，是部分用户提出的信任条件。

这不代表所有人满足这些条件后都会授权。

(3)

访谈没有直接比较 Gmail／Outlook 授权与银行 App 官方授权。

12 位外部受访者尚未直接比较这两种方案；Ame 和南山的内部补充反馈则明确更接受银行 App 官方授权，而不接受邮箱读取。

数据 3｜第三方读取金融数据的第一反应

12人有效回答

担忧或需先了解：10人（83.3%）

初始理解或接受：2人（16.7%）

N=12；本题测量第三方金融数据访问的第一反应，不等于实际 OAuth 授权选择或完成率。

补充发现｜邮箱读取与银行官方授权的信任差异

内部员工 Ame 和南山均不接受直接授权 Kiven 读取 Gmail／Outlook 邮箱。他们担心应用可能接触到与信用卡账单无关的大量私人信息；即使说明读取范围和数据用途，也不能消除这一顾虑。

相比之下，Ame 和南山均表示可以接受跳转银行官方 App 完成授权。这一反馈表明，授权发生在何处、用户认为应用能够接触哪些信息，会明显影响信任感。

以上为 Ame、南山的内部员工补充反馈，独立于 12 位外部受访者的统计结果；“愿意接受官方授权”不代表已完成真实银行授权流程。

5. Kiven 当前定位与信任

(1)

至少 4/12 人看到 Kiven 页面后，首先将其理解为贷款或信贷服务。

将管理与借贷结合的定位并未被所有人清楚识别。

(2)

“帮助管理”和“鼓励借款”之间的关系会影响用户的信任。

管理功能的价值应独立清楚地呈现，金融服务需有明确边界。

数据 4｜Kiven 页面第一印象

12人有效回答

明确主要理解为信贷：4人（33.3%）

其他或混合型理解：8人（66.7%）

N=12；保守归类。“其他或混合型理解”不意味着全部准确理解管理工具。

6. 信贷交互体验的补充发现

与管理工具核心路线不同，这部分结果可用于借贷相关界面优化，不作为管理工具优先级的主要依据。

(1)

借款金额选择测试中，7/12 人明确偏好手动输入；滑块和列表各 2/12 人。

另 1 人回答不够明确，不应归入任一方案。

(2)

大多数用户正确识别还款金额，但有两位将本金误认为总还款额。

总还款额：10/12 人正确回答 3,300 MXN；Alfredo 和 Joaquin 均回答 3,000 MXN（实际是借款本金）。每期金额：10/12 人正确回答 1,100 MXN；Alfredo 回答 300 MXN，Joaquin 回答 3,300 MXN（实际是总还款额）。这表明少数用户混淆了本金、每期金额与总还款额。

(3)

划线利息呈现了三种重要误解：历史费用、广告宣传，以及不知道划线金额的实际作用。

设计原意：本次借款本金 3,000 MXN，优惠前利息 600 MXN、优惠后实际利息 300 MXN；三期每期还 1,100 MXN，总还款 3,300 MXN，优惠已计入总还款额。Rafael 把划线 600 MXN 理解为过去的利息；Brandon 将其当成广告宣传；Erika、Alfredo 对划线金额的作用表示不清楚。与之对照，Dulce Maria、Irma 基本理解为从 600 MXN 降至 300 MXN。

(4)

金额可读性与金融成本可理解性不是一回事。

能回答每期和总还款金额，不代表理解“600 MXN 是否仍需支付”“300 MXN 是实际利息还是额外减免”“优惠是否已体现在 3,300 MXN 中”。因此金额识别结果与折扣理解应分别报告，不应将多种误解拆成重复的平行结论。

数据 5｜借款金额输入方式

12人有效回答

手动输入：7人（58.3%）

滑块：2人（16.7%）

列表：2人（16.7%）

待确认：1人（8.3%）

N=12；用户在手动输入、滑动及列表选择之间进行比较。

数据 6｜总还款金额识别

12人有效回答

正确识别 3,300 MXN：10人（83.3%）

其他回答：2人（16.7%）

N=12；属于展示理解测试，不等于金融知识测试或账单管理功能需求。

Part 02 · Implications

第二部分｜产品启发与下一步重点

把用户研究与同步技术调研放在同一条决策链路中，但不混淆两者证据。

7. 产品方向：围绕账单管理场景确定迭代重点

① 汇总

信用卡与其他待付款项目的基本信息

② 预见

未来 30 天的应付款和截止日期

③ 提醒

由用户控制的还款提醒与余额预警

④ 更新

每个账期通过适当渠道保持数据新鲜

方向依据：管理功能优先级、用户目前分散查看账单的习惯，以及对未来付款、还款提醒和资金预警的需求。管理工具已确定建设，本阶段重点是功能排序与使用体验，而非重新验证项目必要性。

8. 四种账单获取方式：业务价值、技术成熟度和信任边界

方式	已确认的事实	关键限制	建议
PDF 手动上传	现有基础接入方式	需要每个账期重复操作	保留为基础路径，简化分享／上传
邮箱 OAuth 同步	真实 Gmail 的单用户原型可连接邮件并解析测试附件	真实银行覆盖和商用审核未完成；Gmail 数据用于放贷受限制	考虑员工明确提出的隐私顾虑；验证真实邮件覆盖、授权接受度与合规用途
银行 App 官方授权直连	可作为用户授权体验的候选形态	并非仅跳转银行 App 就能获取数据；需要正式接口或可用服务	结合 Ame、南山的正向反馈，优先核实正式接口、可接入银行及账单字段
第三方 API 合作	有潜在数据聚合路径	覆盖、成本、字段与合规取决于供应商	做供应商尽调并测试真实卡片

同事技术调研中，25%–45% 自动覆盖率属于粗略估算，而非实际样本验证；Gmail 原型的 5–9 秒导入速度也不是线上性能承诺。

9. 数据用途需要在产品设计时先确定

账单管理数据 ≠ 可直接用于放贷的数据。Google API 数据存在信用评估和放贷用途限制。不能因为用户同意邮箱读取，就把数据或其衍生信息直接送入授信、贷款定价和营销决策。不同来源的数据用途、授权范围、存储和调用权限应分别评审。

合规判断依据：《墨西哥账单自动同步方案》及 Google API Services User Data Policy；具体商用方案仍应由法务与平台审核确认。

Action plan

10. 下一步重点与证据依据

优先级 P0

确定管理工具下一阶段功能优先级

结合功能“第一优先”和“Top 3”选择，明确消费分析、还款提醒、下月应付款预测、余额预警等能力的迭代顺序与核心页面。

依据：访谈显示功能首选分散，不能以某单项第一名代替整体需求；需结合前三选择与既有卡、账单管理场景综合判断。

优先级 P0

确定用户可接受的账单接入方式

以 PDF 上传、邮箱 Gmail／Outlook 授权、跳转银行官方渠道授权三种用户旅程作对照，重点比较信任感、隐私顾虑、操作理解与实际选择。

依据：12 位用户对第三方金融数据访问普遍存在担忧；Ame 和南山明确不接受邮箱读取，但可以接受银行官方授权。该内部反馈不并入 12 位用户统计。

优先级 P1

优化账单接入与每月更新体验

优化现有 PDF 上传路径及银行 App 分享 PDF 的操作衔接；对支持自动同步的接入方式设计连接状态、授权说明、账单更新提醒和失败后的手动兜底。

依据：当前 PDF 方案需要用户重复操作；邮箱自动化原型已验证部分流程，但用户接受度与可接入银行范围仍影响最终体验设计。

优先级 P1

规划管理工具的持续使用场景

围绕出账、还款到期、下一期应付款和资金预警等关键节点设计用户可控提醒，并明确每项提醒对应的管理动作。

依据：访谈中还款提醒、余额预警、下月付款预测均进入多名用户的前三选择；现有用户依赖银行 App、日历或 Excel 分散管理。

本轮建议的评审决定

产品行动 明确管理功能迭代优先级；开展三种账单接入旅程的用户接受度对照；优化现有 PDF 更新及持续使用场景。

技术依赖与边界 银行直连、第三方 API、真实账单覆盖及解析准确率由技术团队评估；产品负责接入体验、用户权限说明和业务验收要求。

研究基础：2026 年 10 月《Kiven 墨西哥用户访谈》原始问卷和受访者回答（12 人）；《墨西哥账单自动同步方案》及《Kiven 账单自动更新》交互 Demo。所有人数统计仅描述本次定性样本；技术原型结果与真实银行规模化上线能力分别呈现。