Indonesia Singapore ไทย Pilipinas Việt Nam Malaysia မြန်မာ ລາວ
← Back to Blog

Why Your Data Stack Is Two Decisions Dressed as One

Separating compute approval from transformation logic lets marketing teams own the definitions that actually drive personalisation decisions.

Editorial illustration of a data architect separating two tangled cables connected to different machines
Illustrated by Mikael Venne

Most execs approve compute and transformation logic as one budget line. Here's why that confusion is costing your CDP its licence fee.

Your CDP is only as good as the logic sitting upstream of it. And right now, most organisations are treating that upstream logic as an afterthought — bundled into a compute contract that the CFO approved because the vendor had a good slide deck.

A quietly sharp piece from dbt’s Daniel Poppy puts it plainly: your compute platform and your transformation logic are two separate decisions. Most executives approve them as one. That conflation is precisely why so many customer data platforms feel like expensive data warehouses with a prettier UI — because the definitions that should make them intelligent were never properly built.

Compute Moves Data. Transformation Gives It Meaning.

Databricks, Snowflake, BigQuery — these platforms are extraordinary at processing data at scale. They are not, by design, opinionated about what a “loyal customer” means for your brand, or whether a user who browsed three product pages in a Shopee session should qualify for a win-back sequence. That interpretive layer is the job of transformation logic, and it belongs in a separate, version-controlled, team-owned layer — typically dbt in modern stacks.

The practical implication for CDP deployments across Southeast Asia is significant. A telco in the Philippines running Segment on top of a Databricks lakehouse still needs someone to define, in code, what constitutes an “active subscriber” versus a churner showing early signals. If that definition lives only in a BI tool filter or an analyst’s muscle memory, it will drift — and your activation campaigns will quietly target the wrong people for months before anyone notices.

Ownership of transformation logic should be a named responsibility on your data team, not a shared assumption.

Alert Fatigue Is a Data Quality Problem in Disguise

Here’s a failure mode I see constantly in mid-market CDP implementations: the monitoring layer gets bolted on last, configured broadly, and then promptly ignored because it fires too often. Monte Carlo’s recent writeup on their Triage Agent surfaces the underlying dynamic — when every alert carries the same urgency, whether it’s a freshness break on a critical revenue table or a volume dip on a staging table nobody queries, teams stop acting on any of them.

For unified customer profile work, this matters more than it might seem. A silently broken behavioural event feed — say, Grab Food purchase data failing to land for 48 hours — doesn’t throw an error your team will catch. It just quietly distorts your recency scores and suppresses a cohort from activation. By the time someone notices conversion rates slipping, you’re debugging a fortnight of corrupted audience segments.

The fix isn’t more monitoring. It’s tiered monitoring: classify your data assets by their impact on downstream activation, and route alerts accordingly. Revenue-adjacent tables get human eyes within the hour. Staging tables get a weekly digest. This is a configuration decision, not a tooling purchase.


The Hidden Cost of Treating Your Stack as Infrastructure

There’s a mindset problem underneath all of this. When data infrastructure is approved as a single capital line — “the Databricks contract” — it gets managed like infrastructure: procured, deployed, and largely left alone. Transformation logic, which should be living and evolving as your understanding of customer behaviour matures, gets frozen at whatever state it was in when the initial build wrapped.

This is why CDP licence fees get questioned at renewal. The platform hasn’t delivered ROI not because the platform is wrong, but because the definitions feeding it were written once in 2024 and haven’t been touched since. A customer who was “high-value” by 2024 criteria may be churning by 2026 criteria — but your segments don’t know that yet.

The brands getting the most from unified customer profiles in Southeast Asia — and I’m thinking specifically of regional e-commerce players who’ve cracked cross-border personalisation — treat transformation logic as a product, not a project. It has an owner, a roadmap, and a release cadence. The compute platform is the engine. dbt, or whatever transformation layer you use, is the steering.

Distributed Execution Is Closer Than You Think

A more technical note worth flagging for data architects considering federated or multi-region CDP deployments: the tooling for running SQL concurrently across distributed data sources is maturing fast. Thomas Reid’s recent experiment with DuckDB via Quack — executing queries simultaneously across three remote DuckDB instances — points toward an architecture pattern that’s increasingly viable for teams managing data residency requirements across, say, Thailand, Indonesia, and Vietnam simultaneously.

For Southeast Asian brands navigating PDPA, UU PDP, and PDPC obligations across markets, the ability to keep data local while still building a unified analytical layer is not a distant ambition. The compute primitives are arriving. The harder work, as always, is agreeing on what the data means once you can access it — which brings us back to transformation logic, and the importance of owning it deliberately.


Key Takeaways

  • Separate the budget and ownership of compute platforms from transformation logic — they serve different functions and require different governance cadences.
  • Tier your data monitoring by downstream activation impact, so alert fatigue doesn’t silently corrupt your audience segments.
  • Treat your transformation layer as a living product with a named owner and a release roadmap, not a one-time build deliverable.

The organisations that will extract compounding value from their CDPs over the next three years aren’t necessarily the ones with the most sophisticated compute contracts. They’re the ones who’ve been precise and disciplined about what their data means — and who owns the right to change that definition. The question worth sitting with: who in your organisation has the authority, and the accountability, to update what “customer” means when the market shifts?


At grzzly, we spend a lot of time helping brands in Southeast Asia untangle exactly this — auditing what’s living in the transformation layer, what’s quietly drifting, and what’s blocking their CDP from earning its keep. If your unified profile feels like it’s producing outputs that don’t quite match what your commercial teams are seeing in market, that’s usually where we start. Let’s talk

Velvet Grizzly

Written by

Velvet Grizzly

Architecting the unified customer profile — stitching together behavioural, transactional, and declared data into platforms that actually earn their licence fee.

Enjoyed this?
Let's talk.

Start a conversation