Deploy App Sensor

Add the Conviva App Sensor to your application to collect clicks, screens, network requests, errors, and crashes automatically — and send your own business events through the same integration.

Updated 2026-10-13 app sensor, sensor, deploy, ingest

Introduction

The Conviva App Sensor is a lightweight library that you embed in your application. Once installed and initialized, it observes the application as people use it and reports what happened — every screen, tap, network call, error, and crash — to Conviva's real-time analytics platform.

The sensor instruments the application's own UI and networking layers, so the majority of what you need arrives without writing tracking code for each button or screen. On top of that, you send your own business events through a single API without mapping them to a predefined schema, and the heavy computation happens server-side.

Three ideas behind the sensor

Auto-collectionClicks, screen views, network requests, errors, crashes, and app lifecycle are collected from the platform itself — not from tracking code you write and maintain per element.
Schema-less custom eventsSend any business event with any shape through one API. No predefined schema to conform to, no reformatting, no new integration per event type.
Remote configurationWhat the sensor collects is tunable from Conviva after you ship. Block noisy events, refine click tracking, and filter network requests without another app release.

What the sensor collects

The sensor reports two things: events as they happen in the application, and the metadata attached to them. Metrics such as page load time, crash rate, rage clicks, and conversion are not computed in your app — Conviva derives them server-side from these events. Review the full list of metrics powered by the events collected by the sensor.

User interactionsTaps and clicks on buttons, links, inputs, checkboxes, radio buttons, and drop-downs, with the attributes that identify the element and the screen hosting it.
NavigationScreen views and page views, deep link and referrer, and app launch, foreground, and background transitions.
Network activityRequests and responses made through the platform's standard networking stacks, including status, headers, and body where size and content type allow.
Errors & crashesUncaught errors and unhandled rejections, fatal crashes with stack traces, and unresponsive-application events.
Device & app contextDevice category, type, brand, manufacturer, model, OS name and version, screen resolution, application name and version, and sensor version.
Your own eventsCustom events with arbitrary payloads, revenue and purchase events, global custom tags, and the user ID that ties app activity to the same person in Video.
Before you start. Every integration needs two values: your Conviva customer key, found under Account Info in Pulse, and an application name that uniquely identifies this app across your platforms. Use your test customer key while integrating and validating, and switch to the production key at launch.

Plan, Integrate, Validate, Activate, Launch Process

Getting started is quick. On a supported platform the integration is an install, an initialization call, and a user ID — and auto-collection starts producing data immediately, without instrumenting a single button.

The five phases exist for the distance between data arriving and data you can build a business metric on. Every app is different — its navigation, its networking, its idea of what a conversion is. These phases are how that difference ends up reflected in clean data: events that fire where you expect and tags that mean the same thing everywhere.

The payoff. Five short phases, one outcome: auto-collection covering the routine, your own events covering what's specific to your business, and both mapped so the metrics in Pulse are something your teams can act on.

Expand a phase for who leads it and what it involves.

PHASE 1

Plan

App qualification

Event strategy

Kick-off

Led by Conviva account team

PHASE 2

Integrate

Install and initialize

Set user ID

Add custom events

Led by your dev team

PHASE 3

Validate

LiveLens

Event coverage

Fix and re-test

Led by your dev / QA team

PHASE 4

Activate

Sensor Remote Control

Semantic Mapper

Metric Builder

Led by you, with Conviva

PHASE 5

Launch

Production key

Release

Support handover

Led by your deployment team

PHASE 1PlanApp qualification · event strategy · kick-off

Led by the Conviva account team, with your architects and developers.

Why this phaseAuto-collection depends on how your app is built. Twenty minutes checking frameworks, WebViews, and element naming up front is what stops you from discovering at validation that half your clicks were never collectable.

Qualify the application

Auto-collection instruments the platform's own UI and networking layers, so a few characteristics of your app decide how much arrives out of the box. Confirm these before integration begins:

  • Frameworks in use. Conviva auto-collects from the standard UI frameworks on each platform. An unusual or in-house framework limits auto-collection and shifts more events to explicit reporting.
  • Element identification. Can buttons and links be uniquely identified by an ID, class, or accessibility identifier? Click data is only as useful as the attributes your elements carry.
  • WebViews and embedded content. A sensor on the native side does not see inside a WebView or iframe. Applications that mix native and Web surfaces usually need the sensor on both, with the client ID shared between them so the session stays whole.
  • Networking stacks. Auto-collection covers the standard clients on each platform. Custom transports, or requests issued by a media player in its own process, are not captured.
  • Where initialization happens. Initialize at app start. A sensor that starts on the third screen has already missed the first two, along with the launch and any early network calls.
  • Local storage lifecycle. The sensor caches queued events and identity locally. Clearing that storage mid-session splits the session.
  • Multiple domains or subdomains. Each one generates its own client ID unless you explicitly share it, which otherwise breaks a single journey into several.

Event and metadata strategy

Auto-collection covers the routine. What it cannot know is what matters to your business — what a conversion is, which screens form a funnel, what a completed order looks like. Agreeing on that up front is the metadata strategy, and it is part of your acceptance criteria.

  • Decide the custom events you need beyond auto-collection, and the payload each carries.
  • Decide the custom tags that should be attached to every event — tenant, environment, subscription tier, experiment group.
  • Agree on the user ID, using a non-PII identifier. Matching it to the Video Sensor's Viewer ID is what lets you follow one person across app and playback.
  • Keep naming uniform across platforms. The same event from iOS, Android, and Web must carry the same name and the same keys, or it cannot be compared.

Kick-off

Kick-off reviews the implementation lifecycle, timelines, and priorities, qualifies each application against the points above, selects the SDK for each one, and signs off the event and metadata strategy.

PHASE 2IntegrateInstall · initialize · user ID · custom events

Led by your application development team, supported by the Conviva account team.

Why this phaseThe install and initialize part is short — often an afternoon. This phase is about the parts only your app knows: your user identity, your business events, your tags.

Pick your platform from Supported Platforms and SDKs and follow the repository documentation for the specifics. Every platform follows the same shape — see Integration Steps.

AI-assisted integration

The Android, iOS, JavaScript, and React Native repositories each ship agent instructions, so you can hand the integration to an AI coding assistant — Cursor, Claude Code, GitHub Copilot, Codex, Gemini CLI, Android Studio AI — and let it read the repository and apply the changes. Point the assistant at the repository for your platform and it will follow the documented steps in order.

Review what the assistant produces before shipping it, particularly the placement of the initialization call and error handling around sensor calls. The repositories include guidance on both.

Tools and resources

  • Conviva GitHub repositories — the SDK for each platform, with installation and integration documentation, sample applications, and agent instructions.
  • LiveLens — for confirming, while you build, that events are arriving and correctly shaped.
  • Pulse — your dashboards. The integrity of the data here follows directly from the quality of the integration.
  • Conviva SSO — one set of credentials for Pulse, LiveLens, Activation, and the Conviva Developer Community.

Reporting beyond auto-collection

These are the things the sensor cannot infer, in rough order of how often they're needed:

  • User ID — set it as soon as the person is identified, and clear it on logout.
  • Page views — on Web, page views are not auto-collected. See the warning below.
  • Custom events — one API, an event name, and a payload of whatever shape you need.
  • Custom tags — global tags applied to every subsequent event for the lifetime of the application, until cleared.
  • Revenue events — order total, transaction ID, and currency are required; tax, shipping, discount, cart size, payment method, and line items are optional. These power the revenue and conversion metrics.
  • Caught errors — uncaught errors are auto-collected; errors you catch and handle yourself are reported explicitly on the platforms that support it.
Page views are never auto-collected on Web. You must call the page view API on every navigation. If you don't, page views and everything derived from them — page counts, perceived page load time, largest contentful paint — will be missing from your dashboards, and cannot be backfilled later.
PHASE 3ValidateSelf-serve — LiveLens, event coverage, payload checks

Led by your development and QA team · self-serve.

Why this phaseA missing page view call or a mistyped tag costs an afternoon here. Found after launch, it costs an app release and a gap in your data that nothing can fill in retrospectively.

Validation is self-serve. LiveLens tests the data ingest for each application event type automatically and shows you the validation status per event, so your team can confirm the integration independently.

How to validate

  1. Open LiveLens and exercise the application while watching events arrive. Confirm the status for each expected event type.
  2. Check auto-collection coverage against your SDK's documented list. Everything it auto-collects should be appearing — if clicks or screens are missing, the cause is usually a build plugin that wasn't applied, a navigation container that wasn't wrapped, or a SwiftUI screen missing its view modifiers.
  3. Check page views explicitly on Web, page by page. This is the most common gap.
  4. Check custom event payloads — correct names, expected keys, correct types, and keys matching across platforms.
  5. Check custom tags are attached to events reported after they were set, and that they clear when you expect.
  6. Check user ID is present on identified sessions, absent on anonymous ones, and matches the Video Sensor's Viewer ID for the same person.
  7. Walk the error and edge cases, not just the happy path — forced errors and crashes, backgrounding mid-flow, offline then reconnect, logout and re-login.
  8. Re-run the affected cases after each fix, and confirm the data in Pulse.

Your Conviva account team can help with anything that looks wrong during validation.

PHASE 4ActivateSensor Remote Control · Semantic Mapper · Metric Builder

Led by you, with your Conviva account team.

Why this phaseThis is where raw events become your metrics — and it happens in Conviva, not in your codebase. Tuning collection and defining metrics here means no app release and no developer time.

Integration gets events flowing. Activation turns them into the metrics and journeys your teams actually look at, and it is all configured server-side.

Sensor Remote Control

Change what the deployed sensor collects without shipping a new build:

  • Block unwanted events — stop collecting events that are noisy or meaningless for your analysis.
  • Customize click tracking — go beyond buttons and links, or narrow collection to the elements that matter, by tag, type, ID, or selector.
  • Filter network requests — define which requests are collected by matching rules.
  • Intelligent collection — replace the default blocklist with hostname, path, or scheme rules to control request volume.
  • Cohort Replay — reconstruct user navigation and actions for a sample of sessions to see how people actually move through the app.

Semantic Mapper

Map raw events, tag keys, and tag values into the vocabulary your business uses, so a metric can be defined on "checkout started" rather than on a raw event name and a tag. See Semantic Mapper.

Metric Builder

Define custom metrics and flows from an initial and a completing event — time between login and first playback, cart-to-purchase success rate, or any sequence that represents progress in your app. See Metric Builder.

PHASE 5LaunchProduction key · release · support handover

Led by your application deployment team, supported by the Conviva account team.

Why this phaseA handful of checks separate a clean cutover from weeks of test data mixed into your production dashboards.

Deployment checklist

  1. Configure the app to use the production customer key.
  2. Confirm the application name and version are set correctly for the production build.
  3. Confirm the content security policy permits the Conviva endpoints, for Web applications.
  4. Confirm code shrinking and obfuscation rules are in place, where your platform requires them.
  5. Notify Conviva when the app will be released to the general public.

Support handover

After launch, the Conviva support team takes over your ongoing requests. If you change subsequent versions of your application — whether the change relates to Conviva or not — coordinate with your Conviva representative in advance so the integration can be checked. Navigation and UI refactors are the usual cause of silently lost auto-collection.

For production issues, contact support@conviva.com with your Conviva C3 account ID, platform, and SDK version.

Supported Platforms and SDKs

Pick your platform below; each row lists the frameworks that SDK supports. API marks a platform where interactions and navigation are reported explicitly rather than auto-collected. Installation, initialization, and API documentation live in each repository.

Android
Android Native, Jetpack Compose, Fragments, Jetpack Navigation — Android mobile, tablet, and TV Also: a build plugin enables click, screen, network, and deep-link auto-collection
iOS / tvOS
UIKit, SwiftUI, Swift, Objective-C — iPhone, iPad, and Apple TV
JavaScript / Web
HTML, React, Angular, Vue, TypeScript — browsers, mobile Web, and smart TV Web apps Deployment options: npm package, script tag, or Google Tag Manager Commerce integrations: Shopify, Salesforce Commerce Cloud
React Native
React Native, React Navigation, Expo, TypeScript — built on the Android and iOS sensors Also: a build plugin and a navigation wrapper enable click and screen auto-collection
Roku
Roku SceneGraph API
C SDK
Embedded and native platforms with no prebuilt module API
Rust
Rust-based applications API
Getting the SDK. Each repository above carries its own installation instructions, integration guide, API reference, sample application, and agent instructions for AI-assisted integration. Current versions are published under Releases in each repository.

New to the App Sensor? The App Sensor Integration FAQ answers the questions that come up most often during integration.

Auto-Collection and Its Limits

Auto-collection is the point of the App Sensor, but what arrives out of the box differs by platform — and on some platforms a build plugin, a navigation wrapper, or a view modifier has to be in place for it to work at all. Each SDK repository publishes the current list of what it auto-collects and what needs an API call; that list is the authoritative one, so check it for your platform before you plan around a particular event.

Three differences are worth knowing up front because they are the ones that quietly produce missing data:

  • Android and React Native auto-collect clicks, screens, and network requests only once the Conviva build plugin is applied — and on React Native, only with the navigation container wrapped. Without them those events never arrive, and nothing errors.
  • iOS under SwiftUI does not auto-collect clicks or screen views. They are reported with the view modifiers the SDK provides.
  • Web never auto-collects page views. They must be reported on every navigation, and cannot be backfilled.

Roku, C, and Rust have no auto-collection — every event is reported explicitly from your application. See Roku, C, and Rust for their integration instructions.

Collection limits worth knowing

These constraints are architectural, and apply wherever the capability exists:

  • Network request bodies are collected only when the payload is small, its length is known, and the content type is JSON or plain text. Headers require the server to expose them via the appropriate CORS header.
  • Media player requests issued by the platform's default video player are not captured, because the player runs in its own process. Playback telemetry comes from the Conviva Video Sensor instead.
  • WebView and iframe content is not visible to a sensor running on the native side. Instrument both surfaces and share the client ID.
  • Clicks suppressed in your own handlers — stopping propagation or preventing the default action also prevents the sensor from seeing the click.
  • Interceptor ordering on Android — where another networking interceptor short-circuits the chain ahead of Conviva's, network auto-collection stops silently. The Android repository documents the fix.

Integration Steps

Every platform follows the same shape. The specifics — package names, initialization syntax, plugin setup — are in your platform's repository.

  1. Install the SDK.

    Add the dependency for your platform, plus the build plugin where one is required for auto-collection, and any code-shrinking rules the SDK needs.

  2. Initialize the sensor with your test customer key and application name.

    Initialize at application start, before the first screen renders and before any network calls, so nothing is missed.

  3. Enable auto-collection.

    Apply the build plugin, wrap your navigation container, or add view modifiers as your platform requires. See Auto-Collection and Its Limits for what to watch for.

  4. Set the user ID.

    Set it when the person is identified and clear it on logout. Use a non-PII identifier, and match it to the Video Sensor's Viewer ID to follow one person across app and playback.

  5. Report page views.

    Required on Web, on every navigation — page views are never auto-collected.

  6. Report your own events and tags.
    • Custom events for the business moments that matter, with the payload you agreed on in planning.
    • Global custom tags for the dimensions that apply to every event.
    • Revenue events for purchases and orders.
    • Caught errors, on the platforms that support reporting them.
  7. Validate in LiveLens — confirm every expected event arrives with the right shape.
  8. Activate.

    Tune collection with Sensor Remote Control, map events in Semantic Mapper, and define your metrics and flows in Metric Builder.

  9. Switch to the production customer key and release.
  10. Analyze your data in Pulse and start improving the experience.