Overview
Previously, the widget had a rule that could automatically mark an entire consent category as accepted based on how many of its vendors were required - without the visitor actively choosing that. This rule has now been fully removed. This section explains how it used to work and how the system behaves today.
How It Previously Worked
When a visitor's page loaded, or when a visitor saved their preferences, the system checked how many vendors within a category were marked as 'required.' If more than half of a category's vendors were required, the whole category was automatically treated as accepted - even if the category as a whole was not marked as required, and even if the visitor had not explicitly agreed to it.
| Scenario | Category Result |
| The category itself was required | Always shown as accepted |
| More than half of the category's vendors were required (at first page load) | Automatically shown as accepted |
| More than half of a category's vendors were selected when the visitor saved their choices | Automatically shown as accepted |
| Half or fewer of the vendors were required/selected, and the category itself wasn't required | Reflected the visitor's actual choice |
| A Global Privacy Control (GPC) signal was detected | Automatically shown as declined (this override still applies today) |
Updated Behavior
The 50% rule has been completely removed. Now, a category is only automatically shown as accepted when the category itself is genuinely required, or - when a visitor saves vendor-level choices - when every single vendor within the category is required. In every other situation, the category's status reflects exactly what the visitor chose, never a calculated average or majority based on its vendors.
| Scenario | Category Result |
| The category itself is required | Always shown as accepted |
| Every vendor within the category is required (when saving preferences) | Shown as accepted |
| Any other situation, without explicit visitor consent | Reflects only the visitor's actual choice |
| A Global Privacy Control (GPC) signal is detected | Shown as declined (unchanged) |
Why It Was Removed
In setups where visitors can toggle a whole category on or off, the old rule could quietly override a visitor's explicit choice. For example, a visitor could turn a category off, but because most of the vendors inside it were 'required,' the system would flip it back to 'on' without the visitor's knowledge.
On first page load, a category could appear pre-accepted simply because most of its vendors were required - even when nothing about that category was genuinely essential, making it inconsistent with how every other category behaved.
Most importantly: even in setups where visitors only see individual vendor choices (no category-level toggle at all), an optional vendor could still be treated as consented to and allowed to operate - purely because it happened to share a category with enough required vendors to cross the 50% mark, regardless of whether the visitor actually agreed to that specific vendor.
Impact on Callback Methods
If your website listens for any of the consent callback methods below, this change affects the data those callbacks receive. None of these callbacks apply their own logic to decide a category's status - they simply receive whatever status the widget has already determined at that moment. Because the widget no longer inflates category status using the 50% rule, every callback that receives category or vendor data will now report accurate, visitor-driven values instead of majority-based assumptions.
| Callback Method | When It Fires | Receives Category/Vendor Data? | Affected by This Change? |
| priorConsentCallback | When a visitor's existing consent status is checked (e.g. on page load) | Yes | Yes - categories/vendors now reflect the visitor's real choice, not a majority-based assumption |
| consentChangedCallback | When a visitor saves changes to their preferences | Yes | Yes - same as above |
| consentRejectCallback | When a visitor uses the opt-out 'Reject All' action | Yes | Yes - same as above |
| closeCallback | When the consent banner is closed | No | No - this callback does not receive category data |
| consentDeclinedCallback | When a visitor declines consent | No | No - this callback does not receive category data |
| consentWithdrawnCallback | When a visitor withdraws previously given consent | No | No - this callback does not receive category data |
If your integration reads category or vendor values from priorConsentCallback, consentChangedCallback, or consentRejectCallback, you should expect categories that previously came through as 'accepted' - purely because most of their vendors were required - to now come through as 'not accepted' unless the visitor genuinely consented, or the category is genuinely required. If any of your own logic was written to assume the old (inflated) behavior, it should be reviewed against this change.
This same corrected data also flows into any tag management tool (e.g. Google Tag Manager, Tealium) or advertising opt-in integration (e.g. Adobe) connected to the widget, since those integrations are driven by the same underlying consent values as the callbacks above.
Comments
0 comments
Article is closed for comments.