HTML 本身不能做 ROI 计算或数据聚合，仅是静态展示层；必须依赖后端接口或前端 JS 动态获取真实数据并执行公式运算，纯 HTML+CSS 只能呈现硬编码的模板，无法响应业务变化。
直接说结论：HTML 本身不能做 ROI 计算或数据聚合，所谓“营销活动 ROI 分析页面”本质是「静态展示层」，必须配合后端接口或前端 JS 计算逻辑才能真正呈现效果。纯 HTML + CSS 做出来的只是报表模板，不是分析页面。
为什么 ROI 数值不能靠 HTML 标签直接生成
HTML 是标记语言，不执行运算。ROI = (收益 - 成本) / 成本 × 100% 这个公式里所有变量（如 revenue、ad_spend）都需要真实数据输入，而 HTML 无法读取数据库、API 或用户上传的 CSV。常见错误是把数字硬编码进 <td>23.6%</td>，结果活动一换，就得手动改 HTML 文件——这根本不是“分析”，是贴海报。
- 真实场景中，
cost可能来自广告平台 API（如 Facebook Graph API），revenue来自订单库或 GA4 事件，二者时间窗口还可能不一致 - 浏览器里用
fetch()调 API 是可行路径，但需处理跨域、认证、加载状态、错误 fallback - 如果强行用
<script>在 HTML 里写死计算逻辑，数据一变就要重发版本，运维成本远高于用现成 BI 工具嵌入 iframe
table 结构怎么组织才方便后续接 JS 或导出
别用合并单元格（rowspan/colspan）搞“美观表格”，那会让 JS 遍历、Excel 导出、屏幕阅读器解析全崩溃。ROI 分析页核心字段其实就几列：campaign_name、impressions、clicks、ad_spend、conversions、revenue、roi。按这个顺序写 <thead>，每行一个活动，保证每格只放一个原子值。
- 给关键列加
data-type属性，比如<td data-type="currency">¥4,280.50</td>，方便 JS 后续统一格式化或排序 - 避免在 HTML 里写百分比符号，
roi列存原始小数（如0.236），展示时再乘 100 加 %，否则排序和筛选会错乱 - 加
id="roi-table"而不是 class，方便document.getElementById('roi-table')快速定位，减少 DOM 查询开销
用 fetch 接真实数据时最容易漏的三件事
很多人写了 fetch('/api/roi?date_from=2024-01-01') 就以为完事，但实际跑起来常卡在第一步。
立即学习“前端免费学习笔记（深入）”；
- 没配
credentials: 'include'—— 如果后端用 session 登录鉴权，不带 cookie 请求直接 401 - 没处理
response.status !== 200的情况，比如 API 返回{ "error": "date range too large" }，但前端只渲染空表格，运营以为没数据 - 没对
ad_spend和revenue做空值保护，JSON 里字段缺失或为null，JS 计算(null - 1000) / 1000得到NaN，整个 ROI 列变空白
示例片段（仅示意逻辑）：
fetch('/api/roi?utm_campaign=blackfriday')
.then(r => r.json())
.then(data => {
const rows = data.map(item => {
const spend = item.ad_spend || 0;
const rev = item.revenue || 0;
const roi = spend ? ((rev - spend) / spend * 100).toFixed(1) : '-'; // 防除零
return <tr><td>${item.name}</td><td>${roi}%</td></tr>;
});
document.getElementById('roi-table').innerHTML = rows.join('');
});
复杂点在于 ROI 不是单点快照——它依赖归因模型（首次点击？末次点击？线性？）、退款剔除规则、跨设备匹配精度。这些逻辑放在前端既不安全也不可控。真要落地，优先考虑把计算逻辑收口到后端服务，HTML 页面只负责干净地请求和呈现。
