2 September 2025 · Performance
SDK payload size and checkout latency
The 2.8 second median time-to-first-event we quote on the home page was not measured on a flagship phone. It was measured on the devices your customers actually check out with.
A common pattern in dumps we review: the analytics SDK initialises at application start, then immediately flushes a “kitchen sink” identify payload — device graph, ten experiment flags, last 50 viewed SKUs, and a full cart object “just in case.” On office Wi-Fi this is invisible. On a mid-range Android radio in a Bangkok condominium lift, begin_checkout loses the race to first paint. The user has already moved. The event never leaves the batch.
What to measure before you trim
Record three timestamps: SDK init complete, first commerce event queued, first commerce event acknowledged by the collector. If queued-to-ack regularly exceeds a second on mid-range hardware, stop adding properties to identify. Move experiment flags to a dedicated, sampled stream. Do not attach the entire cart to view_item.
Module 04 of Checkout Event Instrumentation includes a lab where students watch a synthetic checkout on a throttled network. The embarrassing outcome is usually not “the SDK is slow.” It is “we asked the SDK to describe the universe on every screen.”
Batching is not innocence
Vendors advertise batching as performance. Batching also means a killed WebView can swallow add_payment_info after the user has already authorised COD. If payment happens off-native, flush the commerce event explicitly before opening the WebView. Document that flush in the parameter contract so the next engineer does not “optimise” it away.
Payload size is a product decision dressed up as infrastructure. Treat it like one. The dictionary should list which properties are allowed on which atoms, with a hard no for dumping warehouse dimensions back onto the client “for convenience.”