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

2026-11-04技术老齐

结论

如果所有请求都使用同一个 App ID，而 HERE 的用量报表又没有客户维度，就无法仅凭汇总数据准确区分各客户的交易量。

App ID 用来标识应用或项目，无法标识最终客户。多个客户共用一套凭据时，HERE 会将这些请求归入同一个计费主体。按客户结算时，最好为每位客户分配独立凭据。合同或平台配置不允许这样做的，则要在自己的系统中记录客户身份和调用情况。

为客户分配独立凭据

先向 HERE 的商务或技术支持确认，当前合同是否允许在同一账户或合同下创建多个 App ID、API key 或项目。如果允许，建议为每位客户分配独立凭据：

customer-a -> credential-a
customer-b -> credential-b
customer-c -> credential-c

这样可以直接按凭据汇总用量。发生凭据泄露、客户停用或异常流量时，也可以单独处理对应的凭据。

能否创建多个凭据、每套凭据是否会单独出现在用量报表中，以及这是否会影响许可费用，都应以合同约定和 HERE 当前控制台提供的功能为准。

必须共用 App ID 时如何处理

如果所有客户必须共用一个 App ID，就要在自己的业务系统中记录客户级用量。

每次请求至少应记录：

内部 tenantId 或 customerId
HERE 服务类型
请求时间
请求结果
应用生成的唯一请求编号
是否发生重试
对账所需的计费分类

检索、路径规划等由后端发起的请求，可以统一通过自己的服务端调用 HERE。例如，可以使用下面这个简化的 Node.js 包装函数：

import { randomUUID } from 'node:crypto';

async function callHere({
  tenantId,
  service,
  url,
  init = {}
}) {
  const usageId = randomUUID();
  const startedAt = new Date();

  try {
    const response = await fetch(url, init);

    await usageLog.write({
      usageId,
      tenantId,
      service,
      startedAt,
      finishedAt: new Date(),
      httpStatus: response.status,
      outcome: 'response'
    });

    return response;
  } catch (error) {
    await usageLog.write({
      usageId,
      tenantId,
      service,
      startedAt,
      finishedAt: new Date(),
      outcome: 'network_error',
      errorName: error.name
    });

    throw error;
  }
}

调用时，应从经过认证的服务端会话中读取 tenantId，不要直接采用浏览器提交的客户编号：

const response = await callHere({
  tenantId: req.auth.tenantId,
  service: 'routing',
  url: hereRequestUrl,
  init: {
    method: 'GET'
  }
});

一条 HTTP 请求未必对应一个 HERE 计费 transaction。HERE 可能根据接口、资源类型、请求结果或合同约定采用不同的计算方式。因此，usageLog 的统计规则应按合同中的 transaction 定义配置，不能直接把请求总数作为账单数量。

JavaScript 地图请求的限制

HERE Maps API for JavaScript 通常由浏览器直接请求地图资源。如果请求没有经过业务后端，服务端包装函数就无法记录每次实际调用。

前端可以记录地图初始化、页面打开和客户会话等业务事件：

navigator.sendBeacon(
  '/telemetry/map-session',
  JSON.stringify({
    tenantId,
    event: 'map_initialized',
    occurredAt: new Date().toISOString()
  })
);

这些数据可以用来分析客户活跃度，但不能直接作为 HERE 的计费 transaction。浏览器缓存、地图平移和缩放、资源重试及 SDK 的内部加载策略，都可能导致业务事件数与计费数量不一致。前端上报也可能被拦截或篡改，因此不适合作为唯一的结算依据。

也不要自行给 HERE 请求添加 customerId 查询参数，并认定它会出现在 HERE 的计费报表中。除非 HERE 明确支持将该参数作为报表维度，否则它可能被忽略、被拒绝，或者只被当作普通请求参数处理。

对账方式

如果只能取得 App ID 级别的账单，可以按计费周期核对内部日志和 HERE 汇总数据：

内部记录总量 = customer-a + customer-b + customer-c
HERE 账单总量 = 该 App ID 的计费 transactions

如果两者不一致，应检查缓存、失败请求、自动重试、客户端直连流量和 transaction 的计算口径。

也可以按照内部计数的占比分摊总账单：

客户分摊量 = HERE 账单总量 × 客户内部计数 ÷ 所有客户内部计数

这只是一种成本分摊模型。内部计数与 HERE 的计费规则一致时，分摊结果才可能接近实际交易量，不能将其视为 HERE 提供的精确客户级统计。

注意事项

先确认合同中 transaction 的准确定义，以及失败请求、缓存命中、地图资源加载和重试是否计费。
客户身份应以服务端认证结果为准，不要使用客户端可随意修改的 customerId。
日志中不要保存非必要的坐标、搜索词或个人信息。
记录完整的重试链路，以免同一业务操作被重复计费。
除非 HERE 的许可条款和技术方案明确允许，否则不要为了统计用量而代理地图资源。
前端凭据无法像服务端密钥一样保密。应使用平台支持的来源限制、域名限制或其他凭据保护措施。这些措施只能降低滥用风险，无法实现客户级计量。
如果客户级数据会直接用于开票，独立凭据通常比共用 App ID 后自行估算更便于审计。