Hospitality marketing analytics platform
Multi-source marketing data for hotel portfolios, turned into reports people act on. I built the analytics and reporting modules, the security-gated CI/CD to Kubernetes, and now lead the team and the architecture.
What it is
A SaaS analytics platform used by hotel groups and their marketing teams to see how paid media, web traffic, booking sources, reviews and social channels perform across portfolios of properties, with scheduled reports, scorecards and data-quality monitoring.
The problem
Each hotel's marketing data lives in different vendor systems, with different identifiers, schedules and failure modes: Google Analytics 4, Google Ads, Meta, Instagram, review sites, booking data. The platform has to ingest all of it continuously, reconcile it to the right property and produce reliable reports, while the codebase grew from a small team's prototype into an 18-module product.
What I built myself
- Analytics modules end to end: models, data-access layer, schemas and API endpoints for channel mix, paid media, visits and revenue, source traffic and top referring domains.
- The reporting API and exports: v1/v2 report endpoints, PDF report queries and CSV/XLSX export utilities behind scheduled property and portfolio reports.
- Contributions to the Google Analytics, Google Ads and Meta ingestion code and the persistence layer for vendor API responses.
- The CI/CD pipelines: primary author of the staging workflow and co-author of production. Snyk and Trivy scans, a security gate with reviewer approval, findings posted to the team's tracker, ARM image builds to ECR and rollouts of the web, Celery worker and beat deployments on EKS.
- Celery configuration and task wiring, including the database-backed periodic scheduler used by every sync job.
What I lead
- Review and merge of every feature, fix and sprint-release branch, around seventy sprint cycles to date.
- The refactor program: I wrote the 2026 engineering brief that replaced a 'migrate all 18 modules' plan, estimated at 3.5 to 6 years, with a bounded target. Six modules cut over, seven dead endpoint groups deleted after access-log verification, stable modules wrapped behind a proxy, the hardest rewrites deferred and planned.
- The ETL v2 platform design: bronze, silver and gold layers with idempotent ingestion runs, file and row hashes, versioned cleaning rules, data contracts and audit tables.
- The AI-reporting initiative, see the coding-agent case study for the LLM side.
Decisions that mattered
- Multi-source identity and data quality: explicit mapping tables and hotel-code change requests, data-completeness and data-quality monitors run as Celery tasks, auto-resolution for known failure patterns. Missing data became a tracked state instead of a silent gap in a report.
- Security in the deploy path without blocking delivery: scans fail builds by default, a reviewer can approve with documented findings, every outcome is written to the workflow summary and the tracker.
- Legacy versus rewrite: prove migration competence on low-risk modules first, delete what has no callers, reserve rewrites for the modules where the old design actually hurts.
Outcome
A production platform in continuous operation since 2023, with automated vendor syncs, scheduled reporting and a security-gated path to Kubernetes, plus a written, agreed multi-year architecture direction with a disposition for every module.