Every number reconciles to an invoice line.
SkyBoosts reporting is built at impression level first and aggregated second, which means every figure in the dashboard traces back to the auction decisions that produced it. The dimensions match the way you actually run your business, and the whole surface, dashboard, API, scheduled exports, server-to-server postbacks, reads from the same store. This page defines what you get, how fresh it is, and how it reconciles against network dashboards.
Impression-level first, aggregated second
Five core metrics, each with a fixed definition.
Ambiguous metrics are how revenue arguments start, so each core metric carries one definition, published in the documentation, and the definition travels with every export. If a definition ever changes, the change notice arrives before the change does.
Impressions
Counted at the point of definition you select: served, rendered or measured. The definition is attached to every report, so totals stay comparable across periods and across teams. When you compare us to a network dashboard, the first question is always which counting point each side used, and the answer is stamped on our side of the comparison.
Revenue
Net revenue attributed to the impression that earned it, in your reporting currency. Because attribution is impression-level, revenue sums by any dimension without double counting. Deductions are visible as their own lines, so the path from gross clearing price to net figure is never a mystery.
eCPM
Effective CPM: revenue per thousand impressions for whatever dimension you are viewing, format, country, placement or network. eCPM moves for two very different reasons, price and mix, so reporting lets you hold one fixed while watching the other. The benchmarks report publishes the reference ranges behind ours.
Fill rate
Share of ad requests that returned a billable impression, broken out per demand source so thin demand is visible where it is thin. A global fill number hides the problem; a per-source split shows whether low fill is one weak network or a request-side issue. Fill by country and placement round out the diagnosis.
Win rate
Share of requests a demand source won out of those where it responded, published per source. Win rate paired with bid rate tells you whether a network is losing on price or dropping out of the auction entirely, different problems with different fixes. It is a diagnostic, and it behaves like one.
Cut the data the way you run the business.
Every metric is available across a common set of dimensions, in the dashboard, through the API and in scheduled exports, so the version your analyst pulls is the version your dashboard shows.
| Dimension | What it answers | Available in |
|---|---|---|
| App | Which application earns what | Dashboard, API, exports |
| Placement | Which ad slot earns what | Dashboard, API, exports |
| Format | Rewarded versus interstitial versus banner and so on | Dashboard, API, exports |
| Country | Where the impression happened | Dashboard, API, exports |
| Demand source | Which network or DSP won | Dashboard, API, exports |
| Bidding vs waterfall | Revenue separated by decision path, per network | Dashboard, API |
| Time | Hourly and daily granularity with stated timezone | Dashboard, API, exports |
LTV views
Ad revenue joins to user cohorts through an MMP integration where supported, so retention and lifetime value can be read against monetization per cohort. The join happens on your side with your MMP identity keys, and the export carries the identifiers that make it possible. Roas-by-cohort stops being a quarterly estimate.
Raw export
Impression-level revenue is exportable for LTV analysis where your MMP and privacy settings allow it, through the API and scheduled exports. Every row carries the placement, demand source and clearing context behind the figure. This is the dataset your data team asks for in the first meeting.
Server to server
Configurable events, including impression and revenue markers, forward over S2S to endpoints you define, with signed payloads and delivery logs. Postbacks fire per event or aggregated per interval, whichever your ingestion prefers. When a downstream system misses data, the delivery log says which events and why.
Integration health
Placement configuration, consent flag state and delivery per integration are tracked alongside revenue. A broken integration surfaces as a health finding with its cause attached, so configuration fixes happen the same day. The revenue chart never has to be the place you learn about it.
A reporting surface your data team can build on.
Access and delivery
Endpoints
REST endpoints for report queries, scheduled exports and account metadata. Authentication uses scoped keys created in the dashboard, with the scope visible on the key so access reviews take minutes. Key rotation is self-service.
Rate limits
Limits are published per key, and responses carry headers reporting the remaining budget, so integrations degrade predictably. A pipeline that approaches its limit knows before it hits it. Quota increases go through support on a published path.
Formats and freshness
CSV and JSON exports, scheduled to storage you control or pulled on demand. The freshness window per dataset is published in the documentation: intraday data lands with a fixed delay, and financial data finalizes on the settlement calendar. Retention windows are listed alongside them.
Reconciliation
A discrepancy guide explains how our numbers relate to network dashboards, which definition differences cause which gaps, and what gap size is normal for each major network type. Support investigations start from the logged decisions, so reconciliation is evidence-led rather than negotiated.
Reporting as the basis of payment
The metrics in this system are the same metrics on your invoice. Definitions do not move between reporting and settlement, and when a definition changes, you hear about it with a transition window before anything moves.
Reporting in practice.
Intraday reporting lands with a fixed delay and financial figures finalize on the settlement calendar, with the exact windows documented per dataset next to the definitions. Because the windows are published rather than discovered, a pipeline can be built against them from day one.
Yes, at aggregate level by demand source, and at impression level through the raw export where your privacy configuration and MMP setup allow it. The impression-level record includes the winning source, the clearing price and the losing bids.
Yes. The split is available per network and per placement, so the unified auction earns its keep in public: what bidding contributed sits next to what the sequenced fallback earned, and the comparison updates continuously.
Each account sets its reporting timezone, and the setting is stamped on every export so two teams never argue about which day an impression belonged to. Hourly granularity follows the same timezone, and the choice is documented in the API responses.
Networks count by their own definitions, so some gap is structural. The discrepancy guide maps each common cause to the gap shape it produces; if a gap falls outside the normal range, support investigates with the logged auction decisions rather than a summary spreadsheet.
Aggregate retention follows the long window published for it, while raw impression-level records follow the shorter window documented for that dataset. Scheduled exports exist precisely for this: anything you need beyond the window lands in your own storage, on your schedule, before it ages out.
Data that matches the invoice.
API keys and scheduled exports are provisioned with your account. Bring your BI stack, and the data will meet it.
Dashboard · REST API · S2S postbacks · scheduled exports