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

1总览

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

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

账户花费结构。 08-13 是 B1 占 89%、共享账户占 11%，08-12 是 85% 与 15%；整体花费 $527.31 对 $624.98。

广告系列花费结构。 两日都是全球投放占 100%，第 3 至 5 节的任何数字都没有夹带广告系列之间的结构变化。

每一项投放价格都在降，每一美元的回报跟着一起降。 花更少的钱买到更多安装、又从这些安装上赚到更少，买到的 就是另一批人。

B1 把注意力买得更好，把注意力转化得更差。 点击率上升、点击→安装下降，两项在合并检验上都是 p = 0.000， 第 3 节的逐小时读数一致。

当日回收的降幅大约是花费的两倍，而付钱的人数没动，两日都在 16 付费用户门槛之上。 每个付费用户带来的 收入从 $12.14 走到 $9.13。

⚠ 口径校验在 B1 的账户日上读作 0.99，落在 0.91–1.06 区间之内。 看着像漂移的其实是付款记录的关联率； 测量过程见口径与边界。

2两个广告账户并列

两个账户都是我们自己的：B1（1738541847343652），广告系列以 bailingxia_ 命名；以及共享的两个 Nomad Node 账户（835434076171203 与 3267486106793669），它们投这个 App 的广告系列以 0811_ 与 0814_* 命名。那两个账户同时还在投 greenvid 与 pixvoo 两个别的产品，那部分投放一律不计入本节。每个账户的 一天都按它自己的账户时区切，而两个账户的时钟并不相同，偏移量以及它是怎么定下来的写在口径与边界。

这些列是什么。 新增注册 是我们自己的注册数，因此它旁边的成本不是下面各节的 Meta 口径 CPI；收入那几列 都建立在入账收入上。

共享账户占了 11% 的钱和三分之一的展示，所以整体 CPM $6.89 是按展示量加权出来的结果，会随两者的结构 一起动。

这两个账户只能按当日回收或同期群@24h 排次序，绝不能按入账排：入账数的是当天到账的所有钱，不论付款人哪天 安装，因此还带着两笔买量各自的年龄。

共享一侧只有 15 个付费用户，只能看方向，不能看幅度 —— 两个按安装日计的口径上，每一美元的回报都比 B1 高。

从第 3 节往下全都只有 B1：共享账户的导出里没有点击、没有 Leads 安装数、没有国家，也没有 Ad ID，那几 张切片因此算不出来。

3B1 分小时，2026-08-13

本节只有 B1，其下每一节也一样。投放列的分子分母都取自 Meta 的计量口径。付费率、ARPU 与 ARPPU 两侧都是自有口径。 两套安装数从不交叉相除。ours 是该小时我们自己的注册数，cov 是该小时同期群在 H=24 上的覆盖率。

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

同期群那一列在整个时钟上都是完整的。 对着 08-16 的付款数据截止时间，每个小时在 H=24 上的覆盖率都是 100%，这一 列不会再动。

花费在整个时钟上是平的，投放比率不是。 整天没有人碰过预算，CPI 在它下面仍从 $0.527 走到 $1.572。

4分国家，2026-08-13

5B1 汇总：两日对比

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

• 点击→安装 19.72% → 16.01%（−18.8%，p = 0.000），下降。
• CTR 5.55% → 6.55%（+18.1%，p = 0.000），上升。

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

三个收入口径并列

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

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

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

08-13 入账的钱里有四分之一来自当天到达的人，25.4% 对前一日的 30.1% 和再前一日的 49.0%。

6B1 各广告系列并列

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

有入账、无投放，且不计入上面任何比率： 德语区（DE/AT） 安装 0 次 (Meta)、注册 0 次 (自有)、 当日回收 $0.00；Earner（08-03 停投） 安装 0 次 (Meta)、注册 71 次 (自有)、当日回收 $0.00。 把它们算进来，它们的安装会进入 CPI 的分母，去除以从未发生的花费。

已停投十二天的 Earner 每天仍产生 71 次注册，且没有花费，前一日是 95 次，两日都没有当日回收。

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

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

仍然只有 B1，只是再低一个层级。下面每一张表、每一张图都是这一个广告系列。

当日结构

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

广告系列里还有六条广告，当日都没有投放。其中四条有注册和入账收入而没有花费，这与附录描述的转化小时效应是同一 件事，只是低一个层级。

A. 分素材 — 投放

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

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

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

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

pool5 这一行是本系列出现过的最不集中的收入行：最大的单个付费用户占 16.8%，08-12 是 82.6%，同一天的 bodysuit 是 10.9%。

C. 分素材 — 国家结构

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

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

pool5 在自己的完整日买到 26.1% 的印度，它的半日是 21.8%，bodysuit 是 36.2% —— 这个差距每一次读数 都在。

8口径与边界

⚠⚠ 计量口径丢掉了任何无法关联到人的付款，修好之后本页重新发布了一次。 measures.py 是拿每一笔付款的用户去 注册记录里查，查不到就跳过，因此一笔关联不上的付款会从三个口径里一起消失。本系列早前的报告写过这类付款仍然留在 入账口径里；它们没有留下。

付款接口在约四分之一的行上把付款人字段留空。它在每一行上都填好的是一个账户 UUID，而注册数据流自 2026-08-13 18:52 UTC 推送开始的那一刻起，就一直把同一个 UUID 跟数字用户 ID 一起送过来。我们这边没有把它保留 下来。把两边关联起来，能捡回来的是付款人在那一刻之后注册的付款，这也是本日只回来几个百分点、而后面几天回来得 多得多的原因：

口径校验读的是这个关联率。 本日最初发布时是 0.96，比 Meta 低四个百分点；在修好的记录上是 0.99，也就是那 四个百分点里有三个是计量口径当时在扔掉的付款。账户没有变，Meta 的数字也没有变。仍然找不回来的， 是那些在推送开始之前注册的人所付的钱，因为我们手上没有任何数据流带着他们的 UUID。这部分在全部历史上共 69 笔， 且几乎全部落在本日之前的日子里，这也是 08-13 之前那几次读数在这次修复下不动的原因。

在同一个付款数据截止时间上、用事后确认带满 24 个小时桶的导出重读，这个序列是：

六次里有四次落在 0.91–1.06 之内，两次刚好在外面、都是 1.07。一个恒定的系统性偏差不会这样进进出出。 08-12 曾发布的 1.09 算在一份账户时间 08-12 22:38 导出的分小时文件上，当时那个 Meta 日还在跑：文件里有 23 个 小时桶，第 23 小时完全缺失，第 22 小时只有最终 $18.42 里的 $9.09。UTC 日报表只需要自己那个 Meta 日的 00 到 16:59，从来没有碰过缺掉的尾巴，账户日上的口径校验会碰到，于是它用我们一整天的付款去除以 Meta 的 22 个小时。 ad_ops/meta_export.py 现在会拒绝任何没有带满 24 个小时桶的分小时导出。

本页动了哪些数字。 入账从 $1,279.80 到 $1,294.09，当日回收从 $314.52 到 $328.81、回报从 0.67 到 0.70， 同期群从 $361.67 到 $375.97 且覆盖率走满，当日付费用户数从 34 到 36，pool5 的付费率从 5.7% 到 6.1%。投放 那一半动了十五美分的花费、十一次展示和三次点击，那是一个已结算的 Meta 日的第二次导出，与这次修复无关。

同期群 24 小时现在承担得起跨日对比，因为两日都已完全覆盖。 对着 08-16 的 10:59 UTC 这个付款数据截止时间，08-12 与 08-13 在 H=24 上的覆盖率都是 100%，因此从 $619.65 到 $375.97 的下降是一个已冻结的同期群对另一个，不需要 加覆盖率的限定。本页最初发布时本日只有 72% 覆盖率，做不了这个对比，当时由午夜即已封存的当日回收口径承担，而两者 到今天仍然一致。

⚠ 本页的 08-12 数字与已发布的 08-12 报告不同，原因是同一份太短的导出。 那一页的花费是 $529.61、CPM $11.16、CPI $1.015，本页是 $532.72 与 $1.021。重新导出的文件在 24 个 UTC 小时上均匀补上了 $3.11 的花费和 259 次展示，没有集中在任何一处。当日回收完全没有动，两次切分都是 $424.78，它本来也不可能动。同期群数字精确 到分都一样，$619.65，覆盖率从 88% 升到 100%，这正是一个固定视野应有的行为。

本页的付款来自两个来源的合并。 付款接口是"付了什么"的更完整记录，在本日 18.2% 的行上丢掉付款人身份。 Telegram 导出几乎在每一行上都带着身份，但它停在 08-13 的 14:50 UTC；从那一小时起，接口就是全部记录，UUID 关联 是一笔付款能不能进入本页任何一个口径的唯一关口。本报告以导出为底，把接口里它没有的行叠上去，本日叠上 94 行。 这 94 行正是 UUID 关联起作用的地方，也是一行关联不上就会从三个口径里同时消失的地方。

整日对整日是这一天给得出、而前一天给不出的东西。 08-12 是 21.3 小时的 bodysuit 对 2.7 小时的 pool5，08-13 是一条素材的 24 小时。A、B、C 三张表是 08-11 以来第一次的整日数字，08-12 上让每一次分素材 对比都不可读的时钟混淆已经消失。

分国家一节与 C 表是账户自己的日，与其他所有表格相差七小时。它们只读结构，不读水平。

共享账户的导出跑在一套不属于我们的列预设上，因此没有点击、没有 Leads 安装数、没有国家，也没有 Ad ID；它 唯一能拿来关联的键是广告组名称，而按名称筛选正是 measures.py 拒绝做的事。

固定图表组没有分账户的切法，第 2 节因此只有两张表，没有图。

汇率表已经有十二天。 33 种货币的收入按 2026-08-02 拉取的汇率折算，而它要给到 08-13 的日子定价。关联率 这一项交代清楚之后，它是仍未了结的口径排查里剩下的唯一候选，而且从来没有被检验过。

⚠⚠ 两个账户跑在不同的时钟上，各自按自己的时钟拼接。 B1 固定在 UTC-7，它的 UTC 日由两个账户日拼出来。 Nomad Node 账户跑在 UTC+0，它们的报表日就是 UTC 日，不做任何拼接。两个偏移都不是假设出来的：把每个账户的分小时 展示次数与我们自己来自它那些广告系列的注册数做相关，注册时间是真正的 UTC，这个办法在 B1 上还原出已知的 k=7， r = 0.878，两侧分别是 0.703 与 0.698；在共享账户上给出 k=0，r = 0.744，两侧分别是 0.589 与 0.404。把共享 账户按 B1 的偏移去拼接，会让它们的花费整体挪动七个小时。

入账口径不能给两个账户排次序，而入账正是 Meta 会拿来跟你说的那一列。 它数的是当天到账的所有钱，不论付款人 哪天安装，因此一个身后压着三周老同期群的账户，和一笔只有三天的买量，量的根本不是同一件事。第 2 节按当日回收与 同期群@24h 排次序，这两个口径只数当天自己的安装；就这一天而言，共享一侧这些数字背后的付费用户数本来也在 16 付费用户门槛之下。

第 3 至 7 节按 Ad ID 对着运行配置里的映射表筛选，因此只有 B1。 共享账户的流量投放在以 334 结尾的 广告 ID 上，广告系列名为 0811_vl_bailingxia_srfhjyd-rain-chuva 与 -health，这些 ID 从来不在那张映射表里。 那几节的任何数字都不含它们的花费和收入，整体口径写在第 2 节。

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

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

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

在这个账户的量级上，pool5 与 bodysuit 的收入之争定不下来。 要求是每条实验臂约 16,692 次安装，较大的 一条只到 750 次。两条实验臂在成本上分得开，在 $450 上跑得更久也不会让回报分得开；而在修好的记录上，两者的回报 本来就是平的，这说的是样本，不是素材。要在收入上选出一条，要么买得大得多，要么换一个每次安装信号量更大的终点 指标，这正是 DECISION_LOG.md #57 提出用每次安装的付费用户数的地方。

剩下的缺口属于哪一个口径。 只剩一个候选，而且从来没有被检验过：汇率表相对它所定价日子的年龄。压在它上面的 另一个候选，也就是接口里关联不到用户的那些付款，正是本页据以重新发布的那个机制；它被移除之后，汇率这个问题上面不再 压着一个更大的效应。把一个已结算日按当前汇率重新定价，一个下午就能回答它。

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

本页在 2026-08-16 重新发布：付款计量口径的一处缺陷被找到并修好，页面上每一个收入数字都变了。 这个口径会 丢掉任何无法关联到人的付款，而本日有一部分付款到达时只带着一个账户 UUID，我们这边没有把它保留下来。注册数据流 一直在传同一个 UUID；把两边关联起来之后，本日付款中能关联到付款人的比例从 90.9% 升到 93.8%。本日的当日 回收从 $314.52 走到 $328.81，回报从 0.67 走到 0.70，付费用户数从 34 走到 36，口径校验从 0.96 走到 0.99。报告投放那一半的每个比率分子分母都取自 Meta 的计量口径，这次修复没有碰到它。 测量过程与仍然找不回来的部分，都在口径与边界一节。

这是 pool5 单独跑 $450 日预算的第一个完整日，也是 08-12 报告把收入读数推迟到的那一天。 当日从零点到 零点只有一条广告在一个广告组里投放，账户内没有任何预算或开关变动，已对照广告系列自己的活动历史确认。本页每一张 表都是整日对整日，这是 08-11 以来没有一份报告能说的话。

10交给下一次读数的东西

08-14 报告接手的是进入第二个完整日的 E2-R10，以及一项不再需要证明的成本优势。有用的问题不再是选哪条素材，而是 面对一批便宜 14.6%、每个又更不值钱的安装，账户该怎么买。$450 日预算上 0.70 的当日回收口径是要盯的那个数字， 而连续两个完整日的同一个预算区间，会是这个广告系列第一次给出的一对。

它接手的还有一份几乎每一行都能关联到付款人的付款记录，以及一道拦住半日导出进入报告的闸门。剩下的排查只有一个候选 那么宽。

11复现

报表时区为 UTC；B1 的导出盖的是它所在广告账户时区（UTC-7）的时间戳，因此它的每一行投放数据都由两个 Meta 日 重新拼接，而共享账户按 UTC 报数，原样取用。分国家的表与 C 表不做拼接，并在出现的地方标注。

python -m ad_ops.daily_pipeline --day 2026-08-13
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 \
    --lum _runs/2026-08-16_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
python _runs/2026-08-16_receipt_series/portfolio_split.py \
    --markdown _runs/2026-08-16_receipt_series/blocks

第 2 节的两张表就是最后那条命令在这一天的输出，原样粘贴。它没有做进 measures.py，因为共享账户的文件里没有 Ad ID 可供筛选；--calibrate 会从数据里重新推导每个账户的偏移，一旦存下来的偏移对不上就直接报错。

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

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 的入账去比我们的当日回收会把两把尺子混在 一起，报出来的差额里会有一部分是尺子的差别。

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

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

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