Alright, let's cut through the usual marketing fluff. I've seen this pattern three times now across different client migrations where OneTrust consent banners are deployed, appear to be working, but the backend logs show zero opt-outs even when you know users are clicking "Reject All." This isn't a "feature," it's a breakdown in your data pipeline, and it will get you fined.
The root cause is almost never the banner UI itself. The banner fires an event, but that event is getting lost, misinterpreted, or never ingested. You need to start debugging from the point of user interaction back to your logging endpoint. Here are the typical failure points I've had to troubleshoot:
* **Misconfigured Event Listener or Callback:** The JavaScript snippet for the banner has a callback function to handle consent changes. If this is misdefined, or if there's a JavaScript error elsewhere on the page that halts execution, the event never fires.
* **Data Layer Mismatch:** You've configured OneTrust to push the consent state to a specific data layer variable (e.g., `dataLayer.push` for GTM). If your Tag Manager container or your analytics tool is listening for a different event name or variable structure, the data vanishes into the void.
* **Network Request Blocking or Failure:** The banner is configured to send a POST request to OneTrust's logging API or your own endpoint. Ad-blockers, overly aggressive CSP headers, or CORS misconfigurations can silently block these requests. You won't see errors in the console unless you're looking at the network tab.
* **Incorrect Purpose/Group Mapping:** This is an insidious one. The banner's "Reject All" button might be linked to specific consent purposes or groups in your OneTrust admin console. If those purposes aren't correctly mapped to the corresponding logging mechanism, the signal is dropped.
First step is to open your browser's developer tools and reproduce the issue. Here's what to look for:
1. **Console Tab:** Any JavaScript errors when the banner loads or when you click a consent button? That's your smoking gun.
2. **Network Tab:** Filter for XHR or Fetch requests. Click "Reject All." You should see a request to a OneTrust or your custom logging endpoint. Check its status. Is it `200 OK` or `4xx/5xx`? Check the request payload. Is the consent state correctly reflected as `false` or `optout`?
If the network request is failing, you need to examine the request details. A common culprit is a missing or incorrect authentication token for the API. Here's an example of a malformed payload I've seen, where the boolean values are sent as strings, which some backend parsers will treat as truthy:
```json
{
"consentModel": [
{
"purposeId": "C0001",
"status": "false" // Problem: This is a string, not a boolean.
}
]
}
```
The correct payload should be:
```json
{
"consentModel": [
{
"purposeId": "C0001",
"status": false // Correct: boolean false.
}
]
}
```
Check your OneTrust script configuration and any custom callback code. The fix usually involves correcting the callback function to ensure it's firing, validating the data structure being sent, and whitelisting the necessary domains in your CSP. Don't just assume the default setup works—it often doesn't in complex, real-world environments with bundled scripts and tag managers.
---
Been there, migrated that