The product question for a SaaS companion app is not "who uses it?" but "is it used?" Treat the mobile surface as its own product and measure the session-level funnel from install to first meaningful action. Cross-platform identity belongs in the application database, not in analytics.
š± What Counts as a Companion App
Companion apps come in a few common shapes:
- ā¢Read-only dashboards ā KPIs, alerts, status pages.
- ā¢Notification + approval handlers ā Approve a deploy, sign off on a request, ack an incident.
- ā¢On-call / oncall-adjacent ā Alert routing, paging, escalation.
- ā¢Lightweight authoring ā Capture, comment, quick-edit; the heavy lifting is on the web.
All of them share one property: the user already has an account. Acquisition is not the question. Retention and depth are.
šÆ The Wrong Question to Ask
"Which of our customers use the mobile app?" is a tempting question because it sounds like account intelligence. But pursuing it forces you to:
- ā¢Send a persistent user ID to your analytics pipeline.
- ā¢Reconcile mobile sessions with web sessions for the same person.
- ā¢Treat your analytics database as a partial copy of your CRM.
The right question is "Is the surface adopted?". That answer comes from session counts, depth, and the meaningful-action funnel ā none of which need a user ID.
š” If you really need per-account data
Put a "last_mobile_login_at" column on the user record in your application database. You already have an authenticated context there; you do not need to leak that identity into your analytics pipeline.
šļø Companion App Event Taxonomy
| Stage | Events |
|---|---|
| Entry | app_opened, push_notification_opened, deep_link_opened |
| Auth | login_started, login_succeeded, login_failed, sso_redirected |
| Read | dashboard_viewed, alert_viewed, document_viewed |
| Act (the meaningful actions) | approval_granted, alert_acknowledged, comment_posted, item_created |
| Health | api_request_failed, offline_mode_entered, crash_recovered |
š¤ļø The First-Time-Use Funnel
Companion apps live or die on first session. If a user installs, opens, fails to log in, and uninstalls ā your rollout is failing silently.
The funnel
app_opened (first session) ā login_succeeded ā dashboard_viewed ā first_meaningful_action
"first_meaningful_action" is product-specific: an approval, an ack, a comment, a doc view. Pick the one your team agrees signals genuine adoption, then track its first occurrence in a session as first_meaningful_action on the SDK side.
š¢ Workspace-Level Adoption Without User IDs
Most B2B SaaS products live inside workspaces (orgs, teams, accounts). When stakeholders ask about adoption, they almost always mean workspace-level, not user-level. You do not need a personal identifier for that ā but you may want a workspace tag.
A common pattern: use a separate Respectlytics app per environment / tier, not per workspace. Track aggregate session counts on the dashboard. If you genuinely need per-workspace breakdowns, the cleanest path is to compute them from your application database (where workspace context is authoritative), not from analytics.
š Cross-Platform Measurement
Web and mobile are different sessions in different products. That is fine. The question to answer is whether the mobile companion is helping the overall product, which you can read from:
- ā¢Mobile session share ā sessions on mobile / total sessions across surfaces.
- ā¢Mobile event share ā Are key actions migrating to mobile, or only catching up on read-only views?
- ā¢Push response rate ā sessions starting from
push_notification_openedas a share of total push sends (push send count from your notification platform).
š Companion KPIs
| KPI | Definition |
|---|---|
| First-session activation | share of first sessions that reach first_meaningful_action |
| Approval funnel | push_opened ā approval_granted |
| Median session length | expect short ā companion sessions are 30sā2min |
| Crash-free session rate | see combining analytics with crash reporting |
š” Why session-based fits B2B
B2B teams care about adoption signal, not psychographics. Session counts, funnel completion, and approval-flow timing answer 90% of the product questions without needing a user ID. The other 10% lives in your application database, where it always did.
ā Frequently Asked Questions
What is a SaaS mobile companion app?
A smaller, mobile-first surface for a SaaS product whose primary experience is on the web. Common patterns: read-only dashboards, push handlers, approval flows, on-call alerts, lightweight authoring.
How do you measure companion app adoption without correlating to user accounts?
Treat the companion as its own product surface. Measure session counts, depth, and the funnel from first launch to a meaningful action. You do not need to tie sessions to specific account users.
What events should a B2B mobile app track?
app_opened, push_notification_opened, dashboard_viewed, alert_acknowledged, approval_granted, item_created, login_succeeded, deep_link_opened, plus product-specific verbs.
How do you tell which SaaS users use the mobile app?
You usually do not need to. If you genuinely need per-user adoption data, capture it in your application database, not in analytics.
Can you do funnel analysis on a B2B mobile app?
Yes. Sessions in companion apps are short and goal-driven, which makes session-level funnels especially clean.
Legal Disclaimer: This information is provided for educational purposes and does not constitute legal advice. Consult your legal team to determine the requirements that apply to your specific situation.
Related Reading
- Analytics Events Every App Should Track
- Session IDs Are Not User IDs
- Retail & E-commerce App Analytics
- Government & Public Sector App Analytics ā Citizen-facing companion of this guide
- Session Analytics Feature