Possible to get more than just 3 list variables? Or how to work around it?

[sorenhoyer]

I work at a big company where the marketing department wants to track all projects within the same report suite.

We need a list variable in our project, but since there's the limitation of only 3 list variables per report suite, and they're already used by other projects, what are our options besides hacking a work-around and using the product variable? (list props won't work either due to the 100 char limitation). Can we pay to buy more list variables or why is this not possible?

"An organization can have many report suites, each containing different data sets. While separate report suites were important in the past, having a single report suite has become more advantageous" ~ https://experienceleague.adobe.com/docs/analytics/admin/admin-console/create-report-suite.html?lang=...

I guess the marketing department agrees that it is indeed an advantage for them to keep all projects in the same report suite, but from a developer standpoint, given the 3 list vars limitation - how is this advantageous?

[yuhuisg · Accepted solution]

I think the number of list variables is a limitation of AA's data store backend. So there's really no way to get more, even if you're willing to pay more.

Are all 3 list variables already in use? If there's one spare one, you could do the following: track it with another eVar, where that other eVar indicates the purpose of the list.

E.g.

eVarXX = "product catalog";

listX = "product A,product B,product C";

and

eVarXX = "internal promo banners";

listX = "banner 1,banner 2, banner 3";

Then when reporting listX, you'd always want to report it with eVarXX so you know what values to get back.

[sorenhoyer]

Thanks, at least this is the best workaround I've seen suggested. I guess I'll have to see if I can get a list variable free'd up, so maybe we can use this trick. A little surprising however that you'd have to go this creative to make it work

[Brian_Johnson_]

@yuhuisg - I like this approach. What are the gotchas around eVar/listVar settings? For example, are you expiring both on the hit? Visit? Something else?

[yuhuisg]

@Brian_Johnson_ Truth be told, I haven't done this before. But I remember this suggestion from someone else, so I'm providing it here too. Yes, the expiries and allocations for the eVar and listVar would have to be exactly the same, so that the data between both variables can be related together. The easiest would be "Hit" expiry. If set to anything else, then it should be even more important that the eVar is never used anywhere else except for this purpose.

[Brian_Johnson_]

@yuhuisg- I gave it a shot with both set on Visit expiration, and the results were a bit of a mess. The eVar was set to last touch, and the listVar, full, and I found that the information was jumbled together. 

I passed "favorite colors" into an the eVar and a list of three or four colors into the listVar (same hit), then repeated the process (different colors) a few times. I followed that by setting the eVar to "best pizza" and passing various types of pizza into the listVar. The image below shows where the "best pizza" data was corrupted by the color information I had collected earlier. (I'm showing Visits, but it's the same for Occurrences and other metrics.):

So, I think you're right... The expiration would have to be set to Hit for both variables in order for this to work. 

I do like the creative approach, though. Thanks for sharing!

[Asheesh_Pandey]

use list prop to set code (abbreviation) value and classify prop with auto classification rule builder to get full details for set code.

[sorenhoyer]

Unfortunately we need a lot more than the 100 bytes that is supported in total for list properties