The problem I needed to solve
If every button guesses its own event name, menu analytics collects inconsistent labels. I added a resolver for recurring sections while retaining awareness of hierarchy-based guessing.
Implementation in this snapshot
AnalyticsButtonNameResolver.Resolve normalizes the button name and ancestor path. Navigation, shop, reward or customize context influences the event name, and unknown cases return an empty string.
The design decision and its cost
BuildPath adds context: skin in a shop differs from skin in customization. This decision is independent of translated visible labels.
Current boundaries
Matching uses Contains and can misclassify unexpected names. Hierarchy or naming changes require event review; automation does not replace a stable contract.
Review scenarios and contract meaning
Following the full path shows that the resolver is only the naming stage. AnalyticsButtonNameResolver can suggest meaning from a button’s name and ancestors, but the current card-game wrapper only forwards its closed list of essential events and omits menu clicks. Finding nav or shop labels in code therefore does not establish actual click traffic. This policy limits data volume and must accompany any interpretation of click reports. Contains-based naming also depends on scene structure: renaming an ancestor can change classification while the visible label stays the same.
PHP keeps tabs and reports independent for each game. Adding an event schema, changing unknown-event acceptance and creating a Count report are different operations; none creates a Unity listener. Definition saves check the expected revision so an older window cannot silently overwrite newer settings. Renaming a visible tab also differs from changing a data identifier. If click events become necessary, stable names, action meaning and a real transmission path must be established. My concern is useful data that answers a product question while keeping the current policy boundary explicit.
Event identity should survive interface translation. Persian and English labels serve readers, while analytics names serve the data contract. The resolver adds context, but name review still matters. Grouping by unstable names can split one behavior into several groups. More events do not solve that problem; naming needs to resolve it.
What this stage taught me
For me, a useful event captures a tap’s meaning rather than merely its occurrence. A resolver helps initial installation, while explicit naming can remain preferable at sensitive interaction points.
