Dynamic Variables in Link/Notification Survey Steps

Feature request

Is your feature request related to a problem?

Yes. In Link or Notification survey steps, links cannot include dynamic variables (e.g. person or event properties). This makes it impossible to pass identifying context—such as user ID or user traits—into the destination URL.

As a result, when a user clicks a survey link, we lose the ability to reliably associate downstream behavior (on the linked page) back to that specific person or survey interaction in PostHog.

Describe the solution you'd like

Allow dynamic variables to be used in Link and Notification survey steps, similar to how variables can be used elsewhere in PostHog.

For example, links could support templating with person or event properties:
https://example.com/onboarding?utm_source=posthog&utm_medium=survey&utm_campaign=nps&user_id={{person.id}}&email={{person.email}}

This would allow teams to:

• Attribute downstream behavior to survey respondents
• Pass context into external tools or flows
• Avoid custom instrumentation or duplicate tracking logic

Ideally, supported variables would include:

• Person properties
• Survey metadata (survey ID, response ID, etc.)
• Possibly event properties tied to the survey trigger

Describe alternatives you've considered

We’ve considered:

• Building custom surveys using the PostHog API
• Handling all survey logic and link generation in the application code

Both approaches are significantly heavier, less flexible, and require ongoing engineering investment. Implementing this purely on the app side is effectively a non-starter for what should be a lightweight product workflow.

A partial alternative would be allowing the API to update survey content dynamically without deploying custom survey code, but this still introduces unnecessary complexity compared to native variable support.

Additional context

This feature would unlock much stronger end-to-end attribution for surveys, especially for use cases like:

• NPS or feedback follow-ups
• Linking users to external forms, docs, or onboarding flows
• Passing UTM-style parameters for analytics consistency

This feels like a natural extension of PostHog’s existing dynamic property capabilities into surveys.

Debug info

- [x] PostHog Cloud, Debug information: [please copy/paste from https://us.posthog.com/settings/project-details#variables]
- [ ] PostHog Hobby self-hosted with `docker compose`, version/commit: [please provide]
- [ ] PostHog self-hosted with Kubernetes (deprecated, see [`Sunsetting Kubernetes support`](https://posthog.com/blog/sunsetting-helm-support-posthog)), version/commit: [please provide]

The issue names no files, tests, or entry points. Start by locating the survey Link and Notification step handling, then trace how dynamic variables are supported elsewhere in PostHog. Done means links can resolve the agreed person, survey, and event context variables, with behavior verified for the supported cases.