Yet another Gmail Meter redesign (with a couple extras!)

GmailMeter-Snapshot

Last June, we moved the legacy Gmail Meter off of the Google Apps Script platform which required a complete rework of our tool. We decided to coincide this with a complete redesign of the interface.

Today, we will be releasing another major update to the Gmail Meter interface. While our plans initially were to simply get the interface more in line with Google’s material design principles, we realized this was also a great opportunity to incorporate a couple of features for which we’ve received feedback over the years.

Access to previous reports

GmailMeter-Snapshot-II

All Gmail Meter reports are stored for your continued access. But up until now we haven’t provided a visual interface for our users to access them. Previously, the only way to access previous reports was for you to retrieve the old email notification that had the link or alternatively, if the email had since been lost, contact our support line.

Now with today’s release, all reports that have been generated for your account will be accessible through the icon found in the top left of the interface.

User controlled generation of failed reports

Previously if a report fails to generate for whatever reason, users would have to contact our support line for assistance. With this new release, the UI will not indicate when a report has been failed (as shown below).

GmailMeter-Snapshot-III

Clicking on the caution icon will allow users to attempt to regenerate the failed report. If additional reauthorization is needed, the tool will prompt you to take the necessary steps.

While this new feature gives an added degree of control to our users, we are still ready to answer and address any issues you may run into. As always, please feel free to reach out to us via hello@gmailmeter.com or through our Twitter at any time!

Thanks for reading, we’re excited to hear your feedback on these new features!

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.

Sneak Peek at our New Gmail Meter

The immediate feedback in the two weeks since we released our new email report is, “Where are the rest of the statistics? What happened to the detailed report, the one with graphs and charts?”

Please rest assured that while we’re not quite ready yet, the new web interface with detailed metrics will be coming very shortly.

Instead of just taking our word for it, we thought everyone might enjoy a preview of what we’ve been working on (in addition to the email report!) This comes with the disclaimer that since we’re still working on it, there is a significant chance that the actual report may look a bit different once we have something ready for release. And that’s why we’ve opted to use the word beta to refer to this initial version of our new Gmail Meter.

Like Gmail Meter?

Leave your contact information below and we'll keep you updated on new features.

I will never give away, trade or sell your email address. You can unsubscribe at any time.

The New Gmail Meter

As promised and without further ado, here’s a preview of the web interface we’re building:

A preview of the Gmail Meter web interface

While many of these charts should appear familiar, we have made quite a few subtle and some not-so-subtle changes to them. The first set of graphs displays the total number of emails received and sent, first by hour and second by the day of the week. Both reflect an accumulation of messages over the course of the month.

Based on user feedback, we found that messages based on hour and weekday were much more valued and therefore decided to prioritize these two charts over a breakdown of email traffic by days of the month.

Internal and External Messages Treemap

New Internal vs. External Messages Chart

One new feature is this breakdown of internal and external messages. This metric is a Google Apps-exclusive as internal and external messages are calculated based on the primary domain name on the Google Apps account. We reformatted the presentation of this data, opting to go with a treemap instead of the pie charts as in the legacy Gmail Meter.

Top Senders and Recipients Replaced by Top Interactions

Top Interactions replaces Top Senders and Recipients

Quite a few of our users have specifically inquired about the Top Senders and Top Recipients charts, and we’re happy to announce that the data makes a return in our new web interface. The major change we made here was to combine the two charts into a single one to minimize the amount of duplicate data.

We’ve also received a lot of feedback about mailing lists and irrelevant email addresses appearing in Top Senders. While this initial release will not have a way to exclude these addresses, we are both researching ways to do so programmatically and designing ways for our end users to manually exclude them.

Details on Received and Sent Messages

Since this is one of the areas of the web interface that we’re still working on, I won’t be able to show you any screenshots at the moment. Still, we plan to provide many more details on the trends in your received and sent messages.

For Received Messages, this includes metrics on:

  • Messages that were addressed directly to you
  • Messages where you were CC’d or BCC’d
  • And your response rate for each

For Sent Messages, this includes metrics on:

  • Email communication you have started
  • Emails you have responded to
  • And your recipient’s response rate for each

Get Early Access

Sign up to our waitlist above or email us at hello@gmailmeter.com, and we’ll send you an invitation to test the new Gmail Meter web interface whenever we have it ready. We’re closing in on the final stretch before we start our beta testing period, so stay tuned to our Twitter and this blog for more updates!

Prioritizing the Gmail Meter web interface

Yesterday, we quietly released our new email report for Gmail Meter.

The new Gmail Meter email report

Pardon our lack of fanfare, but as you can see we decided to simplify the email report a bit. We narrowed it down to the four metrics that our users found most important, specifically sent and received emails, total number of Conversations, and response time. While this does limit the functionality of our email report, it was important for us to deliver an error-resilient product to our users as soon as possible.

As we’ve discussed a couple times in the past, the legacy Google Apps Script version of Gmail Meter will simply continue to fail. Beyond that, many new users attempting to sign up for the legacy version were reporting that they never received their report. For this reason alone, we knew that we had to deploy a working product sooner rather than later.

Shifting focus to a web interface for Gmail Meter

The decision to simplify the email report represents a major shift in our development direction for Gmail Meter. In our previous version of the tool, we focused on delivering an extensive email report to our users every month. For several reasons, we realized that we would ultimately be able to bring our users – yourself included – much more value by developing a robust web interface for Gmail Meter. With this decision, we have much more time and are able to dedicate ourselves to this new interface.

There are numerous reasons why we decided to proceed down this path. Through user feedback, we found that a number of our metrics were not providing the right insights. A few of these metrics will be removed outright and others we realized were just better suited for a web application.

While (or maybe because) we are big proponents of email, we understand just how limited email can be. Having only an email report means that a user is unable change any settings or customize the report at all.

This leads us to the primary reason for our development shift: emails are meant to be static. There are really no ways to interact or engage with an email-only analytics report, besides receiving it. This means that at the end of the day, without the ability for our end users to engage with and finesse their statistics, they were not receiving actionable metrics that allowed them to make improvements in their habits.

Features for the upcoming web interface

There are a number of possibilities that are open to us now that we are focusing on building the new Gmail Meter web interface. For example, one of the most common pieces of feedback we get is that the legacy script did not account for email aliases in data analysis. With a web interface, we will finally be able to allow end users to set email aliases to be analyzed. This is especially important for our users on business email accounts, who may manage several email addresses all from within the same Gmail account.

Similarly, we also understand the need to allow our users to exclude certain types of emails or email addresses from analysis. Many, if not all, of us receive a number of automatic email notifications that are not relevant to the data we intend to present. Custom date ranges for analysis and being able to compare against previous time periods are two additional features now possible after we build a web interface.

In short, although we did simplify our email report significantly, this is because we have been developing both the email report and a web interface concurrently. Our goals are rather ambitious, and there are a number of features that we will be working on once this new interface is released and ready for our users.

In the meantime, we are still planning for a closed beta testing period for the Gmail Meter web interface. If you’re interested in participating, please click to signup for beta access for our new Gmail Meter here.

As always, feel free to follow us on Twitter or stay tuned to our blog for future updates. And never hesitate to send us an email at hello@gmailmeter.com.

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 meant that the process can’t be readily understandable. With that said, we would like to update everyone on what we’ve been doing, or what’s taking us so long.

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 about December or January, 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 realizes 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.)

Collaborating Internationally through Google Apps

A peak behind the scenes at ShuttleCloud

Something that you’re probably not aware of about our company ShuttleCloud is that we have offices in both Madrid, Spain and Chicago, IL. Now for the record, this amounts to a seven hour time difference which we have to work around every day.

While it should be no surprise that we are completely reliant on Google Apps for working together – yes, we do check in daily using Google Hangouts and yes, everything is saved to the Google’s cloud – the real key for why we can successfully work while separated by thousands of miles is our overall approach to work.

Decentralizing the office

First, we have to recognize that business is trending towards a more decentralized workplace. More and more companies are outsourcing, hiring contractors or freelancers, or leveraging new virtual office assistant solutions like Zirtual or FancyHands for a variety of reasons. Our ability to hire and work without the limits of physical borders has never been better, and both employers and employees are enjoying the benefits.

I mentioned earlier that as a basic practice we save everything we work on straight to Google Drive. This means that as long as we have an internet connection and device that can connect, all of our vital files will be accessible from anywhere in the world. Another benefit is the ability to easily share these files with colleagues or supervisors. By default, we set all non-sensitive Drive documents to be searchable and discoverable by anyone within our Google Apps domain. This means that it does not matter which project we’re working on, whom we’re working with, or where we’ll be specifically working from – we’ll always have the right files at our fingertips.

With that said, we generally hold ourselves to a unique, or maybe not so unique, policy that coming into the office is not always necessary and working remote is actually a part of any job.

Yes, this applies to all levels within our company – members of our senior management regularly work weeks, if not months or even years, from remote locations. So, how is this possible and how does one manage a team from thousands of miles away?

Employee agency and self-motivation

It’s actually incredibly simple to manage people who are driven by their own motivations to succeed. The crux of our approach to work is to hire good people – we’ll be talking more about this later – and to engender a solid sense of self agency in every single hire. If it becomes clear that characteristic is lacking, well, then something about the situation has to change.

While this approach is definitely not suggested for every company, it is also not a novel solution to employee management. If you’re a manager or a team leader of any kind, please consider taking some time to read Dan Pink’s Drive (available on Amazon for less than $10!). Admittedly, unless you’re a complete psychology nerd, it may be a bit of a dryer reading. Still, Dan presents a clear and concise picture, backed by contemporary academic research, of the scenarios that best allow employees to be self-driven instead of manager-driven.

By encouraging everyone to take responsibility for their work, management spends a lot less time micro-managing or worrying about what everyone else is doing. We’ll discuss more of Dan’s ideas and suggestions later, but right now let me share some insights specifically for meeting virtually across a 7 hour time difference.

Check in regularly using Google Hangouts

Every company has meetings, departmental meetings, team meetings, meetings dedicated to specific projects, ad nauseum. While one of the benefits of the physical office is the ability to meet with anyone at anytime, research has also shown that maybe some of us spend a bit too much time in meetings to actually be productive.

We split our meetings into two types – one is a “standup” that serves as a daily check in with the rest of the team and the other is a full fledged “meeting” with a set agenda planned ahead of time. Each person who joins an full meeting should have all the documents and talking points ready prior to the start, whereas daily standups are for informal updates and are capped at a maximum of fifteen minutes.

Regardless of whether we’re getting together for a meeting or just a standup, we prefer using Google Hangouts. It’s remarkable how much smoother these go and how much more enjoyable they are when we can see each other’s faces. While it can’t replace face-to-face interactions, it’s the next best thing for a company separated by thousands of miles.

The time for meetings or standups is allocated weeks if not months in advance, so habits are ingrained early on and, at the very least, everyone should expect to check in with the rest of their team during the daily standup. While much more informal, expectations for the daily standups are also set ahead of time. We check in with what we accomplished yesterday, what we plan to accomplish today, and any immediate blocking points for today.

In conclusion, we plan both the time and the agenda for meetings and standups far in advance so that everyone knows what to expect. We do meet on a daily basis, but for the vast majority of people, it’s only 15 minutes per day. And we can trust that everyone is getting the necessary work done during the rest of their day, because we make sure to hire good people and encourage these good people to care about what their doing while feeling supported doing their tasks.

As always, thanks so much for the read! Please let us know if you have any feedback on our process or if you just want to talk more about managerial or operational tactics by emailing info@gmailmeter.com. Subscribe below or follow us on Twitter for updates!

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 info@gmailmeter.com address.

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

Who Cares about Gmail Analytics?

In our last post, we began the discussion on the importance of data and analytics from a very high level. We focused primarily on how our users were signing up and the friction our users were experiencing during the initial activation process.

Today, we’ll be briefly covering our customer development process. If you’re unfamiliar, customer development is a term, coined by Steve Blank, that refers the general process of learning more about your customers or potential customers. Since Blank’s initial publication – first written as part of his Berkeley Haas curriculum – his theory of customer development has become a pillar of the lean startup methodology.

The basic premise is incredibly simple – to build a good product that grows, we need to know who our customers are and what specific problems they’re trying to solve. Use as many points of contact as possible, and continue engaging users through these channels because their feedback will always inform the development process.

Identifying our most engaged users

Relying on support tickets or inbound emails from users is one definite way of identifying users who are really engaged with our product, but these emails are few and far in between. That is, unless of course something goes incredibly wrong.

From the beginning, we knew that we needed to find a way to get more feedback from our customers. We first tried sending out email campaigns with random samples of our user base – you can imagine how well that worked (it didn’t).

After reviewing the results, we realized that in our eagerness to engage with our customers we had skipped the an obvious but flawed solution. We decided to create a feedback form using Google Forms and included two prominent buttons within the email report. The understanding was that we were not going to try emailing anyone for feedback, but instead we wanted to make it easier for someone to give us that feedback.

Feedback surveys can still be relevant

The benefit of this approach is that instead of asking users to respond to us, regardless of how engaged they are, we simply gave our already engaged users an easier way to contact us in a very non-intrusive manner. In our last post we talked about how we lowered the friction for user activation – consider this very similar, we just lowered the friction for user feedback.

We made every question in the survey optional and gave our users the option to anonymize their responses. Interestingly enough though, most of our users decided to remain identifiable. We never asked or prompted any users to give us the feedback, so the users who did were volunteering their time to us and were even open to be reached for a follow up.

If you’re still reading, you probably want me to get to the point of this post – so who cares most about our Gmail analytics tool?

Managers and team leaders need email statistics

While our users include anyone from developers to bloggers to founders, this is the single largest demographic of engaged users by far. When so many of our business communications these days are done over email, and when there are always so many different addresses for emails to come from and go to, it’s no surprise that managers would be interested in understanding how their teams are dealing with it all.

We were very surprised to learn just how creative some of our users are. A few of our users had actually gotten entire teams onto Gmail Meter and set up an automatic filter to forward the monthly reports to a central account.

A business or enterprise version of Gmail Meter became an obvious eventuality. Some of our users have become reliant on the data provided in the current limited Google Apps script version, and we now have a much better idea of what our users could want. While we have a vision for a potential enterprise Gmail Meter, we understand that many of our hypotheses will remain so until our users validate them.

Still, we can’t begin to tell you how excited we are at prospect at building a great tool that can really help some people in not only business operations but maybe even personal productivity as well. I hope you are a bit as well and please feel free to contact us with any questions by emailing info@gmailmeter.com.

Please stay tuned as we’re really treating the early days of this blog as a development journal. We have much more to talk about and a couple of surprises, so feel free to subscribe below or follow us on Twitter to stay updated!

The Importance of Analytics for your Web Application

Last month, we were excited to announce the formation of the Gmail Meter team. Since then, our team jumped right into the analytics (or lack thereof) and we immediately realized how important it was to have these analytics in place before considering things like growth or new product features.

We have a pretty strong commitment to freedom of information and transparency, so in this first series of blog posts, we plan on sharing some of the lessons that we are learning as we progress in our endeavor to bring you the best Gmail analytics tool possible!

Some of these posts will be more technical, others will be more related to customer development, and still others will be focused almost entirely on numbers.

From the title, it should be obvious that today we will be thinking about numbers – many, many numbers. Don’t expect this post to have any detailed how-to’s on things like how to setup Google Analytics, filter out ghost spam, or use Google Tag Manager to track button clicks. These will come later; in the meantime, please feel free to signup below to stay updated!

Instead, please view this as a broad overview on why in-app analytics are absolutely important to building a good product and how these analytics will help inform you on important product decisions.

How are users behaving?

Even with all the time we’ve already spent over the course of the last couple of months, we still feel that we have barely scratched the surface of Google Analytics.

Setting up Google Analytics is very simple and straightforward. All that is required is the addition of a simple Javascript snippet in between the tags to get started, but there are just so many ways to customize analytic triggers and data presentation. It can be difficult to even see from a glance the actual potential of Google Analytics.

Beyond the baseline metrics that are calculated by default, the real power of Google Analytics is the ability to find out what users are doing at every step of their experience with the app. Getting these statistics does require a bit of additional time and set up, but have no worry we’ll be covering those steps in a later post. In addition, there are many articles, both Google- and third-party-provided, that can assist with this process.

I’ll be breaking down the rest of this post according to the different stages of our user flow, roughly correlated to the AARRR method for simplicity’s sake.

Optimizing signup flow and activation friction

Before we took the time to set up these additional metrics, we had only been logging the email addresses of every user who had initially authorized the Gmail Meter script. While this method is the obvious choice for simple implementation, it did not provide an accurate or full picture of our users’ initial signup experience.

One of the first things we did was to link our Google Analytics account with Google Tag Manager and we set up a custom event trigger that tracked the clicks to our signup button. After just one day of data collection, we were quite shocked to discover that there was a large discrepancy between the number of users who initially clicked that button and the number of email addresses collected during our signup process.

Realizing just how little we knew about how our users progress through the signup flow, we decided that we need to take it a step further. We set up yet another custom event to capture the actual number of users who complete the entire signup process and land on our “Thank You” page.

Once we got this data, we knew that we had to go even one final step further. Originally, before getting any of this data, our “Thank You” page had actually included a button for first time users to generate their initial Gmail Meter report. Suspicious that this additional step may have actually created friction for activation, we decided to also track how many users actually requested their first Gmail Meter report.

As you can probably already guess by now, the results were a bit shocking.

The data presented below is just a sample of the total data, specifically this is for the period between January 20th through January 26th.

Of the total users who clicked the “Get My Report” button –

  • 82% of users completed the initial authorization and entered into our internal database
  • 67% of users actually requested their first report to be generated

So this means that from first step of our signup process (“Get My Report” click) to activation (actually being generated their first report), 29% of our users were dropping off.

Conclusions drawn based on analytics

After making these discoveries, we knew that we had to immediately shift priorities to address the shortcomings in our signup and initial activation flow. Previously, we had been focusing on different growth strategies like SEM and additional distribution channels to bring more users to our landing page.

With this data collection set up, we knew that we could make a significant impact in the number of our activated users by focusing on reducing friction for signup and initial activation. In addition, by digging deeper into the data, and separating out each step of our signup flow, we were able to identify and pinpoint the exact steps that needed reworking.

For example, one very easy decision to make was to automate the generation of a user’s first Gmail Meter report. Only 82.1% of users who had completed our signup process actually clicked to generate their initial report. With automating this one step, we are now guaranteeing that 100% of our signed up users are also activated users (barring any bugs or glitches, which is a story for another day).

This decision may seem intuitive and obvious to us now, but without the right analytics or data we would still be in the dark about our signup flow. Now, if there’s a single takeaway for you, reader, it’s that the right data can and should quickly inform your decision making process, and change priorities.

The Gmail Meter Team is Formed

ShuttleCloud is excited to announce that we have recently dedicated two of our most senior employees to focus exclusively on building a new Gmail Meter team. Our goal is to bring you a simple and robust statistical tool that will assist you in managing both your personal email and your professional email habits. We believe that data and knowledge are absolutely essential to making smart decisions on your productivity.

Any discussion of Gmail Meter needs to begin first with credit to the original creator of the tool – Romain Vialard, currently a Senior Product Manager at Revevol. Romain is also a Google Apps Script Top Contributor, and has created other products such as Yet Another Mail Merge, which we use quite often.

With that said, our plans are to move Gmail Meter off the existing Google Apps Script platform in order to build a version that can aggregate data and statistics across an entire domain. This new version will leverage Google’s OAuth2.0 protocol for authorization and their Gmail API for data analysis. While we may require some patience, we aim to ultimately build a better product for our users!

Still, the current Google Apps Script version of Gmail Meter will continue to be available as a free version. We will continue to support and also make enhancements as need arises, but the focus will be on the new Gmail Meter platform.

We’re excited for the New Year and our Gmail Meter team’s path, and we hope you are as well. Please feel free to share any comments, suggestions, or thoughts you may have directly with our Gmail Meter team at info@gmailmeter.com.

In the meantime, feel free to check out the current Google Apps Script version of our Gmail analytics tool and cheers to 2016!