Measure the support journey
The proposed event mapping would distinguish opening support, starting a conversation and reaching an outcome.
Integrations PostHog
PostHogPlanned
PostHogPlannedPostHog context for better support investigations.
Plan a PostHog connection for consent-aware support events and selected troubleshooting context, with customer data minimized.
Planned connector. Native setup is not available yet. The workflows below describe the intended scope; release depends on provider access and testing.
Analytics
What we’re planning to connect.
- 01PostHog
- 02Planned connection
- 03Message support
Use permitted replay context
Where a business chooses replay, keep the session link behind its own access controls and masking rules.
Avoid transcript analytics
Support messages may contain private information. Event payloads should use an allowlist instead of raw conversation text.
The right context
Be precise about what connects.
Define the data, permissions and destination before putting the workflow in front of customers.
Allowlisted support events
Pseudonymous identifiers
Permitted session links
Prepare for the connection
Define your first workflow.
- 01
Choose the first workflow
Define a small event schema and decide which identifiers are appropriate for your consent model.
- 02
Agree on data and permissions
Decide which fields may be read, which people may use them and whether any separate write action is needed. Native setup is not available yet.
- 03
Define the acceptance test
Test a visitor who declines analytics and verify support still works without sending analytics events.
Before you connect
PostHog integration questions
Can I connect PostHog to Message today?
The native connector is planned. The workflows on this page describe the proposed design; there is no native installation to activate yet.
What should we test before using it with customers?
Test a visitor who declines analytics and verify support still works without sending analytics events.