A New Adventure: I’m Taking the Leap to Focus on Preceden and Analytics Consulting

As many of you know, I’ve had a long-running side project called Preceden, a tool that helps people create professional-looking timelines:


I launched Preceden back in early 2010 while I was a still lieutenant in the Air Force and kept it running as a nights-and-weekends side project throughout my time at Automattic and Help Scout.

Over the years its revenue has slowly grown to the point where it’s a healthy little business these days. As its revenue has grown, the amount of time I have to put into it has dwindled to an hour or two each week. Between my work at Help Scout and my family (three kids under four now!), I basically have had time to do support and not much else, despite there being so much more I want to do.

There was never going to be a perfect time to take the leap to focus on growing Preceden, but with its revenue and growth being what it is, my wife and I have decided now’s the time to do it.

For the foreseeable future I’ll be focused on growing Preceden, but also doing some analytics consulting on the side. Going all-in on Preceden was an option, but I really enjoy analytics and business intelligence work and want to continue leveling up there. I’m thrilled to have both Help Scout and Automattic as my first consulting clients.

With my hours now reduced at Help Scout, we’re looking to hire a new analytics lead. Help Scout is an incredible company and you’ll get to work with an amazing group of people who care deeply about building a business and a product that people love. As the lead analyst, your work will have a huge impact on the direction of the business. If you’re interested in this role, check out the job description here: Data Analyst at Help Scout and feel free to shoot me an email with any questions.

I have no idea how this will all play out long term, but I’m really excited to see how it goes.

A Frequent Communication Mistake I’ve Made as a Data Analyst

Looking back at my time so far as a data analyst, some of the biggest mistakes I’ve made were not technical in nature but around how I communicated within the organization.

Two real-world examples to illustrate:

A few years ago at Automattic our ad revenue was way down from what our marketing team expected it to be. For example (and I’m making up numbers here), for every $100 we were spending on ads, we had been making $150 historically, but in recent months we were making $25. Either the performance had gone way down or there was some issue with the tracking and reporting.

I was on the data team at the time and volunteered to work with the marketing team to investigate. As it turned out, there was indeed an issue: there was a problem with the way AdWords was appending UTM parameters to our URLs which was breaking our tracking. For example, a visitor would click an ad and land on wordpress.com/business&utm_source=adwords – note that there’s an amperstand after the URL path instead of a question mark, so the correct UTM source wouldn’t get tracked and the customer wouldn’t get attributed to AdWords.

Fortunately, we had some event tracking set up on these pages (Tracks for the win) that recorded the full URL, so I was able to go back and determine which customers came from ads and calculate what our actual return on ad spend was. After figuring out the issue and determining how much unattributed revenue we had, I wrote up a lengthy post about what happened and published it on our internal marketing blog without informing the marketing team about it first.

Second example: a few months ago at Help Scout, we had an ambitious revenue target for Q1. With a few days left in the quarter, we were still projecting to come in short of the target and no one realistically expected us to reach it. Something about the projection seemed off to me so I dove in and realized there was a mistake in one of the calculations (it was my fault – in the projection we weren’t counting revenue that we earned that month from customers that were delinquent who then became paying again). As a result, our projection was too low and we likely were going to hit our target (and eventually did!). I wrote up a lengthy message about what happened and published it in one of our company Slack channels without informing any of the leadership about it first.

To understand the problem, it’s important to note that as a data analyst, I haven’t typically been responsible for the performance of our metrics. I help set up tracking and reporting and help ensure accuracy, but someone else in the organization is responsible for how well those metrics were doing.

In both of the cases above, I wasn’t intentionally bypassing people. At the time, it was more like “oh, hey, there’s a bug, now it’s fixed, better let everyone know about it” – and probably an element of wanting credit for figuring out the issue too.

However, not consulting with those responsible for the metrics before reporting it was a mistake for several reasons:

  • They didn’t have an opportunity to help me improve how the issue and impact were communicated with the rest of the company and its leadership.
  • I missed an opportunity to have them doublecheck the revised calculations, which could have been wrong.
  • Even though we were doing better than we had been reporting in both cases, it may have indirectly made people look bad because they had been reporting performance based on inaccurate data. They should not be finding out about the issue at the same time as the rest of the company.

In neither case was there any big drama about how I went about it, but it was a mistake on my part nonetheless.

Here’s what I’d recommend for anyone in a similar role: if someone else in your organization is responsible for the performance of a metric and you as a data analyst discover some issue with the accuracy of that metric, always discuss it with them first and collaborate with them on how it is communicated to the rest of the company.

It sounds obvious in retrospect, but it’s bitten me a few times so I wanted to share it with the hope that it helps other analysts out there avoid similar issues. Soft skills like this are incredibly important and worth developing in parallel with your technical skills.

If you’ve made any similar mistakes or have any related lessons learned, I’d love to hear about them in the comments or by email. Cheers!

Prioritization for Data Analysts



For the past two years I’ve worked as a data scientist, first on the marketing team for WordPress.com and now on the growth team at Help Scout. In both of these roles I’ve been the sole data analyst on my team so I tend to have more work to do than I have time for. As a result, I spend a lot of time thinking about how to prioritize what’s on my plate. My goal with this post is to share some of what I’ve learned to help other data folks who are in similar roles.

The prioritization problem

Here’s a made up scenario:

Your manager asks you for help with a medium priority analysis that will take several days. Shortly after you begin working on it, a coworker pings you for help with an urgent request that will only take a few hours. A little while later, your boss’s boss asks you for help with a low priority one-day project.

You now have three requests from people with differing seniority each with a different duration and urgency – which do you work on next and why?

Ad hoc requests vs projects

At a high level, there are two types of data requests:

Ad hoc requests are questions that can be answered fairly quickly. They may take a few minutes or a few hours and the urgency can range from “drop what you’re doing” to “no rush at all”.

Projects take longer and usually have a higher impact on the business. For me, they range from a few days to (rarely) a few weeks.

While it may be tempting to only want to work on ad hoc requests or only on projects, the reality is that they’re both important and if you’re the only analyst, you’ll need to work them both into your schedule. For example, even if you’re working on a big project, you can’t simply ignore the urgent ad hoc requests that come up during the course of a week. Telling your CEO that you’ll get to his request in three weeks when you’re done with your project is not recommended.

Therefore my advice is to set aside about two hours each day to work on ad hoc data requests and spend the rest of your time working on your highest priority project. This will give you time to work on those longer, high impact initiatives but still give you time to work on the shorter requests as well.

I wouldn’t loop your manager into the prioritization of ad hoc data requests; he or she probably has better things to do than helping you decide “spend 30 minutes on this then spend an hour on that” etc etc. Use your judgment: work on whatever is the most urgent or will have the highest impact on the business. When in doubt, base it on the seniority of whoever is asking.

For projects, I definitely would recommend getting your manager’s help prioritizing what to work on. He or she help you decide where you can be the most impactful and when questions come up about why you’re not working on some other thing, it’s not just you who made that call.

I would only work on one project at a time. I’ve tried doing like 3 hours a day on one project, 3 hours a day on another, but all that’s going to do is make both take twice as long if not longer due to the frequent context switching.

When you meet with your manager, keep him or her up to date about where you’re at with your project. Often it’s hard to predict at the start how long a project will take. Something you thought might take a week will take a day. Something you thought would take three days will take two weeks. That’s just the nature of it. Keeping your lead informed.

Sometimes priorities will change. Your expected three-day project that is now in its second week may get put on the back burner in order to work on something else. It’s easy to get frustrated when this happens, but remember that you’re there to have the biggest impact on the business, not to finish projects just for the sake of finishing them. Sometimes what’s highest priority will change so be flexible.

When priorities change and you have to change projects midway, try to estimate what impact that will have on the completion of the original project. If you estimated you would complete your original project by the end of the week, but by switching projects it will now take an additional week, communicate that to the people waiting on the result of the original analysis.

Get clarity before beginning your analysis

Regardless of whether a request is ad hoc or a project, I’d recommending asking the requestor several questions:

  • How important is this?
  • Is there a deadline?
  • How accurate do you need the answer to be?
  • What type of end result are you looking for?

If you don’t ask about importance, you risk spending a lot of time on an analysis that is not that important to the person asking about it. It’s common for someone to ask a quick hey-I-wonder-about-this question, but they only care if you can find the answer quickly.

Similarly, ask whether it needs to be done by a specific date. If the answer is holding something up, it should get higher priority than something that doesn’t.

Asking about accuracy is something that took me a while to appreciate too. I’ve run into a lot of data requests that I can give a 95% accurate solution to fairly quickly, but that would take much longer to get to 100%. A lot of times, people will be fine with a 95% quick solution. Understanding when 95% is acceptable and when 100% is necessary can save you a lot of time.

Sometimes I also ask what type of end result the person is interested in. It often helps them and you clarify what the analysis is all about.

For longer projects, I’d also recommend periodically updating the person who requested it with your progress. As they see your progress, they might want to refine the request or may be happy with the results as-is, freeing you up to work on something else.

Staying organized

I’ve seen some data teams ask people to fill out a little template (usually in a Trello card) to help people ask good data questions. I prefer to discuss the details with the person, then create a Trello card for myself with the relevant information.

I would recommend keeping a list of all potential projects and ad hoc data requests. That is, don’t just try to keep it all in your head. I do this in Trello with four lists:

  • Multi-week Projects
  • Multi-day Projects
  • Multi-hour Projects
  • Quick Requests

Whenever someone asks a question, I get the details from them then create a new card and add it to the appropriate list.

You could also have a Completed list where you drag cards as you complete them to keep a record of it. I’ve also seen some teams have a list for each month or quarter (January 2018, February 2018, etc) and drag completed cards to the relevant list when it’s complete. I did that in the past, but tend to just archive the cards now to avoid cluttering up the Trello board.

Invest in a proper BI tool like Looker

One other big win has been switching from manual data analysis (using MySQL queries and R) to Looker, the premier Business Intelligence (BI) tool on the market today. I could go on for hours about how amazing Looker is, but at a high level it lets you:

  • Create dashboards that are automatically updated as the underlying data changes.
  • Use LookML, Looker’s modeling language, to teach Looker how our data fits together. With that in place, I rarely have to write queries by hand anymore. I can use Looker’s interface to quickly ask and answer questions.
  • This also means that other people at the company who may not have querying skills can answer their own questions without asking me every time.

I’d highly recommend checking out Looker if you still find yourself wrangling data a slow manual way.

If this post resonates with you, I’d love to connect

If you’re a data analyst, especially if you’re the only one at your company or part of a small team, I’d love to chat to learn more about what you’re working on, how you prioritize, etc. Drop me a note: matthew.h.mazur@gmail.com. Cheers!

A New Adventure

Just a note for those of you who follow me online that after almost four years at Automattic, I’m moving on to try something new.

Automattic is an amazing company and I’m incredibly grateful for having had the chance to work there with such a talented group of people.

As for what’s next: later this month I’ll be joining Help Scout to work as a data scientist on their growth team. I’m really excited by the opportunity and hope to share a lot of what I learn on this blog. More to follow!

Analytics Event Name Cardinality

As a follow-up to my post about analytics event naming conventions, I want to share a few thoughts about event name cardinality aka how many distinct event names to track in your analytics tools.

Consider four events that a user can perform: signing up for an account, publishing a post, publishing a page, and publishing an image.

How many analytics events should this be? We have a few options:


  1. Sign Up
  2. Publish Post
  3. Publish Page
  4. Publish Image


  1. Sign Up
  2. Publish Post with an Image property set to true or false depending on whether the post consists of only an image
  3. Publish Page


  1. Sign Up
  2. Publish with a Type property set to Post, or Page, or Image


  1. Perform Event with a Name property set to Sign Up or Publish with an additional Type property when the name is Publish set to Post, or Page, or Image

If you use a robust analytics tool like Mixpanel, Amplitude, KISSmetrics, or Tracks (Automattic’s internal analytics tool), you should in theory be able to perform any type of analysis using any of the options above.

For me, it comes down to what type of analysis you want to perform on the data, the types of properties on the event, and convenience.

Using the single event option will be a pain because you’ll constantly have to be specifying the Name property in the analytics tools to get the data you really want.

The decision between two, three, and four is close in this example. I think it comes down to whether you’re going to need a single Publish event in the types of analysis you’re performing. If knowing that the user published anything is important and each type publishing is conceptually similar, then having a single event might make sense. However, if your analysis is frequently going to focus on whether the user just published a post or just published a page or just published an image, having distinct Publish Post/Publish Page/Publish Image events is more convenient because you won’t constantly have to specify that you want the Publish event where the Type is Post. If publishing an image is similar to publishing a normal post, then maybe the three-event option is best.

At Automattic we went with three (Sign Up, Publish Post, Publish Page) and then added a feature to some of our tools (like our funnel builder) that let you specify a step can be one of several events (like publishing a post or publishing a page).

Hopefully this gives you a few things to think about next time you go to name new analytics events. If you can’t decide which route to go, feel free to reach out over email and I’d be happy brainstorm with you.

My New Home Office, Courtesy of Automattic and Applied Ergonomics

One of the less well-known benefits of working at Automattic, the company behind WordPress.com, is that they will contribute $2,000 towards improving your home office.

My back, neck, and wrists have been slowly worsening over the last few years so when I found out from my mentor, Daryl Houston, that Automattic would contribute money towards a new setup, I jumped at the opportunity. I emailed Lori McLeese, our ever-helpful HR lead, and she introduced me to Automattic’s ergonomic consultant, Jeff Meltzer.

Jeff founded and is the president of Applied Ergonomics, an Illinois-based furniture dealership that works with Automattic employees to solve just the type of issues that I was having. Every Automattic employee he works with receives a custom setup based on their specific requirements. Jeff recently wrote about his experience working with Automattic employees in a post titled Making Happiness Engineers Happier & Healthier One Ergonomic Consultation at a Time.

Jeff and I set up a time to video chat over Skype and wound up talking for almost two hours (Automattic pays for the consultation and the cost is separate from the $2,000 contribution). For the majority of the conversation we discussed my current home office and the issues I was experiencing. I appreciated that he was not just trying to sell me something based on some preconceived idea of what my issues were. He was really trying to understand my situation: How much time did I normally spend at a computer each day? Had I ever tried a standing desk? What was my normal posture? Where was I having pain? We positioned and repositioned my laptop so that he could see my current setup. I took measurements and he took lots of notes.

It was not until the last half hour of the conversation that he started to propose possible solutions. We looked at several different desks, chairs, keyboards, and mice. In the end I wound up purchasing an adjustable desk, a new chair, and a monitor arm.

Home Office: Before

Before the new furniture arrived, this is what my home office looked like:


The four year old L-shaped Office Max desk had been through three moves across three states and was not doing so well. The back corner was propped up by books and the surface was warped from setting too many drinks on it.

The chair is an Herman Miller Aeron chair that I purchased off of Craigslist back in 2010 when I first started experiencing back issues.

The 24″ Dell monitor is propped up by a small monitor stand. The monitor is connected to a Macbook Pro which sits on the bottom left shelf.

The keyboard is a Microsoft Ergonomic Keyboard 4000 that I’ve been using for many years.

The kitchen chair on the right allowed my rat terrier to get onto the desk to hang out in her little dog bed.

Home Office: After

I present to you my new home office:



The Chair

The chair is a HÅG Capisco 8106 [1]:


There are a few things I really like about this chair:

First, it doesn’t have arms. It has these two little nubs that protrude from the back where you can rest your elbows. Because they’re so far back, it forces you to keep your elbows back which encourages good posture.

Also, the front right and left of the seat are carved out which I have found to be a lot more comfortable than one that is even on the front.

Finally, the seat’s height and depth as well as the back height can all be adjusted which makes it easy to find a position that suits you.

The Desk

The desk is a RISE Electric Height Adjustable Desk [2] which means that it can be adjusted so that I can either sit or stand while working. Here is what it looks like in the standing position:


The desk has a small remote under the bottom right ledge which allows you to electronically adjust it up and down:


One of the nice things about the RISE desk is that it has a very sparse under-surface structure which makes it easy to install a keyboard tray (something I might get in the future) or a small shelf. I did wind up building a small one underneath the bottom left side (which you can see in the picture above) to hold my laptop because I don’t use it as a second monitor and therefore I don’t need to have it out on the desk all day.

The Monitor Arm

Rather than use a monitor stand like I’ve done in the past Jeff recommend purchasing a monitor arm so that I could quickly adjust the position as necessary without the constraints that a small monitor stand imposes. We went with a M8 Monitor Arm from HumanScale [3]:


Finishing Touches

I kept my monitor, ergonomic keyboard and my mouse because I didn’t have any issues with them.


I also bought a Bonsai tree which I think adds a nice dash of color to the office. I also stole one of my wife’s hot plates so I can set dishes and drinks down without messing up the surface of the desk:

Initial Impressions

The total cost with shipping came out to be slightly over $2,000. Because the final price was over Automattic’s allowance, I did have to pay a small amount out of pocket but that was fine by me. I considered going with one of the cheaper versions of the chair, desk, or monitor arm but given how important it is to my productivity and happiness that I am comfortable while working, it was easily worth the small extra expense.

I’ve been using this new setup for about two weeks and so far I absolutely love it. I typically stand for about half of the day: either two hours standing/two hours sitting or half the day standing/half sitting (I’ll write a follow-up blog post in a few months once I’ve been using it longer to share what I’ve learned).

My back and neck pain are a fraction of what they used to be and contrary to what I would have thought I find that I have a lot more energy throughout the day.

Most importantly, I’ve found that without my normal discomfort I look for excuses to work instead of for excuses not to work which is exactly how a job should be.

Knowing what I know now, I wish I had purchased better furniture a long time ago. However, without Jeff’s help and Automattic’s contribution, I wouldn’t have known what to buy and I would have been hesitant to spend so much money on something that might or might not help. Props to Automattic for realizing how important this is and making it easy for its employees to take advantage of it.

If you have back, neck, or wrist pain and are on the fence about whether or not to buy a standing desk, I encourage you to take the leap. Even if you don’t get an expensive one you can Google around and find some cheap ones or even build one yourself. If you could use professional opinion, I’m sure Jeff would be happy to help as well. You can email him at jmeltzer [at] appliedergonomics.com.

Finally, if you have any recommendations on how to improve this setup based on your own experience, please feel free to leave a comment below or drop me a note at matthew.h.mazur [at] gmail.com. Thanks!



[1] The actual line item was: “Capisco saddle seat with back in Grade 1 (Insight Stately) with carpet casters and a tall lift.”

[2] There were two line items for the desk, one for the work surface and one for the adjustable base: “RISE Height Adjustable Worksurface – Rectangular worksurface (30″D x 72″W), 1″ High Pressure Wilsonart® Standard Laminate surface MAPLE PVC T-Mold edges” and “RISE Height Adjustable Base Electric E6P 2-parallel base (two electric motors) with low voltage DC motors, Programmable switch, 22″- 48″ Height Range, 26″ Travel Range, 1.5″/second Travel Speed, 300 lbs. maximum distributed topload capacity, Silver Finish”. The Maple edge for the work surface wound up being discontinued so we went with Latte instead.

[3] The line item was: “M8 Monitor Arm with two-piece clamp mount with base, in polished aluminum with white trim, fixed angled link/ dynamic link, and standard VESA plate.”