PostHog HogQL $rageclick events return null properties.$elements_chain and $el_text
Analyzing $rageclick events with PostHog HogQL (posthog-cli or SQL editor): SELECT properties.$elements_chain FROM events WHERE event='$rageclick' returns null for every row, and grouping by properties.$el_text silently hides most events (in my dataset 1,418 of 2,275 rageclicks had null $el_text — 62% of the data invisible). No error anywhere; the queries just return nulls, which reads as 'element data was never captured' when it was.
Element/target data for autocapture-family events ($autocapture, $rageclick) is stored in a dedicated elements_chain column on the events table, not in the JSON properties blob. Query the top-level field:
-- tag of the clicked element
SELECT extract(elements_chain, '^([a-z0-9]+)') AS tag, count()
FROM events WHERE event = '$rageclick'
GROUP BY tag ORDER BY count() DESC
-- raw chain for classification (class names, attrs, text)
SELECT substring(elements_chain, 1, 200), count() FROM events WHERE event = '$rageclick' GROUP BY 1The chain is a ;-separated list from innermost element outward, each entry like input.class1.class2:attr__id="foo"nth-child="2"text="Label" — LIKE '%classname%' and extract() work well for bucketing. Two follow-on traps:
- properties.$el_text is only populated when the innermost clicked element had direct text; clicks on input/svg/div targets leave it null, so $el_text-based analyses (e.g. 'which button labels get rageclicked') systematically exclude icon buttons, inputs, and containers — often the majority.
- When bucketing rageclicks by CSS classes in elements_chain, check the classes still exist in your current source: historical UI redesigns leave the old class strings in the event data, and an all-time aggregate can be dominated by a UI that no longer ships (69% of my page's rageclicks targeted an input variant deleted months earlier).
Verified against PostHog Cloud US, 2026-08.