Correlation analysis - autocapture special handling

[paolodamico]

Is your feature request related to a problem?

We now fully support autocapture within correlation analysis, yet the experience in autocapture is not great. Results are cryptic, and some times appear buggy (as some elements seem repeated) and some element names generic.

Describe the solution you'd like

I'd like us to have special handling for autocapture correlation. Ideally we would treat each element (in this case a property) as a single row element (with all the implications). Additionally we would show relevant pieces of information, rather than just the generic name we generate. Examples: URL of page, any data attributes set (per project settings), class names, and a way to see the entire element DOM chain.

Describe alternatives you've considered

Keep it as it is and hope users figure it out. Even with effort, it's hard to know which element the correlation analysis is referring to.

Additional context

This is more of a design topic first @clarkus.

Thank you for your feature request – we love each and every one!

[neilkakkar]

Right now, we have all the information we need to convert the above^ to something like this (from events table):

But, I agree that there's lots of scope for making this clearer, which would be nice to do for correlation.

Perhaps its even worth having a separate table for Autocapture, so we can customise it and promote it as much as we want: For people that don't have custom events, autocapture is indeed a unique place to provide value.

[paolodamico]

I think we could make it even better this time and whatever we come up with use it for other places in the app. For instance, most of the time, I'll want to see: the page where this is happening, key attributes (id, data-attr, ...) and the content. Only when the previous stuff doesn't provide enough information, I'd need to use the entire element chain to know what this is.

[clarkus]

The markup @neilkakkar shared is a good example of a challenging autocapture event. It's hard to tell which attributes are most meaningful. We're pretty dependent on the semantic quality of the product we're tracking. A reasonable selector chain for that element would be something like: div.insights-page div div div.insight-controls div div.tabs-inner div div div button[role=switch]. In this case the most identifiable attributes are those non-framework -insights classes. The role attribute is handy in identifying the target element somewhat, but mostly the page context helps you understand the broader context. A reasonable translation might be something like Clicked on the button with the role switch in the insights-page div. We might be able to set some order of precedence in weighting which attributes are most identifiable. Otherwise we might rely on the current url to set the broader context.

[paolodamico]

I think the URL & HTML content will always be relevant, we could then have a weighting rule for other attributes (e.g. the ones you set in the settings page), but I'm not sure the answer is showing things here in plain text, we may want to do a different visual component.

[posthog-bot]

This issue hasn't seen activity in two years! If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in two weeks.

[neilkakkar]

Still relevant 😅