A mobile app marketing dashboard should answer a decision, not display every metric the team can export. The useful dashboard reconciles ad delivery, store acquisition, product behavior and realized value at a defined maturity point, then records whether the team will act, hold, repair measurement or stop. A wall of current-period CPI, installs, trials and revenue cannot do that when each number uses a different event, clock, attribution rule or population.
This guide is for app founders, heads of growth, UA leads, product marketers, analysts and finance partners who need a recurring report for an internal team or agency relationship. It is not a software comparison or a universal KPI template. The reporting system should be designed around the decisions your app can responsibly make with the evidence available.
What should a mobile app marketing dashboard include?
A decision-ready dashboard needs five layers:
Delivery: spend, impressions, taps or clicks, and the controls that changed.
Store acquisition: first-time downloads, redownloads or returning acquisitions, store-page traffic and conversion definitions.
Product quality: first open, qualified activation, retention and the product events that define useful behavior.
Realized value: verified purchases, subscriptions, renewals, refunds, advertising contribution or another finance-approved value measure.
Decision record: the question, evidence maturity, discrepancy notes, owner, action and next review date.
The first four layers describe the system. The fifth governs it. Without a decision record, teams can observe the same movement every week without deciding whether to change budget, repair an event, replace a creative hypothesis or wait for a cohort to mature.
Start with a reporting contract, not a chart
Before choosing a visualization, write one contract for every metric that may influence action. A useful Mobile Reporting Contract has nine fields:
Field Question it must answer Example --- --- --- Decision What can this metric change? Hold or increase one campaign budget Owner Who approves the definition and action? UA lead with finance review Source Which system supplies the value? Apple Ads, Google Ads, store, MMP, product warehouse or ledger Denominator What exactly is being counted? First-time download, first open, activated account or paying cohort Event time When is the event assigned? Ad interaction date, install date, event date or transaction date Freshness How late can the source arrive? Intraday estimate, daily close or month-end final Maturity How old must a cohort be? Seven, 30 or 90 days since first open Tolerance What difference triggers investigation? A documented absolute or relative boundary based on historical reliability Action What happens if the rule passes or fails? Act, hold, repair or stop
The example fields are illustrative, not defaults. A seven-day activation window may fit one app and be meaningless for another. The contract forces the team to explain why a metric exists and prevents a chart label such as “installs” from hiding several incompatible definitions.
Platform, store and product reports are not interchangeable
The systems disagree because they observe different events and apply different rules. That disagreement is not automatically an error.
Apple Ads currently defines tap-through installs as new downloads and redownloads attributed within a 30-day tap window; its total-install reporting can also include view-through installs counted under a separate one-day view window. The same reporting documentation distinguishes new downloads from redownloads and provides tap-through and total CPA definitions (Apple Ads reporting definitions). A dashboard that labels this column only “iOS installs” removes information needed to interpret it.
App Store Connect Analytics uses different acquisition concepts. It reports first-time downloads, redownloads and total downloads, and its acquisition views can attribute sales, usage and subscription data to the recorded download source. Apple also states that a manual redownload can reset that recorded source for subsequent activity (App Store Connect acquisition). Its usage metrics have separate availability conditions: Apple says usage totals are based on users who opt in to share data and require at least five active devices in the selected range (App Store Connect metric definitions). Store data can therefore answer a store question without matching an ad platform or product warehouse exactly.
Google Play also separates users, devices and interaction stages. Current Play Console guidance distinguishes user acquisitions from device acquisitions and first opens, and it notes that user metrics count unique users while device metrics count unique devices (Google Play growth overview). Google’s store-listing reporting changed in 2026 to emphasize unique intent clicks for listing-performance views, while completed acquisitions remain available elsewhere in Play Console (Google Play acquisition reporting). A legacy dashboard that treats a current store-listing click label as the former acquisition metric can manufacture a trend break.
The practical rule is simple: keep source-native names in the data dictionary. Create a normalized business metric only after documenting how it is derived and which source remains authoritative for its own domain.
Assign every source a job
A dashboard becomes more trustworthy when every source has a bounded decision right. The following matrix is a planning model, not a claim that every app uses the same stack.
Source layer Best suited to answer Should not decide alone --- --- --- Ad platform Delivery, spend, auction controls and attributed outcomes under that platform’s settings Cross-channel incrementality or realized business value App store Store exposure, downloads or acquisitions, listing behavior and store-reported proceeds or subscriptions Product activation quality across all users MMP or attribution layer Operational campaign credit under configured integration and windows Whether an attributed action was caused by advertising Product analytics or warehouse Qualified activation, feature use, retention and first-party cohort behavior Final recognized revenue unless it is reconciled to transactions Subscription or commerce system Entitlement and transaction lifecycle Media causality Finance ledger Realized revenue, refunds, fees, contribution and approved reporting periods Campaign optimization in real time Experiment Incremental effect for the tested population and design Permanent truth outside the tested conditions
This page focuses on the report that connects those jobs. The broader mobile app attribution framework owns the architecture and privacy layers behind them.
Reconcile definitions before totals
When two systems show different totals, do not begin by forcing one number to equal the other. Reconcile the contract in this order:
Event: Are both systems counting the same action? A store download and an app first open are different events.
Population: Are they counting users, devices, accounts or events? Returning users may be included in one source and excluded in another.
Eligibility: Do consent, privacy thresholds, fraud filters or platform rules exclude some observations?
Time: Are the reports using interaction time, install time, conversion time or transaction time? Are time zones aligned?
Attribution: Are click, view, re-engagement and reinstall windows configured differently?
Value: Are currency, taxes, platform fees, refunds and recognition rules comparable?
Freshness: Has each source completed the same close, including late events and postbacks?
Google Ads explicitly documents that app-conversion discrepancies can arise from different imported sources, settings, windows, reinstall handling, session definitions, filtering, aggregation and missing pings. It also warns against comparing Google Play installs with first opens because download and first-open events occur at different points (Google Ads app-conversion comparison). That is a useful troubleshooting inventory. It is not an instruction to make every external system equal Google Ads.
Record the cause of an accepted difference. “Expected gap: store download versus first open” is more useful than a hidden adjustment factor. If the cause remains unknown, mark the metric as unresolved and restrict the decision it may authorize.
Build five dashboard layers
1. Executive decision layer
The first view should fit the decision meeting, not every analyst question. Show the current decision, eligible spend boundary, one primary outcome, cohort maturity, realized or forecast value clearly labeled, material discrepancies and the proposed action.
A useful executive row might read: “Google App campaign cohort installed September 1–7; 30-day activation complete; subscription contribution remains 60-day immature; spend held; product activation is stable; finance value review due November 8.” This row is less visually impressive than twelve charts and far more difficult to misread.
2. Acquisition layer
Show source-native delivery and acquisition metrics with their windows. Separate first-time acquisition from redownload or re-engagement where the source permits. Keep attributed counts beside—not merged with—store and first-party acquisition counts.
If CPI or CPA governs an operational decision, its event contract belongs in the report. The CPI versus CPA framework explains when an install, activation or deeper event is mature and reliable enough to authorize spend. The dashboard should implement that choice rather than reopen it every reporting cycle.
3. Store-to-product layer
Connect store exposure to the first useful in-app event without pretending the platforms share one funnel. Typical rows may include unique store impressions or listing visits, source-defined downloads or acquisitions, first opens, completed onboarding and qualified activation.
The bridge needs an explicit population and time basis. If store conversion improves while first-open-to-activation falls, the team has a different decision from one in which both improve. The reporting layer must preserve that divergence.
4. Cohort value layer
Align acquisition cohorts by age before comparing value. A campaign launched three days ago should not be compared on cumulative subscription contribution with a 90-day cohort. Report observed value at matched maturity, forecasts separately, and realized finance values once the close is available.
The mobile app LTV guide owns value estimation, refunds, survival and cohort maturity. In the dashboard, label which values are observed, forecast or final. Never let a forecast silently replace an actual.
5. Action and audit layer
Every reporting cycle should finish with a compact decision log:
decision and scope;
evidence cutoff and cohort maturity;
accepted discrepancies and unresolved defects;
action: Act, Hold, Repair or Stop;
owner and deadline;
next evidence required;
configuration changes made after the cutoff.
This is the audit trail that explains why the team changed spend. It also lets a new employee, finance reviewer or agency partner reconstruct the decision without relying on meeting memory.
Use a close calendar, not one refresh timestamp
A live dashboard can still combine data at incompatible maturity. Define a close calendar for each layer.
Daily operational close: delivery, spend, pacing, broken links, event receipt and severe anomalies.
Weekly decision close: creative, audience, campaign and early funnel changes that have enough observations under the agreed contract.
Cohort close: activation, retention, trial conversion, purchase or subscription outcomes at matched cohort age.
Finance close: recognized revenue, refunds, fees and contribution after the accounting source is ready.
Do not infer that weekly is universally correct. Sparse apps may need a longer interval; high-volume operations may need daily controls. The point is to state which decisions are allowed at each close.
GA4 illustrates why scope matters as much as timing. Its acquisition dimensions can be user-scoped, session-scoped or event-scoped; “First user” dimensions describe the source associated with acquisition of a new user, while session dimensions describe the source of a session (GA4 traffic-source scopes). Mixing those rows under one “source” column creates a semantic discrepancy even before latency enters the picture.
A fictional reconciliation example
The following example is invented to show method. It is not a benchmark, forecast or Sharply Labs client result.
An app spends $40,000 across a campaign during September. At the weekly operational close, the ad platform reports 16,800 attributed installs. The store reports 15,900 first-time downloads plus 1,600 redownloads for the relevant source grouping. Product analytics records 15,100 first opens and 6,040 qualified activations. At day 30, the finance-aligned subscription ledger records 755 new paid subscribers from the eligible acquisition cohort and $21,500 of observed contribution after defined fees and refunds.
The team should not select 16,800, 15,900, 17,500 or 15,100 as the universally “correct install number.” It records four facts:
ad-attributed installs under the platform’s rules: 16,800;
store first-time downloads: 15,900;
store total first-time plus redownloads: 17,500;
observed first opens: 15,100.
The report then explains the decision denominator. If the question is operational platform CPI, it uses the platform’s attributed installs and labels the window. If the question is new-user activation, it uses eligible first-time acquisition cohorts and verified product events. If the question is realized subscription contribution, it uses the transaction cohort and finance rules.
Suppose the platform number rises 20% while first-time downloads and first opens remain flat. The decision is not automatically to scale. The report enters Repair until the team resolves whether the shift came from view-through credit, redownload mix, a window change, delayed store data or an integration defect. If the sources are stable but 30-day contribution is still immature, it enters Hold. If definitions and maturity pass and the agreed economic gate is met, it may enter Act. If the campaign attracts users who consistently fail the qualified-value gate, it enters Stop.
Test an agency dashboard before accepting the reporting scope
A polished dashboard is not proof of a sound reporting service. Before signing or renewing an engagement, ask the agency to demonstrate the contract with one historical decision.
The acceptance test should establish:
whether your company owns the ad, store, analytics and reporting accounts;
who defines every business event and who can change it;
whether source-native values remain visible;
how first-time, returning and re-engaged users are separated;
which time zone, currency, windows and cohort dates apply;
how late events, modeled data, refunds and deleted users are handled;
which value is observed, forecast or finance-final;
how discrepancies are logged and escalated;
which actions the agency may make without approval;
what data, logic and history remain with the company at exit.
The commercial bundle matters. The mobile app marketing agency pricing guide explains how reporting, measurement work, account ownership and exit terms should be normalized before fees are compared. A reporting screenshot is not an acceptance criterion; a reproducible source map, calculation and decision record is.
Warning signs in a mobile app marketing report
Pause the decision when the report:
labels several different events “installs”;
combines first-time acquisition and returning users without a buyer reason;
reports current-period revenue against current-period spend without a cohort rule;
presents platform-attributed conversions as incremental outcomes;
changes attribution windows or key events without a dated record;
hides source-native totals behind a blended score;
compares cohorts at different ages;
treats modeled, forecast and realized values as equivalent;
uses a store conversion change as proof that paid media caused the result;
offers no action, owner or next evidence requirement.
A discrepancy is not itself a warning sign. An unexplained discrepancy that can still approve spend is.
What the dashboard cannot prove
A reconciled report improves decision discipline; it does not eliminate uncertainty. Privacy choices and thresholds can reduce observed data. Attribution windows can assign credit without establishing causality. Store metrics can change definition. Product events can break after a release. Currency conversion, tax, fees, refunds and recognition timing can move realized value. Sparse cohorts can remain noisy even when instrumentation is correct.
A holdout or another experiment may answer a causal question that reporting cannot. Even then, the experiment applies to its design, population and period. Do not turn one measured lift estimate into a permanent channel multiplier.
Official platform documentation establishes how a vendor defines its own metric at the time reviewed. It does not establish which platform is commercially superior or which dashboard is universally correct. Keep the accessed date and the limitation beside each time-sensitive rule.
Get the reporting decision reviewed
For established app teams running paid acquisition, Sharply Labs offers a bounded mobile reporting and measurement review. We examine the source map, event definitions, acquisition populations, attribution windows, data freshness, cohort maturity, value reconciliation and current decision log. You receive a prioritized reporting contract showing what can authorize action, what needs repair and what evidence should be collected next.
This is not a promise of lower CPI or CPA, higher ROAS, revenue, incrementality, rankings or scale. It is a scoped decision and measurement deliverable.
Explore our work with mobile app growth teams, review our broader growth services, or discuss a reporting decision.