Desk note · 18 Jan 2026
Latency budgets for mobile SDKs
A freemium purchase often looks instant in the UI and late in the event stream. The store sheet returns, the client fires “success,” and the analytics SDK still sits behind a retry queue, a poor radio, or a batch window. Your realtime drop-off chart then shows abandonment that is actually a 20–40 second receipt. Product rewrites the offer. Engineering had a buffer.
Write a budget next to the event name
In Signal Pipeline Fundamentals we ask studios to put a latency budget on every revenue-adjacent event: p50 and p95 from client intent to warehouse arrival. Intent is the tap. Arrival is when the event is queryable. If p95 exceeds the length of the next screen, you may not use that event in a live funnel.
Typical first drafts we see: purchase_success with “as soon as possible,” no number. That is not a budget. A usable line looks like: purchase_receipt_ok, p50 < 8s, p95 < 25s, owner = payments, fallback = store settlement next morning. If you cannot meet the budget, the live dashboard must label itself delayed.
Batching is not free honesty
SDKs that batch every 60 seconds to save battery will always lose a realtime review. That can be the right trade for a weather app. It is a bad trade for a continue-pack SKU that you claim to monitor live during a sale. Either unbatch revenue events or stop calling the chart live.
Thailand’s mixed radio conditions make p95 worse than a US office test. Measure on the devices your users actually have, not on studio Wi-Fi in Min Buri.
What this page will not do
It will not rank analytics vendors. Switching SDKs without a latency budget just moves the queue. Take Signal Pipeline Fundamentals if you want the measurement exercises, or send the desk your current p95 — even if it is only a screenshot of a retry log.