Daily campaign report — 2026-08-13, against 2026-08-12

1Overview

Cohort value — ARPU and ARPPU at d0, d3 and d7

Keyed on the INSTALL day and measured from each user's own install stamp: dN is their first (N+1) x 24 h. ARPU is Adjust's own series, the one the partner's dashboard reports; ARPPU is our payment ledger, because Adjust exposes no cumulative distinct-payer count. A horizon the window has not lived through yet is left empty rather than written as zero.

Account spend split. B1 89% and the shared accounts 11% on 08-13, against 85% and 15% on 08-12; the portfolio spent $527.31 against $624.98.

Campaign spend split. Worldwide 100% on both days, so nothing in sections 3 to 5 carries a mix change between campaigns.

Every delivery price fell and the return per dollar fell with them. More installs for less money, earning less each, is a different audience.

B1 bought attention well and converted it worse. CTR up and click→install down, both at p = 0.000, and section 3's hour-by-hour read agrees.

Within-day fell about twice as fast as spend, on a flat payer count above the 16-payer bar. Revenue per payer went $12.14 to $9.13.

⚠ The instrument gate reads 0.99 on B1's own clock, inside the 0.91 to 1.06 band. The apparent drift was the join rate; see Caveats.

2The two ad accounts, side by side

Both accounts are ours: B1 (1738541847343652), whose campaigns are named bailingxia_, and the two shared Nomad Node accounts (835434076171203 and 3267486106793669), whose campaigns for this app are named 0811_ and 0814_*. Those two accounts also run greenvid and pixvoo for other products and none of that delivery is counted here. Each account's day is struck on its own account clock, and the two clocks are not the same; Caveats carries the offsets and how they were established.

What the columns are. DNU is our own registrations, so the cost beside it is not Meta's CPI below, and the revenue columns are booked.

The shared accounts are 11% of the money and a third of the impressions, so portfolio CPM $6.89 is a blend moving with the mix.

Rank the two on within-day or cohort@24h, never on booked, which counts whoever paid that day and so carries each buy's age.

At 15 payers the shared side's return is a direction, not a magnitude — more per dollar than B1 on both install-day measures.

Everything from section 3 down is B1 alone: the shared accounts' export carries no clicks, leads, country or Ad ID to strike those cuts on.

3B1 hourly, 2026-08-13

B1 only, as is every section below this one. Delivery columns are Meta's instrument on both sides of every ratio. Payer rate, ARPU and ARPPU are ours on both sides. The two install counts are never crossed. ours is our registrations in that hour; cov is that hour's cohort coverage at H=24.

⚠ Payer counts per hour run 0 to 5. An hourly ARPPU on one payer is that payer's basket and not a rate. Read the all row for level and the hours for shape.

The cohort column is complete across the whole clock. Every hour reads 100% at H=24 against the 08-16 cut, so nothing in it moves again.

Spend is flat across the clock and the delivery ratios are not. Nothing touched the budget all day; CPI ranges $0.527 to $1.572 underneath it.

4Country, 2026-08-13

5B1 aggregate, both days

B1 only, pooled over the 24 hours both days delivered in, on the UTC clock. Meta's instrument on both sides of every ratio.

• click → install 19.72% → 16.01% (−18.8%, p = 0.000) — fell.
• CTR 5.55% → 6.55% (+18.1%, p = 0.000) — rose.

Pooling across hours is a mix comparison; section 3's pairing is the unweighted read of the same days, and where they disagree the mix moved.

The three measures side by side

The mix-neutral account line: CPM $11.16 → $9.14, unchanged at 08-12's campaign mix. One campaign delivered both days, so there is no mix to neutralise.

Booked revenue by the day its payer installed

The top row of this table is the within-day figure. They are the same number seen twice, which is why the gap between booked and within-day is exactly the inherited cohort and nothing else.

A quarter of 08-13's booked revenue came from people who arrived that day, 25.4% against 30.1% and 49.0% on the two days before.

6B1's campaigns, side by side

These are B1's campaigns and no others. Delivery is Meta's instrument on both sides of every ratio; every revenue measure is ours. Cohort horizon H=24h. Report clock UTC. Rank on CPM, cost per click and CPI only — geography is the treatment here, while revenue still needs 16 payers (DECISION_LOG.md #37, #48).

Booking with no delivery, and excluded from every rate above: German (DE/AT) 0 installs (Meta), 0 registrations (ours), $0.00 within-day; Earner (retired 08-03) 0 installs (Meta), 71 registrations (ours), $0.00 within-day. Counting them would put installs into the CPI denominator against spend that never happened.

The retired earner still produces 71 registrations a day on no spend, twelve days after switch-off, down from 95 and earning nothing within-day.

The standing charts for this section plot spend share, CPM and CPI by campaign across the run. One campaign has delivered on every day in the window, so all three would be a single flat line and the chart generator emits none.

7Inside B1's worldwide campaign

Still B1 only, one level further down. Every table and every chart below is that one campaign.

Structure on this day

One ad delivered, alone in its own ad set, for all 24 hours. The ad-set row is therefore the ad row on this day, and the tables below are labelled by asset. That identity is a property of this day's cut rather than of the object model, and it has to be re-checked on any day two ads deliver together.

Six further ads sit in the campaign and none of them delivered. Four carry registrations and booked revenue with no spend, which is the same conversion-hour effect the appendix describes, one level down.

A. Per asset — delivery

Meta's instrument on both sides of every ratio. Our registrations never enter this table.

B. Per asset — the three revenue measures

Ours on every column. Meta can express only booked, so it rides bracketed beside that column and never as a row. Payers are distinct people, never transactions. Cohort horizon H=24h, 100% covered on this day. Report clock UTC.

The 16-payer bar (#37): any row above whose payer count is under 16 is a direction and never a magnitude. pool5 clears it with 34. Nothing else on this page does.

pool5's revenue row is the least concentrated this series has produced: largest single payer 16.8%, against 82.6% and bodysuit's 10.9% on 08-12.

C. Per asset — country mix

⚠ This table is cut on the META day, a seven-hour-offset window against tables A and B. Read it for mix, never for level against them.

The last column is the share of that asset's own within-day revenue that came from the United States: where it far exceeds the US spend share, the return is a property of the geography the asset bought.

pool5 bought 26.1% India on its full day, 21.8% on its partial day, 36.2% for bodysuit — a gap that has held across every read.

8Caveats

⚠⚠ The instrument discarded any payment it could not tie to a person, and this page was republished once that was fixed. measures.py builds its payment list by looking each payment's user up in the registration ledger and skipping what does not resolve, so an unattributable payment was absent from all three measures. Earlier reports in this series stated that such payments were still in booked. They were not.

The payment API leaves the payer field empty on about a quarter of its rows. What it does populate on every row is an account UUID, and the registration feed has been sending that same UUID alongside the numeric user id since the push began at 2026-08-13 18:52 UTC. Nothing on our side was keeping it. Joining the two recovers the payments whose payer registered after that moment, which is why this day recovers a few points and the days after it recover far more:

The gate was reading the join rate. This day first published at 0.96, four points under Meta; on the repaired record it is 0.99, so three of those four points were payments the measure was throwing away. Nothing about the account or about Meta's number changed. What is still unrecoverable is payments from people who registered before the push began, because no feed we hold carries their UUID — 69 payments across the whole history, sitting almost entirely in days before this one, which is why the readings before 08-13 do not move under the repair.

Read at one payment cut, on exports since verified to carry all 24 buckets, the series is:

Four of six sit inside the 0.91 to 1.06 band and two sit just outside it at 1.07. A constant systematic offset would not wander in and out. The 1.09 once published for 08-12 was computed against an hourly export pulled at 22:38 on 08-12, account time, while that Meta day was still running: the file held 23 hour buckets, hour 23 absent and hour 22 carrying $9.09 of its final $18.42. A UTC-day report needs only Meta hours 00 to 16:59 of its own day and never touched the missing tail, but the META-clock gate does touch it, and it divided our whole day of payments by Meta's 22 hours. ad_ops/meta_export.py now refuses an hourly export that does not carry all 24 buckets.

What moved on this page. Booked went $1,279.80 to $1,294.09, within-day $314.52 to $328.81 and its return 0.67 to 0.70, the cohort $361.67 to $375.97 at full coverage, the day's payer count 34 to 36, and pool5's payer rate 5.7% to 6.1%. Delivery moved by fifteen cents of spend, eleven impressions and three clicks, which is a second export of a settled Meta day and has nothing to do with the repair.

Cohort at 24 hours now carries the day-over-day comparison, because both days are fully covered. 08-12 and 08-13 are each 100% covered at H=24 against a payment cut of 10:59 UTC on 08-16, so the $619.65 to $375.97 fall is one frozen cohort against another and needs no coverage caveat. The page as first published read this day at 72% coverage and could not make that comparison; within-day, which is sealed at midnight, carried it instead and still agrees with it.

⚠ The 08-12 figures on this page differ from the 08-12 report as published, and the reason is the same short export. That page carried spend $529.61, CPM $11.16 and CPI $1.015; this one carries $532.72 and $1.021. The re-pulled export added $3.11 of spend and 259 impressions spread across all 24 UTC hours, none of it in one place. Within-day did not move at all, at $424.78 on both cuts, which it cannot. The cohort figure is identical to the cent at $619.65 and its coverage rose from 88% to 100%, which is what a fixed horizon is supposed to do.

Payments on this page come from two sources joined. The payment API is the fuller record of what was paid and drops the payer's identity on 18.2% of this day's rows. The Telegram export carries the identity on essentially all of them and stops at 14:50 UTC on 08-13, so from that hour the API is the whole record and the UUID join is what stands between a payment and every measure on this page. This report uses the export as the base and adds the API rows it does not contain, 94 of them on this day. Those 94 are where the UUID join does its work, and where an unjoined row would vanish from all three measures at once.

A whole-day like-for-like is what this day gives and the one before it could not. 08-12 split 21.3 hours of bodysuit against 2.7 of pool5; 08-13 is 24 hours of one asset. Tables A, B and C are therefore whole-day figures for the first time since 08-11, and the hour-of-clock confound that made every per-asset comparison on 08-12 unreadable is gone.

The country section and table C are the account's own day, seven hours offset from every other table. They are read for mix, never for level.

The shared accounts' export runs on a column preset that is not ours, so it carries no clicks, no leads, no country and no Ad ID; the only join key it offers is the ad set name, which measures.py refuses to select on.

The standing chart set has no per-account cut, so section 2 is its two tables and no figures.

The FX table is twelve days old. Revenue in 33 currencies is converted at rates pulled on 2026-08-02, and it prices days through 08-13. With the join rate accounted for it is the only remaining candidate in the open instrument reconciliation, and it has never been tested.

⚠⚠ The two accounts run on different clocks, and each is stitched on its own. B1 is fixed at UTC-7, so its UTC day is built from two account days. The Nomad Node accounts run at UTC+0, so their reporting day is the UTC day and nothing is stitched onto them. Neither offset was assumed: each account's hourly impressions were correlated against our own registrations from its own campaigns, which are true UTC, and the method recovers the known k=7 on B1 at r = 0.878 against 0.703 and 0.698 either side, and returns k=0 on the shared accounts at r = 0.744 against 0.589 and 0.404. Stitching the shared accounts on B1's offset would move their spend seven hours.

Booked cannot rank one account against the other, and booked is the column Meta quotes. It counts everyone who paid inside the day whatever day they installed, so an account carrying three weeks of accumulated cohort and a buy three days old are not being measured on the same thing. Section 2 ranks on within-day and cohort@24h, which count only that day's own installs, and on this day the payer count behind the shared side's figures sits under the 16-payer bar in any case.

Sections 3 to 7 select by Ad ID against the run config's map, so they are B1 alone. The shared accounts' traffic delivers on ad ids ending 334, under campaigns named 0811_vl_bailingxia_srfhjyd-rain-chuva and -health, and those ids were never in that map. No figure in those sections carries their spend or their revenue, and section 2 is where the portfolio is stated.

37% of registrations never enter a revenue measure and that is true of every day in this series. Every "ours" figure means registrations attributable to a mapped Meta ad. It is internally consistent, because the payer rate divides our payers by that same population.

One draft sits unpublished on the account. The manage view reads Review and publish (1). Nothing on this page depends on it and it was not touched.

9What would settle the open questions

Nothing about pool5 against bodysuit on revenue, at this account's volume. The requirement is 16,692 installs an arm and the larger arm reached 750. The two arms are separable on cost and will not become separable on return by running longer at $450 — and on the repaired record they are level on return anyway, which is a statement about the sample and not about the creatives. Deciding between them on revenue needs either a far larger buy or an endpoint with more signal per install than revenue, which is what DECISION_LOG.md #57 proposed in payers per install.

Which instrument the residual gap belongs to. One candidate is left and it has never been tested: the age of the FX table against the days it prices. The candidate that sat on top of it, API payments joining to no user, is the mechanism this page was republished on, and with it removed there is no larger effect hiding the FX question. Repricing one settled day at current rates would answer it in an afternoon.

The 69 payments that still resolve to nobody. They belong to people who registered before the push began at 2026-08-13 18:52 UTC, so no feed we hold carries their UUID and no query will recover them. They are a fixed historical residue. The open question is whether the payment API can populate the user field directly, which would remove the join from the path altogether.

This page was republished on 2026-08-16 after a defect in the payment instrument was found and fixed, and every revenue figure on it moved. The measure discards any payment it cannot tie to a person, and some of this day's payments were arriving identified only by an account UUID that nothing on our side was keeping. The registration feed had been carrying that UUID all along, and joining the two lifts the share of this day's payments that resolves to a payer from 90.9% to 93.8%. This day's within-day revenue moves from $314.52 to $328.81, its return from 0.67 to 0.70, its payer count from 34 to 36, and the instrument gate from 0.96 to 0.99. The delivery half of the report is Meta's instrument on both sides of every ratio and the repair never touched it. Caveats has the measurement and what is still unrecoverable.

This is the first full day of pool5 alone at $450, and it is the day the 08-12 report deferred its revenue read to. The buy ran one creative in one ad set from midnight to midnight with no budget or status change anywhere in the account, confirmed against the campaign's own activity history. Every table on this page is a whole-day like-for-like, which no report since 08-11 has been able to say.

10What this hands to the next read

The 08-14 report inherits E2-R10 in its second full day and a cost advantage that no longer needs establishing. The useful question moves from which creative to what the account does with a buy whose installs are 14.6% cheaper and worth less each. Within-day at 0.70 on a $450 daily is the number to watch, and two consecutive full days of the same regime will be the first pair this campaign has ever offered.

It also inherits a payment record that resolves nearly every row to a payer, and a guard that stops a part-day export reaching a report. The remaining reconciliation is one candidate wide.

11Reproduce

Report clock UTC; B1's exports are stamped in its ad account zone (UTC-7), so every delivery row of its is restitched from two Meta days, while the shared accounts report in UTC and are taken as they come. The country tables and table C are not restitched and are labelled where they appear.

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

Section 2's two tables are that last command's output for this day, pasted unedited. It stayed a separate reader because the shared accounts' files offer no Ad ID to select on, and --calibrate re-derives each account's offset from data and fails loudly if a stored one stops matching.

The pipeline runs measures, day_compare, cohort_arpu, asset_estimator, report_tables and report_charts in the fixed order, on both the UTC and the META configs it writes, and it now chains the payment and registration ledgers forward from the previous run. The estimator is re-run above across three hourly exports where the pipeline uses two, so that E2-R9 is measured over its whole span.

12Appendix — definitions

The report clock is a UTC day. Adjust reports in UTC, so a UTC-bucketed report lines up with the attribution dashboard without anyone converting in their head. B1 is fixed at UTC-7, so a UTC day on it is account day D−1 17:00 to 23:59 plus account day D 00:00 to 16:59. The two clocks are not close: on a measured day the same figures differed by 14.6% on spend and 40.7% on within-day revenue.

Three things the clock does not reach, each labelled where it appears. Table C's per-asset country mix cannot follow it: the rake is per ACCOUNT, against that account's own hourly margin, and an asset has no hourly margin of its own. The instrument check is invalid off the account's clock, because Meta's conversion value sits on its conversion hour and cannot honestly be restitched. And the estimator runs on Meta's clock deliberately, because its subject is delivery windows and a budget change is an instant on the account's own clock.

The three revenue measures, never one, never mixed, always labelled:

A day whose spend is falling reads high on booked and low on the other two, purely because yesterday's buyers are still paying. Use within-day for day-over-day, because it is immutable and needs no horizon. Use cohort at a fixed horizon to compare hours to each other, because within-day censors by hour of day. Booked is what Meta will quote at you, so it is reported to explain the gap and never to rank.

All three measures are read on our own payment records, and all three count only payments the record can tie to a person who installed through one of our mapped ads. Meta can express only booked, so it appears bracketed beside that column and never as a row of its own. Quoting Meta's booked against our within-day would mix instruments, and part of the reported gap would be the instrument difference.

Two install counts exist and they are never crossed. Meta's Leads and our own registrations disagree by 5 to 10%. Meta's is used for the delivery funnel, so CPI and click→install have both numerator and denominator on one instrument. Ours is used for payer rate and every revenue measure, so the payers and the installs they came from are the same population.

A regime is a stretch over which the ad set's daily budget did not change. The budget is a geography dial on this account, so two creatives measured across a budget change were compared on different audiences. This day held one throughout: E2-R10, pool5 alone at $450, open since 2026-08-12 14:18 account time.

The 16-payer bar (DECISION_LOG.md #37): below roughly 16 payers a revenue figure is a direction and not a magnitude. Revenue per install on this account is a near-zero vector with rare large entries, with a coefficient of variation near 6.5, so separating two creatives by 20% needs about 16,692 installs per arm. The largest regime-matched arm this account has ever produced is 750.