What do you want to see in 2018?

Hi Everyone!

We hope you’ve all thoroughly enjoyed the holidays with friends, family and loved ones. As we ramp up for an incredible 2018, we want to hear from you!

At SparkPost, the goal with each blog that we publish is to be helpful, informative or just plain entertaining. Sometimes we totally nail it, and other times we might miss the mark a bit. That’s why we’d like to hear what you think! What kind of content do you enjoy reading the most on our blog? How-to’s on more technical skills? Features on community members using cool technologies? Thought leadership showcasing trends in the email and messaging industries?

We’ve put together a very short survey so you can let us know what you think – there’s room at the end for comments, suggestions, etc. We appreciate your feedback and promise to incorporate it into our plan for next year. For fun, I’ve listed below our top 5 posts from 2017 – they might help refresh you on what types of content we regularly publish here on the blog:

GDPR: What Email Senders Need to Know

Europe’s GDPR privacy law is an issue for almost every company with an app, SaaS product, or other service. Learn exactly what email senders need to know before the changes go into effect.

How to Use Microservices to Build an API That Lasts

Learn some successful strategies we use to build our microservices architecture and how they allow us to evolve our API during rapid growth.

Community Spotlight: CodeNewbie

Whether you are new to coding, want to brush up on skills or just network, CodeNewbie is an incredible resource. Check out this Q&A with founder Saron Yitbarek, and get excited for some fun upcoming projects we’ve got in store with them in the new year.

RESTful API Versioning Best Practices: Why v1 is #1

Breaking changes can result in frustration and loss of trust between an API provider and their users. API versioning is one way to avoid that frustration.

How To Read Email Headers

Email headers host a treasure trove of information. Learn how to read them and understand more about the mail you’re sending and receiving.

Any industry trends or topics you think were under-represented? Be sure to list that feedback in the survey or tweet us with your thoughts!

Happy New Year!

Jen

Introducing SparkPost Labs

We love to experiment with new ideas at SparkPost! Our regular hackathons are one way our engineers bring to life new ideas. Our engineering team has cooked up some great user features and tools during hackathons or other engineer initiated projects. Some favorite features that began life as hackathon entries are webhooks, multi-factor authentication, the new real-time suppression api, CSS inlining, and even the use of AngularJS for our web UI.

But it isn’t easy to take a proof of concept that is hacked together in 24 hours and release it in the wild. As you might expect, we have high quality standards at SparkPost and expect our APIs to be fully vetted, conform to performance standards, and be versioned. Normally for a hackathon project to make its way to production as a fully supported feature, it will require additional work by Engineering to ensure the feature is fully baked. The downside of our super high standards is many of these very cool projects don’t get to the top of the priority list.

That’s why we created SparkPost Labs—a new program that helps our engineers more easily share new and experimental API and App functionality and other helpful tools with our developer community. This way we can find out sooner if there is interest in the feature, get valuable feedback from our community, and decide to fully-productize if it’s a hit. It’s a great way for our community to be actively involved in the direction of SparkPost!

We’re launching SparkPost Labs by introducing a new A/B Test API endpoint.

What You Need to Know

SparkPost Labs features are different from other new API features that we often expose to customers in beta form. When we beta a feature it is versioned, supported, and production-ready. While beta features may sometimes be initially limited in scope, we release them with the full intention that they will be supported and expanded over time. However, what we release under SparkPost Labs may be discontinued completely or re-envisioned before making it into the core supported product. It’s really up to you, our community, to help us determine what features are most valuable to take the extra mile. Caveat emptor!

Here are some helpful tips to keep in mind when you try out anything marked as “SparkPost Labs” in our API docs:

  • Labs API functionality is not versioned. As such, it is available under a distinct /api/labs/ path rather than /api/v1/ path.
  • Any API feature accessed via /api/labs/ is by definition experimental and subject to change. We may decide to change the behavior or discontinue it at any time. We also may decide to incorporate Labs functionality into the core supported product.
  • Normal support channels or SLAs are not available for SparkPost Labs. You can provide feedback via this Google form. We will route your feedback to our engineering and product teams.

A/B Test API

An A/B test is a fully managed API method of comparing templates to see which one performs better, and automatically choosing the better performing template. It is super simple to use: you provide two or more templates, a recipient list, a sample size, and a test duration to begin. The A/B Testing API endpoint provides the means to create new tests, and view completed results.

The API randomly chooses recipients from the recipient list equal to the sample size. The API distributes sample recipients among the templates and transmits emails.

 SparkPost labs image 1

When the test time has expired, the template with the best conversion rate wins.

 sparkpost labs image 2

All remaining recipients will be sent the winning template.

 sparkpost labs image 3

Example API Call

POST /api/labs/ab-testing

Response

The A/B API endpoint is our first SparkPost Labs project. If there is enough interest from the community in this kind of experimental feature we will do more – so please give us some feedback!

If you have any questions or comments about SparkPost Labs please don’t hesitate to connect with us @SparkPost – and we are always hiring.

Chris McFadden
VP Engineering

Community Driven Development

The Community Driven Development Approach

April 2015 was an exciting time to be an engineer at SparkPost. Our service had just launched. We were seeing the results of all the hard work and dedication from previous quarters spent building our functionality, infrastructure, and teams.

Fast-forward to late February 2016. SparkPost had been generally available for ten months. Our community was growing steadily. We continued to make refinements to our service and infrastructure. We didn’t know it at the time, but MailChimp had just announced some important changes to Mandrill that would change the way we interact with our community and how we improve and support our product.

In the days following the announcement, we’d go on to set up our community Slack and revise our product and engineering processes to embrace community driven development. We used the feedback and experiences to drive our decision making processes to execute on what really makes our community successful.

Channels for information

Several mechanisms for feedback from our community exist at SparkPost. I mentioned our community Slack. There, our community has access to SparkPost team members and, more importantly, each other. We learn from you not only through direct interaction but by observing, listening, and taking notes. Any member of our team can take feedback from community Slack and post it directly to a feedback channel in our internal Slack. There, our engineers, product managers, and executives have direct access to your comments.

community driven development slack screengrab

Support tickets and Github issues are another essential method for understanding ways we can make our community’s lives easier. Our support team does a great job of escalating issues internally to our engineering team as well as bringing up issues that are occurring repeatedly and brainstorming ways to address. Github issues allow us to understand how our client libraries are being used and where we can make improvements.

Attending meet-ups, conferences, and hackathons has been a major source of learning for us too. We get to spend quality time face-to-face with our community, learn about how you use SparkPost and what improvements might help you and your business be more successful. After each event we make a point to share learnings internally so that we can discuss ideas and issues that arise during our conversations with attendees.

What happens behind the scenes?

Collecting all this valuable input wouldn’t mean much if we didn’t act on it. In the past three quarters we’ve acted on a little over 50 items that were a direct result of the information we gathered from our community. These smaller items are what we consider quick wins – things like updating language in our UI, improving documentation, bug fixes, and minor feature improvements. Here are some examples:

  • Click to see event details in Message Events UI
  • Allow customers to clone Templates in UI
  • Create code samples for cc/bcc in the client libraries
  • Surface all 4xx API errors in the web UI
  • Add information about rate limiting and error responses to the docs
  • Fix click tracking on <area> elements

Additionally, the engineering, product, and support teams meet weekly to discuss customer impacting issues, solutions, and action items. Like many software companies, we also have a prioritized list of larger initiatives that we work our way through. Some examples of work completed from the past few quarters include:

Prioritization

Prioritization of new features and improvements is a constant work in progress. We do our best to compile all of the great feedback we receive and maintain a balance between addressing current issues and the planning and execution of new functionality and improvements. Some additional items we’ve heard our community request include:

  • Deliver webhooks by subaccount
  • View the contents of sent emails in the UI
  • View billing history in the UI
  • Add the ability to use a test API key
  • Reporting by geography in the UI
  • Support for stored templates with subaccounts

Lastly, the best way to stay up-to-date with what’s new as well as fixes we deploy is to join the #announcements channel in our community Slack or keep an eye on our change log article. We update both every Friday when we deploy changes that we want to make sure you know about.

Onward & Upward

With 2017 nearly upon us, we’re looking forward to implementing some of the improvements and features you’ve told us are important to you. Our community plays a major role in the development and evolution of SparkPost. We love to hear from you, so keep the feedback coming. And keep pushing us to deliver the best service we can.

—Rich Leland, Director of Growth Engineering

ps: Thoughts on community driven development? How do your teams prioritize and process feedback? Leave us a comment below.