7 June 2026 · Aisha Rahman
One dictionary for iOS, Android, and web
The person is the same. The tap is not. The event name still has to be.
A ride-hailing product we reviewed in the Klang Valley had order_placed on iOS, booking_success on Android, and trip_create on web. Each team was sure their name was the accurate one. The warehouse joined them with a mapping table that two people understood.
The dictionary is not a lowest-common-denominator of tracker APIs. It is a sentence about the person. The person placed an order. The three clients fire order_placed. Differences that are real — gesture, OS permission, a web redirect — live in properties such as client: ios | android | web.
Handoff sheets still differ. iOS may fire on viewDidAppear, Android on a composition callback, web on a route change. Those notes belong in the engineering column, not in three event names.
When a platform cannot fire an event yet, the plan should say so. A blank is better than a made-up web event that product then treats as a hole in conversion.
We write one table, then three trigger columns. If a fourth client appears — a mini-program, a kiosk — it gets a column, not a fork of the dictionary.