Stop exporting AppsFlyer by hand. Opera pulls the right API at the right grain — aggregated spend, event-level conversions — applies your filters, and keeps your existing Sheet current, reconciled.
Teams that run on AppsFlyer rebuild the same export every week: pick the report, set the dates, filter the geo, download the CSV, reshape it to the Sheet's columns, paste, recompute. It works — and it quietly costs a half-day a week while inviting exactly the errors that make clients question the numbers.
Most AppsFlyer reporting pain is using one export for two different jobs. Opera splits them:
Filters travel with every pull:
"Update this week's report with installs, CPI and CAC by country from AppsFlyer."
The discipline transfers. Adjust's aggregate and event-level exposures differ in names and shapes, but the load-bearing decisions are identical: aggregate pulls for spend and installs, event-level pulls deduplicated per user for KPI events, SKAN in its own lane, filters stored per report, periods resolved in the app's timezone. Opera abstracts the MMP behind the same report contract — your Sheet doesn't know or care which referee supplied the attributed column, and a future MMP migration becomes a re-mapping exercise rather than a report rebuild. What does not transfer automatically is history: numbers from two MMPs shouldn't be trended across a migration week without an annotation, which the report carries the same way it carries any definition change.
Agency AppsFlyer reporting multiplies everything above by the roster: each client has its own apps (per OS), its own timezone setting, its own event taxonomy and prefixes. Opera stores each client's AppsFlyer configuration separately — app scoping, event names, filters — and runs each report under its own credentials and schedule, fully isolated. The practical win is that the discipline (dedup, SKAN separation, ISO weeks) becomes uniform across clients even though every configuration differs — which is the consistency clients experience without ever being migrated to anything.
The request — "fill last week's US report with spend and purchase new purchases from US_ campaigns" — resolves to two pulls and one row:
| Pull | API | Filter | Result |
|---|---|---|---|
| Spend & installs | Master | Wk 24 · geo=US · US_ | $22,400 · 11,480 |
| Purchases | Raw Data Pull | + event, dedup, re-eng. excl. | 1,742 events → 1,610 users |
The 132-event gap between rows and users is the dedup earning its keep — re-engagement-heavy weeks would otherwise inflate purchases by 8–10%. The appended row computes CAC at $13.91 against the deduplicated count, which is the only version of that number worth trending.
iOS postbacks arrive late, coarse and capped — useful signal, terrible denominator. Opera writes SKAN-modeled installs and conversions into their own labeled columns beside the attributed series, so the iOS picture is visible without ever inflating the CAC your budget decisions run on. When the iOS share of a market shifts, you see it as a mix change in labeled columns — not as a mysterious efficiency jump.
Schema re-validated before the write; append-only into the detected anchor; the week refused if it already exists; formula columns extended, never overwritten; the full pull-and-write recorded in the audit log. If the sheet changed since last week, the run halts and tells you what moved.
See this running on your own reports.A 45-minute workflow audit maps your current process and shows exactly what Opera automates — step by step.
A 45-minute teardown of how you report today: we map every step, mark what Opera automates, and send you the written spec — useful whether or not you buy.