7+ years in enterprise analytics

Christopher J. Bratkovics

Trustworthy data foundations. Clear metrics. Defensible decisions.

Data Scientist | Analytics Engineer | Applied AI

I integrate messy sources, define business logic, validate results, and automate recurring workflows, connecting analytics engineering with applied data science and AI.

Explore selected work Explore projects

Selected professional work

Decisions behind the delivery

Production reporting, applied modeling, and operational AI work, with contribution and validation in context.

Five-source reporting modernization

Decision: How can five advertising-platform feeds support consistent reporting without erasing valid source rules?

Key finding

A common schema does not automatically make different sources comparable.

Business users need to know which aligned measures are trustworthy, which exceptions remain, and which differences require clarification rather than another transformation.

Recommendation

Compare aligned source and date populations using agreed definitions and traceable reconciliation before calling a discrepancy missing data—or matching totals complete validation.

Implementation and validation

Ambiguity or source problem: A shared schema can conceal differences in populations, timing, deduplication, and business definitions.
My contribution: I built Snowflake/dbt source transformations, unified facts, Sigma-facing marts, inventory enrichment, source-specific deduplication, controlled backfills, and historical recovery.
Validation: Reusable checks expose source/date populations, calculations, and record-level exceptions for stakeholder review.
Delivered result: A maintainable foundation feeds production revenue reporting in Sigma.
Limitations: Source-specific rules remain explicit rather than being flattened into false comparability.

Daily occupancy without double-counted capacity

Decision: What utilization ratio answers the requested question at the intended reporting grain?

Key finding

Adding activity categories does not create capacity; repeating shared capacity across rows changes the meaning of utilization.

A denominator duplicated at a finer activity grain can produce an invalid rollup even when every row looks plausible.

Recommendation

Define grain and measurable population, aggregate only compatible components, and calculate the ratio with the denominator appropriate to that question.

Implementation and validation

Ambiguity or source problem: Activity categories may overlap, while physical capacity is shared and missing capacity must not be silently treated as zero.
My contribution: I built the SSP components and integration; a collaborating data engineer owns the shared-capacity and charted components.
Validation: Checks cover documented measurable populations and detailed and aggregate grains.
Delivered result: Completed programmatic occupancy and buy-type components were built and validated for their documented grains.
Limitations: Not every numerator is additive across overlapping categories, and this does not claim every report was deployed or adopted.

Reviewable advertiser mappings

Decision: Which external advertisers can be linked to internal accounts without hiding uncertain identity?

Key finding

Receiving a match is not the same as establishing a correct identity.

Exact-name matches can still be ambiguous, while similarity scores and coverage are not calibrated accuracy.

Recommendation

Use supported matching rules, retain method and review information, and route suspicious or ambiguous candidates for human review before consequential attribution.

Implementation and validation

Ambiguity or source problem: Names vary, and higher match coverage can introduce false attribution.
My contribution: In the earlier BI role, I built Python/SQL normalization, exact and fuzzy matching, confidence tiers, and review exceptions.
Validation: Retained scores, tiers, methods, and exceptions keep review status visible.
Delivered result: External advertiser data was connected to internal reporting with uncertain candidates inspectable.

Applied modeling for retention and inventory decisions

Decision: Which accounts or inventory warrant closer attention, comparison, or follow-up?

Key finding

Distinct business questions require distinct analytical outputs rather than one model presented as a complete decision system.

A score or segment can prioritize investigation but does not establish a causal driver or the effect of an intervention.

Recommendation

Use outputs as structured prioritization inputs, and evaluate risk prediction, segmentation, peer comparison, and intervention effects separately.

Implementation and validation

Ambiguity or source problem: Risk prediction, customer grouping, inventory performance, and intervention effects are different questions.
My contribution: I developed advertiser churn-risk models and K-means segmentation separately from inventory-utilization and revenue-per-unit regressions, then added peer comparisons.
Validation: Outputs were checked against business-defined criteria as decision support.
Delivered result: Implemented analytical views for retention priorities, customer groups, inventory gaps, and peer comparison.
Limitations: No retention lift, revenue recovery, recurring adoption, or completed intervention experiment is attributed.

Reliable inputs for AI-assisted communications

Decision: Where should diagnosis begin when generated business communications become invalid?

Observed finding

The incident's failing dependency was stale source views, not a problem requiring a prompt or interface workaround.

Generated language cannot compensate for stale or incorrect business inputs.

Recommendation

Check source freshness and business-data correctness during diagnosis, then validate output after correcting the dependency.

Implementation and validation

Ambiguity or source problem: A visible output failure can originate in the interface, prompt, application, or upstream business data.
My contribution: I supported application delivery, traced the incident, coordinated the source correction with the data team, and validated restored data and output.
Validation: Output was checked after the cross-team source correction.
Delivered result: Editable executive communications were delivered and the affected output was restored.
Limitations: This operating recommendation is not a claim that automated freshness monitoring was implemented or that I owned the entire platform.

Experience

Progression from business-critical reporting into applied modeling, operational AI, and production data-product ownership

Senior Data Analyst (Data Science / Analytics Engineering)

OUTFRONT Media

April 2022–Present

Built production reporting systems, developed Python models, and delivered business-facing AI applications. Translated fragmented advertising data and complex business rules into reusable data products for revenue reporting, customer retention, and inventory-performance analysis.

Production data foundationBuilt the Snowflake/dbt data foundation for production revenue reporting across five advertising platforms, integrating source-specific schemas, deduplication, data enrichments, and backfills into Sigma-facing marts.
Reporting migrationMigrated legacy reporting logic as layered source transformations, unified fact models, and Sigma-facing marts, preserving established business definitions through the data-platform migration.
Daily occupancy modelingBuilt and validated daily programmatic occupancy and buy-type models; designed separate sales-activity and shared-capacity components to preserve metric meaning across detailed and aggregate reporting.
Inventory modeling & peer analysisImplemented regression models for inventory utilization and revenue per unit; combined model outputs with cross-market peer comparisons to identify performance gaps and support yield-management analysis.
Retention & segmentationDeveloped Python churn-risk models and K-means customer segmentation to identify advertiser-retention priorities and account-growth opportunities against business-defined targeting criteria.
Generative AI deliveryDelivered generative AI applications for editable executive financial communications; supported production troubleshooting and partnered with the data team on source-data and output validation.
Cross-functional deliveryPartnered with business stakeholders, vendors, and engineers on requirements, troubleshooting, user acceptance testing, and documentation to deliver maintainable data products at scale.

Business Intelligence Data Analyst (Data Architecture / Data Science)

OUTFRONT Media

July 2019–April 2022

Built the data pipelines and analytical models behind recurring executive reporting, combining Python automation, dimensional modeling, and KPI design with applied machine-learning collaboration.

Python ETL & automationAutomated recurring reporting with Python ETL, replacing manual data preparation with repeatable extraction, transformation, and reporting workflows.
Dimensional modeling & KPIsDesigned fact and dimension tables and defined KPIs, creating reusable data structures for consistent executive reporting across business lines.
Advertiser entity resolutionBuilt Python/SQL entity-resolution workflows linking external advertisers to internal accounts through name normalization, exact and fuzzy matching, confidence tiers, and exceptions for human review.
Applied machine learningAuthored and presented an applied machine-learning use case in 2021 for advertising-inventory optimization and customer-value projection with external data-science specialists.
Production release coordinationCoordinated the transition of business reporting from development to production, aligning stakeholders on release sequencing and phased rollout options to minimize disruption to active users.

Education

M.S., Applied Data Science

Bay Path University

June 2025

B.S., Computer Science

University of Vermont

December 2018

Data Science Immersive

General Assembly

February–May 2019

Non-degree training program

Independent Technical Projects

Public implementations and scoped evidence—kept distinct from proprietary professional work.

Flagship evidence

Fantasy Football Data Platform & Decision Lab

A Python and dbt/DuckDB workflow connecting time-aware predictions with tested facts, reconciled evaluation marts, and inspectable decision support.

Decision: When is a projection sufficiently traceable to use as decision support?

Key finding

An evaluation metric is interpretable only when its population, window, model version, candidate, and aggregation rules stay aligned across the pipeline.

A historical error reduction does not show that the product wins leagues, improves lineups, or captures every piece of pregame context.

Practical recommendation

Inspect the metric definition, baseline, applicable population, and reconciliation before acting on a projection.

Explore the data platform Trace a metric

What to inspect: Inspect the data-platform lineage, metric definition, dbt documentation, model card, and pinned evaluation artifact.

Implementation, evidence, and limitations

Python produces predictions and evaluation artifacts; dbt builds tested facts and marts from statistics and artifacts; the API and product expose those distinct provenance paths. The frozen-model evaluation measured 6.5% lower MAE than its baseline across 5,914 player-weeks.

Validation: Tested facts and reconciled marts provide an independent path alongside pinned model artifacts.

Limitations: The 4.4909 versus 4.8046 PPR-point result is a frozen-model historical evaluation, not a rolling-origin result or prospectively published forecast.

PythondbtDuckDBTime-aware evaluationFastAPINext.js

Source code Model card dbt documentation Pinned evaluation

Featured project

SQL Genius AI | SQL Analytics Playground

An inspectable browser analytics workflow: explore a synthetic sample schema, draft or edit SQL, explicitly run an accepted read-only query in SQLite, preview bounded results, and export CSV.

Decision: How can generated SQL remain inspectable and under human control?

Key finding

A syntactically accepted query does not establish that its metric answers the intended business question.

Even an illustrative question such as ‘best customers’ requires a definition, time window, and eligible population.

Practical recommendation

Inspect the schema, define the metric and population, review the editable SQL, and deliberately execute it.

What to inspect: Inspect the maintained local generator, browser SQLite execution, editable query flow, read-only policy, bounded previews, CSV export, and evidence notes. Policy checks narrow behavior but do not prove SQL correctness, tenant security, or a hardened sandbox.

Implementation, evidence, and limitations

The maintained demo defaults to local reviewed-intent/template generation with a conservative schema fallback, separate generation and execution, and synthetic fixtures. A legacy Python/FastAPI Anthropic route remains optional for private compatibility; the browser demo does not call it by default.

Limitations: Read-only checks do not independently prove semantic correctness, tenant isolation, or a hardened sandbox.

TypeScriptNext.jsBrowser SQLiteLocal templatesRead-only policy

Open playground Source code Implementation evidence

Featured project

AI Chat System | Multi-Provider LLM Gateway

An observable FastAPI/Next.js gateway with SSE streaming, provider failover, exact and semantic response caching, structured errors, bounded requests, and per-request/session telemetry.

Decision: When is semantic response reuse worth the cost of a wrong answer?

Measured finding

In the scoped local run, similarity-based reuse produced 23 false positives and 56.6% precision.

A cache hit or avoided provider call is not useful when it returns an answer to a different question.

Proposed next step

Evaluate false-positive costs and workload fit before enabling semantic reuse; treat bypass rules or threshold changes as proposals, not shipped policy.

What to inspect: Inspect the committed evaluation routines and presentation. The simulated primary failure occurred before its request; these checks are not a production SLA, real-timeout guarantee, or Redis-backed benchmark, and cache behavior is configuration-dependent.

Implementation, evidence, and limitations

A scoped 2026-09-09 localhost run from a dirty working tree used an in-memory cache with configured embeddings: failover checks passed 10/10 and SSE checks passed 20/20. The 68-pair semantic-cache run measured 56.6% precision, 90.9% recall, and 23 false positives.

Limitations: The localhost, in-memory-cache run came from a dirty working tree and is not a production reliability or Redis benchmark.

PythonFastAPINext.jsSSECachingTelemetry

Project demo Source code System evaluations Committed benchmark

Additional work

NBA Stat Predictor

A LightGBM batch pipeline with point-in-time features, GitHub Actions, Hugging Face artifacts, Next.js artifact-reading pages, season replay reconciliation, and a read-only tool-grounded brief.

Decision: Does a favorable restricted-cohort score justify the model for the full pregame population?

Measured finding

The restricted eligible cohort improves on its baseline, while the distinct all-replay population does not.

Post-game minutes eligibility is unavailable at the pregame decision point, so mixing populations can reverse the recommendation.

Practical recommendation

Compare like-for-like populations using decision-time information, and prefer the supported baseline where the comparison does not justify the model.

What to inspect: Inspect cohort-aware metrics, replay reconciliation, and the read-only tool-grounded brief. Published replay differences are +0.0021 points, +0.0008 rebounds, and +0.0010 assists against a 0.05 tolerance; the restricted replay and holdout cohorts have different eligibility rules.

Implementation, evidence, and limitations

The holdout artifact reports 4.764 points MAE versus a 4.908 last-10 baseline for 22,244 eligible 2025–26 player-games (at least 10 minutes with baseline available). The distinct all-replay population does not beat its baseline, and post-game minutes eligibility is not pregame knowledge.

Limitations: This is a conclusion about the scoped evaluations, not every target or possible model.

PythonLightGBMGitHub ActionsHugging FaceNext.js

Project overview Source code Replay Agent brief Reconciliation notes

Additional work

Document Intelligence | Hybrid Retrieval With Visible Evidence

A hybrid retrieval service that shows its work: every passage reports its BM25 rank, dense rank, and reciprocal-rank-fused rank, so you can see why a result surfaced and which retriever found it.

Decision: How can a user inspect why unstructured evidence was retrieved?

Illustrated finding

Lexical and dense retrieval can surface different passages, and visible component ranks show which method contributed to a fused result.

Rank visibility helps inspect relevance and provenance, but does not itself establish correctness.

Practical recommendation

Review the passage, source context, available version and scope, and relevance before relying on it.

What to inspect: Try an exact-identifier question, a paraphrase question, and the fusion example where neither retriever ranks the answer first, then compare the BM25, dense, and fused columns. In the repository, inspect the staged ingestion lifecycle, the demo-safety test that blocks any paid-provider call, and the engineering case study.

Implementation, evidence, and limitations

The maintained demo runs BM25 alongside ONNX MiniLM embeddings behind a Next.js proxy. It is retrieval-only by design: no LLM is called. Uploads are size-limited, rate-limited, scoped to the visitor's session, and evicted oldest-first. Curated example questions illustrate retrieval differences; they are not quality measurements.

Limitations: Curated questions are demonstrations, not retrieval-quality results; session filtering is not authenticated tenant isolation.

PythonFastAPIBM25ONNX embeddingsChromaNext.jsHugging Face Spaces

Live demo Source code Engineering case study

Technical Skills

Tools and methods I use across analytics engineering, modeling, and applied AI

Core analytics engineering

PythonSQLSnowflakedbtSigma

Data products and quality

Dimensional modelingETL / ELTSource integrationReconciliationData testingControlled backfillsGit

Modeling and validation

Random forestsLightGBMRegressionK-meansEntity resolutionFeature engineeringTime-aware evaluationBaseline comparison

Applied AI and applications

FastAPINext.jsLLM APIsRetrievalSSE streamingCachingTelemetry

Cloud and delivery

AWSS3DockerGitHub ActionsPostgreSQL

Delivery highlights

Selected outcomes from production reporting, applied modeling, and operational AI.

7+ years

Enterprise analytics

A continuous path from reporting foundations to modeling and maintainable data products

5 platforms

Revenue reporting

Source-specific data modeled in Snowflake/dbt for Sigma-facing production marts

Decision support

Retention and inventory

Models, segments, mappings, and peer comparisons built for distinct analytical questions

Validated delivery

Applied AI

Editable executive communications delivered, with source and output validation during recovery

Let’s connect

Questions about my work or interested in exchanging ideas about data science, analytics engineering, or applied AI? Get in touch.

Professional profiles

Source code for all independent projects is on GitHub.

GitHub