![[HSX] HeadShot Xtreme is officially recognized by the Central Outpost as a genuine gaming organization.](https://www.headshotdomain.net/files/coRpSE/cnopseal_X74-MEW1.png "[HSX] HeadShot Xtreme is officially recognized by the Central Outpost as a genuine gaming organization.")
Hello everyone. Well, yet again, I started looking at old projects that I started and then stopped, and I decided to take it up and actually do it. A couple of years ago at most, I remember talking to a few people, including Lonestar, about redoing the "Database", and the "System Info". Well, at the same time, I mentioned I would like to do a basic website analytics for the CMS. There are some that don't really work in the forums, and back in 2016, I did a tutorial on how to intergrade Matomo, (Piwik), into your site for analytics, but the downfall to that was, it was a pain in the butt, and could slow down your site, and it had a lot of issues with their auto update system they had. So I start working on one a few years ago, and I found my folder with just a few lines of garbage in it. I was messing with Google charts/graphs back then. And I got as far as finding a few graphs I didn't like, and that was it.
Well, for the past 3 days, I have been working on that script and thought this is an old image, (when I say old, I mean from yesterday and doesn't have the new graph in it due to me truncating the table this morning), but here is an example of what it looks like now-ish:
I am still working on it and will be for a couple of weeks, but I am kind-of stuck on one area, and I am wondering if anyone in the community has any thoughts or ideas.
Here is what it has at the moment:
Now, here's the issue.
One of the issues I ran into while building the analytics logging was trying to properly detect tablets. At first, I was relying just on the user-agent string like most setups do, but I quickly realized how unreliable that is. A lot of tablets, especially Android ones, either get detected as mobile because of the “mobile” keyword in the user-agent, or they show up as desktop because the browser is in desktop mode or doesn’t use the word "tablet" at all. That was throwing off the stats pretty badly. Devices like the Nexus 7 or Galaxy Tab just weren’t consistently getting picked up as tablets.
To work around that, I ended up adding a small JavaScript check that runs on the client side, and looks for certain signs that the device is likely a tablet. It checks if the screen is a certain width, if the device supports touch, and makes sure the user-agent doesn't include the “mobile” keyword, which usually means it’s a phone, like a foldable phone. If it passes all that, it sets a cookie that we can then read server-side and use to flag the device correctly as a tablet.
Here’s the bit of JavaScript I used:
Then on the server side, I check for that cookie before falling back to the regular user-agent checks. That gives us better accuracy overall, (I hope).
Here’s the PHP chunk:
This setup seems to be working pretty well now, but I’m putting this out there in case anyone has a better idea or has run into the same issue and found a cleaner or more accurate way to handle it. I have even gone to the extent of using ChatGPT, but I must say wow, that still needs a lot of work.
I am hoping, after about a week of testing, and still optimizing everything, I should have some better SS to share and maybe have something available for some to test by the end of next week.
If there is any other info you like to be there in the chart, suggest it and I will think about it and maybe add it.
Well, for the past 3 days, I have been working on that script and thought this is an old image, (when I say old, I mean from yesterday and doesn't have the new graph in it due to me truncating the table this morning), but here is an example of what it looks like now-ish:
I am still working on it and will be for a couple of weeks, but I am kind-of stuck on one area, and I am wondering if anyone in the community has any thoughts or ideas.
Here is what it has at the moment:
- Visits over the past 7 days - using a mountain chart, this is used for the visits over the last 7 days. It will always show 7 days worth of activity.
- Device Type Usage - Using a bar graph, this shows what is used mostly to visit your site, (Desktop, Mobile, Tablet, Bot, or unknown).
- Visits Over the Past 30 Days - Using a bar graph again, it does the same thing that the visits over the past 7 days does.
- Visits Over the Past 12 Months - Save as before.
- Visits by Hour (24h) - This one is in 2 hour intervals, and is a horizontal bar graph, except when viewing on mobile, then it's vertical.
- Recent Visitor Logs, (last 100) - This shows the page they visit, IP, username, device, referral link, and date & time. If you click the IP, a geoip popups with a bit more info.
- Truncate Table button - this empties everything from the analytics table.
Now, here's the issue.
One of the issues I ran into while building the analytics logging was trying to properly detect tablets. At first, I was relying just on the user-agent string like most setups do, but I quickly realized how unreliable that is. A lot of tablets, especially Android ones, either get detected as mobile because of the “mobile” keyword in the user-agent, or they show up as desktop because the browser is in desktop mode or doesn’t use the word "tablet" at all. That was throwing off the stats pretty badly. Devices like the Nexus 7 or Galaxy Tab just weren’t consistently getting picked up as tablets.
To work around that, I ended up adding a small JavaScript check that runs on the client side, and looks for certain signs that the device is likely a tablet. It checks if the screen is a certain width, if the device supports touch, and makes sure the user-agent doesn't include the “mobile” keyword, which usually means it’s a phone, like a foldable phone. If it passes all that, it sets a cookie that we can then read server-side and use to flag the device correctly as a tablet.
Here’s the bit of JavaScript I used:
Code: [ Select all ]
(function() {
   function isTablet() {
   const ua = navigator.userAgent.toLowerCase();
   const isMobileUA = /mobile|iphone|ipod|android.*mobile/.test(ua);
   const isTouch = navigator.maxTouchPoints > 1;
   const isWideScreen = screen.width >= 600 && screen.width <= 1280;
   return isTouch && isWideScreen && !isMobileUA;
  }
   if (isTablet()) {
    document.cookie = "device_type=tablet; path=/";
   }
  })();Then on the server side, I check for that cookie before falling back to the regular user-agent checks. That gives us better accuracy overall, (I hope).
Here’s the PHP chunk:
Code: [ Select all ]
$device_type = 'desktop';
  if (isset($_COOKIE['device_type']) && $_COOKIE['device_type'] === 'tablet') {
    $device_type = 'tablet';
  } elseif (preg_match('/mobile|iphone|ipod|android.+mobile/i', $agent)) {
    $device_type = 'mobile';
  } elseif (preg_match('/ipad|tablet|nexus 7|nexus 10|sm-t|gt-p|lenovo tab|kindle|silk/i', $agent)) {
    $device_type = 'tablet';
  } elseif (preg_match('/bot|crawl|slurp|spider/i', $agent)) {
    $device_type = 'bot';
  }
This setup seems to be working pretty well now, but I’m putting this out there in case anyone has a better idea or has run into the same issue and found a cleaner or more accurate way to handle it. I have even gone to the extent of using ChatGPT, but I must say wow, that still needs a lot of work.
I am hoping, after about a week of testing, and still optimizing everything, I should have some better SS to share and maybe have something available for some to test by the end of next week.
If there is any other info you like to be there in the chart, suggest it and I will think about it and maybe add it.
Lot of resources being used just for the sake of a UA Parser. Anyone that ever wants to test websites, or be an overall annoyance:
... There must be hundreds of these browser extensions that allow a uers to spoof just about anything they want. What exactly would be the point?
However, if it just so happens to be the case that you just have to parse UA on your own, you are going to need a MASSIVE library.
| Please login to see this link Get registered or Log in |
However, if it just so happens to be the case that you just have to parse UA on your own, you are going to need a MASSIVE library.
Yeah, I’m already aware that user agents can be spoofed, and when working on this I was using one of those plugins, but that’s not really the concern here. The goal isn’t perfect device fingerprinting, it’s just basic categorization for internal analytics, (mobile, tablet, desktop, bot, or other). I’m not trying to identify exact devices or OS versions, so I don’t need a massive parsing library. Just simple grouping, and for that, a lightweight check is more than enough. The question was more for, if anyone knew of a better workaround than what I am doing with the HTTP_USER_AGENT.
screen resolution would be the better choice ... A person can spoof lower, but not higher. The rest is just wasted resources. Just follow CSS Media Breakpoints.
The page hits would be more important! Who came from where? and what was the initial page view hit? Downfall of evo is that "ALL" page hits are index.php!!! One would have to mod the hell to get the meta tags to actually match the page content just to get any useful "why / what are people attracted to on my wesbite" type of thing.
Consensus:
<576px> 576px <768px> 768px <992px> 992px <1200px> 1200px <1400px> 1400px = desktop or TV or projector
Id prolly double check OS and CPU with the above to doublecheck the device against, but both of those would require libraries, the same as UA parsers ( I would think smaller libraries though! )
The page hits would be more important! Who came from where? and what was the initial page view hit? Downfall of evo is that "ALL" page hits are index.php!!! One would have to mod the hell to get the meta tags to actually match the page content just to get any useful "why / what are people attracted to on my wesbite" type of thing.
PHP: [ Select all ]
document.documentElement.clientWidth // Gets Your Viewport Width PHP: [ Select all ]
document.documentElement.clientHeight // Gets Your Viewport Height Consensus:
<576px> 576px <768px> 768px <992px> 992px <1200px> 1200px <1400px> 1400px = desktop or TV or projector
Id prolly double check OS and CPU with the above to doublecheck the device against, but both of those would require libraries, the same as UA parsers ( I would think smaller libraries though! )
Last edited by Doug on Sun Jun 29, 2025 5:08 pm; edited 1 time in total
I just don't think IMO that the screen res alone is thorough enough. I do however agree that the page hits in Evo (and classic PHP-Nuke systems), almost every page loads through index.php. That is why I have all the logging within the mainfile.php. I also built in a measure to stop deduplication by using a 5-second filter for same page results.
Damn.... Editor fudged up my edit, Resolution + OS +maybe+ CPU ..... much smaller libraries, much less resource. Also note, the check should be done on initial page load, never AFTER... all native JavaScript, just push the data to your website via post / or read cookie on next page load.
Yeah, I hear you. Thats more in line with what I’m doing already. I'm not using any libraries, just a quick UA + resolution + touch check combo, and setting a cookie to determine the device type for the next request.
I agree that detection should happen early. Right now I’ve got it in a script block that runs as soon as it’s parsed (wrapped in an IIFE), so it sets the cookie on the first load. From there, the backend can read it immediately on the next page view.
I did consider using fetch() to push it via POST, but since the server-side logging is already time-sensitive and cookie-based, it made more sense to keep it that way for now. Things may change
I agree that detection should happen early. Right now I’ve got it in a script block that runs as soon as it’s parsed (wrapped in an IIFE), so it sets the cookie on the first load. From there, the backend can read it immediately on the next page view.
I did consider using fetch() to push it via POST, but since the server-side logging is already time-sensitive and cookie-based, it made more sense to keep it that way for now. Things may change
I do an internal API ( both in and out ) since I like buttons to trigger changes on-click, but I'm greedy like that. I also don't add Javascript libraries since everything needed is built into Bootstrap, or Jquery. I have spent more time stripping bloated crap out of the core than I care to admit.
The Biggest chore I had was removing all of the "echo" statements out of every script/file i could find and replace it with a single variable. That alone was a massive cleanup!
The Biggest chore I had was removing all of the "echo" statements out of every script/file i could find and replace it with a single variable. That alone was a massive cleanup!
found an alternative! ( Just cause the question sort of intrigued me )
Pretty much only available on Chromium Browsers, so have to do a fallback if THAT is not available first.
Or could just return arrays from both and parse whatever returned.
| Please login to see this link Get registered or Log in |
PHP: [ Select all ]
let platform = navigator?.userAgentData?.platform || navigator?.platform — Doug wrotefound an alternative! ( Just cause the question sort of intrigued me )Pretty much only available on Chromium Browsers, so have to do a fallback if THAT is not available first.
Please login to see this link
Get registered or Log inOr could just return arrays from both and parse whatever returned.PHP: [ Select all ]
let platform = navigator?.userAgentData?.platform || navigator?.platform
I'll look into that. Might be good to have in place just in case it gets more widely used.