Expand my Community achievements bar.

SOLVED

Using Web SDK consent queueing

Avatar

Level 4

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?

Topics

Topics help categorize Community content and increase your ability to discover relevant content.

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

 

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

 

Parvesh Parmar – Adobe Community Advisor
https://www.linkedin.com/in/parvesh-parmar/

View solution in original post

5 Replies

Avatar

Correct answer by
Community Advisor

 

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

 

Parvesh Parmar – Adobe Community Advisor
https://www.linkedin.com/in/parvesh-parmar/

Avatar

Level 4

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:

  1. Load site, consent set to "pending"
  2. Page call triggered, queued due to consent
  3. Consent given
  4. Queued call sent

Actual behavior:

  1. Load site, consent set to "pending"
  2. Page call triggered, queued due to consent
  3. Consent given
  4. Previously queued calls are not sent

There is no page load between queued calls and I've confirmed the consent is set correctly, using Adobe's consent model 2.0.

Avatar

Community Advisor

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

Parvesh Parmar – Adobe Community Advisor
https://www.linkedin.com/in/parvesh-parmar/

Avatar

Level 4

Thanks, that is my plan. I will post back any findings or resolutions to my issue here.

Avatar

Level 4

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 !