Skip to main content

Troubleshooting (Decipher / Forsta)

The failure modes that actually come up, as symptom → cause → fix. Each one is explained in full on the page it belongs to; this page exists so you can find it from the symptom.

Every send returns 401​

Symptom — the dqc_debug column shows an error on every response, or DQC receives nothing at all while the survey runs normally.

Cause — DQC_API_KEY is still the placeholder in the server‑side copy. The key appears in two places and both must be set: the toolbox import URL near the top of the XML (client‑side) and the DQC_API_KEY = "…" variable at the top of <exec when="init"> (server‑side, read by the send_results_dqc() Authorization header). Replacing only the first leaves every send unauthorized.

Fix — set both to your own key. Generate one if you have not already. The entry check dqcValidateApiKey() stops the survey while the placeholder is still there, so add that <exec when="started"> block and the mistake surfaces on your first test link instead of on every response.

"API call to api.dqco-op.com is not allowed"​

Symptom — an error naming api.txt and your client directory, on every attempted send.

Cause — Decipher only permits server‑side calls (v2SendRequest) to pre‑approved domains, and the DQC hostname has not been authorized for your account yet.

Fix — this one is not something you can do yourself. Email SurveySupport@forsta.com and ask them to add api.dqco-op.com to both api.txt and hooks.py, and allow it for v2SendRequest (the request_allowed hook). api.txt alone is not enough — support sometimes stops there. It can take a few days. Full request text and sample email: Step 0.

Every participant gets an error page instead of the first question​

Symptom — Decipher's fatal error page naming a sample source, for all traffic, not only the source it names.

Cause — one of your <samplesource> elements has no <title>. An untitled source has no supplier name to resolve, so dqcValidateSampleSources() stops the survey for everyone rather than letting one supplier's responses arrive unattributable.

Fix — title every <samplesource>, including the default one (usually list="0"). See what that looks like.

vlistSellerName arrives empty​

Symptom — responses reach DQC with no seller, which every response is required to carry.

Cause — the participant resolved to a sample source whose title is missing or is one of Decipher's own placeholders ((no title), Vlist 3). Participants who arrive with no list value in the URL land on the default source, so the default needs a real supplier title just as much as the rest.

Fix — give that source a supplier title, or send an explicit sellerName / supplierIndex, which takes precedence. See Company Mapping and the vlistSellerName field.

Scores arrive as 0, or identifiers as "Submission too quick, data not processed"​

Symptom — early responses carry a device score and Data Trust Score of 0, a persona of NONE, and Submission too quick, data not processed in rid / pid / cty / sub / sid.

Cause — save_dqc_data() ran before the toolbox finished its round trip to DQC, so there was nothing to copy yet. These are the deliberate fallbacks, not an error. Note the score fields fall back to '0', not to the placeholder string — only the identifier fields get that.

Fix — nothing, if it only happens on the in‑progress send: the final send overwrites it. If it happens on terminations, your termination block is too early — '0' is at or below every threshold, so an early block terminates everyone. Move it after the second question's <suspend/> and keep the pid.val placeholder guard. Why.

Terminations fire on the wrong respondents, or on nobody​

Symptom — good respondents are terminated, or a threshold appears to do nothing.

Cause — the threshold is written on the wrong scale. dqc_data.dcs.val holds the device score on its full 0–100 scale and dqc_data.dts.val the Data Trust Score on 0–1000. The narrower 0–40 / 0–420 figures are recommended threshold ceilings, not a second scale.

Fix — write the threshold on the same scale as the stored value, and remember termination happens when score <= threshold, so a higher threshold terminates more people. See One scale per score.

No dqc_data or dqc_debug column in Responses​

Symptom — the holders are in the XML but the columns are not in the response view.

Cause — both are hidden questions (cond="0"); Decipher does not show them until you add them as columns.

Fix — in Responses → View/Edit Responses, click Choose Columns, add the dqc_data and dqc_debug survey variables, then Apply. See Viewing what was sent.

The survey will not compile after adding a condition​

Symptom — Decipher rejects the XML, often pointing at a cond or an <exec> block.

Cause — a literal &, < or > somewhere inside XML that Decipher parses as markup — including inside code comments.

Fix — use Decipher's word form le instead of <= in conditions (see why), build an ampersand from chr(38), or wrap the exec in <![CDATA[ … ]]>.

Still stuck? Send it to us​

You do not have to work it out alone — contact DQC support and we'll look at it with you. Any of these is enough to get started, and the more you can include the faster we can pin it down:

  • The dqc_debug value for an affected response. This is the most useful single thing you can send: it records the exact payload that was dispatched, or the error that stopped it. See Viewing what was sent.
  • Your survey XML from Decipher — the whole thing, or just the <exec> blocks and any <term> blocks. We'll read it against the current integration and tell you what's off.
  • A test link to the survey, if you'd rather we reproduce it ourselves.

We're also happy to review your setup when nothing is visibly broken:

  • A custom <term> you've written, before it goes live — worth a second pair of eyes, since a termination condition that looks reasonable can still fire on every respondent (here's how).
  • Fields you want to send beyond the defaults, or a mapping you're unsure about.
  • A survey you're about to field, as a sanity check that the integration is wired correctly.

Redact your API key before sending anything, and say which state the survey is in — dev, testing, live or closed. Every payload already carries it as decipherSurveyState, so if you're sending a dqc_debug value it's in there.