7+ years in enterprise analytics

Christopher J. Bratkovics

Analytics Engineer

Data Modeling, Quality & Automation

Reliable data. Better decisions.

SQL · dbt · Snowflake · Python · Sigma

Applied Data Science & AI

I build Snowflake/dbt data models, production pipelines, and business-facing data products. My work combines source reconciliation, business-rule validation, and applied data science to turn fragmented data into reliable reporting and decision support.

Explore selected work Explore projects

Selected professional work

Decisions behind the delivery

Data modeling, source integration, metric design, and validation behind reliable reporting and decision support.

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.

Independent Technical Projects

Data integration, modeling, and reconciliation in public implementations, with applied data science and AI as supporting depth.

Flagship evidence

EV Charging Data: Unified Schema

Unified three public charging datasets in a bronze/silver/gold dbt warehouse on DuckDB, with explicit grains, source contracts, reason-coded quarantine, timestamp validation, and reconciled incremental loads.

Decision: How can incompatible public charging feeds support defensible, reproducible utilization decisions?

Measured finding

In Boulder, 45.1% of connected time is idle after charging, but only up to 12.4% is idle while every inferred port is occupied.

Idle time at full inferred occupancy is an upper bound of 12.4% of Boulder connected time. It does not measure waiting demand, recovered revenue, or the effect of an idle fee.

Practical recommendation

Quote the smaller figure as ‘up to.’ Use it only to prioritize investigation at multi-port stations in the late-morning-to-mid-afternoon hours, and validate port inventory and collect queue evidence before claiming constrained demand or choosing an intervention.

Read case study Explore dbt lineage

What to inspect: Inspect the source contracts, bronze-to-gold lineage, quarantine, reconciliation, claim artifacts, and the bounded findings and recommendations.

Implementation, evidence, and limitations

Built to make every published number traceable from raw files through the reporting layer. This independent project uses public data; as of v0.1.0, it lands 440,575 rows, accepts 357,606 as sessions, and retains 82,969 quarantined rows with explicit reasons.

Validation: Contracts, unit tests, raw-to-gold reconciliation, deterministic rebuild checks, and committed claim artifacts keep the published numbers inspectable.

Limitations: No source publishes station port counts. Inferred port counts are lower bounds, so published utilization is an upper bound. Utilization figures are within-source only; the sources differ in operator, place, and period and are not compared. All figures are scoped to v0.1.0.

dbtDuckDBSQLPythonData QualityReconciliation

Source code dbt docs and lineage Findings

Featured project

Entity Resolution: Rules vs. Calibrated Classifier

Built Python record linkage for 482K sampled MusicBrainz release groups against Discogs, with multi-key blocking and dbt/DuckDB marts reconciling match quality, coverage, and review queues to committed artifacts.

Decision: When does a learned matcher earn its place over a well-designed rules baseline?

Measured finding

On the labelled test fold, weighted rules reached 0.962 F1. The isotonic-calibrated classifier raised auto-accept precision from 0.9946 to 0.9993 and cut the review queue from 25,076 to 6,016 records, at lower recall (0.850 vs. 0.931).

The learned model’s contribution was calibration and a smaller review queue, not higher accuracy. Unlinked records are unlabelled, so coverage is never reported as accuracy.

Practical recommendation

Keep the rules baseline as the reference. Adopt the classifier where reviewer time is the binding cost and lower recall is acceptable, and report unverified accepts separately from every accuracy figure.

Read case study Explore the results site

What to inspect: The blocking report (pair completeness before and after the per-record cap), the per-method evaluation artifacts, the tier semantics, the committed test-fold mapping table, the five decision records, and the number checker that verifies every cited figure.

Implementation, evidence, and limitations

482,514 sampled MusicBrainz album release groups against all Discogs masters, with 241,752 in-scope truth pairs from MusicBrainz’s own Discogs links. Multi-key blocking retains 96.2% of truth pairs after a per-record cap of 200, leaving 7.6M candidate pairs. Three methods share one normaliser: an exact-match rule, a weighted-score rules baseline, and one scikit-learn classifier calibrated on a held-out fold. A dbt bronze/silver/gold warehouse on DuckDB carries the mapping; a CI number checker fails the build when any cited figure lacks a matching artifact key.

Validation: Folds are split by MusicBrainz record, calibration uses its own fold, and a too-good-to-be-true audit was run before the results were accepted. Committed artifacts pass a reproducibility check.

Limitations: The full build is owner-run; its ~13.8 GiB data peak does not fit a hosted runner, so CI verifies committed artifacts only. The methods use different tier thresholds, so recall and coverage differ. The learned model’s decision-level calibration remains overconfident. 4,501 rules accepts on unlabelled records are excluded from every accuracy figure. All figures scoped to v0.1.0.

Pythonscikit-learndbtDuckDBRecord linkageCalibration

Source code Results site Findings Methods card

Featured project

Fantasy Football Data Platform & Decision Lab

Built a dbt warehouse with SCD2 player history, incremental restatement, data contracts, and evaluation marts reconciled to versioned Python artifacts before publishing.

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 warehouse implementation at b03b618 includes 26 models and 97 data tests, with local DuckDB development and MotherDuck transformation; 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.

SQLdbtMotherDuckDuckDBPythonSCD2

Source code Model card dbt documentation Pinned evaluation

Featured project

NBA Stat Predictor

Built and validated dbt/DuckDB evaluation marts, reconciling row counts and aggregate error metrics from player-game residuals against versioned season-replay artifacts.

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 warehouse is locally validated on DuckDB; a completed MotherDuck build, pushed gold exports, and routine nightly warehouse operation are not established by committed run evidence. The LightGBM 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 observed minutes with both baselines available). MAE improves about 2–3% in that restricted cohort; the last-10 baseline wins across the broader replay population. Post-game minutes eligibility is not pregame knowledge.

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

SQLdbtDuckDBPythonLightGBMGitHub Actions

Project overview Source code Replay Agent brief Reconciliation notes

Additional work

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

Additional work

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

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

Experience

Enterprise analytics experience building reliable reporting foundations, reusable models, and business-facing data products

Senior Data Analyst / Analytics Engineer

OUTFRONT Media

April 2022–Present

Built Snowflake/dbt reporting foundations, reusable data models, and validated business metrics across advertising platforms, with additional work in predictive modeling and business-data-grounded AI applications.

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

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

Technical Skills

Analytics engineering first, with applied data science and AI depth. Tools span professional work and independent projects; SCD2, incremental processing, data contracts, and MotherDuck are demonstrated in independent projects.

Core analytics engineering

SQLdbtSnowflakePythonSigma

Data modeling & reliability

Dimensional modelingETL / ELTSource integrationData contractsdbt testingReconciliationControlled backfillsIncremental processingSCD2

Platforms & development

DuckDBMotherDuckPostgreSQLAirflowGitGitHub ActionsDockerAWSS3Snowflake Notebooks

Applied data science

pandasNumPyscikit-learnRandom forestsLightGBMRegressionK-meansEntity resolutionFeature engineeringModel evaluationTime-aware evaluationBaseline comparisonA/B testing analysis

Applied AI & applications

FastAPINext.jsLLM APIsRetrievalSSE streamingCachingTelemetry

Delivery highlights

Reliable reporting foundations, validated metrics, and applied analytical depth.

7+ years

Enterprise analytics

Reliable reporting foundations, reusable models, and maintainable business-facing 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

Connect through my professional profiles to discuss analytics engineering, reliable data products, and applied analytics.

Professional profiles

Source code for all independent projects is on GitHub.

GitHub