Autocapture for Phoenix LiveView

[neilberkman]

Congrats on the 2.0 release! The SDK looks great. We're evaluating PostHog to replace our current analytics setup, but have a pain point we'd like to solve first.

The Problem

The PostHog JS SDK looks like it has great autocapture for client-side events. Phoenix LiveView apps handle most interactions server-side via handle_event/3 callbacks, which are invisible to client-side autocapture. This means we need manual PostHog.capture() calls for every event, making it easy to miss tracking new features—which is our biggest pain point with our current setup.

The Opportunity

LiveView provides lifecycle hooks that can intercept all handle_event/3 calls. Event names are already semantic ("create_account", "delete_deal"), and user context is always available in the socket. This is actually better than DOM events for autocapture.

Proposed Approach

Add optional autocapture via on_mount hook:

defmodule MyAppWeb.SomeLive do
  use MyAppWeb, :live_view
  on_mount {PostHog.LiveView, :autocapture}

  # All handle_event calls now auto-captured
  def handle_event("create_account", params, socket) do
    {:ok, account} = Accounts.create_account(params)
    {:noreply, socket}
  end
end

What gets captured automatically:

• Event name
• User ID from socket assigns
• View name and live_action
• Sanitized params

Smart filtering to reduce noise:

# Ignore by default: validate, change, keyup, focus, paginate
# Always capture: create, delete, update, save, submit

Optional property enrichment for complex cases:

def handle_event("create_account", params, socket) do
  {:ok, account} = Accounts.create_account(params)

  # Enrich with computed properties
  socket = PostHog.enrich_properties(socket, %{
    method: if(account.fast_add, do: "fast_add", else: "full"),
    stage: format_stage(account.stage)
  })

  {:noreply, socket}
end

Implementation

The core is straightforward—attach to LiveView's :handle_event hook:

def on_mount(:autocapture, _params, _session, socket) do
  socket = attach_hook(socket, :posthog, :handle_event, fn event, params, socket ->
    if should_capture?(event, socket) do
      properties = build_properties(params, socket)
      user_id = get_in(socket.assigns, [:current_user, :id])
      PostHog.capture(event, %{distinct_id: user_id, properties: properties})
    end
    {:cont, socket}
  end)

  {:cont, socket}
end

Impact

For our app (770 lines of analytics code, 49 tracked events):

• Simple events: zero code needed (currently 150 lines)
• Medium complexity: one-line enrichment (currently 320 lines)
• Complex events: custom enrichment helper (currently 300 lines)

Estimated 50-70% reduction in analytics boilerplate.

Questions

1. Is this something that would fit in the SDK?
2. Any concerns about the approach?
3. Would you prefer this as a separate package?

We're considering building this either way, but wanted to check if you had thoughts on design or would be interested in collaborating.

[martosaur]

Hi @neilberkman

I think LiveView integration would be a very welcome addition. There's in fact an issue about it #29 that discusses implementing it on top of LiveView telemetry. I personally don't have much experience with either LiveView hooks or telemetry though. What was your experience like? Any pros and cons you ran into?

[neilberkman]

Hi @neilberkman

I think LiveView integration would be a very welcome addition. There's in fact an issue about it #29 that discusses implementing it on top of LiveView telemetry. I personally don't have much experience with either LiveView hooks or telemetry though. What was your experience like? Any pros and cons you ran into?

Hey @martosaur I'm not sure how to interpret your question, so let me cover a few bases:

We've been using LiveView in production for about 5 years now (B2B SaaS app) and I think it's the best web framework out there, period - none of the SPA complexity, everything in Elixir, real-time just works, super productive. Biggest pain point for our app is that analytics instrumentation is very manual and tedious (due to our own choices, nothing specific to LiveView), which is the reason for this proposal.

Quick note on #29 - I see that's focused on page_view tracking (LiveView navigation). This proposal should be complementary to that - it's about autocapturing user interactions within LiveViews (button clicks, form submissions, etc via handle_event/3). Both would use telemetry under the hood, but track different types of events. The page_view tracking in #29 would give you "user visited /deals page" while this would give you "user clicked create_deal button, user submitted deal_form, etc."

Regarding hooks vs telemetry for the handle_event autocapture - I initially proposed hooks because it felt more LiveView-native. You explicitly opt-in with on_mount, and it's clear what's happening. But after considering the telemetry events LiveView already emits, I think this is actually the better foundation. It requires zero code changes (just a global handler), it's the standard Elixir observability pattern that Phoenix, Ecto, and Oban all use, and you get better error isolation since handler exceptions won't crash LiveViews. Plus there's lower overhead with a single global handler vs per-socket hooks.

The enrichment pattern ends up being identical for both approaches anyway:

# Set properties in socket.assigns
socket = assign(socket, :posthog_enriched, %{custom: "props"})
# Telemetry handler or hook picks it up

So I'd actually favor starting with telemetry-based autocapture for the SDK, with an optional enrichment helper. You can always add hooks-based opt-in later if users want more granular control.

Just to be clear though - I haven't actually built this yet. This is all from design and research. I did look into LiveView's telemetry events, hook lifecycle and timing, and how property enrichment would work with either approach. The telemetry approach seems cleaner after looking at all the details.

If PostHog is interested in this direction, I think the basic setup would be pretty simple:

# In application.ex
PostHog.LiveView.attach()

# That's it - all handle_event calls now auto-captured

For more complex cases where you need computed properties:

def handle_event("create_account", params, socket) do
  {:ok, account} = Accounts.create_account(params)

  # Optional enrichment for complex properties
  socket = PostHog.enrich_properties(socket, %{
    method: account.method,
    stage: account.stage
  })

  {:noreply, socket}
end

And filtering noisy events via config:

config :posthog,
  autocapture_ignore: [~r/^validate/, ~r/^change/]

This gives users zero-friction autocapture that just works, optional enrichment for complex cases, and simple opt-out via config or socket assigns.

A few questions to help figure out next steps:

• Is telemetry-based autocapture something you would want in the SDK? Or would you prefer it as a separate package?
• Any concerns about the approach - performance, API design, etc?
• Would you want LiveComponent events too? Same pattern, just different telemetry events.

I'm interested in getting this built one way or another - happy to kick off a prototype to validate the approach, but would love your / PostHog's involvement since you all know the SDK architecture better. Let me know if I'm still missing your question!

[neilberkman]

Any interest in engaging with this or should I close it out?

[rafaeelaudibert]

We're definitely interested @neilberkman, but we don't have any internal Elixir usage/public requests, so there isn't a pressing need for us to build this right now. @martosaur is very active on this repository for his own professional/personal needs, but it doesn't seem like he's using this so I wouldn't expect him to build this anytime soon.

If you could be kind enough to contribute an 80% PR for this, I'm happy to take it across the finish line and have it released for general use.