Analytics Systems & BI

I build analytics systems people actually use.

I work across modeling, dashboards, and stakeholder workflows to turn messy questions into something teams can act on. Most of my work is less about fancy tech and more about making sure the numbers are clear, consistent, and easy to trust.

View Selected Work Contact LinkedIn
Data events, finance, media
Model grain + metrics
Dashboard usable interface
Decision aligned action

Stakeholders to systems

How I translate business problems into analytics systems.

Most problems show up as a vague question. My job is to turn that into something concrete, then build the system around it.

Ambiguous question

Usually starts with “can we see…” or “why is this happening”

Clarify decision + metric

Figure out what decision this is actually tied to and what metric should drive it

Model the data

Lock in grain, definitions, and logic so it doesn’t break later

Build the system

Pipelines, models, and whatever interface people will actually use

Decision-ready output

Something a team can look at and know what to do next

Analytics as a product

Dashboards are products. Stakeholders are customers.

A dashboard isn’t useful just because it exists. If people don’t use it in their actual workflow, it’s dead. I think about whether people will actually use it before I build it.

Adoption signal Increased dashboard usage by focusing on clearer structure and aligning views to real decisions.
Workflow fit Replaced manual Excel reporting with automated dashboards so teams didn’t have to rebuild the same numbers every month.
Trust layer Reduced back-and-forth questions by standardizing metric definitions upstream.
Adoption checklist

What has to be true before a dashboard becomes part of the way a team works.

01 Awareness Teams know the source exists.
02 Usage It fits recurring workflows.
03 Trust Definitions are stable and explainable.
04 Decision The output changes what people do.

Decision interface

I design dashboards so someone can answer “what changed and what should I do” in a few seconds.

Good dashboards make the next step obvious. If someone has to interpret too much, it’s not doing its job.

Revenue Health Executive view · Last 30 days
KPIs $4.8M Revenue +8.4%
KPIs 31% Gross margin +2.1 pts
KPIs 94% Forecast attainment
Trends
Narrative

Enterprise expansion is offsetting SMB softness.

Revenue is above plan, but the mix shift is hiding lower SMB conversion. Next decision: protect enterprise capacity while testing SMB onboarding fixes.

Technical depth

If the model is messy, everything downstream is harder than it should be.

I try to keep models simple and predictable. Clear grain, consistent naming, and logic defined once instead of everywhere.

Grain Canonical metrics Layered modeling
Raw
→
Staging
→
Intermediate
→
Mart
→
BI

Reporting modernization

I replace brittle reporting with governed, automated systems.

The goal isn’t a nicer dashboard. It’s less manual work and fewer arguments about numbers.

Before

Excel reporting

Manual refreshes, version drift, hidden logic.
After

Automated BI

Scheduled pipelines, governed metrics, shared definitions.
Before

SSRS extracts

Static outputs that require analyst intervention.
After

Looker workflows

Reusable models, self-serve paths, decision dashboards.
Before

Siloed metrics

Teams debate definitions instead of outcomes.
After

Unified layer

Shared marts and canonical measures across teams.

Selected projects

More systems I have built.

A few examples of how I’ve taken messy data problems and turned them into something usable.

ProductDW Mini ELT System

View

Problem: Raw GA4 event data was not analytics-ready for product KPI reporting.

System built: Python-orchestrated BigQuery pipeline with staging, core, and mart tables plus a Streamlit consumption layer.

Impact: Turned raw events into reusable product analytics tables and a practical KPI interface.

Python SQL Streamlit

API Feed to BigQuery

Private implementation

Problem: Event data needed reliable ingestion without manual exports or duplicate loads.

System built: Python ingestion job deployed on Cloud Run with API auth, pagination, schema mapping, and BigQuery watermarking.

Impact: Created a scheduled, low-maintenance pipeline feeding the warehouse for downstream reporting.

Python REST APIs Cloud Run

Core stack

Tools and systems already represented in the work.

Modeling

dbt SQL Layered modeling Canonical metrics

Warehouses + BI

BigQuery Looker SSRS Excel

Engineering

Python REST APIs Cloud Run Streamlit Fivetran

BI operating model

A few things I try to stay consistent on.

Start with the decision

If it’s not tied to a decision, it’s probably not the right problem yet.

Make grain explicit

Every model should say what one row means. This prevents hidden joins and metric drift.

Centralize metric logic

Definitions belong in governed models, not scattered across dashboard calculations.

Design for adoption

A dashboard is successful when stakeholders return to it during real operating rhythms.

Reduce analyst drag

Good systems remove repeated pulls, one-off reconciliations, and preventable explanations.

Keep builders close to users

The person modeling the data should understand the workflow the dashboard supports.

Next role

Looking for roles where I can own BI systems and still stay close to the work.

Open to BI Lead, BI Manager, Staff AE, or senior analyst roles where the work actually impacts how teams operate.

Email Me LinkedIn GitHub