First-Party Data Flywheels: Build the Loop Before the Platform

Most brands in Southeast Asia have a CDP story that goes roughly like this: procurement approves the platform, the implementation partner lifts existing data pipelines into the new tool, and six months later the data team is maintaining the same broken logic in shinier infrastructure. The flywheel never spins.

LALIGA’s first-party data programme, documented by Tealium, is a useful counter-example — not because football is a special case, but because the flywheel was designed before the platform was chosen.

The Flywheel Comes Before the Platform

LALIGA built its unified fan profile by treating every digital touchpoint — app sessions, video consumption, ticketing, merchandise — as declared or behavioural signal feeding back into a single identity graph. The result is a compounding loop: richer profiles enable more relevant content, which drives deeper engagement, which generates more signal. Tealium reports that this approach improved fan retention and sponsorship yield, because the commercial inventory (audience segments) became genuinely differentiated.

The architectural lesson here is sequencing. The collection mechanism — consent flows, event schemas, identity resolution rules — had to be designed first. The CDP was the vehicle, not the destination. For Southeast Asian brands managing fragmented audiences across LINE OA, Shopee storefronts, and owned apps, this sequencing discipline is the difference between a unified profile and an expensive data warehouse with a dashboard on top.

Before any platform evaluation, map the flywheel: what behavioural signals does each channel generate, what declared data can you legitimately collect at each stage, and how does enriched profile data flow back to improve the next interaction? If you can’t draw that loop on a whiteboard, you’re not ready to procure.

Migration Is Not a Copy-Paste Job

The dbt team’s migration guide published this week makes a point that applies well beyond SQL transformation tooling: lifting and shifting legacy patterns into a new system doesn’t fix the underlying architecture — it just moves the debt. Teams that migrated legacy data models directly into dbt found themselves maintaining the same convoluted joins and undocumented logic, now inside a tool designed for something cleaner.

The same failure mode appears in CDP migrations. A brand running a homegrown customer database with years of accumulated workarounds — duplicate identity keys, inconsistent event naming, channel data siloed by business unit — will reproduce those problems in Segment, mParticle, or any other platform, unless the migration is treated as a redesign, not a transfer.

The practical implication: before migrating to a new CDP or data stack, audit your identity resolution logic and event taxonomy independently of the tooling. Define what a resolved customer profile actually means for your business — which identifiers are authoritative, how you handle anonymous-to-known stitching on mobile-first markets like Thailand or Indonesia where phone numbers often substitute for email — and build the new schema from those definitions. The migration becomes the opportunity to fix the foundation, not just repaint the walls.

---

AI Token Costs Are a CDP Problem Too

Towards Data Science’s analysis of AI financial sustainability this week raised a point that data architects building CDP-adjacent AI features should internalise: inference costs are not fixed, and they scale with query volume in ways that budget owners rarely anticipate at procurement time.

This matters directly for CDPs being extended with AI-driven features — predictive propensity scoring, LLM-generated audience summaries, real-time next-best-action recommendations. Each of these generates token consumption at the profile level, multiplied across your active customer base, multiplied by query frequency. For a brand with 5 million resolved profiles running real-time scoring on purchase intent, the inference bill can dwarf the platform licence within a quarter.

The architectural response is to be deliberate about where AI inference sits in the data flow. Batch-scoring models that run overnight and write propensity scores back to the profile as a static attribute cost a fraction of real-time inference at the point of personalisation. For most Southeast Asian use cases — email segmentation, push notification triggers, paid media audience seeding — batch is sufficient and the cost curve is predictable. Reserve real-time inference for the interactions where latency genuinely changes outcome: in-session recommendation on a Shopee-like storefront, or a live chat triage. Everywhere else, the static attribute is your friend.

The broader point: AI features inside a CDP are not free enrichment. They’re a recurring cost that compounds with data volume, and they need to be architected with the same cost discipline you’d apply to cloud compute.

The Unified Profile Is a Business Asset, Not a Technical Output

The thread connecting LALIGA’s flywheel, the dbt migration principles, and the AI cost question is the same: a unified customer profile only earns its licence fee when it’s treated as a business asset with a defined return, not a technical project with a go-live date.

For Southeast Asian brands, the commercial case is increasingly concrete. First-party data that enables precise audience segmentation reduces dependence on Meta and Google inventory — meaningful as CPMs continue to climb across the region. A well-resolved identity graph enables cross-channel suppression, so you’re not paying to acquire customers you already have. Propensity scores fed from the CDP into Lazada or Shopee ad targeting close the loop between owned data and paid media in ways that third-party audiences simply can’t match.

None of this happens if the flywheel was never designed, if the migration reproduced legacy debt, or if the AI enrichment layer was bolted on without a cost model. The platform is the easy part. The architecture is the work.

---

Key Takeaways

• Design the data collection loop and identity resolution logic before evaluating or migrating to any CDP — the platform should serve the flywheel, not define it.
• Treat CDP migrations as architectural redesigns: audit event taxonomy and identity keys independently, and use the migration as the moment to fix inherited debt rather than transfer it.
• Model AI inference costs at procurement time — batch-scored propensity attributes cover most Southeast Asian personalisation use cases at a fraction of real-time inference spend.

---

As CDPs mature from infrastructure investment to genuine revenue driver, the brands pulling ahead aren’t the ones with the biggest platforms — they’re the ones who defined what a resolved customer profile means for their business before anyone wrote a purchase order. The open question worth sitting with: if your CDP licence disappeared tomorrow, would you know exactly what data architecture you’d need to rebuild, and why?

---

At grzzly, this is the work we do before the platform conversation starts — mapping the data flywheel, defining identity resolution logic, and making sure the architecture earns its keep across every channel a Southeast Asian customer actually uses. If your CDP is underdelivering or you’re about to make a significant data infrastructure decision, Let’s talk.