Could not process

🛑 Handling "Could not process" Requests

Our infrastructure is designed to handle significant traffic spikes and automatically scales to accommodate demand. However, in cases where demand temporarily exceeds available resources, some requests may receive a "Could not process" response while our systems scale to meet the increased load.

We continuously monitor system performance and proactively optimize our infrastructure to minimize these occurrences and ensure reliable service delivery.

If a request could not be processed, the Quality Tools will:

• Return your provided requestId.
• Assign "Could not process" to string attributes.
• Return a device score of 0 for all device numeric metrics.
• Return false for the isDuplicate property.
• Return "No Data" for survey history metrics (e.g., manualISQRate) and lastSurveyTaken.
• Return 0 for quality checks (e.g., brandFamiliarity)
• Return NONE for the persona attribute. See Personas.

Response Example

{
  "requestId": "Could not process",
  "participantId": "Could not process",
  "dataTrustScore": 0,
  "persona": "NONE",
  "deviceScore": 0,
  "country": "Could not process",
  "subdivision": "Could not process",
  "lastSurveyTaken": "No data",
  "isDuplicate": false,
  "surveyId": "Could not process",
  "averageDeviceScore": 0,
  "lowestDeviceScore": 0,
  "totalSurveys": 0,
  "deviceFailures": [
    "Could not process"
  ],
  "completionRate": "No data",
  "duplicationRate": "No data",
  "failureRate": "No data",
  "qualificationRate": "No data",
  "manualISQRate": "No data",
  "automatedISQRate": "No data",
  "osqRate": "No data",
  "brandFamiliarity": 0,
  "openEnd": 0,
  "speeding": 0,
  "honeyPot": 0,
  "straightlining": 0,
  "distinctSupplierCount": 0,
  "suppliers": []
}

---

Could not process reasons

Could not process can come with a reason, carried in requestId. Apart from requestId, the payload is the one shown above, so you do not need to change anything for a reason.

Reason (requestId)	Stored id	When
No Browser Storage	NO_BROWSER_STORAGE	The respondent's browser does not let the survey page use session storage, so the device could not be identified.

Keep branching on participantId, which is Could not process whatever the reason. Send the requestId back on the transaction data as you do today. The reason is recorded so it is clear the cause is the respondent's browser, not DQC.