PostHog Implementation Guide
This page is a quick implementation reference for analytics and feature flags in CRED.
For complete, up-to-date details of all tracked events and available flags, refer to:
- docs/posthog.md in cred-web-commercial
- https://github.com/credinvest/cred-web-commercial/blob/develop/docs/posthog.md
Current Setup
PostHog is used for:
- Analytics (intentional posthog.capture() events)
- Feature flags (progressive rollouts by user/company)
Current integration is split by runtime:
- Web app client: posthog-js
- Chrome extension client: posthog-js
- Server-side: posthog-node
Conventions in Current Setup
- Prefer manual, intentional events over noisy auto-tracking
- Keep event names in
snake_case - Group events by feature prefix (example:
people_,companies_,custom_scoring_) - Use typed enums/constants for event names and property keys where possible
- Include
page_pathwhen relevant - Keep analytics non-blocking (do not let tracking failures break product flows)
How to Add Analytics for a New Page or Feature
- Define or extend an event enum for the feature area.
- Define property key constants/enums for repeated properties.
- Fire events at meaningful user actions only (not every render).
- Add context fields (
page_path, ids, counts, action metadata). - Validate naming consistency before merge.
Recommended event naming pattern:
- <feature>_<action>
- Examples: deals_exported, opportunities_stage_changed, ai_assistant_message_sent
Recommended property naming:
- snake_case
- Stable, explicit keys (entity_id, page_path, action_type, credit_cost)
Feature Flags: Current State
Feature flags are centrally defined and used to gate: - Entire pages - Navigation/menu entries - Feature-specific UI/actions
General behavior: - Flags are evaluated client-side and server-side depending on usage - In local development, flags are typically permissive for faster iteration - Page-level gating uses a wrapper/HOC pattern where applicable
How to Add a New Feature Flag
- Add the new flag to the canonical feature flag enum/type file.
- Create the same flag key in PostHog dashboard.
- Gate UI/page logic using the existing feature flag utilities.
- Handle loading state (
undefined) before assuming on/off in UI code. - Keep rollout scope narrow and place checks close to entry points.
PostHog Dashboard Steps (Operational)
Use this process in PostHog UI so product, engineering, and ops stay aligned:
- Create flag:
- Go to
Feature Flags->New feature flag - Use the exact key from code (example:
my-new-feature) - Add clear name/description and owner
- Define rollout conditions:
- Start with a small rollout or restricted audience
- Prefer explicit targeting rules before global rollout
- Add or remove workspaces (targeting):
- In flag conditions, target by workspace/company properties used by CRED
- Add allowed workspaces to enable the feature
- Remove workspaces to disable access
- Keep the workspace targeting list documented in the flag description/changelog
- Replicate flags across environments:
- Use PostHog's flag copy/duplicate capability to copy the same flag setup between environments
- Keep flag key and rollout logic consistent across dev/staging/prod
- Re-check environment-specific values before saving
- Validate after save:
- Confirm flag status in PostHog
- Confirm app behavior with flag on/off
- Confirm no unexpected exposure outside intended workspaces
Team Checklist (Before Merging)
- Event/flag names follow existing conventions
- No duplicate event names for different behaviors
- Required context properties included
- Tracking wrapped safely (no user-facing impact on failure)
- Feature is safe when flag is off
- PostHog flag has workspace targeting reviewed
- Flag replication across environments is completed/verified
- Detailed reference doc link included in PR description when relevant
Detailed Reference
Use the full PostHog reference for comprehensive event and flag inventory:
- docs/posthog.md
- https://github.com/credinvest/cred-web-commercial/blob/develop/docs/posthog.md