The In-App Help Path Instrumentation workshop exists because most event dictionaries were written by product analytics, not by people who answer tickets. Support Funnel App Analytics needs fewer events, named more sharply. We start with five: help_search_submitted, help_search_zero_result, help_article_opened, help_deeplink_followed, help_contact_tapped. If you only get three, keep search, article opened, and contact tapped. Drop the poetic “engagement” events.
Properties matter more than extra event names. Article ID, locale, surface (in-app sheet vs full help center vs coachmark), and whether a deep link target loaded are enough to argue. User ID join to the desk tool is the political problem, not the tracking problem. When legal or vendor limits block the join, the Atlas records the blocker. Instrumentation class is not a place to invent shadow identifiers.
Scroll depth is optional and often vain. If you keep it, do not call 75% scroll a success. Call it help_article_scrolled and leave interpretation for the brief. Deep links are the opposite: following a link into card status or shipment proof is a real edge. Instrument the destination screen, not only the tap, or you will celebrate taps that 404.
Bots need their own small dictionary: bot_loop_detected (same article or intent twice), bot_human_requested, bot_closed. Closing a bot session is not resolving an intent. Pair bot_closed with a later same-intent ticket using a time window you publish — twenty-four hours is a common house default at Identity Nodecore, not a law of nature.
Finally, write the dictionary in the same language your reviewers speak. English event names with Thai article titles are fine; unexplained abbreviations are not. Module 4 of The Funnel Signal Method is mostly renaming. It is unglamorous work. It is also the work that makes every later chart less fictional.