Weekly Indie Log #11

Coding week for 29th April to 05th May was a bit of a downer. I had big plans but couldn’t manage to do all that I wanted to do in the week. A bit of a recurring theme for the last couple of weeks as other aspects of my life (day job/personal life) have been bleeding into my solopreneur life.

Nevertheless, I did some additional work around the web analytics which I shipped the week before and also tackled a problematic issue with deployment for Stomod. Let’s dive into those.

Improved Web Analytics

If you remember from my Weekly Indie Log #9 , I released web analytics for all users of Stomod to enable them to have an overview of everything that’s happening on their blogs within Stomod.

There were a bunch of metrics included in the initial release among which were:

• Top Pages

• Referrals

• Bounce Rate

• Countries

• Languages

• Devices

• Desktop Screen Sizes

• Browsers

• OS

Attention Metric

Another metric which I shipped is visitor attention - i.e. how much time a visitor spends on a specific page or on the blog as a whole during a specific time period.

The attention metric shows the average time spent on a specific blog post or on a specific blog as a whole as well as the accumulative time spent on the blog.

It also shows a breakdown of the average time spent on each blog post as well.

As I wrote down this paragraph, I realized I could also include estimated reading time vs average reading time on that metric block - the pros of blogging down my thought! 😅

Campaign Metrics

If you run ads or any other type of promotional campaigns, you may have come across UTM tags.

UTM tags, short for Urchin Tracking Module tags, are simple code snippets added to the end of a URL to help marketers track the performance of online campaigns across traffic sources and publishing media. They work by capturing specific data about the link a visitor clicked to arrive at a site.

Here are the common UTM parameters:

1. utm_source : Identifies the source of the traffic, such as a search engine, newsletter, or other referral.

2. utm_medium : Describes the medium used to share the link, such as email, social media, or cost-per-click.

3. utm_campaign : Specifies the individual campaign name, slogan, promo code, etc., that the link is part of.

Stomod Web Analytics now captures metrics around UTM campaigns and displays those stats from within your dashboard so that you can have an idea of how your different campaigns are performing. This is how it looks like:

Deeper Analytics Integration

As part of a more tightly integrated analytics experience for Stomod users, I decided to integrate the analytics more closely to the content users publish - i.e. posts, pages, author pages, tags pages.

It was a fun exercise to do this - Stomod already has listing for posts/pages/authors/tags and it was a matter of adding another column with a spark line chart to display the trend of visitors over time.

This is how it looks like on the post listing page:

While at it, I also took the opportunity to migrate the table which displays the posts to use server-side pagination which I previously figured out how to implement using TanStack Tables when implementing the analytics page.

The final piece of the integrated analytics was to enable detailed analytics view for each blog post when clicking on the spark line chart. This was a simple matter of filtering the main analytics view to only display the post’s metrics. This is how this looks like, as a nice side sheet:

Remembering Analytics Interval

A piece of UX improvement in the analytics which I also shipped was for it to remember across sessions which timespan you were previously looking at. By default the analytics view shows the stats for the last 7 days.

With the update, I made use of LocalStorage to locally store the interval each time the user changes it and then display that same interval on subsequent visits.

This is something super helpful as I found myself constantly switching between intervals on each visit.

Improving Stomod’s CI/CD Pipeline

Stomod’s initial deployment pipeline looked like so in the interest of simplicity:

1. Commit changes

2. Push to main

3. SSH into VPS

4. Pull changes from main

5. Run deploy.sh which did the following

   1. Build Next.js app
   2. Reload PM2

When Stomod was small in size and still not in a TurboRepo monorepo, this setup worked fine for me as I felt no need to automate or complicate things. This setup meant zero-downtime deploys and was working superbly.

However as I moved to TurboRepo and the app grew in complexity, the Next.js build started consuming more and more resources to build.

It reached a point where it would simply hang my VPS, rendering it unusable during the time it took to build Stomod.

At that point in time, accessing Stomod’s dashboard became very slow but blogs remained fast as those are CDN-cached. There have been some instance where I needed to even reboot my VPS because CPU usage spiked so much that it simply rendered everything non-responsive.

Moving Build to Github Actions

I spent some time during the week to move my build process off my VPS to Github Actions. Now the new process looks like so, which is way way more streamlined:

1. Commit changes

2. Push to main

3. Github Actions runs

   1. It SSHes into my VPS and pulls my .env file into the build process
   2. It builds Stomod
   3. It SSHes back into the VPS and copies over the .next folder
   4. It pulls the latest changes from the Stomod Github repo and re-installs Node.js dependencies
   5. Reloads Stomod via PM2

4. Done!

This new process is way more streamlined, I only need to push my changes to Github and it will build and deploy it to my VPS and it builds faster and does not bog down my VPS - big win all around!

That’s it from me - another week of marketing now awaits and I intend to make it count 💪