Role fit
Analytics engineering with operator empathy.
I am strongest in roles that need technical cleanup, practical modeling, and clear communication with business or product teams.
Data engineering · analytics engineering · product analytics
Edwin Tse
I build data systems that make decisions easier to trust.
I work where scattered records, brittle reporting, and unclear definitions are slowing teams down. The useful output is usually a cleaner source of truth, a steadier workflow, and a handoff another team can keep using.
Best fit
Data systems with business users attachedWorking style
Definitions first, dashboards secondCore work
- Customer identity and attribution logic
- dbt-style modeling, tests, lineage, and monitoring
- Product funnels, experiments, and KPI definitions
Tools
Snowflake · dbt · SQL · Python · Airflow · Power BI · GA4 · Salesforce
Selected proof
Projects framed around the problem, the system, and the handoff.
The fastest way to read the work is to look for the messy starting point, the structure added, and what became easier for the next team.
Professional work · GTM data · Attribution · Warehouse
Customer 360 and Revenue Attribution
Pulled customer, product, billing, and support records into one account view for the GTM team.
Recruiter read
This is a good example of the work I do most often: take scattered records and turn them into something people can actually use.
Open case note
Problem
Different teams were working from different customer records, so even simple reporting questions kept turning into reconciliation work.
State
one customer view
Build
shared revenue logic
Result
easier budget calls
System change
- Stitched CRM, GA4, product, billing, and support records into one account-level model.
- Defined shared identity, touchpoint, conversion, and revenue logic so teams were not reconciling the same customer in different ways.
- Added dashboards, lineage, and ownership rules so the model stayed useful after handoff.
Why it mattered
The value was not a prettier report. The value was giving GTM teams one version of the customer so planning and budget decisions stopped breaking on record mismatch.
Snowflake · dbt · SQL · Salesforce · GA4
Professional work · dbt · Airflow · Reliability
ELT Reliability and Monitoring
Built a steadier data foundation with tests, monitoring, and clearer pipeline ownership.
Recruiter read
It shows the production side of the work: make sure the system still works after the first launch.
Open case note
Problem
The pipeline worked just enough to be relied on, but not enough to be trusted.
State
steadier runs
Build
clearer failure paths
Result
faster new-source setup
System change
- Built a layered ELT flow with staging models, curated marts, and reusable onboarding patterns for new sources.
- Added dbt tests, freshness checks, lineage docs, and monitoring so reliability could be checked directly instead of guessed at.
- Used CI workflows and data contracts to catch bad changes before they reached dashboards or leadership reporting.
Why it mattered
Once the pipeline had tests, runbooks, and visible ownership, analysts could stop treating every table like a special case.
Python · SQL · dbt · Airflow · GitHub Actions
Professional work · Experimentation · Funnel analysis · Product analytics
Onboarding Funnel and Experiment Readouts
Built cleaner event tracking and experiment readouts so product teams could see where onboarding was breaking.
Recruiter read
It shows product analytics being used as a decision tool, not just a reporting layer.
Open case note
Problem
Changes were shipping faster than the team could agree on what was working.
State
clearer drop-off points
Build
cleaner test readouts
Result
faster product calls
System change
- Standardized event taxonomy, exposure logging, and reusable funnel models across onboarding and checkout flows.
- Built experiment readout templates with guardrail metrics so results were easier to compare from one launch to the next.
- Added cohort and decision-tracking views that connected analysis back to the change a team actually made.
Why it mattered
The project mattered because it turned experiments into a repeatable workflow. Teams could see the change, read the result, and make the next call faster.
Snowflake · SQL · Python · Experimentation · Dashboarding
Independent project · Fairness · Transportation · ML
FlightPriceBias
Used airfare data to study prediction quality and fairness risk at the same time.
Recruiter read
It combines model work with a question I care about: how a system can look useful while still producing uneven outcomes.
Open case note
Problem
The question was simple: can a fare model look strong while still hiding fairness problems?
State
fairness risk made visible
Build
trade-offs easier to explain
Result
more grounded model review
System change
- Built repeatable preprocessing over DOT DB1B-style fare tables, including joins, route aggregation, and fare-per-mile features.
- Benchmarked baseline classifiers alongside fairness-aware mitigation approaches using scikit-learn and AIF360.
- Compared predictive performance with fairness metrics so the trade-offs stayed visible.
Why it mattered
The point was not to claim the model was fixed forever. It was to make the trade-offs clear enough for someone to make a better decision.
Python · scikit-learn · AIF360 · pandas · Fairness metrics
Recent roles
Experience with data systems that have to survive real workflows.
Across roles, the recurring job has been to make inputs cleaner, definitions more explicit, and reporting easier to maintain.
EnvoyX
GTM Data Engineer
Built GTM data systems that gave sales, marketing, and product teams a shared customer view and reporting they could trust.
shared customer view
steadier reporting flow
cleaner team handoff
United Parcel Service
Data Analyst Intern
Built KPI and reporting systems that replaced manual updates with a clearer operating view for logistics teams.
one KPI language
less manual work
clearer weekly reviews
United Parcel Service
Brokerage Data Administrator
Worked on brokerage intake and review flows where messy documents had to become clean, review-ready records.
cleaner intake
clearer review queue
fewer avoidable handoffs
How I Work
The dashboard is rarely the first problem.
I usually start where trust has broken: mismatched customer records, unclear metric definitions, manual review queues, or pipelines people rely on but cannot inspect. The design goal is a calmer operating surface, not a busier one.
Contact
I am interested in roles where careful systems work makes decisions clearer and day-to-day work easier to trust.
Reach me at tsepaksang8@gmail.com, or start with the resume.