Why we insourced analytics

In late March, we put out an innocuous changelog entry announcing that our tracking infrastructure was now our own. The body of the entry was fairly non-descript: I wanted to find a quieter time to talk about the how and why, and that time is now.

Buttondown, just like most other platforms, relies on vendors like SendGrid or Postmark to actually handle the SMTP side of sending emails. These vendors also offer link and open tracking that they manage and inject on your behalf. Some platforms use these directly; others roll their own implementation. For a long, long time (five years!) we were the former.

This decision — to rely on Mailgun or whomever for click tracking — made sense at the time, but grew more painful as time passed:

1. We currently send outbound emails through five different vendors, and standardizing the events across all five became increasingly annoying.
2. The performance of tracking events was suboptimal, as we had to rely on webhooks to relay the events to our own servers.
3. The privacy posture of outsourcing this is suboptimal relative to "owning this thing end to end".

Moreover: the benefits of outsourcing this, as valid as they are early on, became increasingly diluted as we scaled: as other parts of our application matured, our ability to handle spiky traffic, detect bots, and so on became less hinterlands-shaped and more like solved problems ready for re-use.

Okay but literally how did you do it

The beautiful part about a lot of this work is that it is, from a programming perspective, fairly simple.

For instance! Here is the entire implementation of our open tracking endpoint:

from django.http import HttpResponse
from django.http.request import HttpRequest
from ipware import get_client_ip

from emails.models.asynchronous_action.model import AsynchronousAction
from emails.models.subscriber.actions import track_open


def view(request: HttpRequest, compressed_id: str) -> HttpResponse:
    ip_address = get_client_ip(request)[0]
    user_agent = request.META.get("HTTP_USER_AGENT")
    compressed_payload = track_open.compress(
        track_open.Payload(
            compressed_id=compressed_id,
            ip_address=ip_address,
            user_agent=str(user_agent),
        )
    )
    AsynchronousAction.enqueue(
        track_open.__name__,
        [compressed_payload],
    )
    return HttpResponse()

"Okay", you say. "That's cheating. That just proxies out to a background job. Show me the background job."

That's the point! The background job was already implemented because we were using 95% of it for the email events from the vendors themselves. All we're doing is cutting out the middleman.

Don't don't roll your own

You always hear people in software development say you should never roll your own X. "Never roll your own auth or crypto or emails." There are very good and rational reasons not to mess with those. But you can’t throw the baby out with the bathwater. As you mature as an engineer or an engineering organization, you’ve got to start asking yourself which rules you're accomplished enough to break. (Or, as I've written on my personal blog: the people telling you not to roll your own thing tend to benefit from your instead asking them to handle it for you.)

The truth is that Jack Donaghey is right: vertical integration unlocks synergies. Here are some basic examples of things we get to do now that we've insourced this stuff:

1. Start populating our database of IPs and user agents of bots to help strengthen our spam detection for subscription traffic.
2. Surface conversion funnels for individual archive pages.
3. Throttle (or accelerate) email sending in real time based on engagement metrics.

And all of this stuff is, in the background, cheaper and safer and more private.

Two cakes

Running a software company tends to be about trade-offs. You can try and move quickly at the cost of stability, performance, or polish. You can raise prices and increase short-term revenue, but at the cost of growth and customer goodwill. You can do a feature freeze and focus solely on performance and bug fixes for a month or two, but then you slow down your enterprise sales.

But! Every so often an option presents itself that allows you to have your cake and eat it too. This was one such option: we got to decrease tech debt, increase performance, improve our security posture, and decrease costs, all at the same time. And the only downside is that "success" looks like nothing changed at all, which gives me the opportunity to blog about it.