Defining survey end pages

Every test run ends somewhere: on the survey's own thank-you page, on a screenout message, on a "quota full" notice, or on the panel's finish page after a redirect. SurveyTester can only judge a run - and compare it with the outcome a test case expects - if it knows which of these pages means what. Survey end pages are how you tell it.

This article is for administrators who set up project types, and for project managers who refine them for one survey.

Why this matters

Without end page definitions, a test run that stops is just stopped. You cannot tell whether a SurveyBot reached the complete, was screened out at the age question, or got stuck. Test cases cannot be checked against their expected outcome, and the outcome statistics stay empty.

Survey systems and panels all end differently. One survey shows "Thank you for your participation", the next redirects to https://panel.example.com/finish?status=complete, a third has a page called screenout_age. No tool can know your panels and templates in advance - so you describe them once, and SurveyTester recognises them in every run from then on.

The four outcomes

Outcome	Meaning
Completed	The respondent finished the survey.
Screenout	The respondent did not qualify and was sent out.
Quota	The respondent qualified, but the quota was already full.
Early Complete	The respondent finished through an early completion path.

What an identifier can be

For each outcome you add one or more identifiers. An identifier can be:

• A keyword - a piece of text that appears on the end page, for example You do not qualify. Only visible text counts; scripts and hidden data on the page are ignored.
• The start of the end page's URL, beginning with https:// - for example https://screenout.feedback-experts.com. Add a * to match more complex URLs: https://app.feedback-experts.io/survey/finish/*return=complete matches the finish page no matter which parameters sit in between. The * matches any number of characters, but the identifier must still start with http:// or https://.
• The start of a page name - for example screenout_ matches screenout_gender, screenout_age and so on.

Upper and lower case do not matter.

Three levels, added together

Level	Where	Typical use
Project type	Administration › Project Types › select the project type › Survey End Pages	Your panels' redirect URLs and your template's end texts - valid for every project of this type
Project	Project Details › General › Survey End Pages	A survey with its own end pages or an extra panel
Test case	The test case dialog › Endpage Identifiers	An end page that belongs to exactly this test case's expected outcome

The levels are added together - a project never loses what its project type defines. The project page shows the inherited identifiers with the label Inherited from project type, and the test case dialog lists everything that is Already configured for the selected outcome, so nobody adds an identifier twice.

Step 1: Define the end pages of a project type

1. Open Administration › Project Types and select the project type.
2. Switch to Survey End Pages.
3. For each outcome, type an identifier and press Enter. Add as many as you need - one per panel redirect, one per end text.
4. Changes are saved automatically.

Several project types often share the same panels. Use Copy to put all identifiers of one project type on the clipboard and Paste in another project type to add them there - identifiers that already exist are skipped.

Step 2: Refine them for a project

Open Project Details › General and scroll to Survey End Pages. Add the identifiers this survey needs on top of the inherited ones - for example the screenout page names of this particular questionnaire.

See also Project Level Survey End Pages and End Page Overview in Test Cases.

What happens during a test run

• The run ends on the end page. As soon as a page matches an identifier, the test run stops there - a SurveyBot does not keep clicking until it gives up.
• The run is classified by what it reached. The outcome of the matching identifier becomes the run's outcome, even if the test case expected a different one. That is exactly the difference you want to see.
• Overlaps are resolved predictably. When identifiers of several outcomes match the same page, the outcomes are checked in the order Screenout → Quota → Early Complete → Completed, so a screenout page with a generic "thank you" footer stays a screenout. When two identifiers match the same URL or text, the more specific one wins.
• End pages on other websites are captured too. Panels usually redirect to their own website at the end of the survey, for example app.feedback-experts.io/survey/finish/.... SurveyTester does not know that website as a survey system - but because you defined the page as an end page, it is stored as the last step of the test run, with its screenshot. You see in the test run exactly where the respondent landed.

Good to know

• Pages from unrelated websites do not become test run steps. If a tester opens a different website in the browser that runs the test - their webmail, their online banking - SurveyTester does not add it to the test run: no step, no screenshot, nothing in the project. Only pages that belong to a recognised survey system, or that you explicitly defined as end pages, become test run steps.
• Prefer URLs for panel redirects. A redirect URL is unambiguous. A keyword is the right choice for end pages inside the survey, where the URL does not change.
• Keep keywords specific. A short, common word such as thanks or finished can match a page in the middle of a survey and end the run there. Use a full sentence from the end page instead.
• Check it with one run. After setting up a new project type, run one test to the end and look at the outcome in Test Runs. If the outcome is not the one you expected, the end page did not match - compare its URL and text with your identifiers.