Implement posthog_events submodule to track user actions

Created on 15 October 2024, 3 months ago

Problem/Motivation

See https://posthog.com/docs/libraries/php#capturing-events and https://posthog.com/docs/product-analytics/capture-events?tab=PHP to understand what we'd like to do.

The posthog_events submodule should subscribe (where possible, in other cases we'll probably need good old hooks...) to typical Drupal user actions.

For now:

  • Registration
  • Login
  • Logout

Maybe we should even put this into a further posthog_events_user submodule?
Because there might also be other cases to track. for example page access, which could similarly go into posthog_events_request

Late we could have posthog_events_webform and others...

Basically the module should track user actions server-side.

Another important thing the base module should offer is to also provide the Javscript-Part of Event tracking and connecting the backend session with the frontend session seamlessly so that Posthog knows it's the same user and other Drupal developers can simply use JS or PHP SDK without having to mess around with the identity themselves.

See https://posthog.com/docs/product-analytics/identify

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

📌 Task
Status

Active

Component

Code

Created by

🇩🇪Germany Anybody Porta Westfalica

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @Anybody
  • 🇩🇪Germany Anybody Porta Westfalica
  • 🇩🇪Germany Anybody Porta Westfalica
  • 🇩🇪Germany Anybody Porta Westfalica
  • 🇩🇪Germany Anybody Porta Westfalica
  • 🇩🇪Germany Anybody Porta Westfalica
  • Assigned to Grevil
  • 🇩🇪Germany Anybody Porta Westfalica
  • 🇩🇪Germany Anybody Porta Westfalica
  • 🇩🇪Germany Grevil

    Let's keep it at "posthog_php_events" for now. We could also rename it to "posthog_events", to also have access to the js.

  • 🇩🇪Germany Grevil

    I am not really seeing the benefit of creating custom events for all of these user hooks. Why do we care if a user is blocked, unblocked, has updated their credentials, has deleted their account etc.?

    Currently, the user is identified on login server / client sided, and that's most important. I understand the use of custom events for specific sites (e.g. how many people bought product a, how many bought product b), but not here? Let's discuss this first, before implementing.

  • 🇩🇪Germany Anybody Porta Westfalica

    We care, because these are important events or conversions for analytics. If you want a report on how many users were blocked in month X or how many accounts were deleted, you need this information.

    What do you mean by

    updated their credentials

    ? I can't see that requiremen above.
    But the events you listed are all of minor importance, while the issue summary lists the most important events.

    Let's keep it at "posthog_php_events" for now. We could also rename it to "posthog_events", to also have access to the js.

    Definitely yes, tracking JS events is not a Drupal think and it's easy to be done. We're providing a DRUPAL specific submodule here, which adds events for typical DRUPAL events, that's the point. We're not creating an events SDK. Maybe that was unclear.

    A super important one is confirming the email address (= registration) ( Add server-side tracking for registration confirmation Active ) which means showing the page after clicking the password confirmation link. That's the only place where you can be sure that this conversion (registration) was really finished.

    All the other events beside these 4 above are quick-wins which already have Drupal hooks and should be easily implemented in 3 lines, that's why I think it makes sense. We can copy them from the billwerk module.

  • 🇩🇪Germany Anybody Porta Westfalica

    PS: Of course many events will also be available in the ECA integration as alternative, but this is more lightweight.

  • 🇩🇪Germany Grevil

    What do you mean by

    updated their credentials

    Probably "hook_user_update()". But yea, I still feel a LOT of these hooks have minor importance, but yea it's basic boilerplate code, so why not.

  • 🇩🇪Germany Anybody Porta Westfalica

    Okay, yes I think "profile updated" is very very minor, as the consequences are unclear. But many of the other events have business meaning.

  • 🇩🇪Germany Grevil

    Alright, done, please review!

Production build 0.71.5 2024