Embedded dashboard in action: Postman

Jill Hardy, Blog Editor, Looker at Google Cloud

May 12, 2021

This embedded dashboard feature brings you insights from Postman, a collaboration platform for API development. Postman simplifies each step of building an API and streamlines collaboration so you can create better APIs, faster.

I got in touch with Vasa Prudhvi Kumar, Analytics Leader from the Postman team, to learn about their experience creating embedded analytics for their platform.


How Postman uses Looker embedded dashboards

Tell us about your dashboards. In general terms, why did you build them, and who are they for?

After seeing the incredible benefits of becoming a data-driven organization, we set out to empower our customers to become data-driven themselves. We want our users to be able to, not just develop their API landscape in the most efficient fashion, but also have transparency around those workflows.

These reports are built for our enterprise plan customers—specifically, engineering managers and CIOs—in order to provide insights into Postman’s impact on their organization’s API landscape development. From understanding the overall team behaviour and usage patterns, to looking at the state of APIs at a granular level, these dashboards act as a one-stop destination for people to understand the impact of their development within (and beyond) their team.

The Team Activity report displays information about a team’s behavior and usage patterns

Our customers can also see more granular information, like the APIs built by their team, and details around the developmental progress of the APIs related to testing, documenting, monitoring, and so on.

The All APIs dashboard displays details about an organization’s overall API usage

We also created a Security Audit dashboard so our customers could quickly access details on certain security issues pertaining to their team’s public entities—be it misplaced or revealing API tokens, or similar security threats.

The Security Audit dashboard helps customers track security concerns so they can be addressed quickly

More details on the capabilities/features of these reports can be found in our documentation.

What were your goals in setting up embedded analytics?

Firstly, we want our customers to succeed in their API endeavors—these reports help them do that by making the process of building APIs more manageable and trackable, and by establishing transparency around team activities. Team leads and technical directors can get a clear picture of how their organization’s API landscape looks.

Secondly, the reports help validate that Postman has been useful to our customers as they build out their API landscape.

Building their embedded dashboards

Which team members were involved in creating your embedded analytics?

In Postman, our teams are “product squads.” Each product squad owns their respective features, and looks after the end-to-end discovery and delivery of the feature (with some dependencies on other squads). The reporting squad that drove this embedded analytics development consists of:

  1. Product Manager: Makes high level decisions regarding the product and creates a vision for the product. Also conducts customer interviews to validate the product from the user perspective.
  2. Engineering Manager: Drives the sprint plan to decide how to prioritize tasks, and manages the entire product delivery cycle.
  3. Design Lead: Facilitates the product discovery and comes up with data visualizations that would be relevant to the end user.
  4. Product Analyst: Builds up data models which eventually infuse the reports with data. Collaborates with the Design Lead regarding what can be built from the backend perspective.
  5. Data Engineering team (cross-squad dependency): Constructs pipelines for transforming and ingesting that transformed data into the desired database.
  6. Content team (cross-squad dependency): Validates the naming and notation of each metric.
  7. Software Developer: Builds the APIs and the system to embed reports into the product. Sets up analytics which we can use to measure the performance of these reports.

How long did it take to build your first iteration (MVP)?

Initially, a very basic segment was built internally as a proof of concept so that we could view the feature and get a better idea of the workflows involved. This took about a week’s time.

Once we had the proof of concept ready and reviewed, we went forward with actually building the product and deploying it for our enterprise users, which took up about 1.5 months. The time to our first production deployment included:

  • Setting up our database with Looker
  • Data acquisition & transformation
  • Design/UI decisions regarding the visualizations
  • Addressing security risks
  • And finally integrating it within our product

Have you gone through further iterations to get to the dashboards you have today?

Yes, like in any product or product feature in the discovery phase, we too have undergone several minor and a few major refactoring changes to reach the current stage of the dashboards.

How and why did you decide to change things from your initial design?

As a user-facing product, we are committed to our users; hence, the changes were mostly aimed at improving the overall user experience.

  • We tailored the dashboards to better fit customer expectations and make them more useful, according to what people wanted to see.
  • We made the data and the visualizations more easily consumable.
  • We also improved the performance of the dashboards.

How to design an embedded dashboard that resonates with customers

Take me through the thought process you went through when deciding to showcase the data in the way that you did.

We try to spend some time in our users’ shoes and develop to meet their needs.

We use the “jobs to be done” (JTBD) construct very heavily at Postman. Following this framework, we describe a user’s specific goal (or “job”), and what their thought process might be when deciding how to accomplish that goal. Essentially, we’re looking to find out what we can do to help them accomplish their goal. It helps us study our user personas, use cases they have, and workflows they use.

Once set, we refer to JTBDs constantly to give us direction in each stage in the development of a metric or report. Our next step is to decide on, and validate, each metric we want to include in a report.

Then we define user expectations for the metric. The user might want to compare values, observe a distribution, understand a trend, or something else. This leads us to the type of visualization we’ll use for that metric.

In what way has embedded analytics impacted your customers?

Quite often, our customers spend thousands of hours within the Postman product each month performing critical work related to their API lifecycle. Although this work is tied to strategic initiatives across large organizations, being able to view, analyze, and track progress towards a goal wasn't previously possible.

By having a reporting and analytics suite embedded into our platform, we can now help our customers track their success towards a specific goal. They can also engage new personas and users who, although they aren't involved with this work day-to-day, are significantly impacted by its success or failure. Data that was a question mark previously now becomes an answer and a guiding metric for success.

Did you have a “wow” moment when making this dashboard? If so, what were you surprised that you could do or achieve with Looker?

The “wow” moment for us was the simplicity with which data visualizations can be created using Looker. And how these simple graphs add humongous value for our customers.

Tips for success with embedded dashboards

If you could go back in time to the beginning of this embedded analytics journey and give yourself one tip, what would it be?

One major tip would be to set up the system to be more agile. For this I wish we had utilized the following to their full extent earlier on:

  • Version controlling LookML and dashboards so that multiple people can contribute in parallel, without affecting the final deployment.
  • Building multipurpose Explores by making them more accommodative to future changes and to be able to fulfill a wide range of data visualization needs.
  • Use the Looker API for deployment and time deployment with app releases - so that there seems to be a consistency throughout the product.

The above pointers would facilitate us in being more agile, which would speed up the iteration cycle, in turn helping us meet our customer's expectations sooner.

Another tip would be to set up data sanity checks and alerts early on so that every data point that is made available to the end user is reliable.

How do you see the future of this embedded analytics feature?

We will continue taking user validations so that we are completely aligned with what our customers need. We also have plans to increase the performance of the dashboards and improve data freshness. Along with this, we want to set up more detailed analytics on how people are using certain product features to better understand what they find useful and engaging (and hence, help us make their experience of Postman even better).

Eventually, it all boils down to the user perception of the utility and reliability of our product. When a customer establishes a relationship with our product by adopting it into their workflows, we know they find it useful. But more than that, we know they’re depending on us, and the data they see, to be trustworthy and reliable. When this sense of trust is established, it sets the stage for us to truly empower them to become data-driven—and watch them succeed with the power of data and analytics.


If you’d like to see Looker’s embedded analytics and reporting in action, you can join a group demo.

For a more personal touch, we can help you explore what an embedded analytics deployment would look like for your specific organization. You can get started here.

Next Previous

Subscribe for the latest posts