WordPress.org

Ready to get started?Download WordPress

Forums

WP SlimStat
[resolved] Feature Request: Scale graph of specific date range by views DURING that range? (6 posts)

  1. MGmirkin
    Member
    Posted 1 year ago #

    Okay, so, I tried tunneling down to a specific date range. I think I said something along the lines of Feb 1, 2013 + 12 days (on the 13th I disabled Javascript Mode and our total views spiked back to normal levels).

    Anyway in Javascript Mode, views were around 40/day, in non-Javascript Mode it's more like 9000/day (25,000/day after enabling Wordfence throttling of excessive search bots, which was a counter-intuitive response).

    Anyway, I wanted to see what total views & unique IPs were during the pre-non-Javascript Mode period, to compare to the post-non-Javascript Mode period. The problem is, when I tell it to tunnel down to Feb 1, 2013 + 12 days (or even +11 days), it still seems to scale the graph based on the entire month of February, and not JUST based on the period in question (or something like it [See update @ bottom for what's probably actually happening]). So rather than the scale being about 1-->40, the scale is 1-->800, and the graph is a little line along the bottom. I'm not sure why it's scaling to 800. It seems a bit arbitrary I'd think it would be scaled to the nearest 10, 25, 50, 100, 500, 1000, etc. Or something like that?

    If total page views maxed around 40-50 during the period of Feb 1-12, 2013, and I tell it to JUST graph that period, I'd like it if the graph scale changed appropriately to have the scale cap at ~45-50 instead of capping at 800+ (since some days after turning off Javascript Mode showed total views in excess of about 8500 views).

    See what I'm saying? If I narrow the range of dates to graph, the graph should take into account that range and set its scales according to the data that falls within the date range.

    For example, taking this data set:

    Feb 1: 5 views,
    Feb 2: 40 views,
    Feb 3: 25 views,
    ...
    Feb 12: 48 views,
    Feb 13: 443 views,
    Feb 15: 6987 views.

    If we set the date range to Feb 1-12, the y-axis should be capped at ~50.
    If we set the date range to Feb 1-13, the y-axis should be capped around ~450-500.
    If we set the date range to Feb 1-15, the y-axis should be capped at ~7000.

    Make sense?

    If that's possible, it would be neato! ^_^

    (Update: I think I figured out what it's doing. Maybe?

    So, it doesn't show up while in the "tunneled down" view with just the selected dates showing, but in the regular view with filters removed it graphs a comparison graph in gray that's the prior month's page view history at the same times that month. Last month, my graph peaked around 760, so I think that portion of the graph, within the specified dates of the month, scales to ~800?

    Problem is, in the "tunneled down" view that specific "last month comparison" graph doesn't show up but still maybe impacts the overall graph scaling?

    So, perhaps the solution is to either 1) show the last month's data comparison graph on the tunneled down view and scale the tunneled down view graph based on the highest of all graphs shown in tunneled down view, or 2) Don't show the "last month comparison" graph at all AND don't count it toward the "tunneled down" view graph's scaling. 3) Give an option of whether or not to include last month's comparison graph in the "tunneled down view" and either include it in the scaling if graphed or exclude it from scaling calculation if it's not graphed.

    *I think* that'll fix the issue, if I'm figuring correctly what's going on? It's subtle, so there's a chance I might be wrong what's going on, but *I think* that's it...? Check my logic? Happy to be corrected. ^_^

    Hope that was all cogent and made sense. Just to clarify, by "tunneled down view" I just mean the graph with date selection criteria applied)

    http://wordpress.org/extend/plugins/wp-slimstat/

  2. MGmirkin
    Member
    Posted 1 year ago #

    Yeah, I think it has to do with the prior month's graph comparison. I can limit to the 9th to 11th of February, and the graph scales to about 500 because during the 9th-11th of January a max of about 480/day was recorded during that period (a lull in hits before Javascript mode was enabled), whereas during the 9th to 11th of February (with Javascript Mode enabled) 'recorded' hits maxed around 40.

    So, the "tunneled down" (date filtered) graph of 9th-11th of Feb, 2013 has a y-axis range of ~500 but a graph that only maxes around 40. So, it's pretty clear that the "Last Month Comparison" graph is being factored into the "tunneled down" (filtered) view of this month's data, despite not actually being graphed when the dates are filtered.

    It does seem to me like that's what's going on. So, see my suggested solution(s) at the bottom of the prior post, reiterated below:

    Solution options:

    1) Don't graph past month's stats for comparison, don't use that graph in calculating scale for filtered view of this month's stats.

    2) Show the graph of prior month's stats during the same filtered dates and scale the graph based on the highest counts in ALL graphed data sets.

    3) Give users the option of viewing or not viewing prior month's graph along with the current data filtered by date ranges and scale the graph appropriately, according to their choice, as in 1 or 2 above.

    Hope that makes sense?

    Best,
    ~MG

  3. camu
    Member
    Plugin Author

    Posted 1 year ago #

    Very good point (even though it took you ~870 words to express it! jk). It is indeed because of the prior month comparison. This will be fixed in version 3.0.

    Best,
    Camu

  4. MGmirkin
    Member
    Posted 1 year ago #

    Yeah, sorry 'bout that... ;) Bad habit. Trying to figure things out whilst writing. But did figure it out in the end. ^_^

  5. camu
    Member
    Plugin Author

    Posted 1 year ago #

    That's fine, no prob. Thank you for pointing it out.

  6. camu
    Member
    Plugin Author

    Posted 1 year ago #

    Hi there,

    please see if version 3.0 fixed this glitch for you.

    Cheers,
    Camu

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic