Can you help me with what you mean by "under demdex?" These cookies are not listed as being set by the demdex.net domain, so I'm not sure I follow what you mean by "under demdex". It's possible that these are coming as a result of newly enabled ID syncs. Did you ask customer support to setup any new...

The biggest impact to traits is that you have to change the expression criteria to match Web SDK data. I'm going to assume you're currently using Server-side forwarding from Analytics. The big change with Web SDK is that the data goes from Edge directly to AAM without going through Analytics first. ...

Thanks for the post! Unfortunately, you posted what looks like an AEM question to the AAM channel. Would you be able to repost on the Adobe Experience Manager community?

As a general rule, anyone who had Adobe Consulting help them deploy their AAM code is probably setting this cookie simply because it would come in handy later down the road, so it's in the standard deployment configs. So it is quite possible that it was deployed in your implementation without a spec...

That cookie is very optional and set by Javascript (DIL code or the AudienceManagement Module, whichever you're using for your implementation). The domain is whatever domain the code is running on and duration is also dependent upon code settings of your implementation. It's also a copy of the ID th...

This is the expected behavior. ID service (the calls to dpm.demdex.net) will only fire on the first page of the first visit in order to get an ID. Once that ID is stored in the AMCV cookie, there's no need to keep using up network calls in order to get Experience Cloud IDs. The same is true for the ...