Service model
Anonymised snapshots from recent Seoul engagements. Each note shows the decision that was stuck, what we changed in the event language, and what the team could defend afterward.
Support heard users stall on invite acceptance; the dashboard showed a healthy activation rate. The audit found three overlapping “signup complete” events with different property shapes. We collapsed them into one dictionary entry, rewired the invite path, and validated sample traffic before the next release review.
Outcome: product and support used the same step names in weekly triage. No growth promise—just a funnel that matched tickets.
Leadership tracked D7/D30 because a prior vendor recommended it. Actual usage clustered around fortnightly payroll cycles. We redefined return behaviour around those cycles, instrumented the two paths that predicted return, and documented ownership for each event.
Outcome: retention reviews stopped arguing about empty D7 buckets and started asking whether payroll paths completed cleanly.
Seventeen charts lived on the wall; none had a named owner. Studio day one mapped journeys; day two cut the list to five metrics with formulas and review cadence. Vanity session counts were demoted to supporting context.
Outcome: a one-page sheet the engineering lead could update after each release without a separate analytics ritual.
Most teams begin with a signal audit. If you already have a clean dictionary, tell us on the contact form and we will suggest path work or a release review cycle instead.