Ghost completes: the reconciliation problem nobody budgets for

The GDQ feedback loop code frame defines a ghost complete as a complete recorded in the participant system that is not recorded as complete in the survey data. Code 17.

In plain terms: the router says a respondent completed, and your survey export has no completed response for them. Somebody got credited for work that does not exist in your dataset.

Ghost completes rarely show up as a line item. They show up as a field report that says 500 completes and a dataset with 487, and an afternoon of someone trying to work out where 13 went.

How they happen

Someone opened the complete endlink without finishing. A respondent who saw the complete URL, in the page source, from a forum or from an earlier session, opens it directly. Unsigned endlinks make this possible. Signing them mostly makes it stop.

The survey redirected before it saved. Some survey configurations fire the end redirect before the final page's data is committed, or a respondent's connection drops between the last submit and the save. The redirect reaches the router; the response never reaches the survey database.

The complete link is on the wrong page. A branch that should terminate falls through to the main end-of-survey element. The respondent is recorded as a complete by the router and as a partial or terminate in the survey.

Test sessions. A programmer clicks through the live link to check the end page. The router records a complete; the programmer deletes their test response from the survey. If the test did not use a sandbox session, the complete is now a ghost.

Duplicate-response cleanup inside the survey platform. Some platforms deduplicate or discard responses automatically. The router has no way to know.

How to find them

The only reliable method is matching IDs, and it only works if the session ID is stored in the survey.

1. Export router sessions with status complete for the project. On ResearchDart the export includes the rdid for every session.
2. Export completed responses from the survey with the stored rdid field.
3. Find router completes whose rdid has no completed response in the survey.
4. Before reversing anything, check the survey platform for partial or terminated responses with that rdid. A terminate in the survey means the end-of-survey logic is wrong, which is a programming fix rather than a supplier problem.

Do this before approving the invoice, not after. Reversing a complete three months later is harder for the supplier and harder for you.

How to prevent them

• Store the session ID as the first thing the survey does. If the ID is missing from a response, you cannot match it.
• Sign endlinks, or report completes server-to-server from a system that only fires after the response is saved. The status API's first-outcome-wins rule means a later redirect cannot override what the server already recorded.
• Test with sandbox sessions only. They never count toward totals.
• Put the complete redirect after the final save, and test the path on a slow mobile connection.
• Reverse with code 17 and a note such as "no survey record for rdid; survey shows no partial either". That tells the supplier whether to look at their own respondent or at your survey.

Why the code matters

Before a shared code existed, ghost completes were usually reversed as generic quality removals. That pointed suppliers at their respondents when the cause was often a survey configuration or a test session. Code 17 says "this complete does not exist in our data", which is a different conversation from "this respondent was bad". Suppliers deserve to know which one they are having.

More on using the codes: the GDQ removal codes.