Expand my Community achievements bar.

SOLVED

Consent passing from Mobile Core SDK to AEP

Avatar

Level 4

Hi,


I'm trying to figure out how consent is passed from Mobile Core SDK (latest AEPCore version), with the Edge Consent being configured in Data Collection as well.

From the Mobile app, I'm performing an updateConsent call with setting the marketing options on the generic level:

["collect": ["val": "y"], "marketing": ["preferred": "email","any":["val": "y"],"email":["val": "y"],"push":["val": "y"]]]
 
In AEP however, I see these consents specifically being added to the ECID identity:
consents.idSpecific.ECID.xxxxxxxxx.collect.val = y
consents.idSpecific.ECID.xxxxxxxxx.marketing.email.val = y
...
 

So I'm wondering if I'm missing something in the setup?

Anyone experience with this?

1 Accepted Solution

Avatar

Correct answer by
Level 4

@stefanm38281801 WebSDK behaves exactly the same. It persists consent to the "ID specific". The actual websdk ingestion call is not directly creating the XDM. 

Data sent looks like this 

 

{"consent":[{"standard":"Adobe","version":"2.0","value":{"collect":{"val":"y"},"metadata":{"time":"2022-02-15T11:57:24.217Z"}}}],"query":{"identity":{"fetch":["ECID"]}},"meta":{"state":{"domain":"my.com","cookiesEnabled":true}}}

I guess that's the same for the mobile SDK.

If this assumption is correct, it would mean Adobe is doing this somewhere on the Edge/Serverside which also means we have no control over it.

My suggestion would be to create a client care ticket (and share their response )

View solution in original post

7 Replies

Avatar

Level 5

@stefanm38281801 Not sure what the problem is here, from your snippet, it appears that AEP is correctly reading the consent values from Mobile SDK. All consents are mapped to ECID because ECID is like Adobe's own unique ID to identify customers), so looks like its all working as intended here. 

 

Let me know if I did not catch your question correctly.

Avatar

Level 4

Hi,

since I have the consent field group added to the profile, I was expecting these values under the main branch, and not on the idSpecific.

Furthermore I also tested with adding an idSpecific branch in the updateConsent call, e.g. on another identifier - not ECID, and that does not seem to get recorded in AEP.

Avatar

Level 4

Even if I post something like this:

 

["collect": ["val": "y"],
"marketing": ["preferred": "email","any":["val": "y"],"email":["val": "y"],"push":["val": "y"]],
"idSpecific":["Email":["my_email@mycompany.com":["marketing":["email":["val":"y"]]]]]]
 
I can see in Griffon, on the streaming validation that the idSpecific value on Email is not passed to AEP.

Avatar

Correct answer by
Level 4

@stefanm38281801 WebSDK behaves exactly the same. It persists consent to the "ID specific". The actual websdk ingestion call is not directly creating the XDM. 

Data sent looks like this 

 

{"consent":[{"standard":"Adobe","version":"2.0","value":{"collect":{"val":"y"},"metadata":{"time":"2022-02-15T11:57:24.217Z"}}}],"query":{"identity":{"fetch":["ECID"]}},"meta":{"state":{"domain":"my.com","cookiesEnabled":true}}}

I guess that's the same for the mobile SDK.

If this assumption is correct, it would mean Adobe is doing this somewhere on the Edge/Serverside which also means we have no control over it.

My suggestion would be to create a client care ticket (and share their response )

Avatar

Level 5

@stefanm38281801 Have you selected 'Opted-in' as part of your mobile property set up?

Avatar

Level 1

Yes though we send a channel level still it is attachine to the idspecific - which is ECID OOTB.

 

Is there any way we could stitch consents at profile level example - CRM ID which is common across devices so that profile could stitch latest consents every time?