Tuesday, November 22, 2022

Lots of annoying admin stuff, but also testing out some custom calculations

 I’ve been learning more than I ever wanted to know about login-based license management for Tableau Server, yet I still feel like I don’t have any answers about why some errors keep persisting. How do you have literally pages and pages of documentation with so little actual detail in some spots? There’s pages of explanations on tokens, registry entries, commands to run, etc, but to me it looks like it’s all just repeating the same broad strokes without helping if you run into something truly off-label.

This will mean nothing to people who don’t know the product. I’m sorry. I have no more spoons to explain it, and I also don’t think I know anything useful; I certainly don’t know anything more than I did three weeks ago, which is truly sad considering how much I’ve researched it. The long and short is, we converted Tableau desktop licenses over to the server, and the activation and maintenance of permission to have the license happens via authentication to the server, not through separate product keys. And I keep getting an error that I’ve installed too many times for my license, which is not actually true.

Maybe someday I’ll get to go back to actually working on data modeling and building visuals.

Side note: I did build out a couple of data lenses and got to explore that a bit more. It’s an interesting feature - It allows for ad-hoc exploration of the data, but it’s a bit hard to understand what to do. I like a natural language query better, but considering it didn’t take too long to set this up, it’s not bad.

In other news: I’ve had a request to add some content to our enrollment reporting dashboard (in Pyramid Analytics).

This is exciting because my customer is asking for a view of data that’s based on a set of spreadsheets they’ve been maintaining for a while, which is using data that is already in our model. I’ve been looking for an opportunity to build something more mature for that data, but until now, didn’t have a clear direction on what measures and visuals were going to be the most useful.

Today I spent some time working up custom calculations in Pyramid that shows the figures they want, with the dimensions they need. I’ll be using my tested custom lists and measures to show our developers what we want added to the cube officially. We can do it ourselves, but we have a contract with a vendor to do things like this, which will save us a lot of time.

We have a set of dimensions and measures that report on student applications for admission. The main dimension is application status, and there are a bunch of measures for counting applications and showing how, for example, a particular status, compares to other statuses, or what our application or admit yield is, etc. It turns out there is some overlap between the “canceled” and “admitted” statuses; there are two groups of canceled apps: those who had an application decision (admitted or denied) and then canceled their app, and those who didn’t have a decision before they canceled their app. My customer has been breaking that data apart manually, and then using logic based on that to split the measures out into two groups, and, in some cases, conditionally selecting to display a particular measure for just one group or the other. We care about deferred applications when we look at overall applications measures, but we don’t want that displayed for the original term’s admits, for example, and we want to see fixed calculations on canceled apps along the accepted/admitted dimension. That particular member, or level, doesn’t exist in the “status” hierarchy yet, but it soon will. It may be that this has revealed an issue with the way the statuses and decision codes are transformed; there is a dimension that’s basically a flag to indicate if a student was accepted, but it doesn’t have much impact on the numbers, and it’s not very detailed (the member names are “Yes” and “All” ๐Ÿ™„). There’s also a dimension indicating if the transaction we are looking at is the “final” transaction for an app, which is worth exploring; as far as I know, the application status should default to showing the most recent effective status already. By the way, if it sounds like I don’t know much about some of the dimensions, that’s right - this data warehouse has been in place for 6+ years and I’ve been working with just some of its perspectives for about three years, though not full time. I also write queries and reports on two other platforms, and do a lot of special reporting projects, so when I get to learn something new about a dimension or measure, it’s usually because of a specific request. I don’t have a lot of time for exploration that doesn’t have a developed use case.

I made good progress towards a project that should eliminate some manual data manipulation and help us further direct our decision-makers towards faster automated self-service analytics for their decision support. I feel pretty good about that. ๐Ÿ˜ƒ

(Now, anyway. If you’d asked me six hours ago I might have been a little more frustrated than satisfied. ๐Ÿ˜… It is always thus when in the throes of development and testing.)

No comments:

Post a Comment

Lots of annoying admin stuff, but also testing out some custom calculations

 I’ve been learning more than I ever wanted to know about login-based license management for Tableau Server, yet I still feel like I don’t h...