DEV Community: Uku Täht

Google Analytics & Privacy: Why it matters

Uku Täht — Tue, 08 Oct 2019 00:00:00 +0000

If you’re running a website with Google Analytics installed, you may be wondering how it affects the privacy of your website’s visitors. There’s a growing distrust towards the digital advertising sector but what are the actual issues besides calling out ‘creepy’ ads?Let’s discuss the wider ethical questions around personal data collection and digital targeting.

Why is Google in the analytics business?

The biggest problem with online tracking is not that it’s ‘creepy’. The problem is moving the whole advertising model from mass-broadcasting to individual targeting.

Let’s be honest, the executives at Google don’t care what websites I visit. They care about making more money from advertising so their quarterly report looks good. Google has found that tracking and targeting individuals (or ‘serving relevant ads’ in corporate speak)results in more clicks which results in more revenue. As their ultimate goal is to increase shareholder value, it follows that they need to track as much data about web visitors as possible to be able to serve the most ‘relevant ads’.

Targeted advertising creates a massive global demand for personal information that can be used for such targeting.This means collecting your browsing history, measuring your engagement with content, tracking yourlocation at all times, inferring demographic information about you, etc.

This is why Google Analytics exists. It’s also why Chrome, Gmail, Google Maps, and pretty much every other free product by Google exists. The goal is to embed their free services in the basic infrastructure of the web. This infrastructure can be used to collect as much personal data as possible to drive advertising profits.

Targeted advertisement is unethical

Google’s track record of handling personal data has beenabsolutely dismal. Facebook is even worse. Their online trackers are incredibly intrusive, making us feel like we’re under corporate surveillance at all times. Although we can use their useful software for free, we end up paying with our personal privacy. This is well documented.

Besides the costs to our personal privacy, I’d say the much bigger scandal lies in how targeted advertising affects civil society. Political campaigns are now able to discern with amazing accuracy which voters to target with their advertising. Instead of debating issues in the public and broadcasting ads to everybody, campaigns can target voters on an individual basis. This contributes to filter bubbles, disinformation, radicalization, and a general breakdown of democracy.

This is what the Cambridge Analytica scandal was about. The company was built to use online tracking and targeting to win political campaigns for the highest bidder. They’ve been incredibly successful:

It’s all about understanding the motivations of the target audience and trying to understand at a very granular level why people might undertake a certain behavior, whether that’s joining a terrorist organization or smoking cigarettes or eating fast food.

[on Cambridge Analytica’s services for the Trump campaign] We did all the research, all the data, all the analytics, all the targeting, we ran all the digital campaign, the television campaign and our data informed all the strategy.

It has to happen without anyone thinking it’s propaganda, because the moment you think ‘that’s propaganda’ the next question is: ‘Who’s put that out?’

Alexander Nix, Former CEO of Cambridge Analytica

Regardless of whether you support Trump or not, it’s hard to deny that propaganda is on the rise.Trump’s marketing team, was spending $70 million a month during it’s peak in October 2016.The details are not known, but it’s fair to assume that most of it was spent on digital advertising.

We are thrilled that our revolutionary approach to data-driven communication has played such an integral part in President-elect Trump’s extraordinary win

Alexander Nix, Former CEO of Cambridge Analytica

If you have 10 minutes, I’d recommend watching Alexander Nix himself explain how they use personal targeting to push propaganda and undermine democracy. If you have 2 hours, I’d recommend watching The Great Hack. Orwellian stuff.

What does Google Analytics have to do with this?

Individual targeting is only as effective as the data collected on individuals.With GA used on more than 60% of all websites, Google can track your journey through most websites you visit. Based on this browsing history and many other variables, they can build a profile on who you are and what your interests are.This helps political and corporate campaigns to target you more effectively.

Some say data is the new oil, but what if it's the new CO2?

As developers, marketers, technologists, we shouldn’t be complicit in this. Yes, most of us block ourselves from being tracked individually, but what about the websites we run?

If we keep using Google Analytics on them, we’re effectively handing over our visitors’ browsing habits to Google for free. Same goes for any other third-party scripts and pixels that advertising companies want you to include on your website.

How to control your analytics data

First of all, don’t include any scripts or pixels by advertising companies like Google and Facebook.That’s the starting point.

If you care about measuring traffic to your website, use an open-source analytics tool that you trust.Open-source projects are subject to public scrutiny, and they embody a more ethical culture oriented towards the public good rather than private profits.

It’s also important to consider data ownership. The Google and Facebook model says that the analytics data from your website is to be monetized through advertisering. After all, they must get something in return for offering a free service. If you want to truly own your data, you have to be ready to pay for your analytics.

You can either install a self-hosted analytics platform, or choose a cloud-based service whose business model is to charge directly for their service instead of making money from advertisers. I like convenience so I leantowards cloud services as long as they are open source and promise 100% data ownership.

There are many projects in this space catering for different needs. Last year I started building an analytics tool for my own needs, which are simplicity and performance.I think most analytics platforms are over-complicated to the point of being more confusing than helpful.Meanwhile, websites are getting more bloated due to heavy front-end scripts that degrade the user experience.

Plausible is a stripped-down, lightweight version of what big analytics suites offer. My aim is to build a tool that tracks overall trends in traffic, not personal data on individual visitors. If Plausible is too simplistic for your needs, I’d recommend checking out this listof alternatives to Google Analytics.

Plausible is going open-source

Uku Täht — Mon, 02 Sep 2019 00:00:00 +0000

One of the main reasons I started Plausible was to provide a more transparent alternative to Google Analytics. I believe that people should be able to control and know about their data, instead of having it sold to advertisers behind their back.

Today I’m happy to announce that Plausible is open source with the code being available on Github.This repository includes all of the code powering plausible.io with nothing hidden.

Making the source open to the public is a crucial step to building a more transparent analytics platform. It proves that Plausible does not store any personal information or IP addresses, and that it doesn’t track people across multiple websites like Google Analytics does.

How open?

There’s a lot of debate around what constitutes open-source vs free vs source-available software. My aim with Plausible is for the code to be as open as possible but I still want to charge for it and build a business around it. One option to achieve this is to license your product under the Apache 2.0 license with a Commons Clause. The Commons Clause just stops people from selling the software as-is to compete with the author.

This seems like a really obvious restriction if you’re trying to build a sustainable business. On the other hand if you look at companies like Ghost, they have open-sourced their product completely under the MIT license with no restrictions whatsoever. I suppose the argument is that they own the brand and the distribution network, so it would be futile to compete with them selling the same product.

I chose to follow the example of Ghost here. Plausible is open-sourced under the most permissible MIT license, which basically states that you can do whatever you want with the code. I’m not really worried about the possibility of someone stealing business from me by just getting the code and selling it.

It’s worth noting that for now, there’s no explicit support for self-hosting Plausible. The project is still evolving quickly and maintaining a self-hosted solution would slow product development down considerably. I would love to offer a self-hosted solution in the future once the product and the business are more stable.

What’s next?

Please check out the public roadmap and feedback board to see which features are planned in the near future.

I think it’s also worth talking about ways to raise the standard of trust and transparency even more. No matter how open we are or how much effort we put into making the data anonymous,there are still no guarantees that analytics companies don’t turn around and sell their data to advertisers.

To fix that, I would like for Plausible users to completely own their data in a way that makes it illegal for the company to use it for any purposes other than providing the analytics service. Our role would essentially be renting the processors and disk to you to run open-source software and to safely store datat hat you own.

Do you know of any examples of this? What’s the best way to enforce it? Would adding it to terms of service be enough? If you have knowledge or opinions on this topic, please reach out to me on Twitter

Plain emails are a win-win

Uku Täht — Sat, 10 Aug 2019 00:00:00 +0000

If you’ve ever had to develop transactional HTML emails with slick designs, you’llknow that it’s a complete mess. The incompatibilities between email clients are way worsethan what you see with different browsers. Testing emails is extremely difficult, andthere’s a seemingly endless number of problems with various clients.

Luckily there’s a really simple solution to this problem: just send plaintransactional emails instead with minimal/no design. Email clients were never designedfor complex layouts and graphics. Instead of abusing the format for something its notintended for, let’s respect it and use it to our advantage instead.

Before we go on, of course there are cases where it makes sense to design complex HTML emails forbetter readability. For example, I’m planning to add a regular email reportto Plausible in the future. Such a report needs to fit a lot ofdata in a scannable format, so I will probably lean towards a designed email template.

However, most transactional emails don’t require design. Here’s the emailyou receive when you reset your password on Plausible:

No fuss, straight to the point without any distracting elements. It’s hard to see howadding colours, logos and buttons to the email would improve it.

More than just time savings

Avoiding the complexity of HTML templates can save a lot of time in design and development.An even greater win is that plain emails also havebetter deliverability and response rates.

HMTL elements and images have a negative effect on deliverability because they tend to trigger spamfilters. Over-designed emails can definitely feel spammy to the reader as well, not just the AI.I’m guessing it’s due to the ridiculous amount of unsolicited marketing emailsthat we all receive on a daily basis. They are almost exclusively complex HTML templates withloads of images.

Plain emails get more responses because they feel much more personal than HTML emails. Peopleassociate designed emails with marketing and one-way mass communication. On the other hand, plainemails look like the emails you get from a coworker or a friend. It feels more natural to hit‘reply’ on them.

This is why plain emails are a win-win: not only do they simplify the development process but theyalso reach more people. My takeaway is that we should only get into complex HTML templates if they are completelynecessary to enhance the user experience. We should accept that using them sacrifices deliverability,open rates, and development time. The upside of using email designs must be huge to outweightoutweigh the negative consequences of using them.

Building Plausible: June 2019 recap

Uku Täht — Wed, 03 Jul 2019 00:00:00 +0000

I spent the second half of June back home in Estonia to recharge my batteries and reconnect with family+friends. Summer solstice is a huge celebration in Estonian culture so everyone seems to be on holiday at the moment, enjoying nature, good food and drinks. I haven’t had as much time for Plausible as I normally do, but I’m totally OK with that.

Still, some cool things happened with Plausible this month:

🚀 Shipped public stats pages: You can now show off all the hard-earned traffic to your site
🚀 Added support for ?ref= query param: Link tagging is a common practice to get accurate referrer information. This feature allows you to manually control the referrer.
💵 MRR growth: 43.5%: Monthly revenue is at $67.91, up from $47.34 in May.
👩 1347 unique visitors: Up from 1178 visitors in May. A lot of this traffic is organic from Google, Twitter, and the (now abandoned) journal.plausible.io blog. I also do my best to participate in communities like IndieHackers which drives a lot of traffic.

I’ve also been working on docs.plausible.io to make sure the product and features are crystal clear to everyone. I believe that good documentation is a competitive advantage, and I plan to spend more time improving the docs.

Looking forward

My main project in July is taking part in the IndieHackers 30 days of growth challenge. This will be a good test of my persistence and growth skills. The goal I’ve set for July is to get 40 new trial signups.

In terms of feature work, you can check the public roadmap at feedback.plausible.io/roadmap. The features not necessarily in the order I’m going to tackle them because I’m always trying to prioritise the easiest and biggest wins first.

Hope everyone has an amazing July. Stay tuned for the next update!

Replacing Google products with more ethical alternatives

Uku Täht — Tue, 07 May 2019 00:00:00 +0000

It has become clear how much data is collected on regular people around the world by large corporations and governments. The biggest offenders in this space are government agencies like the NSA and GCHQ, along with large internet companies like Facebook and Google.

I’m not a big Facebook user, but I’ve used Google products daily for more than a decade. Their products are reliable, intuitive, and free to use.

Instead of collecting cash, Google collects data about your identity, behaviour, habits, and preferences. This data is aggregated and analysed on a global scale, sold to advertisers and shared it with intelligence services. The more data Google accumulates, the more powerful they become.

A few years ago I started removing Google products from my life because I don’t want to feed this corporate surveillance machine. There are many great alternatives out there by smaller players. The alternatives are more likely to be paid, but we need to start paying for software if we don’t want to pay with our privacy.

Here’s a list of great replacements that I’ve found in my own use so far:

Google Chrome -> Mozilla Firefox

In my mind, Firefox is the best alternative to Chrome. I love supporting open-source software and Mozilla is doing a great job with both Firefox and Rust.

Google Search -> DuckDuckGo

I started using DuckDuckGo as my default search engine last year. I like their activism for online privacy and the movement they’ve created. The search results are a bit slower and not quite as relevant as Google’s, but it’s a price I’m willing to pay for privacy.

Google Hangouts -> Slack calls

I’ve been forced to use Hangouts in the past, but I’ve always preferred Slack calls and appear.in. I’m eagerly waiting for Tuple to launch so I can get my hands on it as well. It’s a video calling tool built specifically for pair programming. Seems awesome :)

Google Docs -> Notion

I like Notion as a replacement for Google Docs. Notion is markdown-based and seems to fit my brain a lot better than Google Docs. It has way better navigation so it makes a good internal knowledge base where people can actually find stuff.

Google Analytics -> Plausible

When I looked for alternatives for Google Analytics, I didn’t find any that I really liked. Being interested in web analytics, I decided to build my own solution, Plausible. It provides simple, privacy-focused analytics without collecting website visitors’ personal data. I’ve switched all my current projects over from Google Analytics to Plausible.

Google Maps -> Citymapper

I haven’t replaced my Google Maps usage completely yet. For public transport routes, I do use an alternative called Citymapper. However, it’s only available in some cities and it doesn’t replace business discovery. Whenever I’m looking for a restaurant in a new city, I still look for ‘restaurants’ on Google Maps. What’s a good alternative for that?

What I couldn’t replace

The two services I haven’t managed to replace yet are Gmail and Youtube.

I’m sure there are amazing email clients out there that outperform Gmail in every way, so please do shoot recommendations my way.

As for Youtube, I spend a lot of time there watching tutorials, recipes, news, etc. It’s a fantastic knowledge sharing tool that will be very hard to replace. Vimeo has the technology, but they definitely don’t have the community and the content.

Results

I’ve slowly been replacing my tools and habits over the last couple of years. Overall, I feel like this process has been a great success. I’m much less reliant on Google in my everyday life and feel much more in control of my data. I still have some distance to go with Gmail and Google Maps, but I will continue to look for replacements so I can be completely Google-free.

Looking for alternatives has led me to find amazing indie makers and teams building awesome software. Smaller companies tend to be a lot more fun and innovative, so using their products is often a better experience. I hope you check out some of these alternatives and make the switch as well.

I’m launching Plausible

Uku Täht — Mon, 29 Apr 2019 00:00:00 +0000

It’s been 4 months since I wrote about the analytics tool I want. My idea was to create an alternative for Google Analytics that simplifies the UI and enhances the privacy of online tracking.

After writing that initial post, I spent 2 months creating a prototype and launched the public beta for Plausible in February.

By now, more than 60 people have signed up used Plausible successfully. I’ve received encouraging feedback and many feature requests over the last two months. I appreciate everyone’s feedback as it has helped me form the roadmap for the next few months of development.

I could easily hide in my cave for more months to tackle that roadmap. But to see if Plausible has real potential, I have to introduce it to the marketplace and see if people are actually willing to pay for it.

Pricing

Coming up with the price tag for Plausible was a surprisingly difficult process. I started by asking myself: _Should Plausible have a freemium model?_After doing some research, I decided that the support and maintenance costs of running a free tier would be far too high for one person to handle. As a solo founder, I need to keep overhead low so I can keep up with both support and product development.

I’m not going to rule out a free tier or even a self-hosted version of Plausible in the future. However, I want to protect my time for now and get the product working well in the market before scaling up.

As a customer I appreciate products with very simple pricing schemes, so I wanted to keep it as straightforward as possible. There will be no premium features, accounts will be billed purely for the amount of traffic they get.

up to 10k pageviews - $6 / mo
up to 100k pageviews - $12 / mo
up to 1m pageviews - $36 / mo

It was important for me to include a small (<10k) tier to suit personal websites and blogs that don’t get much traffic. I will definitely be experimenting with these plans going forward to see what works best.

Existing beta users also get a third off on all of these plans. This is my way of thanking the beta community for providing feedback and engaging with the product from an early stage.

Going forward

Plausible is still under heavy development. With the introduction of paid plans, I will be investing more into customer support and documentation as well.

The goal for the next month or so is to get payments, invoicing, and VAT handling all working smoothly. Once I have all the tools set up to run the business, I can shift focus back to product improvements.

I’m really excited about making Plausible the best web analytics tool out there. There’s a long way to go on this mission but today marks a big milestone on this journey. Check back on this blog for updates on the product and the business.

You probably don’t need a single-page application

Uku Täht — Sun, 17 Feb 2019 00:00:00 +0000

The meteoric rise of front-end frameworks like React, Angular, Vue.js, Elm, etc. has made single-page applications ubiquitous on the web. For many developers, these have become part of their ‘default’ toolset. When they start a new project, they grab the tools they know already: a REST API on the backend, and a React/Angular/Vue/Elm frontend.

Is there something wrong with these tools? Absolutely not. In fact, I love working with them. However, I would only choose this architecture when an actual requirement is pushing me in that direction. If there are no specific reasons to build a single-page application, I will go with a traditional server-rendered architecture every day of the week. It is simpler and allows you to move faster:

1. Stateless requests

Traditional web servers are built to be stateless. This means that each endpoint can be reasoned about and tested in isolation. SPAs, by contrast, have to explicitly define how all state is loaded, refreshed, and discarded by the frontend during the whole session. This introduces new caching/synchronization problems that just don’t exist in the server-rendered world.

2. The browser knows how to deal with a traditional architecture

If you go with the SPA route, you’ll always need extra code to emulate trivial browser features. I’ve spent many hours making sure that browser history is managed just right, that the loading animation looks smooth, restoring the scroll position when the user navigates through history, etc. It’s a mess.

3. Fewer, more mature tools

Frameworks like Rails, Phoenix, Lavarel, etc. have been around for a while and they are very stable. I learned Rails about 5 years ago and my knowledge is still completely relevant. Around the same time, I also learned Gulp, CoffeeScript, BackboneJS, and SASS, all of which have been superseded by newer tools. Avoid the Javascript fatigue by not relying so much on Javascript!

4. SEO for free

Single-page apps have to add extra infrastructure and code to make sure they can be indexed by crawlers. If you need SEO on your dynamic pages, it’s much easier to accomplish with a server-rendered architecture.

All of this means that single-page applications impose more complexity and cognitive load on the developers. In my experience as a developer, complexity and cognitive load are the single biggest factors in software bugs and development slowdown.

When to go for the single page app

As I said, the default choice in most cases should be the traditional server-rendered application. However, there are some requirements that might force you to opt for the single-page application architecture:

Core functionality is real-time (e.g Slack)
Rich UI interactions are core to the product (e.g Trello)
Lots of state shared between screens (e.g. Spotify)

These products absolutely have to use a single-page architecture to work properly. This is why it’s the right choice for these companies. However, many web-based products do not have these requirements and this complexity can be avoided.

Hybrid solutions

Even if your app needs some real-time capabilities or rich interactions, you don’t need to use the SPA paradigm for your whole app. A great approach is to embed small frontend applications into a traditional architecture.

Github uses this hybrid approach. The backbone of their website is a traditional rails app but some areas, like the projects tab, are built as embedded frontend applications. It’s a beautiful solution that combines the best of both worlds. The great thing is that you can start simple and gradually add more complex UI interactions with this approach.

I believe that my current project, Plausible, will evolve in this direction. The main UI of the app will need rich interactions in the future, but the rest of the app can stay with the server-rendered architecture.

It all comes down to tradeoffs

As with everything in programming, there isn’t a single answer in the SPA vs traditional architecture dilemma. There are cases where it makes sense to go with a SPA because you need a snappy, real-time UI. However, we should recognize that this comes at a cost to the development speed. And if a single-page app is not a requirement, we can avoid the additional complexity and move much quicker by going the traditional route.

Picking the right architecture for the job makes a huge difference in productivity, and ultimately, success. We should aim to have both architectures in our toolbox, so we can use the optimal solution in each case.

How to store ‘last seen’ for users in Phoenix

Uku Täht — Wed, 06 Feb 2019 00:00:00 +0000

This week, I worked on some under-the-hood improvements to Plausible to give me better insights into my userbase. One of these was to store a last_seen timestamp for all users. This is a private piece of data that I use to determine:

How many users are actively logging on and checking their analytics
What is the average usage frequency of Plausible?
When should I consider an account as ‘rotting’? Meaning I’m about to lose them as a user/customer

Let’s see how this can be achieved in Phoenix. First, we’ll start with the schema.

Schema

We’ll need to generate a migration for the last_seen column:

$ mix ecto.gen.migration add_last_seen_to_users

and the migration itself:

defmodule Plausible.Repo.Migrations.AddLastSeenToUsers do
  use Ecto.Migration

  def change do
    alter table(:users) do
      add :last_seen, :naive_datetime, default: fragment("now()")
    end
  end
end

At this point, you’ll want to add the field to your User Ecto schema as well.

Plug

Now I want to update this field every time use uses the website. A natural solution here is to add a Plug that intercepts every request. However, updating the database on every request seems fairly wasteful. Besides, for my purposes, the timestamp doesn’t need to be accurate to the millisecond. This is a perfect case for throttling, which can be achieved by using the browser session.

defmodule PlausibleWeb.LastSeenPlug do
  import Plug.Conn
  use Plausible.Repo

  @one_hour 60 * 60

  def init(opts) do
    opts
  end

  def call(conn, _opts) do
    last_seen = get_session(conn, :last_seen)
    user = conn.assigns[:current_user]

    cond do
      user && last_seen && last_seen < (unix_now() - @one_hour) ->
        persist_last_seen(user)
        put_session(conn, :last_seen, unix_now())
      user && !last_seen ->
        put_session(conn, :last_seen, unix_now())
      true ->
        conn
    end
  end

  defp persist_last_seen(user) do
    q = from(u in Plausible.Auth.User, where: u.id == ^user.id)

    Repo.update_all(q, [set: [last_seen: DateTime.utc_now()]])
  end

  defp unix_now do
    DateTime.utc_now() |> DateTime.to_unix
  end
end

I added this plug to my browser pipeline in my router. Note that I have another plug running before this one which looks up the current user and makes conn.assigns[:current_user] available.

This approach satisfies every requirement I had for this feature:

Persist the last_seen with an hour precision
Runs a database update at most once per hour per user
I specifically use Repo.update_all so the updated_at field on users is untouched.

Technology choices

Uku Täht — Tue, 29 Jan 2019 00:00:00 +0000

In general I don’t think that the tech stack matters too much for software projects. Especially if you’re a solo maker, almost all of the risk is on the sales and marketing side as opposed to the tech side. The best approach is normally to just pick some boring tools and start solving your customers’ problems.

However I’m also very passionate about developer tooling and I thoroughly enjoy nerding out about programming languages and different databases. In this post I’ll go over the main technology choices I’ve had to make so far for Plausible.

Elixir + Phoenix

I think most programmers have a default language or ecosystem they like and are used to. For me that would be Elixir. The first time I tried it was when I saw Dave Thomas speak about it in 2013. Since then I started the Elixir Koans project and used Elixir on a number of commercial projects.

It is a fantastic language designed with so much care and attention to the details. Some might think of it as new and exiting language but for me this is a proven technology that one can rely on. After all, the Erlang VM has been around since 1986 and it’s as mature as it gets.

My only concern with picking Elixir is that it’s not a super high performance data processing language. If Plausible is a success it will have to ingest a lot of traffic. I mean a lot. All the traffic also needs to be analysed to pull out useful information like browser version and referrer source. I don’t know how well Elixir will deal with this but we’ll see. I might have to write a proper ingest pipeline at some point in a lower level language but that would be a great problem to have because it means the product is a success!

PostgreSQL

Again, this is pretty much a default choice for me when it comes to persistence. Postgres is very mature, deeply researched and extensively battle-tested. It’s a beautiful open-source project and they’re making it better every year!

I might have to switch to InfluxDB if Plausible really takes off and it has to ingest tons of traffic. Influx is time-scale database built specifically for high write speed and time-based aggregation queries. It’s perfect for an analytics application. On the other hand there’s a Postgres extension called Timescale that does the same thing and seems just as strong. Plus it’s Postgres!

Tailwind CSS

Instead of the classic, boring way of writing css I decided to go with something new here. Tailwind is a pretty unique way of writing HTML+CSS. Check out their website to learn more about their utility-first approach.

It took me a couple of days to reach the Aha moment but once I did, there was no looking back. It definitely feels like I can achieve better looking designs with less time than any other approach I’ve tried. I’m definitely using it again on future projects.

Server-rendered HTML + sprinkling JS

Seems like every new project nowadays is a single-page app by default. I suppose developers are getting so used to tools like React and Angular that they forget how to not use them.

I went with the classic infrastructure: serve HTML on the server, sprinkle javascript on the frontend for interactivity. I even ditched jQuery because with modern web standards it’s pretty easy get away with vanilla Javascript. You can always include a couple of polyfills if the standards are not well supported yet. The only javascript library I have pulled in so far is Chart.js

I’m very happy with this approach, it keeps things simple and the website loads fast. There are just fewer moving parts in a traditional server-rendered app than modern SPAs which makes them easier to reason about.

External tools

So far I’ve integrated with the following external tools:

Heroku for hosting
Sentry for error tracking
Mailgun for email delivery
Cloudflare for DNS, SSL, and CDN

The only one I’m paying for currently is Heroku, just to make sure the dyno doesn’t go to sleep.

Learning design as a developer

Uku Täht — Wed, 23 Jan 2019 00:00:00 +0000

Working on plausible.io I often find myself doing things I have no clue how to do. I struggle massively with marketing, copywriting, and most of all, UX/UI design. Here are some tips I’ve found helpful when trying to design for the web as an unimaginative developer who hasn’t designed a single thing in his life.

1. Read Don’t make me think

This book basically lays out the common sense foundations for web design. It’s not a new book but it’s a classic for a reason. The principles laid out here are immediately applicable to anything you might be designing for the web. Recommended for any developer who is looking to get into design.

2. Copy designs you like

The secret to creativity is knowing how to hide your sources. Let’s say I need to add a pricing section to my landing page. I could stare at a blank canvas for a whole afternoon, waiting for creativity to hit me, or I can just search ‘pricing page’ on Dribble and instantly see hundreds of pricing pages. This works for almost anything, unless whatever you’re designing is legitimately unique which is very rare.

3. Start without code

Once you have a couple of examples you like, get to the drawing board. I prefer starting either on paper on in Sketch. Some people like to dive into code right away but I find that this approach tends to lock me into the first thing I come up with. Since code is hard to change, I don’t play around with it as much as I would in Sketch or physical paper. On paper you can very quickly come up with 5 different options, show it to someone and start the process of elimination. This is hard to do with code.

4. Lose your ego and get some feedback

I find it really hard to share my design work with others. I feel like my work will be judged and my lack of skill will be exposed. I believe most makers have experienced these feelings and unfortunately, as you might already know, there is no cure for them. I manage these feelings by telling myself that I’m just a beginner and I’m supposed to have no skill. That’s why I’m asking for feedback: to get better. Feedback will expose your flaws but these flaws are there whether they’re pointed out or not.

5. Read Refactoring UI

I’m only halfway through the book and I’ve learned so much! What an amazing resource for developers who want to improve their design skills. This book includes countless of specific tips on UI principles. It will help you start creating design systems and speed you up massively. I would read it after you have already had some practice with design. After all, it’s about refactoring UI not creating a UI from scratch.

Start designing!

My final tip is to just do it. You will probably suck at it to begin with, but so does everyone as a beginner. When a developer says they suck at design they often think that they’re lacking an innate ability or talent to design. That’s like saying you can’t play the piano because you weren’t born with that skill. It’s absurd. Everyone cannot be Mozart but anyone can learn to play easier songs on the piano and have it sound relatively good. That’s where I’m trying to get to with my design skills. I won’t be winning design awards. I won’t be earning a living with design. I just want to be good enough to get by.

The analytics tool I want

Uku Täht — Thu, 20 Dec 2018 00:00:00 +0000

While working on Gigride, our marketing head asked me to integrate Google Analytics for our landing page. My first thought was:

Ugh. Can we just use something other than Google Analytics?

Of course this turned into a half-hour discussion about the merits and problems with Google Analytics. There can be no doubt that GA is a powerful tool that has served countless web developers and marketers over a decade. Still, it manages to make hair stand up on the back of my neck every time I use it. My objections boiled down to the following points:

Complexity : I find GA overwhelming and difficult to learn. The UX could be a lot better, especially for new users.
Privacy : I don’t want Google, or anyone, to track my end users. Have you thought about why GA can be free to use? Because Google is happy to sell their analytics data to advertisers.
Accuracy : You kind of have to learn to ignore some reports on GA because they are widely known to be inaccurate. Two most egregious examples are session length and the direct traffic source
Weight : Google tag manager + Google analytics weigh 73kb in total. That’s more than my app.js on Gigride. Their snippet is jam-packed with features that few people use – better to keep it simple and small.

These problems seem pretty fixable don’t they? When I looked around I was fully ready to pick up another tool and install it on Gigride immediately.

Turns out there are some alternatives for Google Analytics but I didn’t find any of them compelling. Simple Analytics and Fathom are the closest to my ideal but they are a bit too barebones to be useful for my use-case. For example, it’s quite important to me what browsers versions my users are on – if I use a css rule that isn’t supported in IE7, how many users does it affect? Neither Fathom or Simple Analytics provide that answer currently.

This seems like an opportunity to build the tool that I really want. I’m assuming that there are others out there who would also be interested in ditching Google Analytics for a better, more ethical alternative. So what do I have in mind for this new platform?

Track the standard stuff automatically: page views, unique visitors, bounce rate, session lengths, time per page, top referrers, screen sizes, top pages, device type, OS version, browser version, etc.
It should look beautiful and be easy to use. This is hard because my design chops are crap. I’ll just try to keep it super simple for now and maybe involve a designer once product market fit is established.
Never store IP addresses or anything identifiable to an individual. Never sell any data. Side note: can I somehow prove that? Is open-sourcing the only way to verify these claims?
Optimise signal-to-noise ratio. The user should only see data that is accurate, useful and actionable. For example, when showing month-on-month change in unique visitors, it’s really important to know whether this is a statistically significant change or just normal fluctuation. No-one else does this as far as I know.
Javascript snippet that end users download must be lightweight.

Basically it boils down to the Pareto principle: I believe we can get 80% of the benefit on GA with 20% of the complexity and cruft around it.

I’ve been building this tool for about a month now in my free time. I can’t tell you what it’s called because I haven’t settled on a name yet :) A very stripped-down version of this description is close to being usable and I believe I can launch a private beta in January.

If you’re interested in the beta, please write to me on twitter or uku.taht@gmail.com

EDIT: I’ve launched the beta version at https://plausible.io