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

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.

Spend split. Portfolio $624.98 against $903.50; B1 85% against 96%, the shared accounts 15% against 4%. Inside B1, Worldwide held 100% on both days.

The buy shrank; the return per dollar did not move. Spend −39.2% against within-day −37.7% at 35 payers, and within-day ROAS 0.78 → 0.80.

Booked held while spend fell two fifths; the gap is inherited cohorts. 30.1% of booked came from that day's installs, against 49.0% the day before.

Impressions got dearer, clicks got scarcer, and the people who did click converted better. CPM +4.7%, CTR −14.8% against a 42% impression cut, click→install +13.2%.

⚠ The instrument gate is drifting. B1's account clock reads 1.07, 1.07, 1.07 and now 1.09 against a 0.91 to 1.06 band; reconciliation in Caveats.

2The two ad accounts, side by side

Both accounts are ours. B1 (1738541847343652) is the account every earlier report in this series covered, and its campaigns are named bailingxia_. The two Nomad Node accounts (835434076171203 and 3267486106793669) are shared with us, and started buying this app on 08-11; only their 0811_ and 0814_* campaigns are this app, and the greenvid and pixvoo campaigns running beside them are other products and are excluded from every figure here.

Spend and impressions are Meta's, each account read on its own clock. Registrations, payers and all three revenue measures are our own records, and DNU is our registration count: the shared export carries no Meta install column, so our registrations are the only install count both sides have and the CPI and payer rate below divide by them. Rank the two accounts on within-day or cohort@24h, never on booked. This section is a later export and payment cut than the rest of the page; see Reproduce.

The shared accounts returned more per dollar on both rankable measures: within-day 1.29 against 0.80, cohort@24h 1.70 against 1.16. Booked reverses it on age alone.

15% of the spend bought 31,379 of 79,093 impressions. The shared accounts buy a much cheaper person who is much less likely to pay.

The shared side clears the 16-payer bar with 19 payers, and is still thin: three fewer and its 1.29 would be a direction only.

The shared accounts' export carries no clicks, no leads, no country and no Ad ID, so every section below this one is B1 alone.

3B1 hourly, 2026-08-12

B1 only, as is every section from here down. 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 9. An hourly ARPPU on one payer is that payer's own basket. Read the ALL row for level and the hours for shape.

The last three rows are the regime change. Hours 21 to 23 are pool5's only hours, and hour 23's $123.24 rests on four payers.

4Country, 2026-08-12

5B1 aggregate, both days

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

• click → install 17.52% → 19.83% (+13.2%, p = 0.012) — rose.
• CTR 6.51% → 5.55% (−14.8%, p = 0.000) — fell.

Pooling across hours is a mix comparison: it weights each hour by what it delivered, so these rows can move without any hour changing.

The three measures side by side

Mix-neutral account line: CPM $10.66 → $11.16, on 08-11's mix still $11.16. One campaign delivered on 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.

6B1's campaigns, side by side

These are B1's campaigns, and B1's spend is what the shares are taken of. 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), 95 registrations (ours), $0.00 within-day. Counting them would put installs into the CPI denominator against spend that never happened.

The retired earner still produced 95 registrations on no spend, eleven days after it was switched off, and no within-day revenue on either 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. The campaign-level reading for this day is the table above.

7Inside B1's worldwide campaign

B1's worldwide campaign, which carried all of B1's spend on this day.

Structure on this day

Two ads delivered, each alone in its own ad set, and never at the same time. bodysuit ran hours 00 to 21 and pool5 ran hours 21 to 23. The ad-set row is therefore the ad row on this day, and the tables below are labelled by asset. That identity holds for this day's cut alone, and it has to be re-checked on any day two ads deliver together.

Seven further ads sit in the campaign and none of them delivered. Three 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. bodysuit clears it with 30. Nothing else on this page does.

⚠ pool5's revenue row is one person: within-day $92.50, 82.6% of it a payer who registered in hour 01, twenty hours before the regime opened.

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 14.4 points less India and 4.7 points more United States than bodysuit. A cheaper country mix is most of a cheaper CPI here.

8Caveats

⚠ The two accounts keep different clocks, and the account table in section 2 is built on that difference. B1 is fixed at UTC-7, so each of its UTC days is stitched from two account days; the Nomad Node accounts sit on UTC+0, so their reporting day is the UTC day and nothing is stitched. Both offsets were recovered from data by correlating each account's hourly impressions against our own registrations, which run on true UTC: the method returns B1's known seven-hour offset at r = 0.878 and a zero offset for the shared accounts at r = 0.744. Stitching the shared accounts on B1's offset would move their spend seven hours.

Booked cannot rank these two accounts and this report does not use it for that. B1 has three weeks of installs still paying behind it and the shared buy is a day old, so booked credits B1 with revenue that has nothing to do with what either account bought on this day. Every cross-account statement on this page is made on within-day or cohort@24h, and the shared side's within-day figure rests on 19 payers, just clear of the 16-payer bar.

The shared accounts' export column preset is not ours to change. It carries no clicks, no leads, no country and no Ad ID, which is why the hourly funnel, the country cut and the three per-asset tables have no shared-account counterpart.

⚠ The instrument gate has now breached four readings running, and the breach is widening. On B1's own account clock, where the check is valid, our records read 1.07 on the 08-11 first cut, 1.07 on the 08-11 re-cut, 1.07 on the first 08-12 cut and 1.09 here, against a documented 0.91 to 1.06. The 08-11 pair already ruled out maturity: twelve hours and a coverage move from 35% to 71% left the ratio unchanged to two decimals. This reading is wider than the last because our own instrument became more complete, not because the day differed, which points the discrepancy in a definite direction. Refunds have now been eliminated as the explanation. The payment API exposes refunds for the first time and there are 25 across the whole series, worth roughly $8 a day against an instrument gap of about $110 a day on each of these two days. A 9% gap does not invalidate within-day, which never touches Meta's column; it bounds every statement on this page that compares the two.

The cohort at 24 hours is frozen, at 100% coverage on both days. 08-12's last install passed its horizon at 23:59 UTC on 08-13 and the figure has not moved from the $619.65 published here: the 2026-08-13 report carries the same number at full coverage. Against 08-11's completed $787.66 the day reads −21.3%. This page shipped at 88% coverage, and the missing 12% was hours 21, 22 and 23 — exactly the hours pool5 delivered in, which is why the comparison was declined at the time. Those hours added nothing further.

⚠ The 08-11 figures on this page differ from the 08-11 report as published, by one payment. That page carried within-day $665.73 and 0.76; this one carries $681.83 and 0.78. The difference is a single €13.99 purchase at 01:11 UTC on 08-11 that the Telegram export never contained and the payment API does. Within-day did not drift, which it cannot; the instrument reading it became more complete. Two such rows exist across the whole series, the other on 08-02.

Payments on this page come from two sources joined, and the join is what makes the cohort measures readable. The payment API is the more complete record of what was paid and drops the payer's identity on about a quarter of its rows, which silently deflates any measure keyed to an install day. The Telegram export carries the identity on 97.6% of rows and stops at 14:50 UTC on 08-13. This report uses the export as the base and adds the 73 API rows it does not contain. Both sources hold exactly the same 209 transactions for UTC 08-12, with no amount or currency mismatch between them.

No per-arm figure on this page is a whole-day like-for-like. bodysuit ran 21.3 hours of the day and pool5 ran 2.7. Tables A, B and C are whole-day figures and inherit that asymmetry. The regime block is the version that does not, and it is not a comparison for the separate reason given there.

The rule against tabling a regime that opened inside the report's own day was written on 08-11. That daily read E2-R9 as 33% dearer per install than the five-arm regime, and the same comparison read +2% six hours later on nothing but a fresher payment cut.

The 08-11 report carried pool5 at 1.10 and it fell to 0.77 as maturity arrived, which is why its revenue column is read once the regime has a full day and an hour-matched window behind it.

pool5's hours are the day's late-evening hours and its audience is not bodysuit's. Hours 21 to 23 delivered at CTR 6.69% to 9.78% against a day averaging 5.55%. Any straight per-asset comparison on this day is confounded by hour of clock before it is confounded by anything else.

The country section and table C are B1's own account day, seven hours offset from every other table. Where the UTC day splits 21.3 hours of bodysuit against 2.7 of pool5, the Meta day splits 14.3 against 9.7. They are read for mix, never for level.

The FX table is eleven days old. Revenue in 33 currencies is converted at rates pulled on 2026-08-02, and it prices days through 08-12. It is one of the three named candidates in the open instrument reconciliation and it has not yet been separated from the other two.

The second buy is now identified, and sections 3 onward are still B1 alone. The ad ids ending 334 delivering under campaigns named 0811_vl_bailingxia_srfhjyd-rain-chuva and -health belong to the two shared Nomad Node accounts, and section 2 reports them. Every table from section 3 down scopes to the ad ids in the run config, all of which are B1's, so that traffic enters none of them.

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.

9What would settle the open questions

Whether pool5 at $450 holds its cost advantage over a full day. It has now shown a cheaper CPI in five consecutive reads, but never once across a whole day at this budget, and the regime table shows this account's returns falling as budgets rise. The 08-13 report is the first cut that can answer it, because E2-R10 will have a full day and an hour-matched window against E2-R9.

Which instrument the 9% gap belongs to. Refunds are now ruled out by measurement. Two named candidates remain and neither has been separated: the age of the FX table against the days it prices, and the ~20% of payments in the payment API that join to no user. A third has been added by this report, which is that our own record is still gaining rows.

Whether the payer identity missing from a quarter of API payments can be recovered. If it can, the Telegram export stops being needed for anything except history. If it cannot, every cohort measure stays dependent on an export that runs on a laptop.

This day is split in two and no per-arm day figure crosses the seam. For 21.3 hours B1 ran bodysuit alone at $450; from 21:18 UTC it ran pool5 alone at the same $450. The second regime opened inside this report's own day, which is why it is described in section 7 and kept out of every comparison table.

10What this hands to the next read

The 08-13 report inherits a clean question and the first day able to answer it: E2-R10 against E2-R9, same budget, same campaign, same single-arm auction, one creative substituted, and by then both with a full day behind them. It should state each regime's matured install count beside every figure. pool5's cohort coverage is now in place, and what the revenue column cannot yet carry is the payer count behind it.

It also inherits the fourth breach. The standing rule is now to open the reconciliation, and this report has closed off one of its three candidates.

11Reproduce

Report clock UTC; B1's exports are stamped in its ad account zone (UTC-7), so every delivery row is restitched from two account days. The shared accounts are on UTC+0 and are not restitched. The country tables and table C are not restitched either and are labelled where they appear.

Section 2 is a later cut than the rest of the page. Its B1 spend reads $532.72 where every other section reads $529.61, from a later re-pull of the same account day, and its B1 install count is our registrations grouped by campaign name where the rest of the page groups them by Ad ID. B1's within-day and cohort@24h revenue are identical to the cent on both cuts.

python -m ad_ops.measures      --config _runs/2026-08-13_0812_daily/run_config.json --day 2026-08-12 --prev 2026-08-11
python -m ad_ops.measures      --config _runs/2026-08-13_0812_daily/run_config_meta.json --day
2026-08-12 --prev 2026-08-11
python -m ad_ops.day_compare   --config _runs/2026-08-13_0812_daily/run_config.json --today
2026-08-12 --prev 2026-08-11 --h 6
python -m ad_ops.cohort_arpu   --config _runs/2026-08-13_0812_daily/run_config.json --days
2026-08-09,2026-08-10,2026-08-11,2026-08-12
python -m ad_ops.asset_estimator hourly \
    --meta _runs/2026-08-12_0811_daily/exports/ads_hourly_aug11_settled.csv \
           _runs/2026-08-13_0812_daily/exports/ads_hourly_aug12_settled.csv \
    --lum _runs/2026-08-13_0812_daily/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 -m ad_ops.report_tables --config _runs/2026-08-13_0812_daily/run_config.json --day 2026-08-12 --prev 2026-08-11
python -m ad_ops.report_charts --config _runs/2026-08-13_0812_daily/run_config.json --day 2026-08-12
--prev 2026-08-11 \
    --days 2026-08-09,2026-08-10,2026-08-11,2026-08-12 --out ad_ops/figures/2026-08-12 --relpath figures/2026-08-12
python _runs/2026-08-16_receipt_series/portfolio_split.py --markdown _runs/2026-08-16_receipt_series/blocks
python _runs/2026-08-16_receipt_series/portfolio_split.py --calibrate

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. 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 the instrument difference would land inside a gap that is otherwise exactly the inherited cohort.

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 two: E2-R9, bodysuit alone at $450, running to 21:18 UTC; and E2-R10, pool5 alone at $450, from 21:18 UTC.

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.7, so separating two creatives by 20% needs about 17,600 installs per arm. The largest regime-matched arm this account has ever produced is 545.