What breaks in pet activity monitoring
Pet activity monitoring breaks not on the chart, but in the gap between the sensor, the phone, and the server.
The tracker writes steps and sleep to an internal buffer, the app retrieves them over Bluetooth, the server stores the history — and the moment connectivity drops during a walk, the buffer overflows and part of the day disappears irreversibly.
The owner sees a smooth chart, the veterinarian draws conclusions from it, and the real picture of activity is already lost.
False triggers are the second most common cause of distrust in the data. The accelerometer counts shaking in a car or scratching as "steps," and an algorithm without calibration for breed and weight logs extra kilometers for the pet.
After that, the owner either stops opening the app or comes to the doctor with a distorted history, and diagnosis starts from scratch.
Tracker battery life and time synchronization are directly linked. The sensor conserves charge and connects less often — timestamps "drift," events merge into a single interval or shift hours back when the time zone changes.
Sleep and activity swap places, and the circadian rhythm, which is exactly what matters for assessing condition, is read incorrectly.
The cost of these failures is not a spoiled chart, but a delayed response. Data gaps hide the onset of declining activity, false triggers mask it as normal, and time desynchronization makes it impossible to correlate behavior with food and medication intake. Let's break down how this is addressed at the level of the app and data exchange.
What the app delivers: measurable effect
Pet activity monitoring is first and foremost a matter of data delivery discipline. A collar with an accelerometer and a communication module takes readings continuously, but in an apartment with thick walls and on a walk in a lowland area, radio coverage drops out.
That is why measurements are not sent one by one: they accumulate in a local ring buffer and go out in packets when a channel becomes available, and the order is restored using timestamps.
The share of delivered measurements on real routes stays above 99% — the owner sees a continuous activity stream rather than ragged gaps.
The second area is time to notification. An event such as "the pet has left the geofence" or "activity has dropped below the individual norm" must reach the phone within seconds, not at the next synchronization.
This is where a persistent connection to the push channel comes in: the device keeps a session open, and the server sends a notification immediately when a rule triggers.
Our engineers configure priorities so that alert events bypass the queue of background reports — time to notification stays within a few seconds.
The third is an eliminated class of failures. A classic problem with such apps: after losing connection, the device "sticks" and no longer reconnects until the owner restarts it manually.
We close this gap with automatic reconnection using an increasing delay and a watchdog timer that restarts the communication module after prolonged silence. The "device is online but there is no data" failure class disappears from support.
The fourth is battery life and data quality. The polling rate adapts to the pet's state: at rest the device takes readings less often, while moving — more often.
This extends battery life many times over without losing detail, and filtering false triggers by an acceleration threshold removes "steps" that never happened.
We select the stack and hardware for the task — we work with proven communication modules so that behavior is predictable across different phone models.
FitBark
Data collection modes and their limitations
The collection mode determines everything else: how quickly the battery drains, how much data reaches the server, and what the owner sees in the app.
You can't choose it "by eye" — each option has a physical limit beyond which either the tracker dies within a day or the activity chart turns into sparse dots.
| Mode | When it fits | Limitations |
|---|---|---|
| Continuous stream | Clinical tasks, post-surgery rehabilitation, observation as prescribed by a physician | Maximum battery drain, the tracker lasts only a few hours; the communication channel is clogged with "raw" readings |
| Interval measurements | Everyday monitoring of a pet's activity: sleep, walks, overall mobility | Misses short spikes between measurements; with a rare interval, the picture of the day is lost |
| Threshold sending | Tracking specific events: the pet moved little, stayed down for a long time | Requires calibrating the threshold for the breed and age; false triggers when behavior changes |
| Offline buffer | Walks outside the city, basements, areas without network coverage | Data arrives with a delay; when the buffer overflows, old records are pushed out |
In practice, modes are combined: interval measurements provide the baseline chart, threshold sending adds alert events, and the offline buffer covers connectivity gaps.
This set keeps a full day of operation on a single charge and doesn't lose significant episodes — the owner sees both the overall dynamics and individual deviations.
It is more honest to build limitations into the interface rather than hide them: if the app shows "no data," the owner should understand that this is a connectivity gap or battery saving, not a problem with the pet.
We configure modes for the usage scenario and document them so that the tracker's behavior is predictable.
How we implement pet activity monitoring
Pet activity monitoring breaks not on the app screen, but at the junction of the wearable device, the communication channel, and server-side processing.
That is why we work in stages: first we establish what the tracker can actually do and how it transmits data, then we design the exchange, and only after that do we build the interface.
This order eliminates rework — a scenario that cannot be closed on the device is identified before the first line of code.
- Device and channel audit. We look at which sensors are in the collar, how often it writes telemetry, how it behaves without a network, and what it transmits when the battery is low. We check the available communication methods — direct connection and gateway — and choose the one that provides a stable stream without manual actions from the owner.
- Exchange scheme. We describe the packet format, sending frequency, and the rules for re-sending accumulated data after a connection loss. Separately, we define what counts as a step, rest, and anomaly — otherwise activity graphs will be incomparable across different breeds.
- Data reception setup. We set up the server side: stream reception, a queue for peak loads, history storage, and calculation of daily and weekly summaries. Here we also define notification thresholds so the owner receives a signal about reduced activity rather than a stream of raw values.
- Scenario testing. We run through real situations: the pet left the reception zone, the device ran out of battery, the owner changed phones, there is no data for the day. We compare the tracker readings with manual measurements — the discrepancy must fall within an acceptable range.
- Owner interface. We build the activity, history, and notification screens so that the output can be read in a couple of seconds. We separately test the app's behavior under weak connectivity and on older phone models.
- Solution handover. We deliver the configured environment, documentation on data formats, and instructions for firmware updates, train your team, and remain available for change support.
Describe which devices you already have on hand and what should go into the owner's report — we will come back with an estimate and a plan for each stage.
Artifacts: configurations, schemas, regulations
The project ends not with a demonstration, but with the handover of a complete set that your team can use to operate pet activity monitoring without us. Below is what exactly remains with the customer after implementation.
- Data ingestion configurations. Configuration files for the gateway and queue: telemetry dictionary (steps, sleep, activity, heart rate), polling frequencies, aggregation windows, per-device limits. We modify them without rebuilding the application — adding a new tracker model does not require a release.
- Data flow schema. A diagram of the path from sensor to the owner's screen: where offline records are buffered, how conflicts are resolved when clocks are out of sync, and at what point data becomes visible in the app.
- Alert rules. Thresholds and trigger conditions: activity dropping below the breed's baseline, a missed walk, sleep deviation, loss of connection with the tracker. With an indication of which notifications go to the owner, which go to support, and which are only written to the log.
- Documentation. Data model schema, description of exchange interfaces, list of external dependencies, instructions for connecting a new device type, and an analysis of typical failures with their signatures in the logs.
- Maintenance regulations. Frequency of checks, procedure for updating reference data, response to ingestion degradation, integrity control points for activity history, and archive retention rules.
- Access and roles. A permission matrix for configurations, logs, and alerts, so that changes do not go to production without a second confirmation.
The set is self-sufficient: it describes not only the current state, but also the procedure for changes. We hand it over with a walkthrough on a call — your engineers go through each item and ask questions while the context is still fresh.
Case study: a stable data stream without losses
The client came with ready-made hardware: a tracker on a collar was recording data, but it appeared in the app with gaps.
The owner saw "the dog slept for 6 hours," even though the pet was out walking at the time, and the geofence exit notification arrived 20–40 minutes later — when it no longer mattered.
Worse, the app woke the owner at night with false alarms: the sensor lost connection with the phone, and the system treated that as an escape.
PetKit was the name of the platform that had to be brought to production. We broke down three bottlenecks: buffering on the tracker side, the delivery channel, and the rules by which the system decides that an event is real.
The tracker accumulated measurements in a local buffer and sent them in a batch on the next contact — if the connection dropped, the batch was lost entirely.
We rewrote it for acknowledged delivery: the device stores measurements until it receives a receipt from the server, and the app backfills the missed interval when the connection is restored.
The second was latency. Notifications went through periodic polling, hence the minutes of waiting. We switched to a persistent channel: the server itself pushes the event to the app as soon as it is recorded. The third was false triggers.
We introduced confirmation based on several consecutive measurements and a signal-level filter: a single loss of connection is no longer treated as an escape.
| Metric | Before | After |
|---|---|---|
| Share of delivered measurements | 71% | 99.4% |
| Notification latency | 20–40 min | 3–7 sec |
| False triggers per week | 12–15 | 0–1 |
The client confirmed the result on their own fleet of devices: the data stream stopped breaking, the nighttime alarms went away, and owners saw a continuous picture of their pet's activity for the first time.
They separately noted that no rollback to the previous delivery scheme was needed — the new one works on the same hardware without replacing trackers.
How does streaming differ from interval transmission?
The difference lies in what exactly the application sends to the server. With interval transmission, the tracker accumulates data over a window — usually 5–15 minutes — and sends it in a single packet: several points with timestamps, averaged steps, sleep, heart rate.
With streaming, the channel is kept open, and coordinates along with telemetry are transmitted almost continuously, with a step of seconds. The first mode saves battery and traffic, the second provides a detailed picture in real time.
The accuracy of the picture is not only about the frequency of points, but also about how the server stitches them together.
With intervals, it is easy to lose a burst of activity: the pet was actively moving for two minutes within the window, and in the averaged value this dissolved.
Streaming sees such peaks, but requires processing on the service side — filtering jitter, smoothing, cutting off false triggers on geofences. Without this, the stream produces noise, not a picture.
Battery consumption and channel load grow non-linearly. A constant connection does not let the communication module go to sleep, and each wake-up is a spike in consumption.
With interval transmission, the tracker lasts for weeks, with streaming — days, and everything depends on how often the channel is opened and how much data goes out in each packet.
That is why in working pet activity monitoring applications there is almost always a hybrid: interval transmission as the base mode, streaming — turned on by an event.
Went beyond the geofence, started moving actively, lost signal — the application raises the frequency and keeps it until the situation stabilizes. This way, both the accuracy of the picture and the device's resource are preserved.
Technical concerns about monitoring
Five questions that a technical lead asks before the start sound almost the same in any pet activity monitoring project. Below are direct answers without marketing.
How is the app compatible with different devices?
Trackers communicate over different channels — Bluetooth Low Energy, cellular networks, Wi-Fi. We build an abstraction layer: the device firmware is described by an adapter, and the business logic works with a unified event model.
Adding a new tracker model is a new adapter, not a rewrite of the app. On the phone side, we support current branches of iOS and Android, including background synchronization and power-saving restrictions.
What happens when communication with the tracker is lost?
Data is not lost: the device buffers measurements locally and sends them in a batch when the channel is restored. On the server, events are received idempotently — resending does not create duplicates.
If the tracker is silent longer than a set threshold, the owner receives a notification, and the app shows the last confirmed interval rather than an empty screen.
How is the privacy of pet and owner data ensured?
Personal data and telemetry are separated: geolocation and activity are stored separately from the account, with access via time-limited tokens. Transmission goes over a secure channel, and sensitive fields are encrypted on the server side. The owner can export or delete their data, and employee access to it is role-restricted and logged.
Will the system withstand growth in the number of devices?
Telemetry ingestion is the most heavily loaded part, so it is moved to a separate contour and scales horizontally. A queue smooths out peaks when thousands of trackers come online at the same time.
Storage of raw measurements is separated from the aggregates that are served to the app — growth in the number of pets does not slow down the statistics screens.
What about support after launch?
We hand over not only code but also observability: ingestion metrics, synchronization delays, error rate by device model, and alerts for anomalies. This makes it possible to catch degradation before owners complain.
After that — a firmware and app update policy, incident review, and a development plan as the device fleet grows.
Let's discuss the task and come back with a plan
To come back with an estimate and a plan rather than generalities, we need to understand the current product setup and usage scenarios.
Pet activity monitoring is not a standalone screen with a chart: data comes from a wearable device, passes through a mobile app, and ends up in analytics, and each segment of this chain has its own constraints.
The more precisely you describe what already works, the fewer assumptions we will build into the implementation scheme.
Send us the inputs point by point — we will use them to put together an estimate and a plan:
- Current setup: what already exists — an app, a wearable device, a backend, or just an idea and a prototype so far.
- Data sources: which sensors transmit readings and how often, how the device syncs with the app.
- Usage scenarios: what the owner sees in the app — daily activity, sleep, deviations from the norm, notifications.
- Platforms and coverage: iOS, Android, tablets, web dashboard — where monitoring is needed first.
- Integrations: which systems we connect to — maps, veterinary services, warehouses, support service.
- Constraints: deadlines, device battery life requirements, offline operation, owner data privacy.
- What has already been tried: which solutions did not work and why — this will save us a search cycle.
Based on these inputs, we will come back with an implementation scheme: how data flows from the sensor to the screen, where history is stored, how activity metrics are calculated, and what we show to the owner.
The estimate will be tied to stages — from the monitoring prototype to release in app stores, with clear timelines and scope of work.
Describe the task in free form — even if some details are not yet defined. We will ask clarifying questions and come back with an estimate and a plan.