国际地图统一钱包计费需求文档 v1.0
版本:v1.0 | 创建日期:2026-08-10
最近修订:2026-08-16
需求来源:混合来源(用户沟通、研发确认、历史 Wiki、GCP 账单、本地代码、Google 官方文档)
优先级:待确认
文档状态:待确认
需求变更记录
| 变更日期 | 变更人 | 变更内容 |
|---|
依赖需求 Story 列表
当前无已确认的依赖 Story,评审拆分后补充。
| ID | 需求描述 | 涉及端与开发人员 | 是否有依赖项 | 备注 |
|---|
一、需求概述
1.1 客户反馈
客户反馈结论: 无关联客户反馈。本需求来源于国际地图产品整合、供应商成本治理及产品与研发内部对齐,不虚构客户反馈。
| 需求编号 | 反馈客户 | 客户级别 | 反馈人 | 业务场景 | 示意图 |
|---|---|---|---|---|---|
| 无 | 无 | 无 | 无 | 内部产品治理 | 无 |
1.2 系统现状
当前 Google 国际地图能力被拆分为一个开通产品及 PaaS 对象、外勤、服务通三个场景资源包。各场景分别维护余额和扣减规则,客户购买次数与 Google 实际计费 SKU 之间不是一一对应关系,无法直接比较销售收入、租户消费和供应商成本。

用户提供的线上产品截图显示,当前产品列表至少包含国际地图-服务通(1,200 元/财务成本 1,000 元)、国际地图应用(1,200 元/财务成本 1,000 元)、国际地图-外勤(1,800 元/财务成本 1,500 元)和国际地图-PaaS 对象(1,000 元/财务成本 550 元)。这里的“财务成本”是产品列表中的内部成本字段,不等同于本需求测算的 Google GCP 供应商成本,不能单独用来判断地图接口是否盈利。
| 场景 | 当前 License 产品编码 | 当前代码表现 | 现状问题 |
|---|---|---|---|
| PaaS 对象列表地图 | google_map_call_limit | 每次业务操作按consumeCount: 1 扣减,代码已标识 bizSource=udobj、bizKey=list_map(依据:[list.js](/Users/soren/Desktop/work/object_list/object_list/package/base/list/list.js:15)) | 一次内部扣点会产生多项 Google SKU,旧次数不能代表供应商接口调用次数 |
| PaaS 对象地址搜索 | google_map_call_limit | 地址搜索同样固定扣 1 次,业务操作标识为form_loc_search(依据:[location_b.js](/Users/soren/Desktop/work/object_form_pass/objformpkgbase/base/fields/location/location_b.js:38)) | 与实际 Nearby、Text、Data SKU、地图加载之间缺少可审计映射 |
| 外勤 | global_map_outwork_limit | 选址页单独传入外勤资源参数(依据:[OutdoorLocationManager.java](/Users/soren/Desktop/work/fs-android/fxiaoke/src/com/facishare/fs/biz_function/subbiz_outdoorsignin/utils/OutdoorLocationManager.java:259)) | 与 PaaS 使用相同搜索能力但单独售卖、单独计次 |
| 服务通 | service_connect_google_map_limit | Google 定位成功后调用统一配额扣减接口(依据:[utils.js](/Users/soren/Desktop/work/object_form_pass/objformpkgbiz/eservice/standard-operation/utils/utils.js:220)) | 代码扣费时点与历史 Wiki 描述仍需在统一改造前校准 |
研发已确认典型业务动作与 Google 接口的关系如下。Atmosphere Data、Contact Data 会随每次 Nearby Search、Text Search 固定产生,当前链路无法去除,必须计入 Places 综合成本。

| 业务场景 | 已确认的典型调用构成 | 尚未完成的校准 |
|---|---|---|
| PaaS 对象 | Nearby Search 1 次 + Text Search 1 次;两次搜索分别产生 Atmosphere、Contact;使用 Dynamic Maps | Dynamic Maps 每次典型动作实际产生的计费事件数 |
| 外勤(快消) | PaaS 调用构成 + Places Details 1 次;使用 Dynamic Maps | Dynamic Maps 每次典型动作实际产生的计费事件数 |
| 服务通 | Geocoding 1 次,用于逆地址解析 | 统一前校准真实扣费时点 |
Google 接口与业务操作场景对照
以下是按当前产品链路对 Google SKU 的业务化解释,用于帮助产品、研发和财务理解“一个接口调用大概对应什么操作”。它是场景映射,不等同于 Google 账单中的一次业务动作;正式扣费仍以实际成功计费事件和费率版本为准。
| Google 接口/SKU | 大致对应的用户操作 | 纷享典型场景 | 计费理解 |
|---|---|---|---|
| Nearby Search / Nearby Places | 以当前位置、地图中心点或经纬度为中心,搜索附近的门店、客户、餐厅、仓库等地点 | PaaS 对象地图找附近对象;外勤选址或查找附近客户 | 一次成功的周边搜索;当前链路固定带出 Atmosphere、Contact |
| Text Search / Text Places | 用户输入关键词、地点名称或地址文本,搜索匹配地点,例如“Singapore Starbucks”或“客户公司名” | PaaS 对象按名称/地址搜索;外勤按关键词找拜访地点 | 一次成功的文本搜索;当前链路固定带出 Atmosphere、Contact |
| Atmosphere Data | 返回地点的评分、价格等级、营业/就餐/配送等经营属性 | 作为 Nearby/Text 搜索结果的附加地点信息 | 不是独立业务动作;按研发确认随搜索产生,合并进 Places 综合成本 |
| Contact Data | 返回地点的电话、营业时间、网站等联系信息 | 作为 Nearby/Text 搜索结果的附加联系信息 | 不是独立业务动作;按研发确认随搜索产生,合并进 Places 综合成本 |
| Places Details | 用户选中某个地点后,按place_id 查询更完整的地点详情 | 快消外勤选中拜访门店后查看/确认详细信息 | 独立成功详情查询;当前快消比 PaaS 多出这一类调用 |
| Dynamic Maps | 打开或刷新交互地图,加载地图底图并展示标记、中心点和缩放后的地图 | PaaS/外勤搜索结果页展示地图、定位或重新加载地图 | 独立的成功地图加载事件;不等同于搜索,也不保证每次搜索一比一产生 |
| Geocoding | 地址转经纬度,或经纬度反向解析为可读地址 | 服务通打卡/定位后把坐标解析成地址 | 独立成功地址解析;当前服务通主要使用逆地址解析 |
2026 年 1—7 月 fxiaoke-i18n 项目核心地图账单共 9,294.20 美元,月均 1,327.74 美元;按固定汇率 6.7936、税率 6% 折算含税人民币成本 66,929.54 元。其中 Atmosphere、Contact 成本合计约 1,706.09 美元,占核心地图成本约 18.4%。原始账单可以证明供应商 SKU 的调用量和金额,但不包含租户、License、业务对象和业务动作,因此只能用于成本与总量对账,不能直接作为租户实时扣费流水。
Data SKU 的口径: Atmosphere Data、Contact Data 已计入本方案的 Nearby Places、Text Places 综合成本,但此前只在组合字段中表达,未在成本结构表中单独展开。本版补充底层 SKU 明细,避免把它们误读为“未计入”。它们不是额外业务动作,却是每次 Nearby/Text 搜索必须承担的供应商成本。
1.3 竞品现状
本需求不涉及 CRM 竞品能力比较。外部规则仅用于确认供应商计费事件及账单结构:Google 官方说明,一个服务请求可能触发一个或多个 SKU,并作为独立账单行出现;Dynamic Maps 的计费事件为成功地图加载。由此可知,纷享内部的“一次业务动作”不能直接等同于 Google 的“一次调用”或“一条账单”。
| 竞品 | 竞品分类 | 竞品现状 | 来源 |
|---|---|---|---|
| Google Maps Platform | 地图供应商 | 按成功计费事件和 SKU 计费;一次请求可能产生多个 SKU | [Google Maps Platform API usage details](https://developers.google.com/maps/billing-and-pricing/sku-details) |
| Google Maps Platform | 地图供应商 | 官方按 SKU 和使用量档位公布价格,实际账单还受账期、税费及供应商政策影响 | [Google Maps Platform pricing](https://developers.google.com/maps/billing-and-pricing/pricing) |
1.4 产品价值
采用统一钱包不是单纯为了合并产品名称,而是由当前计费结构的四个问题共同决定:
- 资源权益与供应商成本不一致。 一个 PaaS 计次会触发 Nearby、Text 以及两类 Data SKU,外勤还增加 Details;原来的“1 次”不是统一成本单位,按场景固定次数售卖容易出现高成本场景被低价覆盖。
- 客户使用场景会交叉。 同一企业可能同时在 PaaS、外勤和服务通使用国际地图,分开购买会造成一边余额不足、另一边余额闲置,客户无法按真实使用情况调配已购买资源。
- 供应商价格和接口组合会变化。 Google 账单按 SKU 和成功计费事件变化,统一钱包可以只调整版本化费率,不必频繁重做三套资源包和 License 参数。
- 财务和客户都需要可对账。 一个钱包把业务动作、底层 SKU、客户扣减和 GCP 月账单串成一条流水,既能实时展示消费,也能在月底做差异对账。
上述统一方向是用户在多轮沟通中已确认的产品目标:首次开通产品后,后续购买统一资源包,钱包不区分业务场景,按实际 Google 接口费用扣减。对客户,统一钱包提供跨 PaaS、外勤、服务通使用的余额和消费明细;对公司,建立“业务动作—Google 计费事件—钱包扣减—GCP 月账单”的可追溯链路,使产品售价能够覆盖真实供应商成本并保留明确毛利,同时降低多套 License 的销售和维护成本。
三赢的局面:
对产品:产品线更清晰,盈利模式更清晰,同时减少国际地图产品的咨询
对实施/客成:减少咨询和沟通成本
对客户:不需要区分产品购买,避免部分场景冗余+部分场景闲置的问题
1.5 需求目标
- 新购企业通过一次国际地图开通产品启用能力并获得初始额度,后续只购买统一额度包,不再区分 PaaS、外勤、服务通资源包。
- PaaS、外勤、服务通发生 Google 可计费事件时,系统按当时生效的人民币费率实时扣减同一钱包,并生成可追溯消费流水。
- 存量企业的旧场景剩余次数按原权益对应的接口组合换算为钱包额度,保证迁移前已购买权益的可用能力不因计费模型切换而被压缩。
二、产品方案
2.1 整体产品方案
| 方案项 | 统一规则 | 关键边界 |
|---|---|---|
| 产品结构 | 一个首次开通产品 + 一个统一国际地图额度包(新产品) | 首次开通赠送额度,金额待确认 |
| 资产结构 | 每个企业只有一个国际地图钱包 | 额度不可提现、转账或兑换现金 |
| 消费方式 | 按实际成功产生的 Google 计费事件和已发布费率扣减 | 失败调用和平台异常重试不得重复向客户扣费 |
| 费率方式 | 发布带版本的人民币客户费率,实时确定消费金额 | GCP 月账单只做内部影子对账,不追溯修改历史客户消费 |
| 历史迁移 | 按旧次数实际代表的接口权益折算钱包额度 | 不把过去未包含在旧次数中的 Dynamic Maps 强行加入迁移公式 |
2.2 具体方案说明
2.2.1 产品与钱包结构
| 产品 | 购买规则 | 到账/生效规则 | 待确认项 |
|---|---|---|---|
| 国际地图开通产品 | 企业首次启用时购买一次 | 开通 Google 国际地图能力、创建钱包、赠送初始额度 | 是否沿用当前 1,200 元价格;赠送额度金额 |
| 国际地图额度包 | 开通后可重复购买 | 订单完成后额度进入同一钱包 | 固定档位或报价单自定义金额;有效期 |
钱包额度是国际地图资源权益。建议资源包订单金额与到账额度按 1:1 记账,例如购买 1,000 元额度包到账 1,000.000 地图额度;计费精度和取整规则见 2.2.3。
方案 2: 只保留一个产品,这个产品即是首次开通产品,也是后续的额度包,相当于开通产品不收费,按额度用量收费。
2.2.2 业务动作与计费项映射
客户不再购买“PaaS 次数”“外勤次数”或“服务通次数”。系统应在业务动作发生时识别实际产生的计费项并累加扣减:
| 客户计费项 | 内部 Google SKU 构成 | 适用场景 | 客户侧展示规则 |
|---|---|---|---|
| Nearby Places | Nearby Search + Atmosphere + Contact | PaaS、外勤 | 作为一个综合计费项展示,不拆出两个 Data SKU |
| Text Places | Text Search + Atmosphere + Contact | PaaS、外勤 | 作为一个综合计费项展示,不拆出两个 Data SKU |
| Places Details | Places Details | 外勤 | 独立计费项 |
| Dynamic Maps | Dynamic Maps | PaaS、外勤 | 按实际成功地图加载计费事件扣减 |
| Geocoding | Geocoding | 服务通 | 独立计费项 |
典型 PaaS 动作可理解为 Nearby Places + Text Places + Dynamic Maps,典型外勤动作在此基础上增加 Places Details,服务通为 Geocoding。该组合只用于成本解释和测试用例,正式扣费不得直接写死为一个场景固定金额,而应按该次业务动作实际触发的计费项累加。
Dynamic Maps 与 Atmosphere、Contact 的定位不同。Atmosphere、Contact 是 Places 搜索请求固定带出的 Data SKU,已经合并在 Nearby Places、Text Places 的综合计费项中;Dynamic Maps 属于独立的 Maps API SKU,计费事件是一次成功的地图加载。它只有在业务动作实际渲染地图时才产生,不是每次 Nearby/Text 搜索必然一比一产生的附加项。
从 2026 年 1—7 月账单看,Nearby + Text 共 220,252 次,而 Dynamic Maps 为 171,945 次,约为搜索次数的 78.1%,也不等于 PaaS 或外勤动作数。因此底层计量和对账必须保留 Dynamic Maps 独立 SKU;客户侧可以在确认真实日志中的典型动作组合后,将它作为 PaaS/外勤综合动作的一部分展示或定价,但不得直接并入 Nearby Places、Text Places 的基础单项费率。这样既能表达业务动作的完整成本,也不会掩盖独立地图加载或平台重试带来的成本差异。
2.2.3 费率发布与实时扣减
客户 SKU 费率的首版测算公式为:
客户 SKU 费率 = 供应商有效单位成本 ÷(1 - 目标供应商成本毛利率)
- 供应商有效单位成本:按最近 3—7 个完整自然月 GCP 实际账单计算,并纳入汇率和税费。
- 首版目标供应商成本毛利率:暂按 35%,待财务确认。
- 费率版本:每个计费项保存版本号、生效时间、失效时间、客户费率、成本观察口径和发布人。
- 扣减精度:钱包保留 3 位小数,单次业务动作汇总金额按 0.001 额度向上取整。
- 生效规则:新费率只用于生效时间之后产生的计费事件,历史消费不追溯重算。
- 调价触发:建议按季度评估;连续两个月实际成本偏差超过 15% 时可提前发起调价评审。
- 月末对账:GCP 账单仅用于核对总调用量、总成本和各 SKU 偏差,不更改已经向客户展示的历史消费金额。
2.2.4 首版成本与费率草案
以下草案基于 2026 年 1—7 月 fxiaoke-i18n 实际账单、汇率 6.7936、税率 6% 和 35% 目标毛利。该表是评审输入,不是已发布价格。
底层 Google SKU 的 1—7 月供应商含税单位成本如下。Atmosphere、Contact 两行必须参与 Places 综合费率,不能从成本模型中删除:
| 底层 Google SKU | 1—7 月调用量 | 1—7 月成本(美元) | 含税成本/次(元) | 进入客户计费项 |
|---|---|---|---|---|
| Nearby Search | 157,122 | 3,910.784 | 0.1792 | Nearby Places |
| Atmosphere Data | 220,252 | 1,066.305 | 0.0349 | Nearby Places、Text Places |
| Contact Data | 220,252 | 639.783 | 0.0209 | Nearby Places、Text Places |
| Text Search | 63,130 | 900.160 | 0.1027 | Text Places |
| Places Details | 86,265 | 871.505 | 0.0728 | Places Details |
| Dynamic Maps | 171,945 | 713.797 | 0.0299 | Dynamic Maps |
| Geocoding | 284,568 | 1,191.866 | 0.0302 | Geocoding |
由底层 SKU 加总得到客户计费项:
| 客户计费项 | 供应商含税成本/次 | 建议客户费率/次 |
|---|---|---|
| Nearby Places(Nearby + Atmosphere + Contact) | 0.2350 元 | 0.362 额度 |
| Text Places(Text + Atmosphere + Contact) | 0.1585 元 | 0.244 额度 |
| Places Details | 0.0728 元 | 0.112 额度 |
| Dynamic Maps | 0.0299 元 | 0.046 额度 |
| Geocoding | 0.0302 元 | 0.047 额度 |
| 场景示例 | 典型构成 | 供应商成本 | 客户扣减 | 供应商成本毛利率 |
|---|---|---|---|---|
| PaaS | Nearby Places + Text Places + Dynamic Maps | 约 0.423 元 | 0.652 额度 | 约 35.1% |
| 外勤 | PaaS 构成 + Places Details | 约 0.496 元 | 0.764 额度 | 约 35.1% |
| 服务通 | Geocoding | 约 0.030 元 | 0.047 额度 | 约 36.0% |
加入 7 月账单后,各核心 SKU 的加权单位成本相对上半年仅变化约 +0.1%—+1.5%,未出现改变钱包计费方向的结构性偏差。
2.2.5 现行资源包的盈亏分析
本项用于回答“现行按几个资源包分别计价,结合当前 Google 成本是否亏损”。由于 Google 账单没有租户和 License 流水,以下分两层看:
第一层:产品列表价格与内部财务成本。 线上截图显示的单品价格减财务成本均为正:服务通、国际地图应用各约 16.7% 的列表毛利,外勤约 16.7%,PaaS 对象约 45.0%。但这只能说明产品列表的内部成本字段没有倒挂,不能证明 Google 接口成本已经被覆盖。
第二层:按 Google 实际成本和旧资源包权益估算。 以历史测算采用的 10,000 次资源包为口径,按当前确认的接口组合计算如下。这里不把“理论消费值”当作实际销售收入;它是用账单代理事件量乘旧单次售价得到的可比指标。
| 旧资源包/场景 | 旧单价 | 每次旧权益对应的最低接口成本 | 若典型动作含 Dynamic Maps | 10,000 次成本(含 Dynamic) | 10,000 次售价 | 结论 |
|---|---|---|---|---|---|---|
| PaaS 对象 | 0.10 元 | Nearby + Text = 0.3935 元 | 0.4234 元 | 约 4,234 元 | 1,000 元 | 明显亏损 |
| 外勤 | 0.18 元 | PaaS + Details = 0.4663 元 | 0.4962 元 | 约 4,962 元 | 1,800 元 | 明显亏损 |
| 服务通 | 0.12 元 | Geocoding = 0.0302 元 | 不适用 | 约 302 元 | 1,200 元 | 有较高毛利 |
上表是“单个旧资源包完全消费”的权益压力测试;为了把账单代理量、成本和差额直接对上,再按历史测算沿用的分摊规则复算 2026 年 1—7 月。PaaS 代理量为 Nearby + Text - Details,外勤代理量为 Details,服务通代理量为 Geocoding;Nearby、Text、Atmosphere、Contact、Dynamic Maps 的共享成本按 PaaS/外勤代理量比例分摊,Details 全部归入外勤,Geocoding 全部归入服务通。
| 场景 | 账单代理调用次数 | 旧单价/次 | 分摊成本/次(含税) | 调用次数 × 成本/次 = 分摊总成本 | 调用次数 × 旧单价 = 理论消费 | 理论差额 | 理论毛利率 |
|---|---|---|---|---|---|---|---|
| PaaS | 133,987 | 0.10 元 | 0.2364 元 | 31,676.47 元 | 13,398.70 元 | -18,277.77 元 | -136.4% |
| 外勤 | 86,265 | 0.18 元 | 0.3092 元 | 26,670.19 元 | 15,527.70 元 | -11,142.49 元 | -71.8% |
| 服务通 | 284,568 | 0.12 元 | 0.0302 元 | 8,582.88 元 | 34,148.16 元 | +25,565.28 元 | +74.9% |
| 合计 | 504,820 | — | — | 66,929.54 元 | 63,074.56 元 | -3,854.98 元 | -6.1% |
该表的“分摊成本/次”是为复核账单总额而采用的历史代理分摊口径,不代表 Google 已经按租户或 License 直接归因;三类分摊总成本之和与 1—7 月国际地图核心 GCP 含税成本 66,929.54 元一致。正式财务损益仍需补齐同月订单收入、赠送额度、未消费余额、折扣和 License 消费流水。
理论毛利率的口径是“理论消费值”作为分母,而不是供应商成本作为分母:
理论消费值 = 账单代理调用次数 × 旧单价/次
分摊总成本 = 账单代理调用次数 × 分摊成本/次(含税)
理论差额 = 理论消费值 - 分摊总成本
理论毛利率 = 理论差额 ÷ 理论消费值
以 PaaS 为例:理论消费值为 133,987 × 0.10 = 13,398.70 元,分摊总成本为 133,987 × 0.2364 ≈ 31,676.47 元,理论差额为 13,398.70 - 31,676.47 = -18,277.77 元,所以理论毛利率为 -18,277.77 ÷ 13,398.70 ≈ -136.4%。它表示成本约为理论消费值的 2.36 倍;这里的“理论”是因为账单代理量尚未和实际 License 订单收入、赠送额度、折扣及租户流水逐笔关联。
按账单代理事件量对 2026 年 1—7 月做总体复算:PaaS 代理量为 Nearby + Text - Details = 133,987,外勤代理量为 Details = 86,265,服务通代理量为 Geocoding = 284,568。按旧单价得到理论消费值 63,074.56 元,同期国际地图核心成本 66,929.54 元,差额约 -3,854.98 元,理论毛利率约 -6.1%。上半年单独测算为理论消费 52,370.10 元、含税成本 55,294.27 元、理论毛利率 -5.6%。测算依据为[历史成本与定价模型](/Users/soren/Desktop/work/00-Output/国际地图统一License计费方案/国际地图统一License成本与定价模型_v0.1_20260803.xlsx)及 2026 年 1—7 月 GCP 账单。
因此,当前证据支持的结论是:现行模式整体存在成本倒挂风险,主要由 PaaS 和外勤资源包造成;服务通可以覆盖 Google 成本,但无法抵消前两类高成本场景的亏损。 这不是实际财务收入损益表,因为缺少企业实际购买金额、赠送额度、未消费余额、折扣、续购和 License 消费流水;正式结论必须在同月 License 流水补齐后复核。
统一钱包的直接价值之一,就是将这些场景的真实接口成本统一计入钱包费率,不再用一个低价场景的次数余额隐性补贴另一个高成本场景。
2.2.6 扣费责任与幂等规则
| 事件 | 是否扣客户钱包 | 处理规则 |
|---|---|---|
| Google 成功产生可计费事件 | 是 | 按事件发生时生效费率扣减 |
| Google 返回失败且供应商不收费 | 否 | 记录失败原因,不生成消费金额 |
| 用户主动重复搜索、修改关键词或重新加载地图 | 是 | 每个实际成功计费事件正常扣减 |
| 平台超时重试、程序缺陷造成重复调用 | 否,不重复扣 | 平台承担重复成本并生成异常日志 |
| Nearby/Text 成功且固定产生 Atmosphere、Contact | 是 | 按对应 Places 综合费率扣减,内部保留三个底层 SKU 便于对账 |
每次地图业务动作必须生成唯一 bizActionId,每次供应商请求必须生成唯一 requestId,并记录租户、业务场景、业务记录、计费项、调用结果、费率版本、扣减金额和扣后余额。同一 requestId 只能入账一次;无法完成租户和业务动作归因的调用不得直接进入正式客户扣费,应进入异常池人工核对。
2.2.7 余额与消费管理
企业管理后台新增“国际地图额度”入口:
| 页面 | 展示内容 | 权限 |
|---|---|---|
| 余额总览 | 当前余额、累计充值、累计消费、预计可用天数、当前费率版本 | 企业管理员及被授权角色 |
| 消费趋势 | 按日/月汇总,支持按 PaaS、外勤、服务通筛选 | 企业管理员及被授权角色 |
| 消费明细 | 时间、业务场景、业务动作、记录名称、计费项、调用次数、费率版本、本次扣减、扣后余额 | 企业管理员及被授权角色 |
| 充值记录 | 订单号、资源包金额、到账额度、购买时间、有效期 | 企业管理员及订单权限角色 |
| 余额提醒 | 余额低于阈值及耗尽提醒 | 提醒接收人和渠道待确认 |
首版页面位置建议:将“国际地图额度”先放入企业管理后台的“许可信息”页面,在现有“资源池”区域占位,后续再补充余额、累计消费、费率版本和消费明细等字段。以下截图仅作为位置示意,不代表最终交互和字段定稿。

消费明细默认按业务动作汇总为一条,展开后查看 Nearby Places、Text Places、Details、Dynamic Maps、Geocoding 等计费项。客户侧不展示 Google 采购成本、汇率、内部毛利,也不把 Atmosphere、Contact 解释为额外业务动作。
余额不足时,首版建议禁止发起新的 Google 可计费调用,并提示企业管理员购买额度。是否允许签约客户透支属于商务政策,未确认前不提供默认透支。
2.2.8 历史资源包迁移
历史余额按旧次数实际代表的接口权益迁移:
迁移钱包额度 = 旧场景剩余次数 × 切换日冻结的该旧场景接口组合客户费率
| 旧资源包 | 旧 1 次代表的接口权益 | 当前草案迁入额度/次 |
|---|---|---|
| PaaS 对象 | Nearby Places 1 次 + Text Places 1 次 | 0.606 |
| 外勤 | Nearby Places 1 次 + Text Places 1 次 + Places Details 1 次 | 0.718 |
| 服务通 | Geocoding 1 次 | 0.047 |
例如某企业剩余 5,000 次 PaaS,按当前草案迁入 5,000 × 0.606 = 3,030 额度。0.606 已包含两类搜索固定产生的 Atmosphere、Contact,不包含过去未纳入 PaaS 次数权益的 Dynamic Maps。
需要特别区分“旧单价”和“迁入额度/次”:旧 PaaS 单价 0.10 元/次 是历史资源包的销售计量;迁移值 0.606 是把旧 1 次所代表的两类接口权益,按切换日客户费率换算成新钱包额度,计算为 Nearby Places 0.362 + Text Places 0.244 = 0.606。同理,外勤为 0.606 + Places Details 0.112 = 0.718,服务通为 Geocoding 0.047。因此 0.606 不是新的 PaaS 售价,也不是供应商成本;它是旧权益向统一钱包的价值换算系数。Dynamic Maps 当前不计入迁移系数,是因为历史 PaaS 次数权益被确认只代表 Nearby + Text;若研发日志或历史规则证明旧权益实际还承诺了地图加载,则必须在切换日前重新评估迁移系数。
Dynamic Maps 暂不纳入迁移的原因不是它没有成本,而是迁移首先要还原“历史已购买的客户权益”,不能把历史未单独售卖、未在旧次数定义中明确承诺的技术调用,直接追溯为存量客户权益。当前已确认的历史口径是:PaaS 1 次代表 Nearby Search 1 次 + Text Search 1 次,外勤在此基础上增加 Places Details 1 次;Dynamic Maps 是这些业务页面可能同时产生的独立加载事件,不能仅凭账单中存在调用就证明它属于旧资源包的 1 次权益。Atmosphere、Contact 则不同,它们已确认是每次 Nearby/Text 固定产生,因此必须随搜索权益一起迁移。
因此迁移有两个口径,需在切换前根据历史商品说明和调用日志定案:
| 迁移口径 | PaaS 每旧 1 次迁入 | 外勤每旧 1 次迁入 | 适用条件 |
|---|---|---|---|
| 历史权益保全(当前草案) | 0.606 | 0.718 | 旧产品只承诺搜索/Details;Dynamic Maps 只作为平台成本按新钱包实际事件扣减 |
| 功能完整等价 | 0.652(0.606 + Dynamic Maps 0.046) | 0.764(0.652 + Places Details 0.112) | 历史销售口径明确“1 次业务动作包含地图展示”,且日志证明通常每次对应 1 次成功地图加载 |
当前推荐先采用“历史权益保全”,原因是证据链更完整、不会无依据扩大存量赠予;若产品、销售和研发确认旧客户购买的是完整地图动作而不是搜索接口权益,则应切换为“功能完整等价”,并重新生成企业级迁移清单。无论采用哪一种,Dynamic Maps 上线后的新调用都必须继续按独立 SKU 计量,不能因为迁移时是否赠送而改变后续实际扣费规则。
迁移必须使用“客户费率”而不是供应商成本。这里“保证迁移前已购买权益的可用能力不减少”是指:按冻结费率测算,迁入余额至少能继续完成与旧剩余次数等量的旧接口组合;并不保证未来调价后永久拥有相同业务次数。
迁移上线前应输出企业级清单,包含旧产品、原购买次数、剩余次数、冻结费率、迁入额度、有效期和处理状态,由销售与客户成功复核。迁移额度独立标记,不可退款、提现或转让;有效期、扣减顺序和企业汇总取整方式待评审确认。
2.2.9 异常与影响范围
- 计费服务不可用:地图业务是否降级放行待技术方案确认;放行产生的供应商成本不得在恢复后无依据补扣客户。
- 余额并发:钱包扣减必须保证原子性,避免并发请求造成负余额或重复入账。
- 费率版本缺失:停止正式扣费并报警,不得使用未发布的临时价格。
- 人工调账:仅限授权运营人员,必须填写原因并生成前后值审计日志。
- 影响端:PaaS Web/移动端、外勤移动端、服务通、License/订单、计量与钱包服务、客户管理后台、运营后台、财务对账。
- 开放能力:首版不向客户开放钱包扣减接口;是否提供余额和明细查询 OpenAPI 后续评估。
2.3 待确认事项
| ID | 待确认事项 | 影响范围 | 负责人 | 结论 |
|---|---|---|---|---|
| 1 | 首次开通产品是否沿用 1,200 元及赠送多少初始额度 | 首单售价、初始可用量、销售口径 | 产品、财务 | 已确认需要赠送,金额待确认 |
| 2 | Dynamic Maps 在一次 PaaS/外勤典型动作中产生几次计费事件 | 典型成本解释、测试用例 | 研发 | 抽取至少一周真实调用日志确认;正式钱包仍按实际事件扣费 |
| 3 | 历史迁移冻结日期、企业汇总取整方式及有效期继承规则 | 存量客户权益和迁移清单 | 产品、财务、销售 | 待确认 |
| 4 | 额度包固定档位、自定义金额及是否允许透支 | 商品配置、订单和余额不足策略 | 产品、商务、财务 | 可后置确认 |
| 5 | 低余额提醒的阈值、渠道和接收人 | 管理后台、CRM 提醒、企信消息 | 产品、研发 | 待确认 |
| 6 | 计费服务异常时地图能力是阻断还是临时放行 | 可用性、平台成本和补扣争议 | 产品、研发 | 待技术方案评审 |
| 7 | 实际订单收入、赠送额度、未消费余额和同月 License 流水是否可取得 | 将代理口径升级为真实收入损益结论 | 财务、License、数据 | 待补齐;未补齐前不得把 -6.1% 表述为正式财务亏损 |
三、规范检查项
3.1 业务文案多语言 Key
以下为首版页面核心词条,正式 Key 由研发按现有命名规范确认。
| 模块 | 功能点 | 示意图 | 中文 | 英文 | 多语言 Key |
|---|---|---|---|---|---|
| 国际地图额度 | 页面名称 | 无 | 国际地图额度 | International Map Credits | 待确认 |
| 国际地图额度 | 余额 | 无 | 可用额度 | Available Credits | 待确认 |
| 国际地图额度 | 消费明细 | 无 | 消费明细 | Usage Details | 待确认 |
| 国际地图额度 | 充值记录 | 无 | 充值记录 | Top-up History | 待确认 |
| 国际地图额度 | 余额不足 | 无 | 国际地图额度不足 | Insufficient International Map Credits | 待确认 |
3.2 需求埋点
本需求的计费事件、钱包流水和对账记录属于核心业务账务数据,不使用普通前端埋点代替。页面使用分析是否另加产品埋点待交互方案确定后补充。
| 埋点模块 | 埋点描述 | 示意图 | Key | 研发负责人 | 备注 |
|---|---|---|---|---|---|
| 无 | 首版无普通产品埋点 | 无 | 无 | 待确认 | 计费日志见 3.6 |
3.3 沙盒/更改集能力
| 模块 | 功能点 | 是否支持沙盒 | 是否支持更改集 | 说明 |
|---|---|---|---|---|
| 国际地图钱包 | 余额、费率与消费流水 | 否 | 否 | 企业级商业资源与账务数据,不随配置迁移 |
3.4 PaaS 国际化兼容检查
| ID | 多语接入事项 | 是否需要 | 注意事项 |
|---|---|---|---|
| 1 | 接入翻译工作台 | 否 | 页面系统文案使用研发多语言 Key,不属于客户自定义翻译词条 |
| 2 | CRM提醒 | 待确认 | 若低余额通过 CRM 提醒发送,需单独定义模板、接收人和跳转入口 |
| 3 | 企信消息提醒 | 待确认 | 若低余额通过企信发送,需单独定义模板、接收人和频控 |
| 4 | 修改记录 | 否 | 客户不可直接编辑余额和费率;后台变更进入操作日志 |
| 5 | 审计日志 | 是 | 费率发布、人工调账、迁移、充值、作废必须可追溯 |
| 6 | 支持快捷翻译能力 | 否 | 无客户自由输入的跨语言内容 |
| 7 | 支持数据多语能力 | 否 | 钱包金额、SKU 和流水不属于多语业务数据 |
| 8 | 预置配置多语 | 否 | 无需模板企业预置客户可编辑配置 |
| 9 | 预置示例数据多语 | 否 | 不预置示例账务数据 |
3.5 新对象/新字段 BI 分析申请
| 对象/字段 | 是否已做流程支持申请 | 是否已做 BI 分析申请 | 内容 |
|---|---|---|---|
| 国际地图钱包 | 待申请 | 待申请 | 企业钱包、可用额度、累计充值、累计消费、状态 |
| 国际地图钱包流水 | 待申请 | 待申请 | 充值、赠送、迁移、消费、调账、作废流水及前后余额 |
| 国际地图费率版本 | 待申请 | 待申请 | 计费项、客户费率、生效/失效时间、成本口径和发布信息 |
| Google 计费事件明细 | 待申请 | 待申请 | 租户、业务动作、请求、内部 SKU、结果、归因状态和对账状态 |
3.6 操作日志说明
以下操作必须记录操作人/系统、操作时间、租户、业务单据、原因、变更前值、变更后值和关联流水号:费率创建与发布、人工调账、历史迁移入账、订单充值入账、赠送额度、额度作废、异常冲正。客户业务消费还必须记录 bizActionId、requestId、业务场景、计费项、费率版本、调用结果、扣减金额和扣后余额。日志保存期限及脱敏规则由技术与合规评审确定。
3.7 需求风险点检测
| ID | 风险分组 | 风险类型 | 有无该风险 | 涉及风险的功能点 | 影响的企业数 | 是否报备 | 响应策略 |
|---|---|---|---|---|---|---|---|
| 1 | 对现逻辑有影响的风险点 | 交互体验有变化 | 有 | 余额不足后地图能力受限、后台新增额度入口 | 使用国际地图的全部企业,数量待统计 | 是 | 灰度、提前通知、提供余额提醒和充值入口 |
| 2 | 对现逻辑有影响的风险点 | 功能有减少 | 无 | 三个业务场景能力不减少,仅资源售卖与扣减方式合并 | 不涉及 | 否 | 验收时回归原地图能力 |
| 3 | 对现逻辑有影响的风险点 | 功能逻辑的调整 | 有 | 从场景固定次数切换为实际计费事件扣钱包 | 使用国际地图的全部企业,数量待统计 | 是 | 一个月影子计费、企业级迁移清单、灰度核对 |
| 4 | 新能力风险点 | 逻辑不完善 | 有 | 调用归因、异常重试、人工调账、费率版本 | 使用国际地图的全部企业,数量待统计 | 是 | 唯一 ID 幂等、异常池、审计日志、禁止无依据补扣 |
| 5 | 新能力风险点 | 有性能压力 | 有 | 每次地图调用实时计量、扣减和写流水 | 峰值调用量待研发统计 | 是 | 原子扣减、异步明细、容量评估、降级与告警方案 |
3.8 上线策略
3.8.1 收费标准
- [ ] 不收费
- [X] 收费
收费方式:购买首次开通产品和统一国际地图额度包;使用时按生效人民币费率实时扣减钱包额度。正式价格和赠送额度须在上线前完成财务审批。
3.8.2 上线节奏
- [ ] 全网
- [X] 灰度
| 灰度发布的原因 | 新计费模型涉及客户权益、实时扣费、历史迁移和供应商账单归因,必须先验证准确性与稳定性 |
|---|---|
| 预计全网时机 | 完成一个完整自然月影子对账且灰度企业无重大扣费争议后,具体日期待排期 |
| 期间分几次灰度 | 建议 3 次:内部影子计费、少量新购企业、存量企业分批迁移 |
| 各灰度批次的时间节点及灰度的客户范围 | 时间待排期;首批不真实扣款,仅内部对账;第二批选择新购企业;第三批按客户成功可覆盖范围迁移存量企业 |
3.8.3 适用版本
| 资源名称 | 标准版 | 专业版 | 旗舰版 | 无限版 | 扩展资源包 |
|---|---|---|---|---|---|
| 国际地图开通产品 | 待确认 | 待确认 | 待确认 | 待确认 | 否 |
| 国际地图额度包 | 待确认 | 待确认 | 待确认 | 待确认 | 是 |