I'm trying to build a line chart that tracks cumulative performance revenue by order date. I've noticed in our environment that if there are periods where there were no sales, Tess Analytics does not continue to draw the line, instead it breaks down into smaller dashes and dots. Has anyone else experienced this? Is this part of how the sisense software works, or is there something else to look into? Thanks!
For reference:
After-thought, John...
If after the changes to include prior seasons the lines or widget extend into the future and you'd like to limit the scope to only Fiscal Weeks to Date, you can do that with the Fiscal Year to Date Flag field set to include only Y.
While I understand the notion of what you are trying to say, the shape of the matter is that our data here is non-compliant. Even if I throw in the entire season worth of data points from the top of the widget and then start filtering out at a granular level, there are still multiple days where we have no sales (especially over the heart of the summer when our patron base tends to be on vacation). For good or ill, some times we just do not have that many tickets coming in and out on a daily basis. I think I CAN move away from the days since on-sale and to just the simple order date function so as to take advantage of the continuous timeline here. (Thanks for the suggestion, Heath Wilder.) So that takes care of the initial issue with that graph above.
But I still return to absent data issue. I get that, from a data warehouse standpoint, a lack of data on Week 6 means nothing will be returned (and we will for the moment ignore the fact that we cannot easily report on returned tickets as a rate of change CAN go down). And that makes sense from there being nothing in the data that says that. But if a widget is going to be a change over time widget, I would feel like it also has to be smart enough to understand that a week 6 point being plotted is a thing that also needs to happen as well. Basically, for change over time to be accurate, you take the first date that exists, the last date exists and then you plot everything in between whether daily/weekly/monthly. If that data is not in the warehouse, then a zero should be returned. Any database person writing a report knows how to account for that and either insert phantom data for those dates or else construct the required formulas so as to avoid that. And so if you want to sum across the gaps, and look at things like rate of change, yes, there will be some weeks where you have 0% rate of change.
After all, even if there is no data for week 6, it is not like the fact that 6 exists between 5 and 7 is a surprise. We all know it exists there. And so, even being able to illustrate a graph that looks good makes it difficult when you are trying to do more complex calculations based on data that is not there. One of the graphs I have been asked to make is for a % sold/weekly rate of change against the final tally. This is a relatively simple formula that a staff member has on an Excel spreadsheet from which they simply took to the total sold count on the nightly reports and placed them in there. Sounds easy. But I admit, I am not at all sure how to reproduce this in Analytics when random numbers jump up and down because they comparing one week's data against the complete absence of data from the week before. Here is a graph/shot of this second one I wish to produce from Excel.
And I am not even really worried about trying to get them on the same graph; two separate widgets would be fine there. But to get a consistent running percentage of the end total, I admit, is passed what I can try and figure out.
This has long been a difficulty of mine
I'm semi-surprised that Fiscal week of year is nominal (I'd expect that of day of week which needs a ranking, and month of year similarly). I hate excel for how hard it is to do running sums across years from a pivot - because of the layers of bucketing it does with dates. I used to convert the date to an integer to manage it.
I've toyed with creating a dummy performance with one ticket "sold" per day throughout the year and including it as a invisible bucket, like a ruler. End's up with a lot of filtering on the value level.