每日投放报告 — 2026-08-14，对比 2026-08-13

1总览

同期群价值 —— d0 / d3 / d7 的 ARPU 与 ARPPU

按安装日计算，从每个用户自己的安装时刻起算：dN 是他自己的前 (N+1) x 24 小时。ARPU 取自 Adjust，也就是合作方后台看到的那一套；ARPPU 取自我们自己的支付流水，因为 Adjust 没有累计去重付费人数这个字段。窗口还没走完的档位留空，不写 0。

账户花费结构。 08-14 是 B1 占 82%、共享账户占 18%，08-13 是 89% 与 11%；两账户合计花费 $506.46， 前一日 $527.31。

两日中 B1 的广告系列花费结构相同：全球投放各占 100%。 德语区投放与已停投的旧广告系列均无花费， 因此没有哪一节夹带结构变化。

展示便宜了 14.1%，而买来的点击里变成安装的更少了。 两者没有相互抵消：单次安装反而贵了 5.3%。

点击率没有动，6.55% 到 6.51%。变的东西在点击之下，第 3 节的逐小时读数也指向同一处。

当日回收下降 26.2%，大约是花费降幅的两倍，付费用户 28 对 37。 两日的同期群都已经完全成熟， 不需要加视野的限定。

B1 自己的账户日走的是另一个方向： 这个 UTC 日从账户日 08-13 接手了一个疲软的傍晚，又把一个强劲的 傍晚交给了 08-15。

2两个广告账户并列

B1 的广告系列以 bailingxia_ 命名；共享给我们的两个 Nomad Node 账户为这个 app 投的是 0811_ 与 0814_*，它们的 greenvid 与 pixvoo 属于别的产品，不计入这里。

花费与展示次数取自各账户自己的 Meta 导出。DNU 是自有口径下该账户的注册用户数，因此本表的 CPI 是花费 ÷ DNU， 两个账户都算在自有口径上，与第 3 节那个 $0.918 不是一回事：那一个的分子分母都在 Meta 的尺子上。两套安装数 从不交叉相除。

这里的付费用户是当日付了钱的所有人，不问他们哪天来的，也就是入账口径，因此与本页其他地方的当日回收付费用户不是 同一批。下表的 ARPU 与 ARPPU 同样落在这个口径上：入账 ÷ DNU 与入账 ÷ 付费用户。

共享账户的导出里没有这四列：点击、Meta 的安装数、国家、Ad ID。 第 2 节以下因此都只有 B1。

这两个账户只能按当日回收或同期群 24 小时排次序，绝不能按入账排。 按入账 B1 领先，2.87 对 2.06； 两个封存口径把次序翻了过来。

共享那一侧当日只有 12 个付费用户，未过 16 付费用户门槛，它的 1.08 与 1.63 只能看方向，不能看幅度。

共享那一笔买量胜在一个用户多少钱，输在一个用户值多少钱： 每个注册用户 $0.261 对 $0.659， ARPU $0.537 对 $1.892。

3分小时，2026-08-14 — 仅 B1

本节以及下面的每一节都只看 B1 这一笔买量。

投放列的分子分母都取自 Meta 的计量口径。付费率、ARPU 与 ARPPU 两侧都是自有口径。两套安装数从不交叉相除。 ours 是该小时的自有注册数，只数 run config 里映射过的广告，所以它合计 587，而第 2 节是 628；cov 是该 小时同期群在 H=24 上的覆盖率。

⚠ 每小时付费用户数在 0 到 9 之间。一个付费用户撑起来的小时 ARPPU 是那个人的购物篮，不是一个比率。合计行看水平， 分小时只看形状。

同期群那一列在整个时钟上都是完整的。 每个小时在 H=24 上的覆盖率都是 100%，这一列不会再动了。

当日头两个小时是这个账户记录过最差的： 第 0 与第 1 小时是账户日 08-13 的 17 时与 18 时， 正是上一个账户日的傍晚。

花费在后半天一路上行，安装成本没有跟着走。 第 19 小时是全天花费最高、CPM 也最贵的一小时。

4分国家，2026-08-14

5汇总：两日对比 — 仅 B1

两日都是 B1 这一笔买量。按 UTC 时钟，合并两日都有投放的 24 个小时。分子分母都取自 Meta 的计量口径。

• 点击→安装 16.01% → 13.15%（−17.9%，p = 0.001），下降。
• CTR 6.55% → 6.51%（−0.6%，p = 0.801），差异不显著。

跨小时合并是一次结构对比。 第 3 节的逐小时对照是不加权的读数；两者不一致的地方，就是结构动了。

三个收入口径并列

入账口径守住了它的回报，两个按安装日计的口径都在降： 买量收缩时继承下来的老同期群更大， 而入账把他们也数进去。

结构中性的账户行：CPM $9.14 → $7.86，按 08-13 的结构重算仍是 $7.86。 两日都只有一个广告系列投放， 没有结构需要中性化。

入账收入按付费用户的安装日拆分

这张表的第一行就是当日回收。它们是同一个数字的两次呈现，这也说明入账与当日回收之间的差额恰好等于继承下来的 老同期群，别无其他。

08-14 入账的钱里有五分之一来自当天到达的人，前一日是四分之一；这六行合计占 66.0%，前一日是 77.4%。

6各广告系列并列 — 仅 B1

本节的每一个广告系列都是 B1 的；共享账户的那两个广告系列在第 2 节，第 2 节以下都没有它们。投放列的分子分母都 取自 Meta 的计量口径，所有收入口径都是自有的。同期群视野 H=24h。报表时区为 UTC。 只按 CPM、单次点击成本与 CPI 排次序 — 这里地域是被有意选择的处理变量，而收入仍然需要 16 个付费用户 （DECISION_LOG.md #37、#48）。

有入账、无投放，且不计入上面任何比率： 德语区（DE/AT） 安装 0 次 (Meta)、注册 2 次 (自有)、 当日回收 $0.00；旧广告系列（08-03 停投） 安装 0 次 (Meta)、注册 64 次 (自有)、当日回收 $0.00。 把它们算进来，就是把安装放进 CPI 的分母，去对一笔从未发生的花费。

已停投十三天的旧广告系列每天仍产生 64 次注册、没有花费，前一日是 71 次，两日都没有产生收入。

本节的固定图表组画的是跨天的广告系列花费占比、CPM 与 CPI。窗口内每一天都只有一个广告系列投放，三张图都会是一条 平线，图表生成器因此不出图。

7全球投放广告系列内部 — 仅 B1

当日 B1 唯一有投放的广告系列，一路走到广告这一层。

当日结构

当日只有一条广告投放，独占一个广告组，跑满 24 小时。因此当日的广告组行就是广告行，下面的表格按素材标注。 这个等同关系只属于这一天的切法，任何有两条广告同时投放的日子都必须重新确认。

已映射的广告里还有十一条，当日都没有投放。其中三条有注册而没有花费，这与附录描述的转化小时效应是同一件事， 只是低一个层级。

A. 分素材 — 投放

分子分母都取自 Meta 的计量口径。自有注册数不进入这张表。

B. 分素材 — 三种收入口径

每一列都是自有口径。Meta 只能表达 入账，因此它跟在那一列旁边的括号里，永远不单独成行。付费用户是去重的人， 不是交易笔数。同期群视野 H=24h，本日覆盖率 100%。报表时区为 UTC。

16 付费用户门槛（#37）：上表中付费用户数不足 16 的行只能看方向，不能看幅度。 pool5 以 25 个通过，前一日 是 37 个。本页再无第二行通过。

每个付费用户花的钱少了，人数几乎没动。 ARPPU 是 9.35，前一日 12.60；付费率从 6.6% 走到 6.0%。

C. 分素材 — 国家结构

⚠ 本表按账户日切，与 A、B 两表相差七小时。本表只读结构，不与它们比水平。

最后一列是该素材自身当日回收中来自美国的占比：当它远高于该素材的美国花费占比时，这条素材的回报是它买到的那块地域的属性。

pool5 这一天买到的印度比任何一个完整日都少（21.7% 对 26.0%），美国比任何一个完整日都多，赚得却更少。

美国在它自身收入里占 25.2%，前一日是 28.2%： 变动发生在各国之内，印度和美国都把前一日的回报交回去了 大约一半。

8口径与边界

⚠⚠ 计量口径丢掉了本日五分之一的付款，修好之后本页重新发布了一次。 measures.py 是拿每一笔付款的用户去注册 记录里查，查不到就跳过，因此一笔关联不上的付款会从三个口径里一起消失。本系列 早前的报告写过这类付款仍然留在入账口径里；它们没有留下。在那些日子里这没有造成差别，因为占比只有百分之二三。

本日不是百分之二三。Telegram 导出几乎在每一行上都带着付款人，但它停在 08-13 的 14:50 UTC；此后付款 接口就是全部记录，而它在约四分之一的行上把付款人字段留空。它在每一行上都填好的是一个账户 UUID，而注册数据流从 推送开始的那天起，就一直把同一个 UUID 跟数字用户 ID 一起送过来。我们这边没有把它保留下来。把两边关联起来， 这些付款就回来了。

各账户日的付款中能关联到付款人的占比，修复之前与修复之后：

口径校验读的是这个关联率。 这一天发布时是 0.86，落在 0.91–1.06 区间之外，也是本系列 记录过的最大一次越界；在修好的记录上它是 1.05，落在区间之内。账户没有变，Meta 的数字也没有变。仍然找不回来的， 是那些在推送于 2026-08-13 18:52 UTC 开始之前注册的人所付的钱，因为我们手上没有任何数据流带着他们的 UUID。 这部分残留在全部历史上是 69 笔，而且随着推送不断累积，它会越来越无关紧要。

本页动了哪些数字。 入账从 $1,069.12 到 $1,147.14，当日回收从 $164.79 到 $242.81、回报从 0.40 到 0.59，同期群从 $227.60 到 $311.66，当日付费用户数从 16 到 28，pool5 的付费率从 4.0% 到 6.0%。对比日也动了， 动得少一些：08-13 的当日回收是 $328.81，对比它自己那一页写的 $314.52。每一个投放数字都没有变，因为投放的每个 比率分子分母都取自 Meta 的计量口径，与这件事无关。

在修好的记录上，pool5 的付费率在 08-13、08-14 与 08-15 上是 6.6%、6.0% 与 6.0%。 本页第一版把 08-14 写成 4.0%，据此把这一天读成"根本没人再付钱"；那个数字是计量口径本身。

⚠ 本页的 08-13 数字与已发布的 08-13 报告不同，有两个原因。 投放上的差别来自对一个已结算日的一次重新导出： 那一页是 $468.95、51,292 次展示、3,357 次点击、点击→安装 16.03%，本页是 $469.10、51,303、3,360 与 16.01%，这就是一个已结算的 Meta 日在第二次导出时会动的量。收入上的差别来自上面那次修复，而且更大：当日回收是 $328.81，那一页发布的是 $314.52。一个被描述为已封存的口径动了，它之所以动，是因为计量口径忽然看得见它此前一直 在扔掉的付款。

分国家一节与 C 表是账户自己的日，与其他所有表格相差七小时。它们只读结构，不读水平。这一点在本日格外要紧， 因为账户日与 UTC 日走的方向相反：账户日 08-13 是 $431.33 与 471 次安装，账户日 08-14 是 $468.59 与 531 次。

汇率表已经有十三天。 33 种货币的收入按 2026-08-02 拉取的汇率折算，而它要给到 08-14 的日子定价。它是尚未 了结的口径排查里的另一个候选，现在也是唯一一个还没有被指出机制的。

共享账户的导出跑在另一套列预设上，我们也管不了它。 它的文件唯一能用来关联的键是广告组名称，而本报告 不按名称选行，因此共享那一侧在本页任何地方都没有 CTR 与点击→安装行。

两个账户跑在不同的时钟上，第 2 节之所以成立，是因为各自按各自的时钟拼。 B1 固定在 UTC-7，它的 UTC 日由两个 Meta 日拼出来。共享的两个账户跑在 UTC+0 上，它们的报表日本来就是 UTC 日，不需要拼接；给它们套上 B1 的偏移， 会把它们的花费挪走七个小时。两边的偏移都是从数据里定出来的：拿每个账户分小时的展示次数，去跟它的 广告系列带来的、时间戳为真 UTC 的自有注册做相关，这个办法在 B1 上还原出已知的七小时偏移（r = 0.878）， 在共享账户上得到零偏移（r = 0.744）。

这两个账户只能按当日回收或同期群 24 小时排次序，绝不能按入账排。 入账数的是当日付了钱的所有人，不问他们哪天 安装，于是 B1 三周积累下来的老同期群全记在它头上，而 08-11 才开的共享买量几乎没有。第 2 节写出入账那一列，是为 了解释这道差额，不是为了排次序。共享那一侧本日只有 12 个付费用户，未过 16 付费用户门槛，它的回报只能看方向， 不能看幅度。

共享账户在 B1 走弱的这一天变大了，还新开了两个广告系列。 广告 ID 以 334 结尾的流量在 08-14 产生 354 次注册，08-13 是 278 次；0811_vl_bailingxia_srfhjyd-rain-chuva 旁边出现了两个新广告系列：它的 0814_vl_ 版本，以及 0814_vl_bailingxia_srfhjyd_maimai。第 3 节起的数字都不受影响，因为那里的每一张表 都限定在 run config 里的广告 ID 上。两个买量是否在争同一批竞价、代价是多少，见 2026-08-14 的独立报告；本日 与那份读数一致，但没有对它构成检验。

我们还有一个广告账户在本窗口内没有投放。 08-15 发布的 KBM1 广告系列在 08-14 没有产生注册，而且它在 另一个广告账户里，因此完全不进入本页的任何 Meta 导出。等它开始花钱，它会以未映射流量的形式出现在注册记录里。

有 37% 的注册永远不会进入任何收入口径，本系列的每一天都是如此。 第 3 节起的"自有"数字，指的都是能归因到 已映射 Meta 广告的注册。这在内部是自洽的，因为付费率的分母用的正是同一批人。

账户上有一份未发布的草稿。 管理界面显示 Review and publish (1)。本页没有任何数字依赖它，本次也没有动它。

本报告写在预定的自动化取数窗口之前约四小时。 在账户时间 18:10 跑，本日同期群的覆盖率会是 100% 而不是 86%。 页面上其他数字都不会动，因为当日回收口径已封存，而每一个投放数字都来自一个已经结束的 Meta 日。

9要把这些问题定下来，需要什么

还有 69 笔付款仍然关联不到任何人。 它们属于在推送开始之前注册的人，我们手上没有任何数据流带着他们的 UUID， 任何查询都找不回来。这是一份固定的历史残留，而且几乎全部落在 08-13 之前的日子里。还没有答案的 问题是：付款接口能不能直接把用户字段填上，那样这条路径上就不再需要关联这一步。

口径校验里还剩下什么。 在修好的记录上，四个账户日读出 0.99、1.05 与 1.01，对着 0.91–1.06 的区间，所以 此前四份报告描述的那条漂移，自始至终都是关联率。汇率表的年龄仍是一个已具名的候选，而它从来没有被检验过；把一个 已结算日按当前汇率重新定价，一个下午就能把它定下来，而且现在它上面不再压着一个更大的效应。

在这个账户的量级上，pool5 与 bodysuit 的收入之争定不下来。 要求是每条实验臂 17,775 次安装，较大的 一条只到 1,349 次。在 $450 上跑得更久也补不上这个差，而且在修好的记录上，两条实验臂的回报本来就是平的。

本页在 2026-08-16 重新发布：付款计量口径的一处缺陷被找到并修好，页面上每一个收入数字都变了。 这个口径会 丢掉任何无法关联到人的付款，而本日有五分之一的付款到达时只带着一个账户 UUID，我们这边没有把它保留下来。注册数据 流一直在传同一个 UUID。把两边关联起来之后，本日的当日回收从 $164.79 到 $242.81，回报从 0.40 到 0.59，付费用户数从 16 到 28，口径校验从 0.86 到 1.05。报告的投放那一半始终没有动， 因为它的每个比率分子分母都取自 Meta 的计量口径。测量过程与仍然找不回来的部分，都在口径与边界一节。

10交给下一次读数的东西

08-15 报告接手的是本日交出去的那个强劲账户傍晚：账户日 08-14 花费 $468.59、Meta 记录 531 次安装，它最后七个 小时落在 UTC 08-15 里。它接手的还有一套修好的付款计量口径，而它是第一个从头到尾都用这套口径测量的日子。

E2-R10 进入第三个完整日，带着一项连续七次读数都在扩大的成本优势，以及一个现在与被它换下的那条实验臂持平的回报。 真正值得盯的是点击→安装：它在本日下降 17.9%、p = 0.001，是唯一一项同时经受住合并读数与不加权读数的变动。

11复现

报表时区为 UTC；B1 的 Meta 导出盖的是该账户所在时区（UTC-7）的时间戳，因此第 3 节起每一行投放数据都由 两个 Meta 日重新拼接。分国家的表与 C 表不做拼接，并在出现的地方标注。

python -m ad_ops.daily_pipeline --day 2026-08-14
python -m ad_ops.asset_estimator hourly \
    --meta _runs/2026-08-12_0811_daily/exports/ads_hourly_aug11_settled.csv \
           _runs/2026-08-14_2026-08-13_daily_auto/exports/ads_hourly_2026-08-12.csv \
           _runs/2026-08-14_2026-08-13_daily_auto/exports/ads_hourly_2026-08-13.csv \
           _runs/2026-08-15_2026-08-14_daily_auto/exports/ads_hourly_2026-08-14.csv \
    --lum _runs/2026-08-15_2026-08-14_daily_auto/lum --fx _runs/2026-08-02_today_read/fx_rates.json \
    --ads "ww_bikini_10s,ww_bodysuit_10s,ww_pool5,ww_mugshot,ww_spill,ww_lounge" \
    --campaign bailingxia_meituan_ww_cvr_260802 --horizon 6

流水线按固定顺序运行 measures、day_compare、cohort_arpu、asset_estimator、report_tables 与 report_charts，并在它写出的 UTC 与 META 两份配置上各跑一遍；它现在会把付款与注册两份记录从上一次运行接续 下来。它自己用的是两份分小时导出；上面把估计器按四份重跑了一次，为的是让 E2-R9 与 E2-R10 各自按完整跨度被测量。

本页没有引用 day_compare 自己的输出。它的安装数读自内部的注册记录，而且它的窗口比报表日多出七个小时， 因此它在另一个时钟上回答的是另一个问题，与第 5 节的合并漏斗不是一回事。

12附录 — 定义

报表日是一个 UTC 日。 Adjust 按 UTC 报数，按 UTC 分桶的报告与归因面板天然吻合，不需要任何人在脑子里换算。 B1 的广告账户固定在 UTC-7，因此一个 UTC 日等于账户日 D−1 的 17:00 到 23:59 加上账户日 D 的 00:00 到 16:59。 两个时钟差得不小：在实测过的一天里，同样的口径在花费上差 14.6%，在当日回收上差 40.7%；而在本日，它们连方向 都不一样。

有三样东西这个时钟够不到，各自都在出现的地方标注。C 表的分素材国家结构跟不上它：折算是按账户做的，折算的是该账户自己的分小时边际，而单个素材没有自己的分小时边际。口径校验在账户时区之外无效，因为 Meta 的转化金额盖在转化发生的小时上，无法诚实地重新拼接。估计器刻意 跑在 Meta 的时钟上，因为它的对象是投放窗口，而一次预算变动是账户自己时钟上的一个瞬间。

三种收入口径，从不只用一种，从不混用，永远标注：

花费下行的日子在入账口径上读得高、在另外两个口径上读得低，纯粹是因为昨天的买家还在付费。跨日对比用当日回收口径， 因为它不可变且不需要视野。要把不同小时互相比较，用固定视野的同期群口径，因为当日回收口径会按一天中的时点做截尾。 入账是 Meta 会拿来跟你说的数字，写出来是为了解释差额，不是为了排次序。

三种口径都读在内部的付款记录上，而且都只计入能关联到"通过我们已映射广告安装的某个人"的付款。Meta 只能表达 入账，因此它跟在那一列旁边的括号里，永远不单独成行。

存在两套安装数，它们从不交叉相除。 Meta 的 Leads 与自有注册数相差 5% 到 10%。投放漏斗用 Meta 的， 因此 CPI 与点击→安装的分子分母都在同一把尺子上。付费率与所有收入口径用自有的，因此付费用户与他们来自的安装是 同一批人。

预算区间是广告组日预算没有变动的一段时间。预算在这个账户上是一个地域旋钮，跨过一次预算变动去比较两条素材， 比的是两批不同的人。这一天自始至终只有一个：E2-R10，pool5 单独跑 $450，自账户时间 2026-08-12 14:18 开启。

16 付费用户门槛（DECISION_LOG.md #37）：付费用户数低于约 16 时，一个收入数字只能看方向，不能看幅度。 这个账户上每次安装的收入是一个几乎处处为零、偶有大额的向量，变异系数接近 6.7，要把两条素材分出 20% 的差距， 每条实验臂需要大约 17,775 次安装。这个账户产出过的最大的预算区间匹配实验臂是 1,349 次。