site-kit-wp: Enhance survey trigger infrastructure to persist surveys beyond a single page view and orchestrate showing
Right now, when the /survey/trigger/ request returns a survey, it is immediately shown. This mostly works for the case where we request a generic survey in the view_dashboard trigger, but for more event-based triggers it has major limitations: For example, if an event happens right before navigating to a different page (e.g. activating a module), if we wanted to trigger a survey for it, it would just be triggered right before the page navigation, but then it would be gone immediately before the user can possibly interact with it.
We need to enhance the infrastructure to cater for actual event based surveys better. At a minimum, surveys should not be displayed right away when they were triggered. There needs to be some kind of survey queue where these surveys are added to and stored in some way (e.g. client-side cache, or even persistently on the server). We also need to come up with heuristics / logic where, when, and how frequently to show surveys. For example, if there are 3 surveys in the queue, we also don’t want to show all of them right after each other, since we want to avoid overloading the user with surveys.
Do not alter or remove anything below. The following sections will be managed by moderators only.
Acceptance criteria
- Survey display should be decoupled from the survey trigger request
- The
getCurrentSurveyselector should be updated to be fulfilled by the newGET:core/user/data/surveyendpoint- The response should be cached on the client using the standard/default
useCache:truebehavior
- The response should be cached on the client using the standard/default
- The
survey-triggerresponse should be modified to return a simplified object with the shape{ status: Boolean }(this is somewhat redundant but necessary that the request returns valid JSON)- The corresponding
triggerSurveyaction should be updated accordingly such that it is only concerned with the trigger request and no longer concerned with survey state apart from the timeouts which should still apply
- The corresponding
- Survey display should be limited to the main Site Kit dashboard only, and happen only after the
view_dashboardtrigger has completed - No survey should be displayed more than once in a 12 hour period – this should also use a persistent mechanism for storing the timeout which does not rely on client-side cache
- Survey timeouts should only be set when a survey is displayed (no longer as part of a trigger)
- Survey related functionality should only function for authenticated users
Implementation Brief
- In
REST_User_Surveys_Controller, update thesurvey-triggerendpoint- Change the response shape to a simple
{ success: Boolean }, this can probably always betruesince there isn’t any use case for having knowledge of whether or not a survey was really enqueued or not on the client
- Change the response shape to a simple
Datastore
core/user
- Add a new fetch store for
getSurvey- Fetches the new
GET:core/user/data/surveyendpoint - Receives
currentSurveystate similar totriggerSurveytoday - Use default
useCachebehavior
- Fetches the new
- Update
fetchTriggerSurveyStore- Remove
reducerCallback– the response will no longer include anything to be received into state
- Remove
- Update
triggerSurvey- Remove bypass if there is a current survey – trigger should only be skipped if user lacks permissions or trigger is timed-out
- Update the
getCurrentSurveyselector- Add a resolver that fetches the new
GET:surveyroute via thegetSurveyfetch store above if no survey state is present (similar to other resolvers)
- Add a resolver that fetches the new
Survey Display
CurrentSurveyPortal- Remove from
Root; add toDashboardMainApponly - Add a condition to return
nullif theglobalsurvey is on cooldown (isTimingOutSurvey)
- Remove from
DashboardMainApp- Add a delay in rendering
CurrentSurveyPortalso that it is only rendered after 5 seconds
- Add a delay in rendering
Test Coverage
- Changes to
survey-triggerendpoint - Update Jest coverage for the
getCurrentSurveyselector - Update tests for
triggerSurveyaction - Add component tests for
CurrentSurveyPortal
QA Brief
- Setup a new site and connect the plugin to site-kit-local.
- Ask @eugene-manuilov to help you set up a survey for your site.
- Verify that survey appears on the dashboard and you can can interact with it as usual.
Changelog entry
- Enhance survey infrastructure to be more flexible.
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 16 (6 by maintainers)
@aaemnnosttv this is ready for review. Could you please take a look at my PR #6704?
@bethanylang Adding this to the upcoming release now that #6625 has been merged as these need to go together.
@aaemnnosttv Sounds good, LGTM!
@aaemnnosttv ACs LGTM ✅
One thing that’s not explicitly mentioned is whether the logic regarding survey timeouts etc should happen on the client or on the server. The ACs state that
GET:core/user/data/surveyshould (unconditionally?) return the first survey in the queue, but I was wondering whether we shouldn’t also do those survey timeout checks on the server and only return the first survey if none was completed/dismissed in the last 12 hours already.I think it’s okay to not force this to be a certain way in the ACs, but we should cover it in the IB.