Shared customer view
Reporting gets easier once the team is working from the same customer record.
Data engineering, analytics systems, and workflow design
Edwin Tse
I help teams turn messy, hard-to-trust data into something clear and usable.
That usually means tracing broken handoffs, fixing inconsistencies, and leaving behind a setup other teams can use with confidence. Most of the work is practical: clean up the records, make the logic clear, and make sure the result holds up after handoff.
GTM data systems
Analytics engineering
Product analytics
Decision infrastructure
Steadier pipeline
The value is not the alert by itself. It is a calmer reporting week and a clearer fix path when something breaks.
Cleaner review work
When the intake flow is clearer, people spend less time fixing preventable mistakes.
Selected projects
A quick read on the kind of work I do.
These projects show the problems I tend to take on, how I approach them, and what changed for the people using the result.
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.
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 project note
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
What changed
- 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 helped
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.
It shows the production side of the work: make sure the system still works after the first launch.
Open project note
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
What changed
- 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 helped
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.
It shows product analytics being used as a decision tool, not just a reporting layer.
Open project note
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
What changed
- 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 helped
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.
It combines model work with a question I care about: how a system can look useful while still producing uneven outcomes.
Open project note
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
What changed
- 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 helped
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
Research · Urban planning · GIS · Transportation
Transit Hub Access Study
Used maps and planning analysis to compare access, safety, and network fit around transit hubs.
It shows the public-systems side of my work in a form that is still easy to read.
Open project note
The project needed to explain transit trade-offs, not just show a map.
State
hub trade-offs made clear
Build
map story easier to read
Result
planning context kept intact
What changed
- Analyzed hub access and surrounding conditions with a GIS workflow designed to compare several planning factors at once.
- Used layered maps, planning criteria, and short narrative framing to show why a hub can look strong on one measure and weak on another.
- Turned a planning question into a case study that someone outside a GIS classroom could still follow.
Why it helped
This is one of the clearest public examples of the broader context that keeps showing up in my work, even when the tools change.
ArcGIS · GeoPandas · Spatial analysis · Planning research
How I Work
The pattern is usually the same even when the tools change.
The work usually starts when the data exists but the usable version does not. The job is to find where the records drift, where the handoff breaks, and what needs to become clear before another team can trust the result.
Contact
I am interested in roles where careful systems work makes decisions clearer and day-to-day work easier to trust.
If that sounds useful for your team, feel free to reach out at tsepaksang8@gmail.com.