{"id":163,"date":"2023-04-20T20:10:52","date_gmt":"2023-04-20T20:10:52","guid":{"rendered":"https:\/\/hotbrain.co\/?p=163"},"modified":"2023-04-21T22:21:12","modified_gmt":"2023-04-21T22:21:12","slug":"segmenting-out-internal-website-traffic-the-most-robust-while-still-practical-way-possible","status":"publish","type":"post","link":"https:\/\/hotbrain.co\/segmenting-out-internal-website-traffic-the-most-robust-while-still-practical-way-possible","title":{"rendered":"Segmenting out internal website traffic: What’s the best way?"},"content":{"rendered":"\n
When you have a large staff and\/or a staff that visits the organization\u2019s website a lot, it can really mess with your website analytics data. It\u2019s easy to imagine 10\u201320+% of your website traffic<\/strong> being irrelevant to your external marketing efforts \/ the audience you want to reach. This in turn nerfs conversion rates, while inflating traffic, engagement \/ time on site, etc! And of course, it also precludes doing internal website usage analysis.<\/p>\n\n\n\n To make matters more complicated, these days a lot of the time staff just isn\u2019t at the office\/campus, and\/or is using their mobile phone data vs the office wifi\u2014so GA4\u2019s built-in IP address filter<\/a> method is just really not a good solution at all.<\/p>\n\n\n\n We could<\/em> take a fairly passive approach and segment our traffic by those users who visit the administrative area<\/strong> of the organization\u2019s website.<\/p>\n\n\n\n But this is pretty weak since, for many organizations the people who regularly do this might be limited to a very small number of personnel. However it could be a good fit if all employees are required to log in to the website for HR purposes\u2026<\/p>\n\n\n\n The other major challenge is that normal segmentation relies on either setting our own, or using Google Analytics\u2019 built-in cookies. We decided that cookies were too fragile, as they tend to get deleted after a year (max), some users delete them periodically manually, or don\u2019t accept them at all. And people just generally have something of an aversion to them nowadays, so minimizing reliance on them is not a bad call.<\/p>\n\n\n\n In the end, we couldn\u2019t find a solution that was robust enough for us<\/strong>,<\/em> especially since we don\u2019t work at our client\u2019s organizations full-time and don\u2019t want something high maintenance\u2014i.e. where we would have to be updating (potentially) rotating IP addresses for staff (we already looked at why this was suboptimal anyway), replacing cookies, etc. (yes, cookies could be replaced automatically if not present, but again we wanted to try something that wasn\u2019t cookie-based).<\/p>\n\n\n\n First, we had our client ask all staff to visit a special, secret URL on the organization\u2019s main website.<\/p>\n\n\n\n When that URL was visited, we used Google Tag Manager (GTM), along with some special custom javascript, to place a \u201cpermanent\u201d record in the browser\u2019s local storage<\/strong> that indicated that they were \u201cinternal\u201d traffic.<\/p>\n\n\n\n Basically it\u2019s a more permanent, harder-to-delete place to store persistent data in browsers (it also offers larger storage than wimpy cookies). You can read more about it here<\/a>. It\u2019s also very easy to interact with via javascript!<\/p>\n\n\n\n You can see local storage in action here:<\/p>\n\n\n\nSo what can we do?<\/strong><\/h2>\n\n\n\n
What we ended up doing:<\/strong><\/h2>\n\n\n\n
What\u2019s local storage?<\/strong><\/h2>\n\n\n\n