GCP Data Architecture Design and Decisions/Roadmap for AdTech / Travel Retail Media Cloud

Overview We are working with a travel retail media startup building a Travel Data Cloud. A data network aggregating behavioural, transactional and intent data across 30+ travel retailers (airlines, OTAs, holiday brands) to power three core use cases in retail media travel: 1. Audience packaging and data monetisation: packaging travel audience segments for activation across paid media channels 2. Attribution and measurement: closed-loop measurement connecting media spend to travel bookings 3. Intelligence layer: demand-based insights products (e.g. informing when and where a tourism board should run campaigns based on live booking demand signals) The company is a network play, not a single retailer, this is a critical architectural distinction. They are the aggregation layer sitting across multiple travel brands, each with their own data, cloud infrastructure, consent frameworks and commercial sensitivities. The core platform is built on OutSystems (low-code, full-stack). The Travel Data Cloud is a separate but connected data and intelligence layer being designed and built on top of this. The primary cloud assumption is GCP/BigQuery, with Fivetran already in use for data ingestion. Cloud tool choices is one of the open decisions this engagement needs to address. We need an experienced data/cloud solutions architect to review existing documentation and produce two precise, tangible deliverables the team can act on immediately. Engagement Structure Week 1-2: Document review and deliverable production Review all Notion documentation provided at project start 1hr briefing call within 48hrs of project award to walk through context, open questions and priorities Produce both deliverables (see below) ready for internal review by end of week 2 Week 3: Client-facing availability Available for 3-5 calls with the end client team as a technical resource This includes presenting findings, answering architecture questions and participating in working sessions You will be introduced as part of the delivery team, professional, client-facing communication is essential Deliverable 1: Travel Data Cloud Architecture Blueprint A structured written document covering: Current State Assessment Review of existing Notion docs, current BigQuery/Fivetran setup and data flows from the travel retailer network Gaps and risks identified against best-practice data cloud architecture Recommended Data Architecture Ingestion, storage, transformation and serving layers — GCP-first assumption to be validated How data from 30+ travel retailers with different cloud stacks (GCP, AWS, Azure) is ingested and unified at network level Federated data and zero-copy architecture options — where data stays at source vs moves to a central layer, with privacy and performance trade-offs clearly articulated Clean Room Approach Recommended option across GCP Data Clean Rooms, Snowflake Clean Rooms or AWS Clean Rooms Rationale covering: DPO/data privacy compliance, time to value, match rates, and what level of client technical maturity each option requires How clean room selection maps to the consent and data sharing framework needed to onboard travel retail clients into the network Client Integration Tiers Recommended approach for onboarding travel retail clients at different levels of technical maturity Tier model based on existing cloud stack (GCP, AWS, Azure), DPO process complexity and data sharing appetite What connectors, APIs or pipelines are needed at each tier Three Use Case Architecture How the platform architecture supports each use case: monetisation, attribution and intelligence layer What needs to be built or configured differently for each Dependencies between use cases and recommended sequencing MVP vs Full Network Play Clear distinction between what needs to be built to monetise a single travel retail client quickly (e.g. single brand audience activation) versus the full multi-retailer network architecture What can be deferred without creating technical debt Format: Written document with architecture diagrams where appropriate. Minimum 10–12 pages. Deliverable 2: Prioritised Decision Log A concise, structured document covering the key technical decisions that must be made before build begins, in priority order: Each entry should include: The decision to be made Options available Trade-offs for each option Recommended path with rationale What this decision unlocks or unblocks Decisions must include (at minimum): Cloud provider selection and commitment strategy (GCP vs multi-cloud) Clean room technology selection Federated vs centralised data architecture Client data ingestion approach by tier Consent and data sharing framework design Identity resolution and match rate approach MVP scope on single client fast vs network foundation first Build vs buy decisions for key components (ingestion, transformation, activation layer) Vendor negotiation and credits strategy (Google Cloud, Snowflake, AWS) Decisions should be sequenced so the document can be used directly as the basis for a Google Cloud technical workshop. Format: Structured table or log, clean and exportable. Written for both technical and non-technical stakeholders. Skills Required GCP (BigQuery, Dataflow, Pub/Sub, Looker, Data Clean Rooms) Data architecture and cloud infrastructure design at network/platform scale Clean room technologies, GCP, Snowflake or AWS Clean Rooms Federated data architecture and zero-copy patterns Data privacy, consent frameworks and DPO compliance Ad tech, retail media or data monetisation experience, strongly preferred Client-facing communication, you will be presenting to the end client team in week 3 Able to write clearly for both technical and non-technical audiences