Gmail Meter now supports send-as aliases

It has been some time since our last blog post – our apologies for the delay, but we wanted to take the time now to share some great news!

First though, I wanted to start off with a bit of a history lesson on Gmail Meter. The legacy Gmail Meter was originally built off of the Google Apps Script platform (our personal thoughts on it here). The Apps Script platform was intended as a scripting language, maintained by Google, that allowed for easy automation and integration between Google Apps. Google also supported their Script Gallery which served as an internal marketplace where users could find different Apps Scripts. Gmail Meter was one such script that was built to integrate with a Google Sheet for a variety of features, including support for send-as aliases.

Send-as aliases are alternative email addresses associated with a primary Google Apps or Gmail account. They can either be domain-level aliases or user-level aliases, and are controlled accordingly. User aliases can be found and managed by accessing the Accounts and Import tab within your Gmail Settings. Within this tab, there a section labeled Send mail as: which provides a comprehensive list of aliases associated with the account. Please note that while you are free to remove any user aliases, domain aliases do not have that option and can only be managed by Google Apps administrators.

In the original iteration of Gmail Meter, the end user was able to edit the associated Google Sheet file to set a series of custom parameters. One of these parameters was a list of send-as aliases to be accounted for in analysis. Once Google deprecated their Script Gallery, the legacy Gmail Meter was no longer able to easily extract data from a Google Sheet and lost support for both send-as aliases and custom date ranges. From that point onwards, our legacy Gmail Meter excluded any email received by an alias from analysis. And any emails sent by an alias were actually counted as emails received to the primary account.

We recently had a soft launch of our new Gmail Meter back in June. We’ve been quite quiet because this new version, while a definite improvement, is still very much an early release. We did so with the previous failure of our legacy report in mind. We knew we had to put out an early product, and that many aspects still needed to be polished.

In addition to spending the last couple of months focusing on optimizing and stabilizing our new platform, we’re happy to announce that we did also implement support for send-as aliases. While this is admittedly a long-overdue improvement, we are excited because this represents our first significant step in bringing you a better Gmail Meter.

As always, thanks for the read and please don’t hesitate to reach out via email or Twitter.

RE: The New Gmail Meter

We recently added a new notification to our signup flow. In fact, many of you reading may have even been directed here straight from that very page. If so, then you know that we are keenly aware of the current state of our Gmail Meter report.

With some embarrassment, and a fair share of humility, we admit that our Gmail Meter script currently just does not work as intended. (If you’re curious of the reasons, we’ve previously written about our ongoing Apps Script problems.) Essentially, Gmail Meter has outgrown its existing Apps Script platform and will continue to fail as long as it remains on this platform.

Two months ago, back at the end of February, we announced that we had begun the substantial undertaking of building an entirely new Gmail Meter from the ground up. As typical with software development, we grossly underestimated just how much time this task would take. And for full disclosure, besides Gmail Meter, we here at ShuttleCloud have several projects with a couple large enterprises that take up much of our time.

I know that software development can sometimes seem like a bit of a black box, but this does not mean that the process can’t be readily understandable. With that said, we would like to update everyone on what we’ve been doing.

Lessons learned in software development

First though, let’s recap and take a retrospective on some of the lessons we’ve learned in 2016. Starting in December, we began receiving an increasing number of emails reporting a series of error messages. While looking into the cause of these messages, we vastly improved our internal error reporting system. Doing so made us realize that the error messages themselves were being sent by Google, and that we had absolutely no control over the content or the sending of these messages.

Furthermore, our improved reporting revealed that there were way more scripts failing than errors reported. There was no way at the time to explain what exactly was going on, so we just went ahead and added even more reporting. This time from a broader level, on how scripts were running and/or failing.

Upon analyzing this new data, we discovered that the legacy script was programmed to run every instance of Gmail Meter worldwide within the same 30 minute interval, every day. We immediately thought that this was the problem and implemented an algorithm that schedules all script instances to run evenly spread throughout the day.

That’s what we had originally thought, but the actual result? We ended up experiencing a drastic and dramatic increase in the number of error messages and number of scripts failing.

Sometimes pivoting means a fresh start

At our wit’s end, it was sometime around then that we started the conversation with Google representatives. These conversations only solidified our growing suspicion that in order to make any improvements to Gmail Meter at all, we actually had to rebuild the tool from the ground up. While this endeavor can be considered costly and risky, it can also be viewed as a bit of a blessing in disguise by allowing us the chance to fix a few of the problems with the legacy script that we never got right.

Chief among our concerns is – no surprises – the issue of scaling. The legacy Gmail Meter script has continued to fail at a very regular rate since the start of this year. Unfortunately, no amount of optimization will prevent this from occurring and would only result in more errors and/or script failures. With the new platform no longer on the Google Apps Script infrastructure, we will actually have control over how data is managed in the backend. This means that not only is the new report much more stable and error resilient, it is already much faster than the legacy script.

Additionally, we opted to remove several process heavy metrics, specifically the word cloud and subject line analysis sections of the legacy report. We made this decision after reviewing feedback you have provided us, ultimately realizing that these metrics were both costly and needed serious revision before they could bring actual value to our end users. For example, the word cloud for the legacy script did not exclude words from signatures and would thus consistently provide biased data.

This decision was also made in part because we are understanding of the sensitive nature of the data we have access to. We are committed to giving our users valuable data and insights while reducing the amount of identifying data that we need to process. If we have to prioritize other features first and are not able to do the analysis well, we would rather not do that analysis for the time being. Privacy and security is one of our main priorities for this new Gmail Meter.

New Gmail Meter design to look forward to

So what are some of the new features that we are prioritizing instead? Well, besides the focus on resilience and security, another one of our priorities is data accuracy. This refers to both validating the accuracy of the data and ensuring that the data is presented in an easily understandable manner. We’ve broken down just about every metric found in the legacy Gmail Meter and for the ones we’re keeping, we’ve also reevaluated how to display these metrics.

To give a bit more background on the legacy Gmail Meter script, Google Charts was used to generate all graphs within the report. While Google Apps Script is not directly compatible with Google Charts, Google maintained an App Script library that allows a script to create charts. The stipulation is that most of the Charts features available to Apps Script are within the UI service, which was deprecated in December 2014.

While the charts in the legacy Gmail Meter worked well enough, a major overhaul was bound to happen. We felt right now was the best time to fit in a redesign (and facelift) of both the email report and the web interface. Now that we’ll be using the full functionality of Google Charts, we’re considering other kinds of graphs – ones that can better represent the data accurately and understandably.

A redesign isn’t the only thing that we’ve been working on. There have been a few core features that have been coming up regularly in conversation with our users and with this new platform for Gmail Meter, we will be able to address some these long standing requests.

More information will be available next week, stay tuned for upcoming updates or tweet at us. (And do please forgive me for the recent lack of updates, promise it won’t happen again.)

Why we’re Moving off Apps Script

If you’re a current user of Gmail Meter, you are might know that this month we got a bit more practice apologizing than we anticipated.

And if you’ve contacted us about the error messages, you’ll know that these messages that a good portion of you have received are almost completely out of our control. That may not seem like the best response to these inquiries, so I wanted to take some extra time to explain what exactly is going on here.

Google Apps Script and Gmail Meter

The current version of Gmail Meter is built off of the Apps Script platform, which is a scripting language maintained by Google designed to let a user to integrate different Google Apps services together. Basically, it lets the various Google services talk to each other much better, which is obviously helpful for the end user.

With Gmail Meter, a user’s Gmail usage data is collected and compiled within that user’s Drive storage, making Google Apps Script the ideal language to build the initial version of our tool. Beyond being hosted within Google’s App Script architecture, which requires very little in terms of setup from our end, another added benefit is the simplicity of moving a user’s data from one Google service to another.

This platform has served us well for a number of years, but we have realized a few limitations in the last couple of months. Instead of going into detail about every minor limitation, I want to focus only on the major problem, which is that Apps Script is hosted on proprietary Google Apps Script machines as opposed to the standard Google Compute Engine machines.

While this simplifies many maintenance and backend operational needs, this also sacrifices a lot of fine grain control. Without that control, we are unable to provide you with the best user experience possible.

So what does this have to do with the error messages?

Over the course of the last few of months, we noticed a significant increase in the number of users who reported receiving some kind of timeout error. Typically, the email would include a message along the lines of “Exceeded maximum execution,” which in layman’s terms means that the Gmail Meter script took so long to run that the server killed the script.

Unsure of the reason for the sudden jump in these error messages, we spent some time investigating what could be causing our script to timeout.

After review, we realized that there was a major flaw in how we had programmed the script to be run. The Gmail Meter script is programmed to turn on once a day for each user, but due to an oversight, every user’s script was set to run within the same 30 minute period every day. Obviously with thousands – tens of thousands, actually – of scripts running simultaneously, some timeout errors are to be expected.

The decision to optimize was made quickly. We created an algorithm that spaces out the running of the script for our users throughout a 24 hour period. Instead of having a maximum of fifteen thousand scripts running at the same time, all users were spaced out evenly throughout the day, with only a maximum 200 or so scripts running simultaneously within the same minute.

After implementing this load balance, of course we saw way more support tickets reporting this error message than ever before because this is how software development works.

Having no clue what we did wrong and after spending another countless number of hours investigating, we finally came across this known Google Apps Script issue. It’s difficult to explain the strange combination of emotions we felt when we first saw this. There’s the relief knowing that we hadn’t done anything wrong coupled with the helplessness knowing that there’s a systemic issue within the platform that we’ve built our product out of.

We’re not the only company that has experienced this issue, nor is Gmail Meter the only application that is currently affected. We’ve reported our experiences within that open ticket, and have also exchanged emails directly with Google employees about the specifics of the issue.

Unfortunately, even though there have been many reports of the same error, the only definitive answer we’ve received from Google is that they are still unable to replicate this issue.

Looking forward to a new Gmail Meter

With that said, we did ultimately implement a workaround to prevent these error messages from being triggered. Unfortunately, the only way to do so was to slow down the script and severely limit how fast it processes through emails. To be clear, we’re talking about reducing the speed by a factor of a quarter of what it was a couple months ago.

It should be no surprise to anyone then that we have since made the decision to move Gmail Meter off of its current Apps Script platform. While this unfortunately means that we will provide less technical support for this legacy version of our tool, this does mean that we will be bringing you a much better version of our Gmail analytics tool much quicker than previously planned.

As always, please feel free to subscribe below or follow us on Twitter to stay up to date on our development progress. And please don’t be shy about emailing us with questions or concerns using our address.

Thanks for reading and I look forward to the next update!