As soon as we started programming, we found to our surprise that it wasn’t as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs.
- Maurice Wilkes, 1949
From time to time, I like to remind myself that things like debugging that seem endemic to the concept of writing code actually had to be invented at some point. When ‘computer’ went from meaning a person who computes to a machine that performs specified computations, we went from checking for errors in execution to investigating systematic errors. Now, in the age of the webapp, we’re seeing the same evolution with user experience.
Optimization vs. Debugging
We hear a lot about optimization in the marketing community; there are endless tools and tricks for A/B testing ads, landing pages, and follow up emails, and that’s great. We love building and using those tools, but there’s a bit of a risk of putting the cart before the horse.
To go back to the coding metaphor, reworking a page so that it makes fewer database calls and subsequently loads in 100ms instead of 250 is a substantial improvement. A 60% improvement in app performance, however, doesn’t do you much good if it fails 10% of the time and the user has to spend all that saved time reloading the page.
As a young CS student, using print debugging to isolate errors is one of the first practical skills you learn. For those who have never been young CS students, print debugging is just inserting lines of code that output increasingly vulgar tracer messages as each section of code executes, so you can say “Ok, well it was working as expected all the way until riiiiiight here.”
What Does this Look like for Email?
Well that’s something we’ve been trying to address. The first step is actually trying to figure out what a failure state looks like. Emails won’t seg fault or hit infinite loops (not entirely true, we have seen this, it’s not pretty) but sometimes you can find specific drop-off points. The best way is to follow users that have unsubscribed from your service or mailing list.
As you can see from this blatantly oversimplified example, the user above was 100% engaged until their payment failed. Then they opened that email but never took the corrective action. So what happened? In Sendwithus, we have a couple of options for digging deeper into this failure state.
First, you can check the actual series of events leading up to delivery, including their timing.
No red flags here
Everything here checks out: no huge delays or errors. What if we take a look at the data that got passed to fill variables in the template?
If a dynamic email goes out without Data, that could be an obvious issue
The next step from here is to look into the actual email that was sent. The “View Email” option will show you a rendered version of the email as the user received it.
From here you can also forward the email with the original data to yourself or to your support team for further action.
