Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

SOLVED

aam_uuid cookie description for policy page

Avatar

Level 1

Hi,

I'm looking for the following information for our cookie policy page specific for the aam_uuid cookie:

 

  • Publisher (host)
  • Cookie name
  • First/Third Party Cookie
  • Description
  • Validity

 

Here's an example:

 

Publisher (host): demdex.net

Cookie name: demdex

First/Third Party Cookie: Third

Description: This cookie is stored by Adobe on the visitor's browser to assign website visitors a unique Adobe ID, which then allows the Adobe services we use to perform basic functions such as visitor identification, ID synchronization, segmentation, modeling and reporting . The cookie contains a unique identifier assigned by Adobe. This allows Adobe to recognize the visitor's browser and device. By analyzing visitor behavior, we can improve our digital offering and show visitors information, functions and advertising that match their interests.

Validity: 180 days

 

Thank you!

1 Accepted Solution

Avatar

Correct answer by
Employee

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 that's in the demdex cookie. As such, the best answer I can give you is something like this:

 

Publisher (host): <whatever your domain(s) is (are)>

Cookie name: aam_uuid

First/Third Party Cookie: First

Description: This cookie is set by Adobe code on the visitor's browser and is a copy of the ID found in the 3rd party demdex cookie. The cookie contains a unique identifier assigned by Adobe.

Validity: <however many days you put in your implementation> days

 

Now, that description is pretty vague and simple because Adobe doesn't actually use that cookie for anything. It's typically used by customers who want a copy of the ID that's in the demdex cookie for whatever reason. So the purpose is going to come down to whatever you are using it for. 

 

Does that help at all?

 

View solution in original post

0 Replies

Avatar

Correct answer by
Employee

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 that's in the demdex cookie. As such, the best answer I can give you is something like this:

 

Publisher (host): <whatever your domain(s) is (are)>

Cookie name: aam_uuid

First/Third Party Cookie: First

Description: This cookie is set by Adobe code on the visitor's browser and is a copy of the ID found in the 3rd party demdex cookie. The cookie contains a unique identifier assigned by Adobe.

Validity: <however many days you put in your implementation> days

 

Now, that description is pretty vague and simple because Adobe doesn't actually use that cookie for anything. It's typically used by customers who want a copy of the ID that's in the demdex cookie for whatever reason. So the purpose is going to come down to whatever you are using it for. 

 

Does that help at all?

 

Avatar

Level 1

Thank you so much for your reply!

 

We're not sure what it's used for. Can you say what the purpose might be or what it's usually used for?

Avatar

Employee

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 specific use case in mind. The use cases where it was used were for a variety of things. Since the demdex cookie is set in a 3rd party domain (demdex.net), there's just no way to read it using JavaScript on the page, so we made putting it in a first part cookie an option just so developers could get to it for whatever reason. Often they were troubleshooting scenarios. Sometimes it was for ID exchanges/syncs with other data providers (outside of the standard ID syncing done by ID service for AAM). I'm sure there are others I'm not thinking of right now, but yeah. those were the two common ones I've seen. If you aren't using it for some reason, perhaps it would just be simpler to remove it rather than try to account for it in your policies.