Platform Fit Deep Dive

Multi-Cloud Orchestration.

Solving enterprise data collaboration when the brand uses Snowflake, Databricks, AWS, Google / ADH, BI, CDPs, DSPs, and activation systems at the same time.

Large brands rarely have one data collaboration environment. Customer data, media exposure, identity, transaction history, event streams, analytics, models, and activation paths often live across several clouds and platforms. The job is not to force every workflow into one system. The job is to define which environment owns which part of the decision.

The product is not multi-cloud data movement. The product is multi-cloud decision orchestration.

DECISION ORCHESTRATION Snowflake — a cloud data warehouse environment in the mix. Snowflake Databricks — a lakehouse environment in the mix. Databricks AWS — a cloud platform environment in the mix. AWS Google / ADH — an ads data hub / clean-room environment in the mix. Google / ADH Orchestration layer — the decision router. It decides which environment owns which part of the decision, then governs the single output. ORCHESTRATION LAYER decides who owns the decision Governed decision — one consistent output, regardless of which environment did the work underneath. Governed decision one consistent output Not data movement — decision orchestration.
Map the orchestration model → Run the 5-minute assessment → See what the work produces →
Executive summary

It is an operating model, not a platform pick.

If a brand is using multiple clouds, the right answer is rarely "pick one platform." The right answer is an operating model: where the data stays (its data gravity), where logic runs, what outputs can move, what governance applies, and which team owns the workflow.

  • Keep data near its gravity point unless there is a clear reason to move it.
  • Move logic, models, permissions, or approved outputs before moving raw data.
  • Assign platform roles by decision type, not vendor preference.
  • Define output policy before running the POC.
  • Create one orchestration model across privacy, product, data science, media, and commercial teams.
What you get

What the orchestration work produces.

The model is not a slide. These are the artifacts an orchestration engagement actually builds — the operating system for the decision, not a vendor bake-off.

  1. Data gravity map

    Where each source lives, who owns it, and what can move.

  2. Platform role assignment

    Which environment owns governance, collaboration, measurement, modeling, activation, or reporting.

  3. Output policy workbook

    What can leave each environment — rows, aggregates, scores, segments, reports, APIs — and under what rules.

  4. Control-plane RACI

    Who is accountable, consulted, and informed across business, data, privacy, media, and measurement.

  5. Use-case registry

    The live decisions the data must improve, scoped and prioritised.

  6. Data / logic / output movement map

    What stays in place, what logic runs where, and what approved output moves.

  7. POC-to-production plan

    Match logic, privacy checks, methodology, owner, and the path past the test.

  8. 90-day operating model

    Cadence, refresh, monitoring, and the commercial package that turns a workflow into infrastructure.

The shape of the problem

A control plane, surrounded by environments.

Each environment plays a role. The orchestration layer — the control plane — decides which one owns which part of the decision.

Multi-Cloud Decision Orchestration A central Collaboration Control Plane surrounded by six platform environments — Snowflake, Databricks, AWS, Google / GMP / ADH, CDP / DSP / RMN, and BI / MMM / analytics — each connected to the control plane by a thin line. Collaboration Control Plane owns the decision Snowflake sharing · marketplace · native apps Databricks governance · discovery · AI/BI AWS S3 · Clean Rooms · AMC Google / GMP / ADH media exposure · ADH · BigQuery CDP / DSP / RMN activation · suppression · audiences BI / MMM / analytics reporting · forecasting · incrementality
  1. Collaboration Control Plane — owns the decision
  2. Snowflake sharing · marketplace · native apps · clean rooms
  3. Databricks governance · discovery · AI/BI · agents
  4. AWS S3 · Clean Rooms · AMC · IAM · ML
  5. Google / GMP / ADH media exposure · ADH · BigQuery · DV360
  6. CDP / DSP / RMN activation · suppression · audiences
  7. BI / MMM / analytics reporting · forecasting · incrementality

CDP / DSP / RMN and BI / MMM are two of the environments around the control plane — and each activation, measurement, and decision surface has its own deep dive. Open the Ecosystem Surfaces cluster →

Core framework

Five questions before any platform decision.

  1. 01

    What decision needs to improve?

    Suppression, activation, measurement, overlap, frequency, enrichment, LTV, forecasting, planning, or partner evaluation.

  2. 02

    Where does the data already live?

    Customer, transaction, exposure, identity, media, event, and outcome data may each have different gravity points.

  3. 03

    Where should the logic run?

    Sometimes compute moves to data. Sometimes data moves to compute. Often, only the approved query, model, or application should move.

  4. 04

    What output is allowed?

    Rows, aggregates, model scores, segments, reports, APIs, dashboards, or activation instructions each require different controls.

  5. 05

    Who owns the decision?

    Media, analytics, CRM, product, finance, data science, legal, privacy, and sales may each need a different version of the workflow.

Platform role map

Assign platform roles, not platform winners.

A multi-cloud brand does not need one collaboration platform to win. It needs each platform to play the right role.

Data cloud & infrastructure

  1. Snowflake

    Distribution and governed data product packaging

    Best when
    • buyer already works in Snowflake
    • data sharing or marketplace distribution matters
    • clean room or native app packaging is useful
    • provider wants to package data, logic, or workflow close to customer data gravity

    Watch-out: Do not treat a marketplace listing as a GTM strategy by itself.

    Deep dive into Snowflake →

  2. Databricks

    Lakehouse intelligence, governance, AI/BI, and agent-ready workflows

    Best when
    • data and AI assets are heterogeneous
    • governance, discovery, lineage, and semantic curation matter
    • the workflow spans analytics, ML, BI, apps, and agents
    • the buyer needs open data and model workflows

    Watch-out: Do not skip metadata, benchmark, and evaluation work.

    Deep dive into Databricks →

  3. AWS

    Infrastructure-native collaboration and security-controlled workflows

    Best when
    • buyer is AWS-native
    • data gravity sits in S3, Redshift, Glue, or Lake Formation
    • IAM, security, and infrastructure control are central
    • clean room or ML workflow needs to stay inside AWS

    Watch-out: Do not underestimate implementation and solutions architecture effort.

    Deep dive into AWS →

  4. Google / GMP / ADH

    Google media measurement, privacy-safe analysis, and activation path

    Best when
    • use case depends on Google media exposure
    • ADH, BigQuery, DV360, PAIR, or GMP workflows are central
    • buyer needs aggregate privacy-safe measurement
    • output feeds BI, MMM, planning, or media optimization

    Watch-out: Do not force ADH into general enterprise collaboration jobs.

    Deep dive into Google / GMP / ADH →
Specialist, identity & media

  1. InfoSum

    Neutral, non-movement-of-data collaboration between two parties

    Best when
    • neither party will move or pool raw data
    • the counterparty wants a neutral, vendor-independent environment
    • the use case is a governed match-and-measure between two first parties
    • decentralized architecture and non-movement are hard requirements

    Watch-out: Confirm identity, match logic, and output thresholds for your data before committing — validate current support.

    Deep dive into InfoSum →

  2. LiveRamp

    Identity resolution and interoperable match across partners and clean rooms

    Best when
    • the workflow depends on resolving identity across partners
    • collaboration must reach across multiple clouds or clean rooms
    • a durable, interoperable identifier improves match and measurement
    • activation and measurement span more than one environment

    Watch-out: Identity is the connective layer, not the decision — anchor it to a specific output. Validate current support.

    Deep dive into LiveRamp →

  3. Amazon Marketing Cloud

    Walled-garden measurement and activation inside Amazon Ads

    Best when
    • the decision is about Amazon media exposure and outcomes
    • the output is audience insight, measurement, or activation in Amazon Ads
    • signals come from Amazon DSP and Amazon Ads campaigns
    • first-party data can be matched for analysis inside the clean room

    Watch-out: AMC answers Amazon questions — do not stretch it into a general cross-platform measurement layer. Validate current support.

    Deep dive into Amazon Marketing Cloud →

  4. Meta Advanced Analytics

    Meta-specific advanced analytics and signal recovery

    Best when
    • Meta media is material to the decision
    • CAPI and first-party events are important
    • path-to-purchase, overlap, lift, Advantage+, or custom attribution is needed
    • the output improves budget, creative, frequency, or audience decisions

    Watch-out: Meta AA is not a general enterprise clean room, and access is commonly partner-mediated. Use it when Meta signal gravity is central. Validate current access and support.

    Deep dive into Meta Advanced Analytics →
Specialist platforms

Specialist platforms in the control plane.

Specialist clean rooms are not interchangeable. Each plays a distinct role in the orchestration model — and none of them removes the need for output policy, platform role assignment, and governance.

Multi-cloud control plane — specialist clean-room role map The Multi-cloud control plane routes to three specialist roles — InfoSum, LiveRamp, AMC, Meta AA — and every one of them still passes through a shared governance layer: Output policy, Permissions, Activation rights, Measurement, Trust model. Multi-cloud control plane owns the decision InfoSum Non-movement /PET collaboration LiveRamp Identity, activation,measurement AMC Amazon media /retail signal gravity Meta AA Meta media /signal recovery SHARED GOVERNANCE LAYER Output policy · Permissions · Activation rights · Measurement · Trust model
Multi-cloud control plane — specialist role map
  • InfoSum → Non-movement, multi-party collaboration through PET-led Bunkers.
  • LiveRamp → Identity-led activation and measurement across partners and clouds.
  • Amazon Marketing Cloud → Amazon-centered measurement and audience workflows on retail-media signal gravity.
Data movement strategy

Move less data. Move more logic.

The default should be to move raw data only when necessary. Most enterprise workflows work better when the logic, model, query, permission, or approved output moves instead.

  1. 01

    Move logic to data

    Use governed functions, templates, clean room queries, native apps, or model containers when sensitive data should stay in place.

  2. 02

    Move approved outputs

    Export aggregates, scores, segments, measurement results, or decision signals when raw row-level data cannot or should not leave.

  3. 03

    Move identity carefully

    Identity resolution, match keys, HEMs, device graphs, household graphs, and PAIR-like workflows need explicit permission and output rules.

  4. 04

    Move only what can be governed

    If the output cannot be audited, explained, permissioned, or refreshed, it is not ready for production.

The collaboration control plane

One operating model across platforms.

This does not need to be one vendor product. The collaboration control plane is an operating model that defines how decisions move across platforms.

  • Use case registry
  • Business decision owner
  • Source data owner
  • Platform owner
  • Privacy / legal owner
  • Identity rules
  • Consent and permission logic
  • Join rules
  • Semantic definitions
  • Metric definitions
  • Output policy
  • Activation rights
  • Audit and lineage
  • Monitoring
  • Feedback loop
  • Escalation path
  • POC-to-production path
  • Renewal / expansion path

Without a control plane, every clean room, warehouse, dashboard, and model becomes a one-off project.

Operating model

Who owns what — the control-plane RACI.

A control plane is only real when ownership is explicit. This is the default split across the workstreams; tailor the names to the org.

Workstream Accountable Consulted Output
Business decisionCMO / analytics / productMedia, financeApproved use case
Data accessData ownerPrivacy, legalPermitted inputs
Platform roleData platform leadSolutions, vendorPlatform role map
Output policyPrivacy / legalAnalytics, mediaAllowed outputs
ActivationMedia / lifecycleCDP, DSP, RMNDestination rules
MeasurementAnalyticsFinance, mediaMethod and KPI
Output policy is the operating system

Agree on the output before the platform.

Most multi-cloud projects fail because teams agree on the platform before they agree on the output. The output policy defines the risk, the buyer value, the workflow, and the commercial model.

Output type Where it usually belongs Risk question Commercial use
Raw rows Rare; only when rights and use case are clear Can this data legally and safely move? Data licensing or internal analytics
Aggregates Clean room, ADH, BI, MMM, analytics Are thresholds, privacy checks, and methodology clear? Measurement, overlap, reach, frequency, incrementality
Scores Model workflow, ML platform, CDP, warehouse Can the score be explained, refreshed, and governed? Propensity, LTV, churn, qualification, prioritization
Segments CDP, DSP, RMN, DV360, clean room activation path Are activation rights and suppression rules clear? Activation, suppression, retargeting, exclusion
Reports BI, analytics, dashboards, stakeholder workflows Are definitions consistent across teams? Planning, optimization, executive reporting
APIs Apps, agents, product integrations Are permissions, rate limits, monitoring, and fallback rules defined? Automated workflows, embedded intelligence, partner products
Output policy funnel — what is allowed to leave A narrowing funnel — much goes in, a governed output comes out. Stages top to bottom: Raw rows → Governed aggregates → Scores & segments → Reports & measurement → Approved API / activation. Raw rows rarely leave the environment Governed aggregates counts · sums · indices PRIVACY GATE Scores & segments propensities · audiences Reports & measurement BI · MMM · planning Approved API / activation explicit rights only
Output policy funnel — what is allowed to leave
Example patterns

Common multi-cloud patterns.

  1. 01

    Snowflake customer data + Google media measurement

    Customer data stays near Snowflake. Google exposure and campaign data stay in Google / ADH. Approved aggregate outputs move into BI, MMM, or planning workflows.

    Decision improved: Which campaigns, audiences, or partners drove measurable value?

  2. 02

    AWS event lake + Databricks modeling

    Event and product data stay in AWS. Modeling and AI workflows run in Databricks or another governed ML layer. Approved scores or outputs return to activation or analytics.

    Decision improved: Which users, events, or behaviors should trigger action?

  3. 03

    Publisher data + advertiser clean room + activation destination

    Publisher and advertiser data join inside a governed clean room. Only approved overlap, reach, frequency, or segment outputs move downstream.

    Decision improved: Which audience or content signal creates advertiser value?

  4. 04

    Retail data + supplier measurement + BI

    Retail transaction and loyalty data remain governed. Supplier or media data joins through an approved collaboration path. Outputs flow into measurement and supplier planning.

    Decision improved: Which media or retail signal changed commerce outcomes?

  5. 05

    Agentic analytics across governed systems

    Agents do not get broad data access. They use governed tools, semantic definitions, approved APIs, evaluated outputs, and monitored feedback.

    Decision improved: Which business questions can be answered safely without creating shadow analytics?

Worked example

Google analytics lane inside a multi-cloud model.

GA4 / site / app events and Google media exposure may sit in Google / BigQuery / ADH, while CRM, commerce, product, and offline data live in Snowflake, Databricks, AWS, or a CDP. The orchestration model decides which data stays, which logic runs where, and which outputs move to BI, MMM, activation, or CRM.

Layer Google role External role Output
CollectionGA4 / Google Ads / GMP / Firebase eventsCRM / POS / product / CDP / offlineEvent and customer source map
AnalysisBigQuery / Ads Data HubSnowflake / Databricks / AWSGoverned analysis path
MeasurementADH privacy-safe aggregation / Meridian inputsMMM / BI / incrementality frameworksChannel contribution and decision metrics
ActivationDV360 / Google Ads / PAIR where eligibleCRM / CDP / DSP / RMN / owned channelsApproved audience, suppression, or personalization path
LearningLooker / Looker Studio / query refinementEnterprise BI / data science / financeMonitoring and refresh loop

Google / GMP / ADH is strongest when Google media, BigQuery, privacy-safe measurement, and Google activation matter — it is one lane in the model, not the whole journey. Open the Google / GMP / ADH deep dive →

Anti-patterns

Where orchestration goes wrong.

  • Choosing Snowflake vs Databricks vs AWS before defining the output the workflow must produce.
  • Treating ADH or AMC as general enterprise clean rooms instead of ecosystem-specific environments.
  • Moving raw data when a governed output — aggregate, score, segment — would do.
  • Letting each platform team define its own metrics, so dashboards and agents disagree.
  • Running a POC with no owner for production — a demo that never ships.
  • Treating identity resolution as the strategy rather than the enabler.
  • Adding agents on top of unclear data logic and undefined output policy.
First 30 days

A concrete way to start.

Before a platform decision, before a POC — the orchestration engagement starts here.

  1. 01

    Inventory the data estate — sources, owners, locations, sensitivity.

  2. 02

    Identify three live use cases the data should improve.

  3. 03

    Map data gravity — what can move, what must stay in place.

  4. 04

    Identify the platform owners for each environment.

  5. 05

    Define output policy for the first use case.

  6. 06

    Select one POC — narrow, ownable, measurable.

  7. 07

    Assign the control-plane RACI.

  8. 08

    Define the success metric and method up front.

  9. 09

    Decide the production path before the test starts.

POC to production

From POC to production in a multi-cloud environment.

  1. 01

    Define the decision

    Output: Business question, owner, KPI, allowed output

  2. 02

    Map data gravity

    Output: Where each source lives, who owns it, and what can move

  3. 03

    Assign platform roles

    Output: Which platform handles governance, collaboration, measurement, modeling, activation, or reporting

  4. 04

    Design output policy

    Output: Rows, aggregates, scores, segments, reports, or APIs

  5. 05

    Run the POC

    Output: Test workflow, match logic, privacy checks, query logic, methodology, and buyer usability

  6. 06

    Operationalize

    Output: Refresh cadence, monitoring, feedback loop, support owner, commercial package, renewal path

You likely need this when…

Signs the orchestration layer is the work.

  • The brand uses more than one cloud or clean room environment.
  • Teams are debating Snowflake vs Databricks vs AWS vs Google instead of defining outputs.
  • Media, analytics, data science, and legal each own part of the workflow.
  • POCs work technically but fail to become production workflows.
  • Each platform team has its own definitions, metrics, and approval rules.
  • Outputs move downstream without clear governance or activation rights.
  • Agents, AI/BI, or automated workflows are being layered on top of unclear data logic.
When this may be overkill

When a single decision is enough.

  • One-off analysis with no production path
  • Single-platform buyer with a narrow use case
  • Simple data share with clear rights and low sensitivity
  • Internal-only dashboard with no external collaboration
  • No near-term need for activation, automation, or repeatability

Need to map the multi-cloud collaboration model?

The platform decision should follow the output, data gravity, governance model, and commercial motion. This work turns fragmented platform choices into one operating model.

Scope this playbook → Back to Platform Fit → Run the 5-minute assessment →