Ask a team how much data their device uses and the most common answer is the payload size multiplied by the reporting frequency. Ask their connectivity invoice the same question six months after launch and it gives a number two to five times larger. Neither is lying; the gap is everything the first calculation left out.
Data forecasting matters because it drives plan selection, pooling structure and the commercial model itself, all decided before real consumption data exists. Get it badly wrong in one direction and you pay for capacity nobody uses; in the other, overage charges and mid-contract renegotiation. The method below produces estimates that survive contact with production, and it works for anything from a sensor to a video device.
Step 1: Start with the payload, then stop trusting it
The base arithmetic is genuinely simple. A device sending a 2 KB telemetry message every 15 minutes sends 96 messages a day, around 192 KB daily, under 6 MB a month. Write this number down, because everything that follows adjusts it upward, and the adjustments are where forecasts succeed or fail.
Step 2: Add protocol and transport overhead
Application payload travels wrapped in transport, encryption and protocol layers, and the wrapping is proportionally brutal for small messages. TCP/IP headers, TLS handshakes and session establishment can multiply tiny payloads several times over; a 200-byte reading inside a fresh TLS session can cost several kilobytes on the wire. The overhead factor depends heavily on protocol choice (MQTT with persistent sessions is far leaner per message than repeated HTTPS requests) and on how often connections are re-established.
The practical rule: for chatty small-payload devices, apply a multiplier of 2 to 5 on raw payload arithmetic until measured; for devices sending larger payloads over persistent connections, 1.2 to 1.5 is usually closer. These are starting assumptions to be replaced by measurement, not facts to be defended.
Step 3: Count the traffic that isn’t yours
Devices generate traffic their application teams never see. Network attach and re-attach signalling, DNS lookups, NTP time sync, keepalives that hold sessions open through carrier-grade NAT, platform agent check-ins, and the retry storms that follow any connectivity blip. Individually trivial, collectively a steady baseline that dominates the bill for very low-payload devices. A device whose application sends 1 MB a month can plausibly spend more than that on keepalives alone if the interval is aggressive.
Step 4: Budget the exceptional events
Three event classes break naive forecasts, and all three belong in the model as explicit line items.
Firmware updates. A single over-the-air update can exceed a year of telemetry for a small device. Estimate update size, expected frequency per year, and whether delta updates reduce the payload, then spread the total into the monthly figure.
Retry and failure behaviour. What does the device do when its backend is unreachable: buffer and batch, or hammer the network with retries? An unbounded retry loop during a four-hour backend outage has rescued many connectivity providers’ revenue figures. If you do not know the retry policy, the forecast carries silent risk and the firmware needs a review anyway.
Diagnostics and logging. Verbose remote logging, enabled during an incident and forgotten, is a classic consumption spike. Decide what diagnostic modes exist and cost them.
Step 5: Build per-class profiles, not one average
Estates are mixtures, and pooled data plans are priced on the mixture. Build a small table per device class: base payload arithmetic, overhead multiplier, baseline network traffic, event budget, and a resulting monthly estimate with a stated confidence range. Three worked sketches show the spread:
A lone worker device sending periodic check-ins and occasional alarms: raw payload a few hundred kilobytes monthly, realistic estimate 1 to 3 MB once overhead and keepalives are counted. A telematics unit reporting position and CAN data every few seconds with daily bulk uploads: tens to a few hundred megabytes monthly depending on richness. A connected camera uploading event clips: governed almost entirely by clip length, resolution and event frequency, spanning hundreds of megabytes to tens of gigabytes, which is why video devices get their own forecasting treatment in our video telematics data piece.
The class table does double duty later as the structure for plan selection: classes with stable consumption suit fixed allowances, volatile classes argue for pooling, and the mixture determines the pool size. Our guide to IoT data plan pricing models covers that mapping.
Step 6: Measure before you commit
Every number above is an assumption with a confidence range, and the cheapest way to collapse the range is to measure real devices on a real network before signing multi-year terms. A structured trial, a handful of devices per class, running production firmware for two to four weeks, replaces the overhead multiplier and baseline estimates with facts. Per-SIM, real-time consumption visibility matters here: OV ONE shows session statistics and data consumption per SIM as they happen, which turns a trial into a measurement exercise rather than a wait for the first invoice. A free IoT SIM trial exists for exactly this purpose.
The forecast as a living number
Post-launch, the forecast becomes a monitoring baseline. Devices drifting above their class profile are telling you something, a firmware regression, a retry loop, a connectivity issue forcing re-attaches, and per-SIM alerting against expected consumption catches it as an anomaly rather than an invoice. Data caps on classes with hard ceilings convert worst-case scenarios into bounded ones. The teams with boring connectivity bills are the ones that forecast by class, measured before committing, and kept the model alive afterwards.
Frequently asked questions
How much data does a typical IoT device use per month?
There is no useful typical figure; consumption spans from under a megabyte for simple sensors to tens of gigabytes for video devices. The meaningful approach is per device class: payload arithmetic, an overhead multiplier, baseline network traffic and an event budget for updates and retries, then measurement on real hardware to replace the assumptions.
Why does real IoT data usage exceed payload calculations?
Because payload travels inside transport and encryption layers, and devices generate traffic beyond their application: signalling, DNS, time sync, keepalives and retries. For small-payload devices these can multiply raw arithmetic several times over, which is why unmeasured forecasts should carry an explicit overhead factor.
Should firmware updates be included in data forecasts?
Yes, as an explicit line item. A single over-the-air update can exceed months of telemetry for a low-data device, so estimate update size and annual frequency and spread the total into the monthly figure. Delta update support changes this line significantly and is worth confirming with your device team.
What is the best way to validate a data forecast?
Run production firmware on a small set of real devices over a real network for two to four weeks, with per-SIM consumption visibility, before committing to commercial terms. A free IoT SIM trial with real-time usage monitoring converts the largest assumptions in the model into measurements.
