List Var or List Prop in this case? | Community
Skip to main content
M
mjdavid007
Level 3
December 9, 2024
Solved

List Var or List Prop in this case?

  • December 9, 2024
  • 1 reply
  • 1879 views

Hi! We are struggling with collecting multivalues and the List Var limits. We have categorized all pages of the site with different metadata, and two of this metadata fields might have multiple values. As it is information regarding a page, should we use List Prop instead? Or is it better to go for List Vars? At the same time, we also have Logged User information we want to capture, also with multivalues. As this CRM information is "static" through the Visit, what's the best way to capture it? List Var in this in case?

 

Thanks in advance!

Best answer by bjoern__koth

Hi @mjdavid007 

it depends a little on how much information can be passed in at the same time.

 

Lists / List vars are - as you have correctly pointed out - unfortunately limited in numbers (3 only), but they can hold 255 Bytes (more or less characters) per item value.

List props are having the same limitations than regular props / traffic variables, meaning a total length of 100 Bytes, for all values combined (including value delimiters).

 

So, if you know your overall collected data is rather small, a list prop may suffice.

What could make your life a lot easier is using a list var with prefixed values e.g. "tags:tag1,tags:tag2,metadata:foo,metadata:bar,..."

Using this namespace approach, you can easily filter in your analysis workspace project.

When it comes to the metadata you are talking about, maybe it's also possible to even just get the metadata IDs into AA (using a list prop), and use classifications to give them more speaking names. For instance, if you are applying tags, maybe each tag has an ID, that is potentially even language independent. That way, you could easily upload a classification that give more context to these values.

1 reply

bjoern__koth
Community Advisor and Adobe Champion
bjoern__kothCommunity Advisor and Adobe ChampionAccepted solution
Community Advisor and Adobe Champion
December 9, 2024

Hi @mjdavid007 

it depends a little on how much information can be passed in at the same time.

 

Lists / List vars are - as you have correctly pointed out - unfortunately limited in numbers (3 only), but they can hold 255 Bytes (more or less characters) per item value.

List props are having the same limitations than regular props / traffic variables, meaning a total length of 100 Bytes, for all values combined (including value delimiters).

 

So, if you know your overall collected data is rather small, a list prop may suffice.

What could make your life a lot easier is using a list var with prefixed values e.g. "tags:tag1,tags:tag2,metadata:foo,metadata:bar,..."

Using this namespace approach, you can easily filter in your analysis workspace project.

When it comes to the metadata you are talking about, maybe it's also possible to even just get the metadata IDs into AA (using a list prop), and use classifications to give them more speaking names. For instance, if you are applying tags, maybe each tag has an ID, that is potentially even language independent. That way, you could easily upload a classification that give more context to these values.

Cheers from Switzerland!
    Jennifer_Dungan
    Community Advisor and Adobe Champion
    Jennifer_DunganCommunity Advisor and Adobe Champion
    Community Advisor and Adobe Champion
    December 9, 2024

    I agree with @bjoern__koth... if you know the data you are going to collect is always going to fit into 100 characters max, then a List Prop is fine...

     

    Otherwise, the only way to ensure that you don't lose data is to use a list. I am a big supporter of the "namespace" or "value set" method to increase what I can track with a single list item.

     

    By using creative prefixes on your information, you can essentially pass unlimited information into a single list, and use classifications to split them into their own subsets. Even more beautiful is when you create your regex rules using the prefixes/namespaces/etc, you don't actually have to include the prefix or namespace in the outputted value... you can merely use it identify what classification the value should be placed into, but only pass the value.

     

     

    For example:

     

    s.list1 = "a:value,a:value 2,b:something,c:something else"

     

    Using the comma as the delimiter, you will end up with the following rows in your base list1 dimension:

    • a:value
    • a:value 2
    • b:something
    • c:something else

     

    Now, using some simple regex rules:

    1. (a:)(.*)
    2. (b:)(.*)
    3. (c:)(.*)

     

    You would set the first one to "Classification A", and only pass $2 (resulting in "value" and "value 2" in your classification).

    You would do the same for "Classification B" and "Classification C", so that "something" would be in the B classification, and "something else" would end up in the C classification.

     

    You don't need to set the full classification name in the values in your lists... short forms are enough... I use "cat" for categories, "auth" for author info, "n" for active notifications, etc.

     

    However, if you are already using your lists, this can be a bit of a lift to shift your tracking over...  I know, I did something similar about a year ago.

      M
      mjdavid007Author
      Level 3
      December 10, 2024

      Thank you both @jennifer_dungan and @bjoern__koth . It was really helpful. Having in mind that the User information is always less than 100 characters, Prop List would be enough, but, would I be able to "link" conversions to that information? From what I understand, as Prop does not persist beyond the hit, this information would only be available on the first hit (when the user logs in), but if that user makes a conversion later, would I have that track?

      Terms & ConditionsAccessibility statement

      Loading footer...