Yes, IMHO there should be something in place to either correct wrongly formatted input or at least specify the correct format to use
i.e.
yyyy-mm-dd
1 Like
I remember reading about the shouting WPEngine’s customers did a while back because their Google Analytics metrics were way different than WPEngine’s “visits” counter.
WPEngine responded with this:
http://wpengine.com/2014/02/03/refining-pricing-gap-solution/
Here’s a description of how they count visits:
http://wpengine.com/support/count-visits/
In short, they are pricing their tiers based on “visits per month”, counting them with separate IP hits per day (to actual content, not static assets), not pageviews.
This is a really easy metric to measure and I believe it would be a fair metric for your customers.
Perhaps this is the solution you’re looking for rather than using pageviews?
1 Like
This counter is based on Ember page transitions, so every time the browser transitions to a different “route”, the next request is counted.
2 Likes
Wow this is super complicated. Check it out. From their page:
Definitely good food for thought. It concludes with...
- When a human being first arrives on the site and loads the page, staying there for 31 seconds, that’s a visit.
- If that same human then clicks a link and sees another page, that’s not a new visit; that’s part of the same visit.
- If that same human doesn’t have cookies or Javascript enabled, still all that should count as one visit.
- If that same human loads the site with a different browsers, that’s still not a new visit; that’s part of the same visit.
- If that same human bookmarks the site, then 11 days later comes back to the site, that is a new visit.
- When a robot loads the site (like a Google or Bing search bot), that’s a visit, but if one robot scans 100 pages quickly, that’s one visit. (You might disagree that a robot is a “visit,” but consider that from a hosting perspective, we still had to process and serve all those pages just like it was a human being, so from a cost or scaling perspective, bots count the same as humans.)
- If a robot scans 20,000 pages over the course of a month, that’s not just one visit. It shouldn’t be 20,000 visits, but neither should it be 1. Something in the range of 100-1,000 visits is acceptable. This is because the same robot can come from different IP addresses.
- There are additional cases too where the “right thing to do” is less clear. For example, take the case of a “quick bounce.” Suppose a human clicks a link to the site, then before the site has a chance to load the human clicks “back.” Does that count as a visit? Our servers still had to render and attempt to return the page, so in that sense “yes.” But a human didn’t see the site and Google Analytics isn’t going to see that hit, so in that sense “no.” Because we need the notion of a “visit” to correspond to “the amount of computing resources required to serve traffic,” we round off in favor of saying “yes.”
We take the number of unique IP addresses seen in a 24-hour period as the number of “visits” to the site during that period. The number of “visits” in a given month is the sum of those daily visits during that month
2 Likes
Yup … but their solution was dead simple.
Count unique IP visits per day, discard static asset hits.
EDIT I didn’t notice @codinghorror’s edit there … 
1 Like
Warning! I got this reply from Jason Cohen (he’s a friend of the company)
Note on that, however: We do get blow-back from people who disagree with our definition of “visit,” to the point where we’re actively looking at changing our pricing to not depend on “visits.” So, beware!
So that simple definition of “visit” as
number of unique IP addresses seen in a 24-hour period as the number of “visits” to the site during that period
May not suffice.
1 Like
Maybe download bandwidth would be a good metric?
2 Likes
I still think page views (new term needed so we don’t confuse people with google analytics) as currently defined is good.
We do a +1 every time you hit a URL and get HTML back and a +1 each time you transition routes.
The one pain point we have with it is that bots can skew numbers a lot.
1 Like
You know who bots are because they only see non-JavaScript pages?
Perhaps bots for free and increase user request prices appropriately?
At the moment the only egregious bot we are seeing is actually one we are running to ensure sites are up and running, we test each site we run 3 times a minute and it adds up to quite a high number. So we will add a specific ignore for it in our custom plugin.
2 Likes
Actually I run Pingdom against a few of my Discourse instances and would benefit from a similar plugin.
Is this something that would be “easy” for you to open source?
If not don’t worry - I’m sure you have enough to do.
1 Like
Actually leaning on just using a our custom header for this,
If Discourse-Track-View is false or 0 do not count. Does pingdom allow you to inject headers?
Yes:
4 Likes
This is now implemented per:
https://github.com/discourse/discourse/commit/cbe18eb0dfb8063251d2b3f18d4a326464ef3e1b
3 Likes
Soo … how about simplifying this even more …?
Skip the traffic metric and base your pricing on # of users…
(I used dev tools to remove the traffic and just have limit on users)
1 Like
Thanks @sam! - updated my pingdom monitoring…
… not sure where to look to make sure it’s working - I’m sure some numbers in admin will decrease over the next couple of days.
1 Like
From our experience the vast majority of traffic sites get are from anon, you have to factor that in.
2 Likes
No, I don’t support limiting by number of users at all. Violently opposed. The whole point of Discourse is to build a large community. What if you have 100,000 users but only 1,000 show up every day? That’s what we want to measure and charge for, and that is activity aka “API views”.
Not to mention anons as @sam noted.
3 Likes
These stats are now visualised as well!
3 Likes