Long running surveys don't work well

[neilkakkar]

Bug description

We’re not dealing well with long running surveys where the same survey can be shown to the same person again and again as they browse incognito / clear cookies / etc. etc..

For example, if you have a churn survey that targets on whether a user churned from product X property.

Two things that would help here I think:

1. Time-sensitive event based targeting, so the survey fires in the session only if the event happens in the session (probably happening this quarter)
2. Change our targeting filter to have an expiration date, like it remains true only for a week after disabling.

Both would work, but (2) currently is too hard for end users to implement because we don't have #17392

[neilkakkar]

related to (1): #16681

[neilkakkar]

Option (3) that works better for some use cases:

Whenever a user responds, we should add a $survey_response/<surveyID> property to the user. This way, we can target users who don't have this property set for surveys.

It's a bit rougher than the above two, specially around the UX, (because the property needs to exist before we can target) but much faster & can unblock long running surveys for now.

[Phanatic]

Related issue : #22099

I think both of these can be combined and the motive here is to give people the ability to repeat a survey and track survey responses on each of those "iterations".

Here's what we need to do to solve this :

Data model changes to the surveys table

1. Add properties to the survey data model to track

Column name	type	description
survey_frequency
survey_max_iteration_count	integer

survey_frequency (cron like syntax for interval between iterations), survey_max_iteration_count. so a user can say, repeat this survey 4 times, once every 3 months , they can also just leave the survey_max_iteration_count as zero to have an infinitely repeating survey `repeat this survey, once every 3 months

Once we have the above properties, we can show the user an interface to set the frequency of the survey and how many times it should repeat. These two properties are nullable and we need to make our work backwards compatible to make existing survey responses function without issues to show NPS scores etc.

UI changes.

1. Show the user an interface to pick the repeat interval of the survey, this can be relative (every 4 months) or absolute (pick specific dates).
2. Show the user an interface to pick the iteration count, how many times should this survey repeat?
3. If a survey has an iteration count of more than 1, change the existing UI to run custom clickhouse queries to account for a survey with multiple response sets, one for each iteration.

posthog-js changes.

1. To decide when to show a survey, see if a user has a survey response submitted for the current survey start date, and show the survey if they haven't.
2. When a survey is submitted, add properties for survey iteration count and survey start date in the current iteration to the person properties. So this person is accounted as having submitted the survey for this iteration/start date.
   $survey_response/${survey.id}/${survey.iteration_start_date}/
$survey_response/${survey.id}/${survey.iteration_count}/

out of scope

1. Survey creators cannot change the frequency once a survey is created, as this will change the way we calculate the survey response rates.