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 getCurrentSurvey selector should be updated to be fulfilled by the new GET:core/user/data/survey endpoint
    • The response should be cached on the client using the standard/default useCache:true behavior
  • The survey-trigger response 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 triggerSurvey action 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
  • Survey display should be limited to the main Site Kit dashboard only, and happen only after the view_dashboard trigger 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 the survey-trigger endpoint
    • Change the response shape to a simple { success: Boolean }, this can probably always be true since there isn’t any use case for having knowledge of whether or not a survey was really enqueued or not on the client

Datastore

core/user

  • Add a new fetch store for getSurvey
    • Fetches the new GET:core/user/data/survey endpoint
    • Receives currentSurvey state similar to triggerSurvey today
    • Use default useCache behavior
  • Update fetchTriggerSurveyStore
    • Remove reducerCallback – the response will no longer include anything to be received into state
  • 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 getCurrentSurvey selector
    • Add a resolver that fetches the new GET:survey route via the getSurvey fetch store above if no survey state is present (similar to other resolvers)

Survey Display

  • CurrentSurveyPortal
    • Remove from Root; add to DashboardMainApp only
    • Add a condition to return null if the global survey is on cooldown (isTimingOutSurvey)
  • DashboardMainApp
    • Add a delay in rendering CurrentSurveyPortal so that it is only rendered after 5 seconds

Test Coverage

  • Changes to survey-trigger endpoint
  • Update Jest coverage for the getCurrentSurvey selector
  • Update tests for triggerSurvey action
  • 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)

Most upvoted comments

@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/survey should (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.