Skip to main content

No Browser Storage

🗄️ Handling "No Browser Storage" Responses​

No Browser Storage is a Could not process response that comes with a reason. It means the respondent's browser did not let the survey page use session storage, so the Quality Tools could not identify the device.

Nothing changes in your integration. The payload is the regular Could not process payload, so any logic you already have for Could not process keeps working. The only difference is the reason, carried in requestId, which tells you the cause is the respondent's browser or device, not DQC and not your survey setup.

  • The respondent is not blocked. The survey carries on.
  • The device is not identified, so there is no device score, Data Trust Score or duplicate check for this response.
  • Only DQCToolBox.getIdentity() returns it. DQCToolBox.getIdentityRequestId(), used by React and server-side flows, is unchanged.

When does this happen?​

The Toolbox keeps the respondent's identification in the browser's session storage while they move through the survey. In the Decipher / Forsta integration getIdentity() runs on every question, so without storage each question would start a brand-new identification and the respondent would be identified over and over.

To avoid that, the Toolbox checks that the page can use session storage and, when it cannot, returns No Browser Storage straight away, without identifying the device.

This is typical of:

  • Some in-app browsers and WebViews on Android and iOS, such as the browser built into a mobile app.
  • Browsers or privacy settings that block site storage for the survey page.

What you need to do​

Nothing needs to change. Handle it exactly like Could not process:

  1. Let the respondent continue. Do not terminate them. There is no score to judge, which is why the Decipher termination script already skips Could not process, and that check is on participantId, which is still Could not process here.
  2. Send the requestId back with the transaction data, as you do for every response. Do not blank it out or replace it. DQC records the reason against the response, stored as the fixed id NO_BROWSER_STORAGE.

Keep branching on participantId if you already do. It is Could not process for this response, same as always.

Response Example​

Everything is the Could not process payload except requestId, which holds the reason.

The example shows the default surveyId. In an integration the Toolbox replaces it with your survey's own id.

{
  "requestId": "No Browser Storage",
  "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": []
}

Looking it up with GET /tools/request​

Like the other special values, the reason can be passed to GET /tools/request/{requestId}. It is recognised on our side: the call needs no authentication and does not look anything up. It returns the Could not process payload with requestId set to the value you passed.

Either form works:

GET /tools/request/No%20Browser%20Storage
GET /tools/request/NO_BROWSER_STORAGE