Amazon Ads 报表里最容易被低估的字段是 date。它看上去只是一个分区键，实际可能代表点击发生日、广告平台归因日、购物者下单日、接口生成日或数据进入数仓的处理日。转化会在点击之后发生，报告会继续回填，profile 又带有 marketplace、币种与时区。若系统把这些差异压成一个日期维度，ACOS、TACOS、placement 表现和预算判断都可能在 SQL 正确的情况下产生错误结论。
这篇文章的中心判断是：时间不是 Amazon Ads 模型中的一个普通维度，而是一组必须进入指标契约、数据版本和动作门禁的业务角色。 数据团队需要同时回答三件事：一条事实发生在什么时候；系统在什么时候观测到它；这条事实到什么时候才足以支持投放动作。只有把三者分开，报表重算才不会变成历史覆盖，小时级数据也不会被误当成即时利润。
先把五种时间拆开：广告事实为什么总在变化
Amazon Ads 的 campaign、ad group、target、search term、ASIN 与 placement 并不总由同一类报告提供。Amazon Ads Dimensions library列出了不同报告维度，官方报告指南也把 targeting、search term、advertised product 与 placement 报告分开。它们都可能有 date，但这不代表这些日期具有同一种业务含义，更不代表可以只按 campaign 和 date 连接。
五轨时钟校准台把本节的判断压缩成可检查的关系：区分点击、归因、业务日、处理与知识时间。人物动作对应执行责任。
至少要区分五种时间。第一是事件时间，例如点击或订单真实发生的时间；第二是归因时间，即平台把转化记到某次广告互动上的报告时间角色；第三是业务日，即 profile 所属时区下用于运营复盘的自然日；第四是处理时间，即接口结果进入数据平台的时间；第五是知识时间，即系统从哪个时点开始相信某一版事实。这五种时间有时相同，更多时候不同。
Profiles API提供 profile 级 currency、timeZone 与 marketplace 信息。这里的时区不是展示偏好，而是切分预算日、报告日和经营日的边界。美国西海岸 profile 在当地 23:30 发生的点击，若按中国标准时间直接截断，会进入第二天；同一个 seller 若同时管理美国、日本和德国站点，把所有 UTC 时间先转成统一自然日，会把各站点的预算节奏和转化曲线错位。
币种与时间也不能分开治理。某个 campaign 的 spend 以 profile 币种记录，财务利润可能按集团本位币观察。若汇率取点击日、订单日、结算日或月末日，结果会不同。语义层必须声明换算日期角色与汇率来源，而不是给所有金额增加一个 amount_cny 字段。否则，一个 ACOS 变化可能来自投放表现，也可能只来自汇率版本。
当下问题：同一个 date 正在制造三类错误决策
第一类错误是把尚未成熟的最近数据与已经稳定的历史数据并列比较。Sponsored ads reporting FAQ说明报告具有异步生成和历史更新特征。广告花费通常较快出现，归因销售需要等待购物者完成购买并被平台回填。若系统在上午看到 spend 上升、sales 尚未回填，就立即降低 bid，等于用不同成熟度的数据比较同一 search term。
错位日历断层剖面把本节的判断压缩成可检查的关系：展示同一个 date 如何制造三类错误决策。人物动作对应执行责任。
第二类错误是把报告重算当成源表更新。常见实现按 profile_id + campaign_id + date 做 upsert，新结果直接覆盖旧结果。最终看板数字可能正确，但团队无法回答昨天为何批准扩量、今天为何又发现当时的 ACOS 不成立。投放系统需要的不只是最新真相，还需要“决策发生时可见的真相”。覆盖历史会切断策略、证据和结果之间的审计链。
第三类错误是跨报告拼接虚构粒度。search term report 可以回答购物者查询与 target 的关系，placement report 可以回答 Top of Search、Rest of Search 与 Product Pages 的表现，但两张表未必共同提供 search_term × placement 的联合事实。只要用 campaign、ad group、date 连接，两边的多行就会形成乘法放大。ACOS 若分子分母被同倍复制，表面甚至可能保持不变，库存、利润或订单一接入便开始失真。
问题的本质不是缺少一张日期表，而是缺少“允许比较什么”的语义约束。RDF Data Cube Vocabulary将 observation、dimension、measure 与 slice 分开，提醒统计观察必须明确维度组合。Amazon Ads 数仓也需要把每个报告族看作具有独立 grain 的 observation set，先声明可比范围，再允许指标编译。
语义机制：用双时态事实和成熟度状态保存变化
单纯的事件时间不足以解释重算。更适合广告事实的是双时态模型：有效时间说明事实对应哪个业务区间，系统时间说明这一版事实在什么时候进入系统并被哪次抽取替代。每次 API 返回不直接覆盖，而是生成一个带 valid_from、valid_to、observed_at、superseded_at、extract_id 与 schema_version 的版本。
双时态抽屉账本把本节的判断压缩成可检查的关系：保存事件发生与系统知晓两条时间轴。人物动作对应执行责任。
例如，5 月 10 日某 search term 的 spend 为 100 美元，系统在 5 月 11 日首次看到 attributed sales 300 美元，5 月 15 日又回填为 420 美元。业务有效日始终是 5 月 10 日，但知识时间有两个版本。最新看板使用 420，5 月 12 日做出的竞价决策则应重放 300 那一版。这样才能判断决策逻辑当时是否合理，而不是用后来信息倒推执行者“本该知道”。
PROV-O提供 Entity、Activity、Agent 以及生成、派生和归属关系。工程上不必把所有数据都改造成 RDF，但可以借用这套语义：报告快照是 Entity，抽取和换算是 Activity，Amazon Ads API、转换任务与审批人是不同 Agent。每个指标结果至少能回到源报告版本、转换版本、汇率版本和指标定义版本。
成熟度不能只用“距离今天几天”推断。它应是显式状态，例如 provisional、maturing、stable、reopened。状态由广告产品、归因窗口、报告重算策略、退款观察期和业务风险共同决定。最近数据可以用于预算耗尽告警，却未必能用于暂停高价值 target；成熟数据可以进入周度调价，发生 schema 变更或大范围重算后又可能回到 reopened。
这种设计把“数据新鲜”和“证据成熟”分开。小时级数据很新，却可能不成熟；两周前的报告成熟，却可能因源接口修订而重新打开。语义层应同时暴露 freshness_age 与 maturity_state，不允许前端只用一个绿色圆点概括两种含义。
策略一：按报告族声明事件时间、观察时间与可比范围
每个 Amazon Ads 报告族都应有时间契约。契约至少包含：业务主时间、可选辅助时间、profile 时区、日期截断规则、允许的回溯区间、重拉频率、稳定判定、可连接键、禁止连接组合和可下钻维度。契约进入版本库，由数据、投放与财务共同审批，而不是散落在调度脚本注释里。
报告族时间护照墙把本节的判断压缩成可检查的关系：为不同 Amazon Ads 报告声明时间角色。人物动作对应执行责任。
search term 日报的主时间可以是 profile local report date，处理时间记录 API 响应落地时刻；placement 日报使用相同业务日却保持独立 grain；订单事实同时保留下单、付款、发货、退款时间；库存使用 snapshot time。需要计算 TACOS 时，系统选择经批准的运营日视图，不能把广告报告日与财务结算日临时拼在一起。
RDF 1.1 Concepts与 RDF Schema提供类型和关系的标准基础。落到关系模型，可以把时间角色设计成受控枚举和契约对象，而不是让每张表自行命名 created_at、updated_at、stat_date。同名字段不自动同义，异名字段也不自动不同义，是否可比较由契约决定。
可比范围需要进入查询规划。用户问“过去 7 天美国与日本站 Top of Search ACOS 谁更好”时，编译器先检查币种、profile 时区、归因成熟度和广告产品是否一致，再决定换算与窗口。若最近两天仍未成熟，系统可以返回成熟 5 天结果和 provisional 2 天结果，但不能合成一个没有说明的 7 天小数。
策略动作同样受范围约束。预算 pacing 可以读取快速到达的 spend 和预算利用率，竞价优化则等待更成熟的转化与利润信号。两类动作共享事实却使用不同证据门槛。产品经理定义业务容忍度，架构师把门槛映射到契约，工程师确保 SQL、任务与 API 执行都不能绕过它。
策略二：让 ACOS 与 TACOS 携带窗口、币种和版本
ACOS = spend / attributed_sales 只是数学表达，不是完整指标定义。合格的 ACOS 还要声明广告产品、归因窗口、销售范围、profile、币种、汇率策略、时间角色、零分母处理、成熟度和聚合方式。缺少任一关键项时，系统应返回“口径不完整”，而不是从上下文猜一个默认值。
行级 ACOS 与聚合 ACOS 也要分开。两条 search term 记录不能对百分比做简单平均，汇总必须计算 SUM(spend) / NULLIF(SUM(attributed_sales), 0)。MetricFlow将实体、时间维度和指标请求编译为查询计划，dbt model contracts则为模型字段与类型提供契约思路。Amazon Ads 场景需要在此基础上增加窗口、成熟度与报告族限制。
TACOS 的分母是总销售，不是“广告带来的全部销售”。广告 spend 与 total sales 在同 marketplace、同币种、同业务日下对齐，仍只能说明费用占总销售的比例，不能证明广告增量。若 total sales 来自订单系统，退款和取消的处理版本也必须固定。把广告归因销售之外的余额直接命名为 organic sales，会把计算残差伪装成已观察渠道。
指标命名不必无限增长，但机器标识必须稳定。界面可以继续显示“ACOS”，底层使用 acos.sp.v3.click_window_7d.profile_currency.local_report_date 之类的标识，或通过结构化字段表达同样信息。展示名服务于阅读，技术身份服务于兼容和审计。指标边界变化时创建新版本，旧版本保留到所有看板、Agent 与策略完成迁移。
Cube 的 Join 文档强调主键、方向与 fanout 风险。对于 Amazon Ads，比自动寻找 Join 路径更重要的是明确禁止的路径：search term 与 placement 若没有联合事实，不得通过 campaign/date 推导；ASIN 与 SKU 的关系若随 seller offer 变化，需要按有效期连接；跨 marketplace 不得在换算前聚合金额。
策略三：把重算变成可审计流程，而不是覆盖历史
重算流程应由“发现变化—评估影响—生成新版本—回归验证—发布—必要时重放动作评估”组成。API 抽取发现同一业务日数字变化时，先记录差异和来源，不立即覆盖所有下游物化表。系统计算受影响的指标、看板和策略，并判断差异是否跨过动作阈值。
ACOS 窗口望远镜把本节的判断压缩成可检查的关系：把归因窗口、币种和版本带入指标。人物动作对应执行责任。
如果 5 月 10 日的 attributed sales 从 300 回填到 420，历史 ACOS 会下降。系统不需要撤销当时已经发生的一切，但要回答三个问题：当时动作基于哪版证据；新事实是否表明规则阈值需要调整；同类 provisional 数据以后应等待多久。重放用于改进策略，不用于用后见之明追责。
发布新版本前至少做四类验证。结构验证检查 schema 与类型；语义验证检查窗口、币种和时间角色；数值验证比较新旧版本差异分布；业务验证抽样检查 campaign、target、ASIN 和 placement 是否符合投放人员理解。只有验证通过，新版本才成为 default，旧版本仍可按 as_known_at 查询。
社区对语义层的讨论常暴露“定义写了却没人真正使用”的问题。关于语义层含义的 Reddit 讨论和 dbt 实践讨论可以帮助发现旁路查询、性能和维护负担，但不能定义 Amazon Ads 事实。治理的硬边界必须来自官方报告语义、标准和组织审批。
动作审计应关联 decision_id、输入快照、指标版本、策略版本、审批、Amazon Ads API 请求、响应与执行后观察。若系统只存“把 bid 从 0.8 调到 0.9”，就无法判断这是哪一站点、哪一币种、基于哪个成熟窗口。可审计不是多写日志，而是把动作放回当时可见的语义环境。
组织落地：产品、架构与工程各自承担什么
产品负责人决定哪些业务问题值得自动化，以及错误动作的成本。例如预算耗尽告警可以接受 provisional 数据，暂停核心品牌词则需要更成熟证据。产品文档不应只写“实时优化”，而要写清实时的是花费、曝光还是完整利润，延迟到什么程度仍可接受。
跨站点时区转盘把本节的判断压缩成可检查的关系：解释 marketplace 经营日的边界错位。人物动作对应执行责任。
架构负责人维护时间角色、报告 grain、指标合同和版本依赖，确保 BI、Agent 与策略服务消费同一语义接口。架构评审重点不是表名是否优雅，而是新的报告能否与现有事实合法连接、时间边界是否一致、回填如何影响下游以及怎样回滚。
工程负责人把契约变成调度、存储、测试和查询门禁。增量任务按业务日回溯重拉，版本表保留系统时间；测试验证跨时区边界、夏令时、零销售、迟到转化、币种换算和重复抽取；查询编译器拒绝没有联合 grain 的维度组合；动作服务只接受带成熟状态和版本标识的决策包。
投放与财务不是需求提供者后退出，而是语义治理的共同 owner。投放人员确认 search term、target 与 placement 的实际解释，财务确认净销售、退款、COGS 与汇率日期角色。变更评审用具体 Amazon Ads 决策回归，而不是只检查 JSON Schema。
未来探索：从静态日期表走向时间知识图谱
下一步不是把所有数据迁入图数据库，而是让时间关系可查询。系统能够回答：某个 campaign 在动作发生时使用哪版目标 ACOS；这版指标依赖哪个报告 schema；某个 ASIN 的 COGS 和库存策略在何时生效；重算之后有哪些建议发生结论反转。这些问题天然跨越数据、规则和动作版本。
重算封存胶片把本节的判断压缩成可检查的关系：保留历史版本而不是覆盖旧事实。人物动作对应执行责任。
OWL 2 Overview提供类、属性与推理的表达能力，SPARQL 1.1支持属性路径和聚合。可以先用它们定义小范围时间与 provenance 模型，再将高频指标留在数仓执行。图负责身份、依赖和版本关系，数仓负责规模化扫描，策略服务负责确定性门禁，三者不必争夺唯一真相入口。
还需要建立“时间语义回归集”。每次 Amazon Ads API、报表 schema、时区库、汇率源或指标版本更新，都用固定 campaign、跨午夜点击、迟到转化、退款和多 marketplace 样本重跑。回归不仅比较数字，还比较拒绝理由、成熟状态和动作资格是否变化。
随着小时级甚至更快的投放信号增加，系统会更频繁地面对“快但不完整”的证据。未来能力的重点不是把每个信号立即转成动作，而是根据风险选择观察、告警、建议、限幅执行或等待成熟。速度是一种输入属性，不是决策质量的替代品。
一套可以直接进入评审的时间契约清单
时间治理如果只停留在概念图，工程团队仍会回到各写各的日期逻辑。更实际的交付物是一张逐报告评审表。每个报告列出业务主时间、原始时区、分区时间、首次可见延迟、建议回拉天数、预计稳定时间、最大重算范围、金额币种、可连接 grain 和禁止查询。投放负责人确认业务解释，数据工程确认抽取事实，财务确认金额与退款时间，三方对同一版本签字。
这张表需要用真实问题验证。对 search term 报告，抽取一个跨午夜点击和延迟订单样本，确认业务日不会因服务器时区变化；对 placement 报告，验证同一 campaign 日汇总与平台界面在允许误差内对齐；对订单与退款，验证运营日和结算日两种视图不会共享一个含糊的 sales_date。每个失败样本都转成回归用例，不靠下一位工程师记住事故。
指标服务还要返回“为什么现在不能算”。当用户选择尚未成熟的窗口，响应包含最早稳定日期、缺失报告、预计下一次回拉和可用替代窗口；当跨 marketplace 币种未配置，明确指出缺少汇率策略；当维度组合没有联合 grain，列出可用的两个分拆查询。拒绝信息必须面向投放决策，而不是只抛出 invalid semantic query。
发布节奏可以分三步。第一步只增加版本列、成熟状态和差异审计，不改变现有看板；第二步让新旧指标双跑，比较 campaign、ASIN、search term 与 placement 的差异来源；第三步才让预算和竞价 Agent 强制读取新契约。这样能把语义迁移从一次大切换改成可观察过程，也能找到仍在旁路读取旧宽表的消费者。
最终验收不看“日期维度是否建完”，而看四件事：历史决策能否按当时知识重放；跨站点报表能否在明确换算后比较；未成熟数据是否会被动作门禁拦住；报告重算后是否能定位受影响指标和策略。四件事都成立，时间才真正从字段升级为治理资产。
还要保留一条朴素原则：任何图表都同时展示数据截止时点和成熟截止时点。前者回答系统拉到了哪一天，后者回答哪一天以前的转化足以支持判断。两条日期相同是结果，不是默认。投放负责人看到这一差距，才能正确选择继续观察、调整预算或要求重算。
总结概要：时间语义决定指标能否进入动作
Amazon Ads 的 date 背后至少有事件时间、归因时间、业务日、处理时间和知识时间。时区决定自然日边界，币种决定金额可比性，归因窗口决定证据成熟度，报告重算决定历史版本。只保存最新结果，只能回答现在看见什么；保存双时态与 provenance，才能回答当时为何行动、后来发生了什么。
成熟度放行闸把本节的判断压缩成可检查的关系：只有证据成熟后才允许触发投放动作。人物动作对应执行责任。
可落地的顺序是：先为每个报告族声明 grain 与时间合同，再为 ACOS、TACOS 等指标绑定窗口、币种、聚合和成熟规则，最后把重算、发布与动作重放纳入版本流程。语义治理的目标不是让所有数据立刻可算，而是让系统明确知道哪些能比较、哪些仍需等待、哪些问题根本没有合法粒度。只有做到这一点，指标才有资格进入竞价、预算和搜索词治理。