(Updated 25th August 2021): Updating Umami section has been added.
For any new site, there is always the tendency to reach out and grab Google Analytics as the "go to" method for collecting and analysing stats about your site and users. I, for one, have been guilty of that in the past but with the growing popularity of open source analytics and cheaper options out there, more and more developers are looking elsewhere.
Personally I am trying to move what I can away from Google's ecosystem but, in the grand scheme of things, I think there is something fundamentally wrong with how easily we open up our sites to Google. I think a lot of the time this comes down to convenience and the perceived best practice of it all, which is totally understandable, and something I can relate to. But, with internet privacy becoming an alarming concern for many people I think it makes sense to explore other options, and keep our visitor information safe.
In addition to this, here are some other benefits I can see:
Note: Before I ventured down the path of self-hosted analytics I researched whether it was possible to set up Google Analytics to be GDPR compliant. At the time of writing this, there was nothing concrete or anything "official". For the amount of developers/site owners that reach for Google Analytics for a new project, I found it interesting and slightly disappointing that there wasn't extensive documentation or guides for this.
It may be a coincidence or it may be fate but as it happens the first open-source analytics solution I digitally stumbled across was in fact Umami! I first discovered it from issue #102 of Kai Brach's Dense Discovery and even though it came out a while back, it still made a big impression on me. In addition to this, thanks to the Twitterverse and "the algorithm", I came across Mike Cao’s (@cauzilla) post How I wrote Umami in 30 days which shared some great insights into the inspiration, why the project came to be and how it was created. I’m still pretty blown away that it only took 30 days from start to *finish. But as fated as this was I did look at a few other solutions:
Ackee
Free Alternative
Fathom
Paid/Free Trial
Splitbee
Paid/Conversion Focussed
Now I had chosen an analytics solution I needed to decide where it was going to be hosted. As a rule, self-hosting an open-source project can be a bit of a pain with many moving parts. Luckily, Umami's docs give you a few options when it comes to hosting, ranging from all-in-one solutions (DigitalOcean, Railway, Heroku) to set up your frontend and back-end separately (Vercel). The biggest thing for me here was finding an easy to use, all-in-one solution so I didn't need to worry about the database and UI layer separately and sign up for two different services. So, as with anything, I did a couple of searches and came across Railway.app via the blogpost Self Hosted Web Analytics.
Railway provided everything I wanted above, a single service that automagically deploys the database and front end for you, and linking them together seamlessly. Having never heard of Railway before I was excited to give it a go.
Note: You could also use Heroku which from what I remember should set up your database and UI layer for you, but I've never been a fan of Heroku so that's why I didn't use it.
I'd like to tell you that it was a complicated process and only really smart people will be able to accomplish this but in reality, it's one of the easiest, friction-free deployment processes I've experienced. Railway provides you with an Umami starter (along with a lot of other starters worth checking out) which automagically deploys your Postgres database and Next frontend for you. To get started you can click this link.
HASH_SALT
(this can be anything you want) and then click deploy.So we have Umami up and running on Railway and everything is starting to come together. The only thing left for us to do now is to configure our website in Umami and add the tracking script to our website. So let's do just that:
add website
Name
and Domain
fields and click save</div>
button next to our newly created domain. Click it and copy the tracking code_document.jsx
file (you may need to create this if you haven't already) we can add the followingimport Document, { Html, Head, Main, NextScript } from 'next/document';
class MyDocument extends Document {
render() {
return (
<Html lang="en">
<Head>
{process.env.NODE_ENV === 'production' && (
// the tracking script copied from umami
<script
async
defer
data-website-id="your-umami-id"
src="your-umami-src"
/>
// end of tracking script from umami
)}
</Head>
<body>
<Main />
<NextScript />
</body>
</Html>
);
}
}
export default MyDocument;
Notice how I have added the process.env.NODE_ENV
conditional here to make sure that we are only getting stats sent to umami on production. The conditional could be more complex in my opinion but it works for what I need.
Once your site is deployed with the tracking script you should start to see some stats coming through in Umami.
There we have it! In a relatively short amount of time, you can move your personal site/project away from Google analytics and have the peace of mind that you own the data and a range of other benefits. I want to give a big thanks to Mike Cao (@cauzilla) for creating Umami as without him the project wouldn't exist, and if you do switch over I hope you will send him some love. Also, big claps for railway.app as they have taken the (annoying) problem of self-hosting open-source projects and made the process incredibly easy. What they've built and achieved with this is nothing less than remarkable.
Finally, I do hope you will check out Umami or any of the other listed solutions and migrate away from Google Analytics. I don't think you will regret it.
Being a relatively young project there are bound to be a lot of updates, so how do we update our Umami repo and deploy it to Railway? After updating from 1.17.0 to 1.22.0 here's how I did it:
git remote add upstream <https://github.com/mikecao/umami.git
>.git pull origin master
we should get an error fatal: refusing to merge unrelated histories
. We could force this to happen by appending -allow-unrelated-histories
but this leaves us with a bunch of merge conflicts. To me (and it may just be me) it makes more sense to "start again" with an upstream to the original repo.git reset --hard origin/master
. This will replace all of our local files with what exists in original repos master (the latest update)./bin
and package.json
. Taking this as best practice apply the same changes to your updated project.f
your git push
command and once that is pushed Railway will automagically deploy it for you. If your wondering how this happens, you can head to your Railway project and go to Deployments > Triggers. You'll see that it's connected to your repo and auto deploys when any changes are made to your main branch.