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

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 82% and the shared accounts 18% on 08-14, against 89% and 11% on 08-13; the portfolio spent $506.46 against $527.31.

B1's campaign spend split: Worldwide 100% on both days. The German buy and the retired earner spent nothing, so no section carries a mix change.

Impressions got 14.1% cheaper and fewer of the clicks they bought became installs. The two did not cancel: the install cost 5.3% more.

The click rate did not move, 6.55% to 6.51%. Whatever changed sits below the click, where section 3's hourly read puts it too.

Within-day fell 26.2%, roughly twice the spend cut, on 28 payers against 37. Both cohorts are fully matured, so no horizon caveat applies.

B1's own account day moved the other way: the UTC day inherited a weak evening from Meta 08-13 and handed a strong one to 08-15.

2The two ad accounts, side by side

B1 buys under bailingxia_; the two shared Nomad Node accounts buy this app under 0811_ and 0814_*, their greenvid and pixvoo campaigns excluded.

Spend and impressions are Meta's, read off each account's own export. DNU is our own registration count for that account, so CPI in this table is spend ÷ DNU on our instrument for both accounts and is not the $0.918 of section 3, which has Meta on both sides of the ratio. The two install counts are never crossed.

Payers here are everyone who paid inside the day whoever brought them, which is the booked basis, so they are not the within-day payer counts used elsewhere on this page. ARPU and ARPPU below sit on that same basis: booked ÷ DNU and booked ÷ payers.

Four columns are missing from the shared accounts' export: clicks, Meta's leads, country and Ad ID. Everything below section 2 is therefore B1 alone.

Rank the two accounts on within-day or cohort@24h and never on booked. Booked puts B1 ahead, 2.87 against 2.06; the sealed measures reverse it.

The shared side sat at 12 payers, under the 16-payer bar, so its 1.08 and 1.63 are a direction and never a magnitude.

The shared buy wins on what a user costs and loses on what one is worth: $0.261 a registration against $0.659, ARPU $0.537 against $1.892.

3Hourly, 2026-08-14 — B1 only

This section and every one below it is B1's buy alone.

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, counted over the ads mapped in the run config, which is why it totals 587 against the 628 in section 2; 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 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% coverage at H=24, and nothing in it can move again.

The day's first two hours are the worst the account has recorded: 00 and 01 are Meta 08-13 at 17:00 and 18:00, the previous evening.

Spend climbs across the second half while the install cost does not follow it. Hour 19 carries the day's peak spend and its dearest CPM.

4Country, 2026-08-14

5Aggregate, both days — B1 only

Both days are B1's buy. Pooled over the 24 hours both days delivered in, on the UTC clock. Meta's instrument on both sides of every ratio.

• click → install 16.01% → 13.15% (−17.9%, p = 0.001) — fell.
• CTR 6.55% → 6.51% (−0.6%, p = 0.801) — did not separate.

Pooling across hours is a mix comparison. Section 3's pairing is the unweighted read; where the two disagree, the mix moved.

The three measures side by side

Booked held its return while the two install-day measures fell: a shrinking buy inherits more of yesterday's payers, and booked counts them.

The mix-neutral account line: CPM $9.14 → $7.86, and $7.86 again on 08-13's mix. One campaign delivered on both days, so nothing needs neutralising.

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 fifth of the account's booked revenue came from people who arrived on 08-14, against a quarter before; the six rows cover 66.0% against 77.4%.

6The campaigns, side by side — B1 only

Every campaign in this section is B1's; the shared accounts' two campaigns are in section 2 and nowhere below it. 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), 2 registrations (ours), $0.00 within-day; Earner (retired 08-03) 0 installs (Meta), 64 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 64 registrations a day on no spend, thirteen days after it was switched off, down from 71 and earning nothing.

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 the worldwide campaign — B1 only

B1's only delivering campaign on the day, walked down to the ad.

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 alone, and it has to be re-checked on any day two ads deliver together.

Eleven further ads sit in the account's mapped set and none of them delivered. Three carry registrations 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 25, against 37 the day before. Nothing else on this page does.

What each payer spent fell; their number barely moved. ARPPU is 9.35 against 12.60, the payer rate 6.6% to 6.0%.

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 less India and more United States than on any prior full day, 21.7% against 26.0%, and earned less.

Its American revenue share is 25.2% against 28.2%: whatever moved sits inside the countries, with India and the United States each giving back about half.

8Caveats

⚠⚠ The instrument discarded a fifth of this day's payments, 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 is absent from all three measures. Earlier reports in this series stated that such payments were still in booked. They were not, and on those days it made no difference because the share was two or three percent.

It was not two or three percent here. The Telegram export carried the payer on essentially every row and stopped at 14:50 UTC on 08-13; from there the payment API is the whole record, and it 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. Nothing on our side was keeping it. Joining the two recovers the payments.

The share of each account day's payments that resolves to a payer, before the repair and after it:

The gate was reading the join rate. This day published at 0.86, outside the 0.91 to 1.06 band and the widest breach the series had recorded; on the repaired record it is 1.05 and inside. Nothing about the account or about Meta's number changed. What is still unrecoverable is payments from people who registered before the push began on 2026-08-13 18:52 UTC, because no feed we hold carries their UUID. That residue is 69 payments across the whole history and it shrinks to irrelevance as the push accumulates.

What moved on this page. Booked went $1,069.12 to $1,147.14, within-day $164.79 to $242.81 and its return 0.40 to 0.59, the cohort $227.60 to $311.66, the day's payer count 16 to 28, and pool5's payer rate 4.0% to 6.0%. The comparison day moved too, by less: 08-13's within-day is $328.81 against the $314.52 its own page carried. Every delivery figure is unchanged, because delivery is Meta's instrument on both sides of every ratio and never touched this.

pool5's payer rate on the repaired record runs 6.6%, 6.0% and 6.0% across 08-13, 08-14 and 08-15. The first version of this page put 08-14 at 4.0% and read the day as a collapse in people paying at all; that number was the instrument.

⚠ The 08-13 figures on this page differ from the 08-13 report as published, for two reasons. The delivery difference is one re-pull of a settled day: that page carried $468.95, 51,292 impressions, 3,357 clicks and click→install 16.03%, against $469.10, 51,303, 3,360 and 16.01% here, which is what a settled Meta day moves by on a second export. The revenue difference is the repair above, and it is larger: within-day $328.81 against the $314.52 that page published. A measure described as sealed moved, and it moved because the instrument could suddenly see payments it had been throwing away.

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. This matters more than usual on this day, because the account day and the UTC day moved in opposite directions: $431.33 and 471 leads on account day 08-13 against $468.59 and 531 on account day 08-14.

The FX table is thirteen days old. Revenue in 33 currencies is converted at rates pulled on 2026-08-02, and it prices days through 08-14. It is the other open candidate in the instrument reconciliation, and it is now the one that has not been given a mechanism.

The shared accounts' export runs a different column preset and we do not control it. The only join key its files offer is the ad set name, which this report refuses to select on, so the shared side carries no CTR or click→install row anywhere on this page.

The two accounts run on different clocks, and section 2 only works because each is stitched on its own. B1 is fixed at UTC-7, so its UTC day is built from two Meta days. The two shared accounts run on UTC+0, so their reporting day already is the UTC day and no stitch applies; giving them B1's offset would move their spend seven hours. Both offsets were derived from data, by correlating each account's hourly impressions against our own registrations from its campaigns, which are true UTC: the method recovers the known seven-hour offset on B1 at r = 0.878 and returns zero on the shared accounts at r = 0.744.

Rank the two accounts on within-day or cohort@24h and never on booked. Booked counts everyone who paid inside the day whatever day they installed, so it credits B1 with three weeks of accumulated cohort and the shared buy, open only since 08-11, with almost none. Section 2's booked column is reported to explain that gap and is not a ranking. The shared side also sat at 12 payers on this day, under the 16-payer bar, so its returns are a direction and never a magnitude.

The shared accounts grew on the day B1 weakened, and opened two more campaigns. Traffic under ad ids ending 334 produced 354 registrations on 08-14 against 278 on 08-13, and two new campaigns appear alongside 0811_vl_bailingxia_srfhjyd-rain-chuva: a 0814_vl_ twin of it and a 0814_vl_bailingxia_srfhjyd_maimai. No figure from section 3 down is affected, because every table there scopes to the ad ids in the run config. Whether the two buys contest the same auctions, and what that costs, is the standalone report of 2026-08-14; this day is consistent with that reading and does not test it.

A further ad account of ours has not delivered in this window. The KBM1 campaign published on 08-15 produced no registrations on 08-14 and sits in a different ad account, so it enters none of Meta's exports here. It will appear in the registration ledger as unmapped traffic once it spends.

37% of registrations never enter a revenue measure and that is true of every day in this series. Every "ours" figure from section 3 down 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.

This report was written about four hours before the scheduled staging window. Running at 18:10 PT would have put the day's cohort at 100% coverage instead of 86%. Nothing else on the page would move, because within-day is sealed and every delivery figure comes from a closed Meta day.

9What would settle the open questions

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

Whether the instrument gate has anything left in it. On the repaired record the four account days read 0.99, 1.05 and 1.01 against a 0.91 to 1.06 band, so the drift that four earlier reports described was the join rate throughout. The FX table's age remains a named candidate and has never been tested; repricing one settled day at current rates would settle it in an afternoon, and there is now no larger effect sitting on top of it.

Nothing about pool5 against bodysuit on revenue, at this account's volume. The requirement is 17,775 installs an arm and the larger arm is at 1,349. Running longer at $450 does not close that, and on the repaired record the two arms are level on return anyway.

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 a fifth 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. With the two joined, this day's within-day revenue goes $164.79 to $242.81 and its return 0.40 to 0.59, the payer count 16 to 28, and the instrument gate 0.86 to 1.05. The delivery half of the report never moved, because it is Meta's instrument on both sides of every ratio. Caveats has the measurement and what is still unrecoverable.

10What this hands to the next read

The 08-15 report inherits the strong account evening this day handed forward: Meta day 08-14 spent $468.59 and booked 531 leads, and its last seven hours land inside UTC 08-15. It also inherits a repaired payment instrument and is the first day measured on it from the start.

E2-R10 goes into its third full day with a cost advantage that has widened on seven consecutive reads and a return that is now level with the arm it replaced. The useful thing to watch is click→install, which fell 17.9% on this day at p = 0.001 and is the one movement that survived both the pooled and the unweighted read.

11Reproduce

Report clock UTC; B1's Meta exports are stamped in that account's zone (UTC-7), so every delivery row from section 3 down is restitched from two Meta days. The country tables and table C are not restitched and are labelled where they appear.

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

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. It stages two hourly exports; the estimator is re-run above across four, so that E2-R9 and E2-R10 are each measured over their whole span.

day_compare's own output is not quoted on this page. It reads installs from our own registration ledger, and its window reaches seven hours past the report day, so it answers a different question on a different clock from section 5's pooled funnel.

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's ad account is fixed at UTC-7, so a UTC day is Meta day D−1 17:00 to 23:59 plus Meta 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, and on this day they differ in direction.

Three things the clock does not reach, and each is 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 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.

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