Ask for feedback after cancellation is scheduled

Distinguish intent, scheduling and the subscription ending

The example reports subscription_cancellation_scheduled only for the confirmed middle step. An open form, a confirmation-button click or a failed request is not enough. Match the timing and event name to the state your own backend actually accepts.

Show the confirmation before requesting feedback, and keep a clear way to leave. The survey is not a required reason field, a condition of cancellation or a replacement for your normal confirmation.

Use a neutral reason question and a conditional follow-up

The recipe asks “What is the main reason you decided to cancel?” without assuming that the price was too high, a feature failed or a discount would change the decision. The survey itself is optional, even though its first question is required within the questionnaire.

The optional text question is “Is there anything else you would like us to know?” It appears for missing_feature, hard_to_use and other; price and no_longer_needed finish after the first question. All five paths are completions, not screen-outs. Someone may have more than one reason, so a single choice is a useful summary rather than a complete explanation. Preview every path before publishing.

Save this complete definition as survey.json and use the public CLI instructions in the React guide, or recreate its questions and conditions in the dashboard. The JSON is a survey definition, not SDK initialization data or a dashboard import.

{
  "schema_version": 1,
  "name": "Cancellation scheduled feedback",
  "content": {
    "schema_version": 1,
    "title": "Help us understand your decision",
    "description": null,
    "language": "en",
    "collect_partial_responses": true,
    "questions": [
      {
        "id": "cancellation_reason",
        "kind": "single_choice",
        "prompt": "What is the main reason you decided to cancel?",
        "required": true,
        "options": [
          {
            "id": "price",
            "label": "The price no longer fits my needs"
          },
          {
            "id": "missing_feature",
            "label": "A feature I need is missing"
          },
          {
            "id": "hard_to_use",
            "label": "I found it difficult to use"
          },
          {
            "id": "no_longer_needed",
            "label": "I no longer need it"
          },
          {
            "id": "other",
            "label": "Something else"
          }
        ]
      },
      {
        "id": "cancellation_details",
        "kind": "text",
        "prompt": "Is there anything else you would like us to know?",
        "required": false,
        "max_length": 2000,
        "logic": {
          "show_when": {
            "type": "answer",
            "question_id": "cancellation_reason",
            "comparison": {
              "operator": "one_of",
              "value": [
                "missing_feature",
                "hard_to_use",
                "other"
              ]
            }
          }
        }
      }
    ],
    "thank_you": "Thank you for sharing your feedback."
  },
  "rules": {
    "schema_version": 1,
    "audience": {
      "type": "field",
      "source": "event_property",
      "key": "flow_version",
      "comparison": {
        "operator": "eq",
        "value": "react-cancellation-v1"
      }
    },
    "triggers": [
      {
        "type": "event",
        "event_key": "subscription_cancellation_scheduled"
      }
    ],
    "frequency": {
      "mode": "custom",
      "max_shown": "1",
      "after_seen_seconds": 604800,
      "after_dismissed_seconds": 604800,
      "after_completed": {
        "type": "never"
      },
      "after_screen_out": {
        "type": "never"
      }
    }
  },
  "sampling_percent": 100,
  "priority": 0,
  "enrollment_epoch": "cancellation-v1"
}

• Install and publish with the React guide →

  The event definition, CLI commands and end-to-end verification steps.

• Writing useful surveys →

  Question wording, choices and interpretation.

Send the minimum useful context

import userreason from '@userreason/js';

void userreason.event('subscription_cancellation_scheduled', {
  flow_version: 'react-cancellation-v1',
  plan_tier: 'starter',
}).catch(() => {
  // Keep the confirmed cancellation unchanged if feedback is unavailable.
});

flow_version separates this recipe from other cancellation flows; plan_tier describes the fixed fictional plan in the sample. Keep the event free of account IDs, payment details, email addresses, billing URLs and free-form reasons. Survey answers travel through the separate response path.

The recipe targets event_property flow_version equal to react-cancellation-v1 and uses one display per tracked visitor in enrollment cancellation-v1. These browser values are unverified. Do not use them to decide billing access or infer that the backend state is trustworthy to another system.

Choose storage, response access and retention to fit the information you collect. The sample’s memory storage avoids persistent visitor state in the browser but does not prevent requests or server-side answer storage. Do not ask for payment-card details or other secrets in an optional reason field.

• Events and verified backend facts →

  Separate browser context from trusted event provenance.

• Storage and consent →

  Review the behavior before collecting real feedback.

Keep feedback completion separate from cancellation

Check one complete test answer in the dashboard before reading results as customer evidence. Partial collection is enabled in the recipe: advancing past the first question may save the reason even when the person leaves before submitting the optional detail.

Typing without advancing does not save the current edit. A partial response reports which answers were saved, not whether the person changed their mind about cancelling. Keep partial and completed feedback counts distinct, and keep both separate from the billing system’s cancellation state.

The free allowance is 10,000 responses per workspace per UTC calendar month. A response counts once when its first answer is saved, including partial responses. The allowance resets at 00:00 UTC on the first day of the month. At the limit, new responses stop being recorded; a counted response can still finish. A feedback quota must not affect cancellation in your application.

• Partial responses →

  Saved-answer boundaries and response-status filters.

• Response allowances →

  The workspace allowance and custom enterprise limits.

Turn reasons into questions you can investigate

Review answers with the survey version, time period, plan category and response status. Respondents are a subset of people who scheduled cancellation and chose to answer. Their percentages are not the cancellation rate for your customer base.

A reported reason can point to a problem without proving its cause or size. Show counts alongside percentages, preserve contradictory answers and keep uncertainty visible when the sample is small. If you change the product or billing flow, evaluate its outcome separately rather than claiming that a new survey result proves retention improved.

Test the whole path before asking customers

The recipe and its five answer paths were reviewed on 18 October 2026. Use a test site and verify the successful and failed demo cancellation paths before adapting the code. The example uses a fictional local backend; your production billing result and real saved responses need their own checks.

• Download the React example →

  App code, local cancellation stub and the paired recipe.

• Follow the React integration guide →

  Setup, event registration, review, publication and response verification.

• Onboarding feedback →

  A different moment: an explicit pause before setup is complete.

• Next.js integration example →

  Use the App Router lifecycle when your application runs on Next.js.