Knowing Instead of Guessing

Two teams ship the same connected product. One argues in meetings about whether users find the pairing flow confusing. The other opens a dashboard and reads that 38 percent of installs never complete pairing, that the drop happens on the Bluetooth permission prompt, and that Android 13 devices fail twice as often as iOS. The second team fixes it in a sprint. The difference is a few days of instrumentation work done before launch.

Analytics in a companion app is not a growth-marketing exercise. It is the only view you have into how a physical product behaves in homes you will never visit.

Three Layers of Measurement

Instrument in this order. Each layer answers a different question, and skipping the first makes the others misleading.

Layer one is stability and performance. Crash-free session rate, ANR rate on Android, cold start time, API latency and error rate, and connection success rate to the device. Target a crash-free session rate above 99.5 percent; below 99 percent, every behavioral number you collect is contaminated by users who could not proceed. Crash reporting costs little and belongs in the first build, not after the first bad review.

Layer two is usage and behavior. Which features get used, in what order, how often, and by whom. Daily and weekly active users matter less for a hardware app than for a social app, since a garage door opener that is used twice a day is healthy while a water sensor app might be opened monthly by design. Define what "engaged" means for your product before you measure it.

Layer three is business. Activation rate, subscription conversion and churn, support contact rate per thousand units, warranty claims, and repeat purchase of consumables. These are the numbers that decide whether the product line survives, and they are usually the ones nobody instrumented.

Design Events, Do Not Drown in Them

The common failure is logging everything. Two hundred event types with inconsistent names produce a data set nobody queries. Start with twenty to thirty events that map to real decisions, and write them down in a tracking plan before implementation: event name, when it fires, which properties it carries, and what question it answers.

  • Naming convention, enforced. Pick object_action in lowercase with underscores and never deviate. Mixed conventions are the top reason analytics projects rot within a year.
  • Properties over event proliferation. One device_paired event with properties for method, duration, and attempt count beats five separate events.
  • Firmware and hardware context on every event. Firmware version, hardware revision, device model, app version. Without these you cannot tell whether a spike in failures came from the app update or the new production batch.
  • Timing, not just occurrence. Log how long setup took, not only that it finished. Duration distributions expose usability problems that completion rates hide.
  • Failures as first-class events. Log the error, its code, and the recovery path taken. Most teams instrument the happy path and stay blind to the one that matters.

The Funnel Is the Main Instrument

For a companion app, the funnel that decides the product's fate runs from install to a working device: app installed, account created, permissions granted, device discovered, device connected, network credentials accepted, first successful use. Instrument each step and watch the fall-off.

Real numbers from connected products are sobering. It is common to lose 10 to 15 percent at account creation, another 10 to 20 percent at the Bluetooth or location permission prompt, and 15 to 30 percent during network setup. A product that converts 55 percent of installs into working devices is unremarkable, and every percentage point recovered is a return avoided and a support call not made. The specific fixes live in onboarding and pairing design, in when and how the app asks for Bluetooth and location permissions, and in the reliability of Wi-Fi provisioning from the app. Segment the funnel by platform, OS version, and hardware revision before drawing conclusions, because aggregate numbers hide a single broken combination.

Measure the Device, Not Only the App

The app is a window onto hardware behavior, and device telemetry is where a product company gets an advantage a pure software team never has. Useful signals: battery discharge curves across the fleet, connection drop frequency by firmware version, sensor drift over months of service, actual duty cycles versus the ones the mechanical team assumed, ambient temperature at time of failure, and the count of units that reset unexpectedly.

This data changes engineering decisions. If real duty cycles are triple the design assumption, the bearing sized for a five-year life will fail in twenty months. It also underpins predictive maintenance from product data and gives the support team the fleet view described in an IoT device dashboard. Store the high-frequency streams appropriately, since aggregating millions of sensor rows in a general-purpose table gets slow fast, which is the argument in time-series databases for sensor data.

Privacy Is a Requirement, Not a Preference

Analytics on a connected product collects data about a person's home, health, vehicle, or workplace. Treat it as regulated from the start. Collect only what answers a defined question, avoid storing precise location or raw audio and video unless the product genuinely needs them, use a pseudonymous device or account identifier rather than an email address in the analytics pipeline, and set a retention period with automatic deletion.

The compliance surface is real: consent and deletion rights under GDPR and CCPA, Apple's App Tracking Transparency prompt and privacy nutrition labels, Google Play's data safety declaration, and stricter rules again for products used by children. What to build in is covered in privacy compliance for connected product data, and anything aimed at kids has to clear the requirements in COPPA compliance before launch, not after. Practical rule: if you would be uncomfortable showing a customer the exact rows you hold on them, do not collect those rows.

The Habit That Makes It Worth Anything

Instrumentation without a review cadence is decoration. Pick five to eight numbers, put them on one page, and read that page every week with the same people: crash-free rate, setup completion rate, weekly active devices, support contacts per thousand active units, and whichever business metric your model runs on. Investigate anything that moves more than 10 percent week over week, and annotate the chart with every app release, firmware release, and production batch so causes stay findable.

Start collecting during the pilot, not at launch. A structured beta test with fifty instrumented units surfaces the setup failures and firmware bugs that would otherwise arrive as returns from your first thousand paying customers, and it costs a fraction as much to fix them at that stage.

Instrument the Product, Not Just the App

Projects House designs connected products where the firmware, backend, and app are planned together, so the telemetry that engineering needs and the analytics the business needs come from the same pipeline. Tell us about your device and what you wish you could see from the field through our contact form.