There is no single "correct" method of accomplishing this task. Let me explain why.
Within a single IP many PC may reside behind the NAT. Within a PC user may use different browsers. Withing each browser user can reset it's history (or simply clear cookies).
From other side user can have multiple devices that will create multiple IP addresses for a single user.
In such way a single human can have many user accounts and multitude of historical sessions (i.e. periods of time when neither cookies not environment were not reset).
The most appropriate way counting users is assigning each "clear" session (which has no tracking cookie set) new cookie with a unique ID, which is written back to DB. Upon multitude of criteria IDs are merged.
You can merge two IDs when:
- user logged in your system (assuming each person has its private credentials).
- you suspect very intense cookie reset, i.e. spam attack, maybe via Maching Learning
- there is any other action sequence that connects those IDs
In terms of schema, you may use four tables:
hits (*-1) sessions (*-1) people (1?-1) users.
Each hit just connects the visited page and tracking ID in time.
Each session is uniquely described with tracking ID and contains browser and client data (UA, IP etc) and (possibly) foreign key to people row.
Each row of people table represents "unique" visitor. If it's registered, it has one-to-one FK to users table.
However, it might be much better to use log processing tool or write stats to MongoDB collection in order to handle big load.
P.S. If you really need to count exact number of hits, like in serious voting system, you might require SMS two-factor authorization with one-time prior identity verification (like dummy credit card hold) each time the historical session is reset. But something tells me that's an overkill for you.