我如何构建信用卡管理仪表板（以及为何电子表格无法满足需求）
Source: Dev.to
请提供您希望翻译的正文内容，我将为您翻译成简体中文并保持原有的格式、Markdown 语法以及技术术语不变。
情况
我拥有 17 张信用卡，每张卡都有特定用途：
| 卡片 | 用途 |
|---|---|
| 0 % APR 余额转移 | 4 个月的优惠期 |
| 商务卡 | 广告消费 3 倍积分 |
| 个人卡 | 轮换 5 % 类别 |
| 商业库存卡 | 进货采购 |
| … | … |
我在 Google Sheet 中记录所有信息，列包括：
- 卡片名称 / 发卡机构
- 信用额度
- 当前余额
- APR / 促销利率
- 促销到期日
- 年费日期
- 奖励结构
- 备注
行使用颜色标记紧急程度，并设置条件格式以提示即将到来的截止日期。
这种方式运行了大约 两年——随后失效了。
触发点
我错过了一张 0 % APR 到期的卡片的还款，该卡上还有 12,000 美元 的余额。
促销利率在一个星期二结束。我那周没有查看表格，标准 APR 开始计息，我因此支付了本可以避免的利息。
电子表格 已经有日期，且条件格式也正确。
问题在于：电子表格 不会像 “嘿，你还有 7 天就要到期了，而且这张卡上还有 12,000 美元” 那样推送通知。
正是这一刻促使我决定 构建更好的工具。
出了什么问题（两年的基于电子表格的卡片管理）
| 问题 | 失败原因 |
|---|---|
| 没有主动提醒 | 表格仅显示数据，从未提醒我。 |
| 手动计算使用率 | 计算 17 张卡的总体使用率需要每次更新余额、求和并除以总额。 |
| 没有“该使用哪张卡”逻辑 | 我在脑中了解奖励结构，但常常在错误的商户使用错误的卡。 |
| 被动的年费决策 | 我只在账单上注意到费用，而不是在费用产生前。 |
| 申请跟踪混乱 | 我必须手动统计申请数量，以保持在 Chase 的 5/24 规则以下。 |
| 手动余额录入 | 用户（包括我）没有保持数据更新，导致仪表板失效。 |
核心数据模型 – 每张卡都是一个对象
{
"name": "string",
"issuer": "string",
"creditLimit": 0,
"currentBalance": 0,
"standardAPR": 0.0,
"promoRate": {
"rate": 0.0,
"expiration": "YYYY‑MM‑DD"
},
"annualFee": {
"amount": 0,
"date": "YYYY‑MM‑DD"
},
"rewardStructure": {
"baseRate": 0.0,
"categories": {
"groceries": 0.0,
"gas": 0.0,
"...": 0.0
},
"rotating": {
"quarter": "Q1‑2024",
"categories": ["dining", "travel"],
"multiplier": 5,
"cap": 1500
}
},
"applicationDate": "YYYY‑MM‑DD",
"lastStatementDate": "YYYY‑MM‑DD",
"paymentDueDate": "YYYY‑MM‑DD"
}关键点： 有几个属性是 时间相关 的（促销到期、轮换类别、年费日期）。
Deadline Engine – The Real‑Time Alert System
每张卡片会生成一组 deadlines，并附带严重程度等级和建议操作：
| Deadline | Alert Timing | Example Message |
|---|---|---|
| Promo‑rate expiration | 90 d, 60 d, 30 d, 7 d before | “您的 Citi 0 % APR 将于 30 天后到期。余额：$8,400。Action: 偿还或转账。” |
| Annual‑fee renewal | 60 d, 30 d before | “年费 $95 的 Amex 将在 30 天后到期。评估保留还是取消。” |
| Payment due date | 7 d, 3 d before | “付款 $1,200 将于 2024‑04‑15 到期。避免滞纳金。” |
| Rotating‑category activation | Start of each quarter | “Q2 奖励：杂货类 5 %（上限 $1,500）。” |
alert engine 是实际防止代价高昂错误的功能。
利用率计算（实时）
- 总利用率 = Σ (currentBalance) ÷ Σ (creditLimit)
- 单卡利用率 = currentBalance ÷ creditLimit
- 影响模拟 – “如果我把 $3,000 从卡片 A（45 % 利用率）转移到卡片 B（12 % 利用率），每张卡的利用率会是多少？”
这些数字很重要，因为 信用评分模型关注每张卡的利用率，而不仅仅是整体。
卡片选择器 – “哪张卡给我最高回报？”
给定一个消费类别（例如，杂货、加油、餐饮、线上），选择器会评估：
- Base reward rate per card。
- Current bonus categories（包括轮换的季度奖励）。
- Activation status – 本季度奖励是否已激活？
- Spending caps – 该消费是否超过了奖励上限？
结果是一个 lookup function，它会在每个季度更新，并遵守上限和激活状态。
促销利率逻辑 – 处理不同术语
| 术语 | 到期逻辑 |
|---|---|
| “Promotional APR” | 固定日历日期（例如 2024‑07‑01）。 |
| “Introductory rate” | 固定日历日期 或 “账户开立后 X 个月”。 |
| “0 % for 18 months” | 计算到期 = applicationDate + 18 个月。 |
系统会将这些不同的表达统一规范为 单一的到期日期，用于提醒调度。
减少手动数据录入
问题： 手动录入会形成鸡生蛋的循环——仪表盘只有在数据是最新时才有用，但用户不愿意保持更新。
探索的解决方案：
- API 同步 与发行方（如可用）。
- 银行级聚合（例如 Plaid）用于余额。
- 快速添加小部件（移动友好）用于余额更新。
- 智能默认值（例如，从上一次对账单自动填充付款到期日）。
目标是让数据录入 无摩擦。
通知引擎 – 核心价值
所有的图表和仪表板都很不错，但真正的价值在于在促销费率到期前三天发送的通知。其他一切都次于这个警报引擎。
YMYL（Your Money, Your Life）考虑因素
金融内容被搜索引擎归类为 YMYL。这意味着：
- 每个数字必须准确。
- 每个声明必须经得起辩护。
- 不要提供草率的建议——用户在真实的金钱决策中依赖这些信息。
因此，在金融科技领域的构建需要严格的数据验证和明确的来源说明。
StackEasy – 用户真实使用情况
| 功能 | 为何重要 |
|---|---|
| 投资组合仪表板 | 一目了然地显示所有卡片、余额、额度和使用情况。 |
| 截止日期跟踪器 | 对促销到期、年费和付款日期提供主动提醒。 |
| 卡片选择器 | 为每个消费类别推荐最佳卡片。 |
| 申请日志 | 跟踪在不同发行商的申请速度（例如，保持在5/24以下）。 |
当用户告诉我他们捕捉到了本可能错过的促销到期时，这是最大的验证。这就是全部意义所在。
非显而易见的金融科技构建者经验教训
- 从自己的痛点出发。 我创建 StackEasy 是因为我需要它。
- 专注于最有价值的单一功能。 对我而言：截止日期提醒引擎。
- 让数据录入无摩擦 或实现自动化；否则产品会夭折。
- 提前统一术语（promo APR、intro rate 等），以简化逻辑。
- 把每个数字都视为法律主张——YMYL 标准严苛。
- 先迭代提醒功能，再逐步加入仪表盘和分析。
TL;DR
- 电子表格可以存储数据，但 无法推送及时提醒。
- 具有时间依赖字段的 卡片对象模型 能实现自动化。
- 截止日期提醒（促销到期、年费、付款到期日）是核心价值。
- 实时 利用率 和 卡片选择器 有助于优化信用评分和奖励。
- 减少手动录入并遵守 YMYL 标准是金融科技成功的关键。
如果你正在构建信用卡管理工具，先解决提醒问题——其余功能自然会随之而来。
关键要点
- 先了解边缘情况 – 在写任何代码之前，确保已经识别出所有边缘情况。
- 管理工具被低估 – 每个人都在构建帮助人们寻找或购买金融产品的工具，但几乎没有人构建帮助人们管理已有资产的工具。
- 简洁胜过巧妙 – 一个准时触发的截止日期提醒比一个预测消费模式的机器学习模型更有价值。
- 信任是全部 – 人们正在输入他们的金融数据。通过透明度、安全性以及绝不对他们的信息耍花招来赢得信任。
如果你在同时使用多张信用卡且你的电子表格开始崩溃，去看看 StackEasy。我很乐意在评论中回答关于构建的任何问题。