Skip to main content
Skip to main content
Back to Blog
API Design

Turning API Logs Into Board Decisions

Our API usage data was sitting in Elasticsearch and S3, technically "available" and practically invisible. Here is how it became a dashboard executives opened themselves.

Thakur Ganeshsingh
December 27, 2024
9 min read
Share this post:
Turning API Logs Into Board Decisions

This is Part 3 of "API Evolution Chronicles" — real stories from a decade of API transformations across multiple companies.

💡

The Data Was Never the Problem

Every API call we served was already logged, indexed, and technically queryable. What we didn't have was a way for anyone outside engineering to ask a business question and get an answer before the meeting ended. This is the story of closing that gap.

The Question Nobody Could Answer in Time#

While leading API strategy at Bazaarvoice, I kept running into the same wall. Someone in a planning meeting would ask a perfectly reasonable question — which integrations were growing, where usage was concentrated, whether a partner rollout was actually landing — and the honest answer was: give us a few days.

Our API usage data lived in two places: live logs in Elasticsearch, and anything older than the retention window archived in AWS S3. Both were "available." Neither was usable by anyone who wasn't comfortable writing a query. Getting a real answer meant an engineer manually pulling from both sources, reconciling them, and building a one-off spreadsheet — by which point the decision had usually already been made without the data.

That's not a data problem. That's a translation problem.

Before and After#

Before: Logs Nobody Outside Engineering Could Read
API usage data fragmented across live Elasticsearch and a 60-day S3 archive. Every business question meant filing a request and waiting on an engineer to hand-build a one-off export.
×No unified view across live and archived data
×Manual, one-off extraction for every question
×Engineering was the bottleneck for basic usage insight
After: A Dashboard Leadership Opened Themselves
A unified ETL pipeline feeding interactive Tableau dashboards with geographic and time-series views, built for self-service instead of one-off requests.
90% adoption rate among the business stakeholders it was built for
75% faster report generation
50% faster data-driven decisions

What We Actually Built#

The technical work wasn't exotic — an ETL pipeline unifying two data sources into one model, sitting behind Tableau. The part that mattered was building it backward from the questions people were actually asking, not from whatever fields happened to already exist in the logs.

Ingest

Pull live usage data directly from Elasticsearch without adding load to production.

Completed

Unify

Merge live logs with the archived S3 history into one consistent data model instead of two.

Completed

Visualize

Build interactive Tableau dashboards with geographic distribution and time-series trend views.

Completed

Hand off

Train business stakeholders to filter and explore on their own instead of filing a request.

Completed

Author Insight

Thakur Ganeshsingh

The pipeline succeeded because it was designed around the questions Product and Leadership were already asking in meetings — regional distribution, usage trends over time — not around the fields Elasticsearch happened to make easy to query. Instrumenting data is an engineering task. Deciding which two or three views make a leader trust the data enough to act on it is a different skill entirely.

The Metric That Mattered More Than Uptime#

It would have been easy to call this project done once the pipeline was reliable and the dashboards loaded fast. But a fast dashboard nobody opens twice isn't a win — it's a cost center with good intentions. The number I actually cared about was adoption.

Business Impact

90%

User Adoption

Of target business stakeholders

75%

Reporting Efficiency

Faster report generation vs. manual extraction

50%

Decision Speed

Faster data-driven decisions

100%

Data Visibility

Unified view across live + archived data

99.9%

Data Accuracy

Validated across both sources

-60%

Manual Effort

Reduction in manual analysis time

Once Product Management and leadership could open the dashboard themselves — filter by region, scrub the time series, see the same numbers engineering saw — the conversation in planning meetings changed. Usage data stopped being something people waited on and started being something they checked before the meeting, not during it.

Same Data, Different Audience

Nothing about the underlying API logs changed. What changed was who could reach them, how fast, and whether the view in front of them answered the question they actually had.

A Framework for the Next Pipeline#

Turning Telemetry Into a Business Story

0 / 4 completed
Start with the question leadership actually asks, not the metric engineering already tracks
Design for self-service — if only the platform team can query it, you haven't fixed the bottleneck
Match the view to the decision: geography for market bets, time series for trend calls
Track adoption as the real success metric, not just uptime or query latency

The Personal Takeaway#

Across REST, GraphQL, and now this, the pattern repeats: the technical migration is rarely the hard part. The hard part is translation — turning something only engineers can read into something the rest of the business trusts enough to act on. A 90% adoption rate on a BI dashboard taught me more about API strategy than any latency benchmark ever did.


Next in the series: what happens when that same instinct — turning raw signals into decisions — starts getting handled by the API itself.

Have a dashboard nobody opens? I'd genuinely like to hear what's blocking adoption — drop it in the comments.

Thakur Ganeshsingh
Thakur Ganeshsingh
Engineering Manager - Developer Relations at Freshworks