Begüm Koca Ceyhanlı

Begüm Koca Ceyhanlı

Senior Data Analyst · working as an Analytics Engineer at Mews

Building data products @ Mews · Netherlands

I'm Begum. I build the path from raw signal to a decision grounded in evidence. At Mews I own the customer dimension and the metric definitions behind the company's main reports, from source tables to the semantic layer that Looker and AI tooling read from, and I hold every metric to one rule: definition stated, denominator named, tested before it ships. AI is in the loop with a review step: coding agents draft models, tests and docs; I check the grain, the SQL and the numbers before anything merges.

// at a glance

  • dbt Certified Developer, hands-on with dbt, SQL, Python and BI
  • Agentic development and LLM context management for the dbt repo, with a human review step on every model
  • Focus on metrics people can actually decide on

// what i do

  • Analytics engineering
  • Metric design
  • Data modeling
  • Semantic layers
  • Self-serve BI
  • Agentic development

// stack

  • SQL
  • dbt
  • Python
  • Git
  • Databricks
  • Snowflake
  • BigQuery
  • PostgreSQL
  • Claude Code
  • Cursor
  • Looker
  • Power BI
  • Tableau
  • Looker Studio
  • Azure
  • Microsoft Fabric
  • Excel
  • Power Query
  • Data warehousing
  • Dimensional modeling
  • Data governance
  • Statistics

// ai in the loop, with review

  • Agents draft, I own the merge: every generated model is compiled and run against a dev target before review.
  • Grain and row counts are checked against the source before a model is trusted.
  • dbt tests (unique, not_null, relationships, accepted_values) and unit tests with fixed inputs are written with the model, not after.
  • Metric definitions live in version-controlled YAML so BI and AI read the same number.

// projects

Source it, model it, serve it.

Three end-to-end builds, each with the source, the model and the serving layer spelled out. Every card opens the code.

Case study: a tested transformation layer on Snowflake

repository ↗
Problem

Raw sample data (jaffle_shop customers and orders, stripe payments) landed in Snowflake with no shared definitions. The goal: a version-controlled transformation layer where every table is documented, tested and rebuilt from one command.

Design

Two databases: raw for landed data, analytics for dbt output. Sources declared in YAML, one staging model per source table (stg_customers, stg_orders, stg_payments) that renames and types columns, then two marts: dim_customers and fct_orders at one row per customer and one row per order.

Quality

unique and not_null tests on every source and model key, order status documented as a markdown doc block so the accepted values are explicit. A failing test stops the build before the marts are rebuilt.

Tradeoff

Kimball-style dim and fact tables over one wide table: slower to write, but customer lifetime metrics and order metrics keep separate grains, so a payment fix never double counts an order.

Next

Slim CI on pull requests (build only changed models), a snapshot for order status history, and an incremental strategy for fct_orders once the volume justifies it.

More visualisation work · 5 dashboards and analyses

// certificates

Three that matter, the rest on request.

Each opens the original PDF. Where the issuer offers it, there is a verification link as well.

dbt LabsFeb 2026

dbt Certified Developer

valid until Feb 2028 · id 174936611

dbtAnalytics EngineeringSQL
DatabricksMar 2024

Get Started with Data Analysis on Databricks

DatabricksLakehouseSQL
Learning · 8 more courses and certificates
  • dbt FundamentalsMar 2024pdf ↗
  • Excel Business Intelligence: Power Pivot and DAXDec 2023pdf ↗
  • Advanced SQL – Window FunctionsDec 2023pdf ↗
  • Advanced SQL: Logical Query Processing, Part 2Mar 2023pdf ↗
  • Advanced SQL: Logical Query Processing, Part 1Mar 2023pdf ↗
  • Microsoft Certified: Power BI Data Analyst Associateexpired Jan 2023Jan 2022pdf ↗
  • Excel Business Intelligence: Data Modeling 101Oct 2021pdf ↗
  • Excel Business Intelligence: Power QueryOct 2021pdf ↗

// experience

  1. MSenior Data AnalystMews · Remote · Netherlands

    Mar 2024 — Present

    Working as an analytics engineer at a hospitality cloud: I own the customer dimension and the metric definitions behind the company's main reports on Databricks, from source tables to the semantic layer that Looker and AI tooling read from.

    • Own dim_customers, the customer dimension behind the company's main reports: PMS application data and Salesforce (Nue) subscription data through staging, intermediate and mart layers in dbt, enriched with external sources such as GIATA and CoStar. Runs daily, incremental where query time demanded it.
    • Defined the company churn metric (a customer counts once a subscription has been charged, not at deal signature; denominator is total active customers), giving GTM one agreed definition, and added it to the context tier of the semantic layer so AI answers apply the same rule.
    • Architected the customer models for self-serve and AI access: Looker explores on top, and beneath them a semantic layer of table and column metadata, metric views, warehouse metric definitions and a context tier, documented well enough for business teams, conversational analytics and a Databricks agent app to consume without an analyst in the loop.
    • Drive AI-assisted workflows in the analytics engineering function: built an LLM skill for the dbt repository that, given only the source table in Databricks, generates the source definitions, the staging models and their YAML, and manage the LLM context for the repo so agents follow its conventions.
    • Tests ship with every model: unique and not_null on keys, relationships between PMS accounts and Nue subscriptions, accepted_values on subscription status, dbt unit tests with fixed inputs for the churn logic, and row-count and grain checks against source before anything is delivered.
    SQLdbtDatabricksLooker
  2. MData Analysis ConsultantMerkle · Prague · Czech Republic

    2022 — 2024

    Delivered Datorama and Tableau reporting across Salesforce CRM, Data Cloud and Marketing Cloud for tobacco and healthcare clients, presenting to senior management and technical teams.

    • Datorama reporting that let a global tobacco client see product performance by region and country at a glance, replacing slide-by-slide market updates.
    • Market-entry research for the same client's expansion: Google Trends (pytrends) interest and trendlines for branded and unbranded keywords per country, plus SimilarWeb data on competitor paid keywords, site traffic and affiliates. The findings shaped the regional marketing strategy.
    SQLSalesforceDatoramaTableauPython
  3. AJr. Portfolio ManagerAlpiq · Prague · Czech Republic

    2020 — 2022

    Portfolio analytics for an energy trading desk: Power BI models on MSSQL over larger data sets and more complex data models than any previous role.

    • Built and ran the Power BI reporting the whole trading desk reviewed in its daily stand-up; the analysis informed each day's trading approach and fed directly into the daily P&L discussion.
    Power BIMSSQLDAX
  4. AEnergy Trading and Analysis SpecialistAlarko Holding · Istanbul · Turkey

    Jan 2019 — Oct 2020

    Energy trading analysis on PostgreSQL: automated the ETL steps behind the desk's reporting so the analysis data stayed clean and reliable.

    PostgreSQLETLExcel
  5. İSales & Marketing Analystİpragaz · Turkey

    Jan 2017 — Dec 2018

    First analyst role, working with a wide range of data types and tools including SAP CRM.

    SAP CRMExcelStatistics

// education

  • M.Sc.
    Engineering
    Statistics & data-driven research
  • B.Sc.
    Chemical Engineering
    Where the love for statistics started

// focus

Decisions over dashboards. Definitions stated, denominators named, and models that fail loudly instead of silently.

// contact

Talking data? Say hello.

Open to conversations about analytics engineering, data analysis and building data products people trust.