Broken line chart in Tess Analytics

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:

  • x-axis: order date by days in date
  • values: RSUM(Total Ticket Paid Amount)
  • break by: performance

 

Parents Reply Children
  • ,

    I am trying to do something similar and I do not have the "Display Missing Values as Zeros" option either.  RAMP as well for me.  Did you get that eventually straightened out?  I am looking at some running sales data that looks misleading to me because it keeps skipping random numbers.

    John

  • Hey JAM2.0

    does that analytic coffee wiki link answer your thoughts.  there are get rid of the dots and join the lines options

  • ,

    (Delayed response; was out of the office for a few days, taking them breaks!) Thanks for that suggestion!  Unfortunately, it does not, though I feel like it is getting close.  The problem with my data is that there are points in all of the data being returned with there is just no information.  If there was some OTHER line returning that data point that link helps to connect the non-changing data, so that DID indeed help some of the other lines, but not the overall issue.  I am looking at a running sales by week (and by day, but the week is more obvious in its flaw).

    For example, this image is just looking a single performance run of one of our classical events (it did not do too well, but was a fabulous concert).  Anyway, just looking at this makes one thing that single ticket sales started off slow but then picked up as time went on.  If you are looking merely at graph designations, assuming that the changes are weekly, you assume that first month so (4 lines) was a little slow but then things started picking up.  However, looking closely AT the axis designations, you will note that there were just plain no sales on weeks 6, 9 and 11.  So it is not really one month of slow sales, but almost two full months of slowness.

    To anyone looking for a graph of change over time, they want to see those flat sections there.  At least, I would.  I do not want them skipped because of "no data".  Looking at the numbers solves that issues, too, but the general idea behind a dashboard for many is not to have to look THAT closely, and that visual certainly is a little more skewed to the reality than I would like.  I want to be able to look at them and say "wow, that was a long time with basically no sales; I wonder why that was" instantly just by reading the graph, not having to read and decipher what was going on on the Axis.

    I feel like there HAS to be a way to do this, but I am currently stymied.  All thoughts welcome.

    JAM 2.0

  • Oh my dude! you are after Continuous Timeline me thinks.  It's an option in the hamburger of the X-axis in the widget

    Be careful though if you push through too much data in v15 it'll blow up your dashboard and you have to edit the code in Notepadd++ to go back to Contiunuous Timline =off.  But looks like you are on weeks so should be all good.

  • Hi John,

    From an Analytics perspective, when there's no related data (sales and seats in a given bucket) it doesn't know that Fiscal Week of Year 6 comes between 5 and 7 weeks any more than it knows My Name is Not Mom comes between Postmodern Jukebox and Johnny Mathis on an event calendar. The exception to that is the Continuous Timeline feature that's available only on [Date] fields in Analytics. I think we can get you a step closer to what you want though, and then let's look again.

    Because those weeks don't exist in the data, we need to expand the data set for the widget and then do the filtering in the values. For example, if we have a dashboard filter limiting the set to the current season, all the widgets on the dashboard might respect that filter. In this widget, we might override the filter to include also last season, or even all seasons. With that, we can expect prior seasons to have sales against those weeks, so they should appear on the x-axis. 

    Then in each of the Values, add a filter on season that mirrors the dashboard filter. E.g.

    ( [Total Ticket Count] , [Price Type Category = Subscription] , [Season = 2023 Season] )

    I expect that will work, but may also have the unexpected/undesired outcome of showing all future weeks in the current season as well. 

  • 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, .)  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.