List Var or List Prop in this case?

[mjdavid007]

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!

[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.

[Jennifer_Dungan]

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.

[mjdavid007]

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?

[bjoern__koth]

That is correct. A traffic variable has no persistence.

So, if you are interested in conversion attribution, you must go and sacrifice a list variable and configure it like any other eVar

[Jennifer_Dungan]

Yep, if you need attribution, then you will need to use eVar...However, there are different approaches you can take...

First, if you have finite number of items (i.e. one or two values), you don't need to use a "list". You can actually send these as a normal dimension, and use classifications to split the value based on the pattern of how the information is sent. So if you have one or two pieces of user info, you don't need to necessarily use a list...  this can sometimes be better... you can use the original value with two pieces of info, or use one of the classifications with the the isolated data. I have used this technique for related info on many occasions.

For "Logged In", you may not even need attribution.... I have a "log in event" (i.e. the actual action of successfully logging in), and I have a "log in status" (i.e. yes / no) as well as "user entitlement status", "user guid". etc...

I don't track any of this information with attribution.. I pass this information on all pages views and actions. If the user logs out, or the user's authentication token gets corrupted and they are kicked out, etc... I am always sure I am getting the correct current status. So this information is "HIT" regardless of using a prop or an eVar.

The other concept that you might be interested in, is using "Conversion Syntax" merchandising eVars. Let's use a shopping cart application for an example, if on the add to cart or purchase event, you want to know the search criteria to show how a user found the item (but you need this per item.. not the last search that was done overall). When you perform a search, if you can send information to these "special eVars".... they will NOT appear in any reporting until the "binding event" (let's use "Add to Cart"). When the product info is sent for the "Add to Cart", because this is the binding event, the search value in Adobe will be stitched to the product data as a merch var only now... and each add to cart will pass the last search performed per item... if that Merch Var has attribution, it should maintain that value to the Purchase event, so that it's also available at this point.

So while you may be looking at lists and attribution, there may be other options out there to use depending on your use case.... Things you haven't even considered.

Either way, have fun and good luck with your tracking!

[mjdavid007]

Thanks so much for the additional information! And you are right: I can capture this CRM related information on a regular eVAR, then use Classifications. Indeed, it would be the same that I already use for UTM tracking.

As per the merchandising eVars, I will tell the developers to pass interactions information to these in order not to lose information along the way when it comes to Orders attribution.

Again, thanks for the help: you don't know how much you help everyone, specially the ones like me who are starting in the Analytics world (and who also have to deal with so many different issues in the company lol).

[mjdavid007]

Sorry the this reply again, but I was just thinking that your solution of using a eVar+Classification would not work here, since I would be capturing different values for the same Dimension. For instance, we ask the Visitor to choose up to 3 countries in which they are interested in. If he chooses more than one, an eVar would not work here, right?

[Jennifer_Dungan]

Well it depends... 

If you want all the countries to appear in the same dimension as equal weights, then yes, you would need a list.

If it's sort of a weighted "first, second, third".. then in theory you could have a classification for "first country", "second country" and "third country"

If no second/third is selected, then those other classifications won't be populated.

But you know better than me how you want to use the data,, and this was the first specific example that was provided

If you were tracking something like "user guid", "use account level" and "user country", etc... which are three distinct values, the non-list approach works just fine... but I agree... for one or multiple of the same type of data, this is potentially more challenging, and really depends on your reporting needs.