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": []
}