Your campaign dashboard says 8,400 installs. The ad network says 9,100. Your warehouse records 7,900 first opens, and finance trusts none of them. This is the problem behind most searches for branch metrics: not a lack of numbers, but uncertainty about what each number represents and which one should guide the next budget decision.
The fix is to treat Branch reporting as a measurement system, not a scoreboard. Define the event, attribution rule, time basis, and source behind every KPI before comparing it with another platform. This guide gives mobile growth, product, and analytics teams a practical scorecard and a repeatable reconciliation process.
What are Branch metrics?
Branch metrics are the traffic, acquisition, engagement, conversion, revenue, and attribution measures reported by Branch across paid, owned, and earned mobile journeys. Core measures include impressions, clicks, installs, opens, reinstalls, conversion events, revenue, and calculated rates such as click-to-install; their meaning depends on event instrumentation, deduplication, attribution windows, and report filters. Branch operates as a mobile measurement partner as well as a deep-linking platform.
The term can also refer to Branch Metrics, the former company name behind Branch. In a reporting context, however, teams usually want to understand the performance values inside Branch dashboards, exports, and APIs.
Branch's analytics glossary makes several distinctions that matter immediately:
- An install is the first app open after the app is downloaded to a device. It is not necessarily the same thing as an app-store download.
- An open is an app launch after the initial install.
- A reinstall is the first open after a previously removed app is downloaded again.
- A unique metric deduplicates repeated actions at the user level. Total clicks and unique clicks therefore answer different questions.
- Click-to-install (CTI) is installs divided by clicks. Click-through rate and click-to-open rate use different denominators and should not be substituted for CTI.
These definitions explain why two platforms can be internally correct and still disagree. Google, for example, documents that Google Play install reporting counts downloads while third-party measurement commonly counts first opens; it also notes differences in deduplication, time zones, conversion dates, and processing delays in its app attribution discrepancy guidance.
A practical Branch metrics scorecard
A useful scorecard follows the user journey from exposure to durable value. It does not promote every available column to KPI status.
| Journey stage | Primary metrics | Diagnostic metrics | Decision supported |
|---|---|---|---|
| Exposure | Impressions, unique impressions | View-through conversions, blocked impressions | Whether reach is producing qualified activity |
| Response | Clicks, unique clicks, CTR | Click-to-open, link routing failures | Whether creative and routing earn action |
| Acquisition | Installs, reinstalls, CTI | Organic share, paid share, cost per install | Which sources acquire new users efficiently |
| Activation | Opens, registrations, trial starts | Install-to-activation rate, time to activate | Whether acquired users reach initial value |
| Monetization | Purchases, subscriptions, revenue | Purchase rate, average revenue, ROAS | Whether campaigns create economic value |
| Retention | Returning users, cohort retention, LTV | Re-engagement opens, repeat purchases | Whether acquisition quality lasts |
Traffic and routing metrics
Impressions and clicks describe the top of the measured path. They are valuable for checking delivery and link behavior, but neither proves that a user reached the intended app content. Compare total and unique clicks to identify repeated activity, then segment by channel, campaign, platform, operating system, and link when diagnosing an outlier.
Clicks also need context. A low CTI can reflect weak audience quality, but it can also point to a store handoff, fallback, platform-association, or deferred-routing problem. Before cutting spend, run the link on fresh-install and returning-user paths with the same campaign parameters. A structured deferred deep-link testing workflow helps separate media problems from routing defects.
Acquisition metrics
Installs are the standard acquisition outcome, but the operational definition is first open. That means an app-store download that never launches will appear in store reporting but not as an MMP install. Reinstalls should remain separate because they represent returning devices rather than net-new acquisition.
Use CTI as a funnel diagnostic, not a universal benchmark. Its formula is simple:
CTI = attributed installs / measured clicks × 100
The numerator and denominator still need aligned filters. If clicks include web traffic that cannot become an app install, or installs include view-through credit while the click report does not, the rate will tell a misleading story.
Engagement, conversion, and revenue metrics
The best acquisition metric is usually a downstream event tied to the product's value moment: registration for a fintech app, first stream for an OTT app, completed order for commerce, or tutorial completion for a game. Branch supports standard commerce, content, and lifecycle events plus custom events, according to its event-tracking documentation.
Prefer standard events when they accurately describe the action, then define the required properties and identity rules in a tracking plan. Branch notes that revenue is aggregated in reporting when it is tracked on a PURCHASE event. If one client sends purchase value while another sends only a custom event, the dashboard can understate revenue even when both applications appear to log a conversion.
Revenue alone also misses quality. Add activation, retention, or app LTV by acquisition cohort so a cheap campaign with weak repeat behavior does not outrank a more durable source.
How Branch attribution shapes the metrics you see
Branch metrics are event counts after measurement rules have been applied. Those rules determine whether an event is attributed, which touchpoint receives credit, and when the result appears.
Touchpoints, claims, and deduplication
Branch's cross-platform attribution overview describes last-touch attribution as its default approach for choosing among eligible touchpoints, while its broader product also supports journey and funnel analysis. For self-attributing networks, the mechanics differ from ordinary click streams: Branch's Meta Ads FAQ explains that Meta claims eligible events, after which Branch compares those claims with other networks and owned sources and deduplicates attribution.
This creates three legitimate views:
- The ad network reports conversions it claims under its own rules.
- Branch reports the winning attributed source after cross-channel arbitration.
- Your product or warehouse reports observed events, often without marketing credit.
Do not force these views to match before deciding which question you are asking. Network data helps optimize delivery inside that network. Branch data supports cross-channel budget allocation. First-party event data confirms product and financial outcomes.
Attribution windows
An attribution window is the maximum eligible time between a touch and a later event. Branch's current attribution configuration reference lists separate defaults for click-to-session, click-to-install, click-to-conversion, impression-based events, deep linking duration, and re-engagement inactivity. These settings can differ by organization, app, or ad partner.
Changing a window changes future attribution, not the historical record. Branch's attribution-window guide explicitly says new settings apply to future attributions. Record every change with its effective timestamp; otherwise a trend break can look like campaign performance when it is really configuration drift.
Total, unique, organic, and paid activity
Total events answer “how many times did this happen?” Unique events answer “how many users did it?” Paid attributed events identify a winning paid source. Organic or unattributed events are not necessarily SEO wins or tracking failures; they are events for which no eligible marketing touchpoint received credit under the active rules.
Always label these dimensions in reports. “Purchases” is incomplete; “unique attributed purchase users by conversion date, app, and campaign” is a metric someone else can reproduce.
SKAN and deterministic reporting are different datasets
Apple's privacy-preserving attribution data should not be blended casually with device-level attribution. Branch's SKAdNetwork reporting guide describes reports based on postbacks, conversion values, download types, campaign identifiers, and available source-app detail. Those dimensions and delays differ from deterministic event reporting.
Keep SKAN and non-SKAN rows distinct through ingestion. Combine them only in a documented executive view that explains overlap handling, date logic, and modeled values.
Build a dashboard that supports decisions
Start with a question, then choose the smallest set of metrics that answers it. “Which campaigns should receive next week's budget?” needs spend, attributed installs, a value event, revenue, and perhaps 7-day retention. It does not need every event in the ontology.
Branch's new Analysis dashboards overview organizes reporting around channel performance, paid activity, SKAN, short links, cohorts, funnels, and other use cases. The documentation warns that the new and legacy experiences do not have a one-to-one relationship, so migration QA should compare metric definitions and filters rather than dashboard names.
Use a three-layer reporting model:
- Executive layer: spend, activated users, revenue, ROAS, and retention trend.
- Channel layer: impressions, clicks, installs, CTI, cost, activation, and revenue by partner and campaign.
- Diagnostic layer: app version, OS, country, link, event name, attribution type, touch date, conversion date, and identity status.
Save a canonical view for recurring reviews. Branch's dashboard report guide supports filters, comparison dimensions, configurable columns, granularity, saved views, and CSV exports. It also warns that some large report requests initially show preview data, so confirm that a report is complete before treating it as a full-period total.
How to reconcile Branch metrics step by step
Reconciliation is not “make the totals equal.” It is the process of explaining the remaining difference after comparable populations and rules are aligned.
1. Write a metric contract
For every KPI, document the event name, human definition, counting method, source, timestamp, timezone, currency, attribution model, attribution window, identity key, and exclusion rules. Assign an owner in analytics or growth operations.
A contract for installs might read: “First app open observed by Branch, unique at device level, attributed by Branch's eligible last touch, grouped by conversion timestamp in UTC, excluding test devices.” The warehouse version may use an account ID and local timezone, which immediately explains why it should not be expected to match row for row.
2. Freeze the comparison scope
Choose one app, platform, campaign ID, event, timezone, and narrow date range. Compare IDs rather than campaign names wherever possible. Branch notes that campaigns sharing the same name can be combined in the dashboard even though campaign IDs remain distinct in the backend and Query API.
Avoid beginning with an all-channel monthly total. A seven-day slice for one stable campaign is much easier to reason about, while still exposing systematic gaps.
3. Align touch time and conversion time
Confirm whether each platform groups conversions by the date of the ad interaction or the date of the conversion. Google documents that its Ads reporting commonly assigns conversions to the day of the ad interaction, while third-party reports often use the conversion-event date.
To compare a seven-day click cohort with a 30-day conversion window, allow the downstream report to mature through the end of that window. Comparing both systems on the same calendar end date truncates late conversions and creates a false gap.
4. Align attribution and counting rules
Match click-through and view-through windows where a like-for-like comparison is required. Check whether the network includes modeled conversions, reinstalls, cross-device activity, or view-through claims. Check whether Branch is showing total events, unique users, paid attribution, or all activity.
Also verify currency conversion and revenue aggregation. A count can match while value differs because refunds, taxes, exchange rates, duplicate purchase IDs, or missing revenue properties are handled differently.
5. Validate instrumentation from the app outward
Trigger a test click, install, open, and value event. Confirm the deep link parameters at app launch, the event in live or raw data, the expected identity, and the final dashboard row. Repeat on supported platforms and on fresh-install, reinstall, and returning-user states.
If an event appears in the app analytics tool but not Branch, inspect SDK initialization, consent timing, event mapping, payload properties, app version adoption, and server-to-server identifiers. If it appears in Branch but not the warehouse, inspect export freshness, schema parsing, filters, and late-arriving data.
6. Reconcile aggregate and raw records
Use aggregate reporting to locate the gap, then raw exports to explain it. Branch's API overview separates real-time aggregate Query data from delayed device-level daily, custom, and scheduled exports, each with different availability and export windows. Choose the interface that matches the investigation and retain the extraction timestamp.
Join records with the most stable available event, transaction, campaign, and user/device keys. Classify unmatched rows rather than deleting them: late arrival, duplicate, missing identifier, outside window, organic, rejected claim, reinstall, test traffic, or unknown.
For teams that mainly need reliable deep linking, deferred routing, install attribution, and accessible raw-data workflows, Deeplinkly provides lightweight SDKs, webhooks, APIs, and CSV export with transparent usage-based tiers. That narrower, developer-first setup can reduce reporting overhead when a broad enterprise measurement suite is more than the team needs.
7. Set a tolerance and monitor the residual
After alignment, calculate both an absolute and relative difference:
difference = source A − source B
difference rate = (source A − source B) / source B × 100
Set tolerances by event and platform using your own stable baseline, not a universal “acceptable discrepancy” percentage. Alert on sustained changes, not every daily fluctuation. Investigation notes should record the cause, owner, corrective action, and whether historical data will or will not restate.
Common Branch reporting discrepancies
| Pattern | Likely causes | First check |
|---|---|---|
| Network installs exceed Branch installs | Self-attribution claims, longer windows, modeled conversions, cross-channel deduplication | Align one campaign's windows and attribution basis |
| Store downloads exceed Branch installs | Download versus first-open definition, users never launching, delayed SDK initialization | Compare first opens, not download requests |
| Branch events exceed warehouse events | Export lag, ingestion failures, warehouse filters, identity joins | Trace one raw event through the pipeline |
| Warehouse purchases exceed Branch purchases | Event not sent, consent timing, old app versions, server payload gaps | Audit event coverage by app version and platform |
| Revenue differs but purchases match | Currency, missing value fields, refunds, tax, duplicate transaction IDs | Compare raw transaction IDs and amounts |
| Dashboard changes after a filter or migration | Total versus unique, preview data, new dashboard semantics, saved-view drift | Rebuild the view from a metric contract |
| A sudden organic spike appears | Paid integration failure, expired credentials, changed windows, missing campaign parameters | Check partner status and recent config changes |
A weekly operating cadence for Branch metrics
Give every reporting horizon a job:
- Daily: monitor event delivery, partner health, spend freshness, routing failures, and major anomalies.
- Weekly: evaluate campaign CTI, activation, revenue, and early retention; review discrepancies above tolerance.
- Monthly: reconcile finance-grade revenue, mature cohort outcomes, attribution changes, and schema coverage.
- Quarterly: audit event taxonomy, permissions, data retention, dashboards, attribution assumptions, and whether the measurement platform still fits the team's needs.
Keep a change log beside the dashboard. Include campaign launches, SDK releases, consent changes, attribution-window edits, partner credential updates, and warehouse transformations. When a line moves, this log often provides a faster first hypothesis than another round of filtering.
Frequently asked questions
What is Branch Metrics used for?
Branch is used for deep linking and mobile attribution across paid, owned, and earned channels. Teams use its metrics to connect impressions and clicks with installs, opens, conversion events, revenue, and longer-term campaign outcomes.
How does Branch attribution work?
Branch evaluates eligible marketing touchpoints and attributes an install, open, or downstream event according to the configured model and windows. For competing network claims, it can deduplicate across sources so one winning touchpoint receives attribution in the cross-channel view.
What is the difference between an install and an open in Branch?
An install is the first app open after download on a device. An open is a later app launch after that initial install, while a reinstall is the first open after a previously removed app is downloaded again.
Why do Branch and ad-network metrics not match?
Common reasons include different attribution windows, self-attribution, cross-channel deduplication, view-through or modeled conversions, time zones, touch-date versus conversion-date reporting, reinstall rules, and processing delays. Compare one campaign and event after aligning those rules before treating the gap as an error.
How do I export Branch metrics?
Dashboard tables can be exported as CSV, while Branch provides aggregate query and export APIs plus device-level daily, custom, and scheduled exports. Availability, freshness, retention, and package access differ by interface, so select the export based on whether you need a quick campaign total or raw records for reconciliation.
Which Branch metrics should executives see?
Executives usually need a compact path from spend to value: activated users, revenue or another value event, ROAS, retention, and a trend or target. Clicks and installs belong in diagnostic views unless acquisition itself is the business outcome.
Conclusion
Branch metrics become decision-ready when every number carries its definition, attribution rule, time basis, and source. Start with a journey-based scorecard, separate network claims from cross-channel attribution and first-party outcomes, and reconcile narrow cohorts before rolling results into an executive view.
If unexplained gaps persist, the decision is not simply whether one dashboard is “right.” Decide whether to repair instrumentation, standardize reporting contracts, or simplify the measurement stack around the events and exports your team can consistently verify. Then choose the platform and operating process that make that evidence easiest to reproduce.