如何在单个 App ID 下追踪各客户的交易使用量？

2026-10-24支付老李

结论

仅靠一个共享的 HERE App ID，无法在 HERE 的交易统计或账单中可靠地按客户拆分 transactions/usage。App ID 用于识别应用和汇总用量，并不是面向最终客户的计量维度。使用同一 App ID 发出的请求，通常都会计入同一个应用账户。

要按客户计费，可以采用以下方式：

为每位客户分配独立的 HERE 凭据或 App ID，分别统计用量。
如果合同或账号体系不允许创建多个凭据，则在自己的服务端建立计量层，按客户记录可计费操作。
不要将浏览器访问日志、页面加载次数或 JavaScript API 方法调用次数直接视为 HERE transactions。计费口径应以许可协议和 HERE 提供的定义为准。

推荐方案：为客户分配独立凭据

为每位客户分配独立凭据，可以让 HERE 的统计维度直接对应实际计费对象：

Customer A -> App ID / API Key A -> HERE
Customer B -> App ID / API Key B -> HERE
Customer C -> App ID / API Key C -> HERE

应用可以在安装或部署时注入对应客户的配置：

const platform = new H.service.Platform({
  apikey: customerConfig.hereApiKey
});

如果使用的旧版 HERE 接口仍支持 app_id 和 app_code，配置形式可能如下：

const platform = new H.service.Platform({
  app_id: customerConfig.appId,
  app_code: customerConfig.appCode
});

具体采用哪种认证方式，取决于 HERE API 版本和合同配置。新项目不应默认旧式 app_id/app_code 认证仍然可用，应以当前 HERE 项目后台及对应 API 文档为准。

这种方式的统计边界比较清楚，也不需要自行推算 HERE 的交易数量。实施前应向 HERE 确认：

同一许可协议下能否为不同客户创建多个项目或凭据；
报表能否按项目、App ID 或 API Key 导出；
多个凭据能否归入同一商业合同；
凭据的数量或创建方式是否受到限制。

备选方案：建立自己的客户级计量层

如果必须共用一个 App ID，产品需要自行识别客户并记录使用行为。例如，可以让所有需要经过后端的地图服务请求都由服务端代理：

// 浏览器只把业务身份令牌发送给自己的服务
const response = await fetch(
  `/api/here/geocode?q=${encodeURIComponent(address)}`,
  {
    headers: {
      Authorization: `Bearer ${sessionToken}`
    }
  }
);

const result = await response.json();

服务端从登录会话中取得可信的客户标识，记录调用信息，再访问 HERE：

app.get('/api/here/geocode', authenticate, async (req, res) => {
  const customerId = req.user.customerId;

  const url = new URL('https://geocode.search.hereapi.com/v1/geocode');
  url.searchParams.set('q', req.query.q);
  url.searchParams.set('apiKey', process.env.HERE_API_KEY);

  const hereResponse = await fetch(url);
  const body = await hereResponse.json();

  await usageStore.record({
    customerId,
    service: 'HERE Geocoding',
    occurredAt: new Date().toISOString(),
    status: hereResponse.status
  });

  res.status(hereResponse.status).json(body);
});

计量记录至少应包括：

customer_id
service
operation
request_id
occurred_at
response_status
billing_period

customer_id 应由服务端根据经过认证的会话确定。不要接受客户端直接提交的客户编号，否则客户可能伪造请求归属。

JavaScript 地图需要特别处理

HERE Maps API for JavaScript 可能会由终端浏览器直接请求地图瓦片、矢量数据或其他资源。这些请求不一定经过自己的后端，因此服务端只能统计由自己代理的搜索、路线等调用，无法自然获得完整的地图交易明细。

在这种情况下，记录一次地图初始化或监听地图事件，只能得到产品使用指标。例如：

map.addEventListener('mapviewchangeend', () => {
  navigator.sendBeacon(
    '/usage/map-interaction',
    JSON.stringify({
      event: 'mapviewchangeend',
      occurredAt: new Date().toISOString()
    })
  );
});

这类事件有助于分析客户活跃度，但不能据此确定产生了多少个 HERE 可计费 transaction。一次拖动或缩放可能触发多个底层资源请求，缓存则可能减少请求量，因此两者通常不是一一对应的。

也不建议将所有地图资源简单地反向代理到自己的服务器。这样做除了会带来技术复杂度、缓存和性能问题，还可能受到 HERE 服务条款、内容分发规则及凭据使用规则的限制。实施前应取得 HERE 的明确许可。

对账与计费

采用自建计量时，可以按账期执行以下流程：

记录每位客户对各项 HERE 服务的使用事件。
按合同中的 transaction 定义，将这些事件换算为可计费用量。
汇总所有客户的内部用量。
将汇总结果与 HERE 提供的 App ID 总用量或账单核对。
分别处理缓存、重试、失败请求、预加载以及无法归属的差额。

只有在 HERE 明确说明某个请求或操作如何折算为 transaction 后，内部事件才能作为正式计费依据。否则，自建数据更适合用于分摊估算，不能视为与 HERE 账单完全一致的交易明细。

注意事项

不要尝试在 HERE 请求 URL 中添加任意 customerId 查询参数来拆分账单。除非相应 API 明确支持该字段，否则 HERE 不会将其作为计量维度，请求还可能被拒绝。
Referer、域名或 IP 地址通常不能作为可靠的客户标识，因为它们可能缺失、发生变化、由多个客户共享，或被代理隐藏。
在可安装的客户端产品中使用共享 API Key，存在凭据被提取和滥用的风险。应采用 HERE 支持的来源限制、域名限制或其他凭据保护机制，具体可用能力取决于凭据类型。
内部用量日志需要处理重复请求、客户端重试、失败状态、缓存命中和时区边界。
如果需要精确、可审计地向客户转售交易量，最稳妥的方式仍然是由 HERE 为每位客户提供独立且可报告的凭据或计费维度，并将这一安排写入合同。