Instrumenting itinerary saves when the network drops
Travel apps die in tunnels, on ferries, and on islands where the only bar of signal belongs to a different carrier. If your analytics assume a live POST, you will either miss the save or count it twice. Both errors are common. Both are avoidable.
Offline Save Instrumentation is the shortest live title we teach, and the one engineers argue with most. That is a good sign. The arguments are usually about idempotency, not about slide design.
The local write is the source of truth
When a traveler taps “save itinerary” without a network, the device should persist the itinerary and an analytics envelope with a client-generated id, a local timestamp, and a connectivity flag. The server event later must reuse that id. If the server mints a new id on sync, you have invented a second save.
Teams that only fire analytics after a 200 response undercount island use. Teams that fire immediately and again on sync overcount. The envelope is how you choose neither.
Retry grammar
Retries need a reason code: first attempt, resume after background, resume after connectivity. Without reasons, a retry storm looks like an enthusiastic traveler. With reasons, you can see that a particular OS version is waking the app ten times an hour.
Do not attach the full itinerary payload to every retry event. Attach the id, the attempt number, and the reason. Payload size is how offline analytics become a battery problem, which travelers notice faster than your dashboard does.
Time zones and ferry clocks
Local timestamps should be stored in UTC with the device offset recorded separately. A traveler who saves a trip on a ferry between terminals may cross a timezone boundary that your product never intended to support. If you only store “local hour,” Songkran cohorts and day-of funnels will smear.
What not to log
Offline buffers are tempting places to stash everything “just in case.” Do not stash passport numbers, hotel confirmation codes, or free-text notes. Travel App Analytics is not a backup of PII. The red-list from In-App Search Telemetry applies here with more force, because an offline database can sit on a lost phone for days.
If this note is uncomfortably specific, the two-week studio is the place to bring your actual queue implementation. Dates go through the Bangkok desk. The method page on route telemetry explains how offline saves still belong to a corridor.