In a general sense, this feature refers to the functionality where you can trigger certain actions outside the PostHog environment when certain actions are triggered. It extends on our current messaging webhook & Zapier functionality. This also greatly builds on our plugins functionality. It could even be seen as the data-out part of the plugins functionality.

Context

Currently if you want to create workflows based on actions taken by a user, you would have to connect Zapier (n8n coming soon) and then create workflows in there based on actions triggered on PostHog. Some examples of such workflows include:

• Welcome email after a user signs up or becomes a paid customer.

• Link user information between platforms (e.g. create customer record on orbit.love or customer.io when a user signs up).

• Notifying customer support about a user action on Slack. An example from an actual user, they trigger a Slack message when a user requests an onboarding kit. The CX team then sends them their physical team and would love to be able to mark that request as processed.

• Sending unusual activity / fraud alerts.

• Goal: Strengthen our strategic position of a single platform to make products successful (removing the need of yet another product). Increase retention of teams by providing more value that could even be considered mission-critical.

• Assumptions: A few assumptions for this feature set,

  • We can cover 80% of use cases with basic trigger functionality. Or, there's a select few use cases that already provide a bunch of value.
  • The value of having this in a single platform outweights the cost of creating your own manual workflows (vs. integrating with something like Zapier that already includes a bunch of integrations out of the box).
  • Teams are using PH as their primary source of behavioral information. If you have a pipeline in the middle (like Rudderstack or Segment), it might not be as attractive.

• Success metrics: A few ideas on how to measure success for this,

  • Number of workflows created and active.
  • Number of teams with workflows.
  • Retention of teams with workflows vs. teams without workflows

In a general sense one key question that needs to be raised for a feature like this is whether it makes sense to build a version ourselves or to strengthen our integrations with other software that focuses on this.

Current numbers

• Currently from a sample of only cloud users, 1.6% of projects have enabled some sort of webhook.
• From the sample above, 6.5% of actions trigger a webhook.

Target user

One thing that it's particularly important to keep in mind is our target user. We're looking for the technical user, and particularly not the marketing or customer success team. The reason this is of particular importance is that for non-technical users, a key value of a feature like this comes from the built-in integrations, and it's definitely not our core to build the myriad integrations that dedicated tools that n8n or Zapier have.

Another important consideration is the question/assumption of whether technical users will have the use case for these integrations. A case could be made that these integrations are mostly targeted for business, CX, marketing, sales teams, ... which in turn require the out-of-the-box integrations previously mentioned.

Initial Ideas

• Most basic version is allowing to trigger vanilla HTTP requests after certain actions are triggered. We would need some basic data transformation too as no other service will have the same data structure as we do.
  • As we're creating this feature for technical users, we could even create something light on the UI side (maybe even code-based?)
• Allow scheduling / delaying actions in the workflow.
• Provide stats on number of triggers, historic triggers (for debugging), and a version control system for changes in workflow configuration.
• Allow creating a library of workflows, we could then have something similar as to what we have for plugins, in which community workflows can be created. For instance, if I create a workflow to create a customer record on Hubspot after a user sign up, I could share that workflow for anyone else to use them.
• Allow more complex decision functionality. This could be particularly served using a code editor, which would in turn allow for even more complex logic. Examples: if/then logic, wait for webhooks, parse other data formats (e.g. HTML, XML, CSV, ...), ...
• Track down success metrics for workflows. For instance, if I send an email, track down opening and clickthrough rate. If I send a churn prevention campaign, track down if users come back to the app.
• Feature flag (A/B test) flows. Allow to determine a FF state on the go to trigger different workflow steps for users.
• A radically different approach would be consider a tight integration with OSS that already does this. We could for instance allow a very easy installation of n8n in the same instance that gets already shipped fully linked to PostHog.

What others are doing

• This is in essence a more basic version of what Zapier (docs) and n8n (docs) do. Some key features worth mentioning: you can filter stuff on trigger actions and conditionally take different next steps depending on event props, you can make vanilla HTTP requests (e.g. to obtain/enrich your information, trigger some action on another system ...) at any time, you can manipulate the data at all times (e.g. if the service you're reaching uses a different currency format), you can add timing considerations (e.g. timeouts / cool downs / scheduling), automatic retries, and trigger history.

  

• Braze (relevant docs) (targeting mostly marketing campaigns) has a relevant event-triggering functionality where you can fire campaigns based on a schedule, after an action or after an API request.
  

• Mixpanel used to have a messages & experimentation feature now deprecated, which allowed sending emails, push notifications, ... to users, as well as A/B testing different variants and measuring relevant campaign results.

• Leanplum & Airship are more targeted downstream products for messaging & engaging customers. These mostly fall out of the scope of this feature, but added here to provide context on stuff that might be too specialized to support.

Wireframes

This time I decided to include some wireframes to spice up the discussion and get more ideas/feedback flowing.

Workflow list

Workflow details (UI-based)

Workflow details (code-based)