A couple issues, not sure they've been addressed

MediaServe

There have been a couple bugs that I've reported to support, but to avoid asking them about these things again as a ticket, I figured I post about it.

Problem one. We have a client that uses https://sendy.co/ for bulk email. Enhance doesn't support this script due to the lack of the calendar module.

Problem two: Website analytics have wildly inflated numbers for the first couple days, and somehow they settle down somewhere about day 3 to reasonable numbers.

Problem one is fairly critical for cPanel migrations which I hope to begin after the November update.

Adam

MediaServe Problem one. We have a client that uses https://sendy.co/ for bulk email. Enhance doesn't support this script due to the lack of the calendar module.

We can add this module. It is technically possible to compile your own PHP modules but this is not something we currently support.

MediaServe Problem two: Website analytics have wildly inflated numbers for the first couple days, and somehow they settle down somewhere about day 3 to reasonable numbers.

These numbers are taken directly from the web server log, similar to more traditional web stats packages like AWStats and Webalizer. Unique visitors are calculated from a hash of UserAgent + IP which is a reasonable method but will, for example, count the same user as multiple "uniques" if they have a rotating IP. These stats are more useful for correlating traffic against server load than they are for website visitor analysis which is better done with something like Google Analytics.

MediaServe

Adam

In our ticket discussion about the calendar module you said:

It's ok I've already logged it in our Asana :-)

So this should be resolved at some point correct? Hopefully before we can migrate from cPanel in December?

Regarding the analytics I get what you're saying but the actual problem is those daily totals change by day 3 and alway significantly downward. That's what my line of questioning is about. The analytics numbers should not change after 3 days. I don't plan for our hosting clients to rely on the analytics for business decisions but I do want to prevent those numbers fluctuating like they have been since the time we saw it happening a few months back.

MediaServe

Adam Any chance of getting a response to my last reply?

Adam

Sorry for the delay. Yes it should easily be possible to add the calendar module to the default PHP config before December. We release PHP updates separately to the main update schedule.

I don't have an explanation for the stats fluctuating. They're taken directly from the web server logs so it shouldn't be possible for them to be wrong. We also have a lot of tests in CI for stats accuracy.

When we add the log retention feature, we can maybe compare the retained logs to your processed stats and look for any discrepancy there.

MediaServe

Regarding analytics I'd like to provide an example. Here are analytics for the past four days with the exception of the current day in progress. These are the daily unique visitor stats.

I will track how those numbers change over the next two days to prove my point. These are collected from a LiteSpeed server:

10/25: 1242
10/26: 1294
10/27: 1278
10/28: 2256

As you can see the 10/28 numbers are inflated, but even 10/27 will change. 10/25 & 10/26 will not. We're currently measuring stats from 10/29 so 10/28 shouldn't be changing, but I'll show the numbers tomorrow.

MediaServe

I decided to check the uniques about half an hour from GMT for 10/29 since the containers don't honor the server time zone.

At that point the uniques amounted to 3466.

Ran some errands, had a late dinner, returned home to check the uniques again for 10/29 and they've been reduced slightly to 3293 after the day boundary passed. And of course that day's numbers will decrease drastically for the next two days.

Here's all the current numbers:

10/25: 1242
10/26: 1294
10/27: 1278
10/28: 1244 (originally 2256)
10/29: 3293 (originally 3466)

This is why the analytics aren't remotely accurate for 2-3 days (and who knows they're trustworthy then?). I'll post new numbers tomorrow for 10/25 through 10/29 to show how they change.

Adam

I'm wondering if this might be a UI issue related to the local timezone moving past the midnight boundary. In theory the stats returned by the API are immutable and are recorded in UTC.

We will try to reproduce this behaviour and if we can find a bug it will be fixed in an upcoming release.

Thanks for reporting.

MediaServe

It's not the first day boundary, it's declining after the first boundary and into the second one too.

Current numbers now:

10/25: 1242
10/26: 1294
10/27: 1278
10/28: 1244 (originally 2256)
10/29: 1057 (originally 3466 near the end of 10/29, then shortly after the first day boundary fell to 3293)

10/29 decreased a bit after the first day boundary, and then plummeted at the next day boundary.