Skip to main content

​
Why can’t I switch my Airbridge data source between Actuals and Active Users?

Each Airbridge data source is locked to one report type at creation: Actuals (ad performance and attribution events) or Active Users (engagement and revenue aggregates). The two report types use different Airbridge APIs and different metric and breakdown catalogs, so the choice cannot be changed in place once the data source exists. To report on the other report type, create a second Airbridge data source for the same app and select the other type during setup. See How to connect Airbridge to Adriel.
A single query cannot combine Actuals and Active Users fields. A widget that mixes metrics or breakdowns from both report types returns no data, because the two catalogs belong to separate data sources.

​
Why don’t my Airbridge app and web numbers add up?

On Active Users data sources, app and web are tracked as separate metrics with distinct keys — for example, airbridge:active_users_app_au (active users, app) and airbridge:active_users_web_au (active users, web). Airbridge does not merge the two platforms into a combined figure, so an app total and a web total are never rolled up automatically into one number. To see a combined view, place both the app and web variants of a metric on the widget, or build a custom metric that sums them. The per-platform split covers active users, paying users, revenue, ARPU, and ARPPU. For the full list, see the Airbridge data reference.

​
Why did my wide Airbridge date range fail?

Airbridge enforces a maximum reporting period per report and returns an error when a request exceeds it, surfaced in Adriel as a “too much data requested” result (TOO_MUCH_DATA_REQUESTED). The cap varies by report type and by the fields requested, so Adriel does not impose a single fixed limit. If a wide date range fails, narrow it and reload the dashboard. Splitting one very long range into shorter periods, or reducing the number of breakdowns on the query, also keeps each report request within Airbridge’s allowed window.

​
Why does my Airbridge dashboard load more slowly than other connectors?

Airbridge report data is fetched on demand when a dashboard is visited, rather than served from a pre-built snapshot. Each query asks Airbridge to generate a report and then waits for that report to finish before the data returns, so dashboards built on Airbridge can load slightly slower than connectors that read from a cache. This is expected behavior, not a fault. For how the connector sources its data, see the Airbridge data reference. To keep dashboards responsive, keep the number of Airbridge widgets on a single dashboard reasonable and avoid very wide breakdown combinations. Very large or slow reports can occasionally time out; when that happens, narrowing the date range or the breakdowns usually lets the report complete.

​
Why don’t my Airbridge attribution numbers match another tool, especially on iOS?

Attribution-window logic is configured per app inside Airbridge, and the connector reports whatever windows the Airbridge Reports API returns. Two tools set to different attribution windows will report different totals for the same campaign, even when both are reading Airbridge data. On iOS, SKAdNetwork attribution follows Apple’s postback timer rather than arriving in real time. Apple deliberately delays and batches these postbacks, so recent iOS installs and conversions often appear lower at first and fill in over the following days as the postbacks land. Comparisons are most reliable once the recent days have settled.