Within Adobe Tags, when setting up the Web SDK extension, we have default options for consent. Three default models (in, out and pending) as well as a configurable object to configure with more in-depth level.
My question is regarding the "pending" option, which is stated to queue the calls until user gives consent and then act based on consent given, either by sending calls with opt-in or discarding them with opt-out.
The issue I'm facing that regardless of if I use the default "pending" option, or define a custom consent object that uses the pending values, calls triggered before opt-in and should be queued are never sent. Is this expected behavior or am I missing something?
Solved! Go to Solution.
Topics help categorize Community content and increase your ability to discover relevant content.
Views
Replies
Total Likes
Hi @SSampsa ,
I found the following documentation that might be helpful:
If I understand it correctly:
Even when the Web SDK defaultConsent is set to "pending"—either by default or through a custom consent object—
defaultConsent: "pending"
Events (like sendEvent) triggered before consent is granted should not be sent immediately.
They should be queued and only sent after setConsent indicates opt-in.
If opt-out is given, queued events should be discarded.
Kind regards,
Parvesh
Hi @SSampsa ,
I found the following documentation that might be helpful:
If I understand it correctly:
Even when the Web SDK defaultConsent is set to "pending"—either by default or through a custom consent object—
defaultConsent: "pending"
Events (like sendEvent) triggered before consent is granted should not be sent immediately.
They should be queued and only sent after setConsent indicates opt-in.
If opt-out is given, queued events should be discarded.
Kind regards,
Parvesh
Hey Parvesh and thank you for the answer.
I have been looking at the same documentation and the model on how consent is supposed to work. The issue is that even as I set consent to be "pending" and then later opt-in, calls that were supposed to be queued are not set, but rather just discarded.
Expected behavior:
Actual behavior:
There is no page load between queued calls and I've confirmed the consent is set correctly, using Adobe's consent model 2.0.
Views
Replies
Total Likes
Hi @SSampsa ,
I agree with you — it’s not working as expected in your case.
Sometimes, certain information might be missing or not fully defined in the documentation, especially when there are dependencies on other components.
In such cases, I usually contact Adobe Support and explain that I’ve implemented everything as per the documentation. I also include screenshots, documentation links, and any relevant details.
They are generally quite responsive, so you might consider reaching out to them as well.
Kind regards,
Parvesh
Thanks, that is my plan. I will post back any findings or resolutions to my issue here.
Views
Replies
Total Likes
Update on the case: The issue was pretty much as you described, for whatever reason in design, "pending" is only valid as an initial state, but you cannot set it using setConsent, only as a default value. This system works if you set the default from extension configuration to be "pending" and then later "opt-in" the user, but if you try to use "setConsent" to handle pending, there will be an error.
In our case the issue was that consent system always gave the signal to data layer when loaded, regardless if consent was set or not. This is due to requirements by other systems, but it had the unfortunate side effect that the consent for us was never really pending, that state was immediately overwritten by "opt-out" being default for setConsent-call and later by an "opt-in". When used like this the queue does not work and calls are discarded.
Long story short: If you use the queue, make sure you don't use "setConsent" until direct confirmation of consent is given. Thank you again for your help @Parvesh_Parmar !
Views
Replies
Total Likes
Views
Likes
Replies