Imbalanced class use is a signal to restructure; do not rely on intuition alone

What it is

When one class in a layer holds 80% of objects and clicks, and its neighbours sit on single digits for months, the tree is already voting against the current cut. Imbalance is a restructure signal: oversized buckets to split, empty buckets to merge, wrong dimensions to replace—all should be triggered by counts, not by a workshop that eventually feels “a bit messy.” Intuition favours loud teams and recent incidents; use says which way lookup actually walks. The signal does not auto-execute splits. It forces a restructure proposal onto the table.

Imbalance has to be read on object count, entries, and success together. Clicks without success may be false scent; objects without entries may be a label failure.

Why it happens

A balanced cut gives sibling classes similar decision load. One giant bucket is no cut: people who enter it still have to do the elimination that belonged on the layer above. A row of empty buckets spends breadth, contributes no elimination, and makes distinctive neighbours harder to scan. Over time the giant grows unofficial substructure (query words, bookmarks, support passwords), and the official tree splits from the walk people actually take.

Intuitive restructures often rename what “looks ugly” and spare the volume that is actually wrong. Counts drag attention back to the layer whose cut failed. Thresholds need domain calibration, but a threshold must exist, or every week can say “watch a bit longer.”

Studying it

Build a class dashboard and use imbalance events to predict when to tree-test and restructure, rather than letting a feeling decide when to look at data.

• Paradigms: per layer, count objects, entries, success, and enter-then-leave; define imbalance (Gini, share of the largest class); after the metric crosses a line, tree-test the giant’s internal error types. Compare intuition-driven redesigns with metric-triggered ones on findability.
• Independent variables: imbalance threshold, whether the metric is objects or entries or success, whether seasonal spikes are excluded.
• Dependent variables: whether a crossed line is confirmed as a failed cut by tree tests, whether imbalance falls after restructure, how often a healthy imbalance (a required tiny compliance class) is wrongly split.
• Methodological note: traffic is not correctness. High clicks on a giant may be false scent. Read success, backtracks, and search escapes together. New classes look imbalanced during cold start; use a window, not a one-day snapshot.

Where it stops holding

Statutory small classes and high-stakes infrequent classes may stay “imbalanced” for life; they are not there for traffic. A personalized home is not a classification layer; counting recommendation clicks into class use distorts the signal. Language and region traffic structures differ; one global threshold will punish legitimate classes in a small market. Object imbalance with high lookup success may just be the world (one type really is larger). Split only if a new distinctive inner difference exists; do not cut to pretty up a dashboard.

Applying it

• On each layer, watch three charts: object share, entry share, success share. Any one crossing a pre-written threshold opens a restructure ticket, not an empty “shall we redesign” talk.
• Giants: run an internal card sort or query cluster first, and split only if a distinctive inner difference exists. Empty buckets: merge before renaming.
• Exclude seasonality and launch weeks from the threshold call, so a promotion spike is not a structural failure.
• Verify: the week a threshold crossed, did a data-backed restructure proposal actually appear. If the dashboard is green and someone guts the tree by feel, or the dashboard is red and nobody proposes, the signal is not wired into governance.

Related

• Within the group: G1.11.1 A taxonomy should leave room for future content, not fill up around what is known today · G1.11.2 Premature classes for tiny sets lose meaning as content grows · G1.11.3 The cost of changing architecture rises with inbound links, bookmarks, and settled mental models · G1.11.4 Structural changes need redirects so old paths do not break · G1.11.5 Governance decides who may add or merge classes, or the taxonomy inflates without order
• Adjacent: G1.07 Content inventory and audit · G1.03 Taxonomy and hierarchy · G2.04 Depth versus breadth tradeoff
• Search terms: category imbalance · taxonomy metrics · restructure trigger