I was under the impression that you could use dynamic lists as filters for an analytics dashboard or widget, but either I'm mistaken or I'm doing something wrong. I create a dynamic list several weeks ago for someone to use, but they recent said it doesn't appear any data was changing. I saw the list contents were the same as they were when I created it, so I generated counts again and it went up a bit. However, these new people on the list won't be available to analytics until tomorrow.
Does anyone know how to get dynamic lists to work without having to manually generate counts each day, or at least some kind of work around? We could in theory schedule an execute output set on the list each day, but that seems a bit troublesome.
Hi Jesse,
I have been using dynamic lists as filters on several Analytics widgets, and I did schedule the "Generate a list" utility for each of those to run daily as that was the only solution I found. If there's an easier one I'd love to hear it too!
That's what I do as well
Just coming to this: is there a good reason why dynamic lists shouldn't be regenerated before import into Analytics?
I have so many lists that need regular updating that I built a nightly job to regenerate lists based on a list of individual lists and categories, but now I'm going to have to worry about timing with the Analytics load, or else lists will always be 24 hours out of date compared to the other data.
I got in trouble with this recently (again) and noticed that there wasn't a mention of this in Ideas, so I've added one:
community.tessituranetwork.com/.../analytics-should-honor-dynamic-lists
Love that.
So what we are essentially advocating for is before an incremental load, run "Generate a list" on all lists that have both dynamic and analytics checked? I might load test that and if ok, just set up that job in SSAgent.
The problem is that you don't have much control over what that load is going to be: I can see certain times when suddenly analytics-checked lists will proliferate, and that could be a huge rapid change in a consortium at the start of a new fiscal year or season. Then you have to try and pad enough time for the regeneration to finish before the analytics load begins, but not so much that the lists are effectively stale when it happens. Being able to make it part of the load (regenerate, then on finish immediately start the load, or regenerate the lists as their data is being loaded, or whatever) is definitely safer. And add that to the fact that we (UC Berkeley) still don't have a good plan for culling old lists....
Anyway, what I'd started doing was adding the lists to a list category that I have scripted to be updated nightly, but really I should be looking for all the analytics + dynamic lists. Maybe I'll change that script.
Yep I was thinking further on this after I posted. Depending on how the org uses dynamic/analytic catagories and time of year that could be a spicy meatball. Top 10 by recent date could be a start but you also need to know if a list NEEDS to be regenerated which has a whole variety of complexities depending on the underlying select statements. This is separate to the conversation on the code optimisation.
Still if the alternative is people running a bunch of Generate a List schedules ...
... this is one of those times that I'm imaginging Tessitura Network Engineering shaking their head at me glimpsing 1% their ongoing backlog