The Evolution of Customer Data Platforms from SaaS Solutions to Google Cloud Infrastructure

The modern digital landscape is characterized by a deep fragmentation of the user journey. A customer might start interacting with a brand through a mobile app, continue exploring the product on a work laptop browser, and complete the transaction from a smart TV or tablet. The situation is complicated by browser privacy policies (like Apple’s ITP), the widespread use of ad blockers, and the regular clearing of cookies. As a result, the database records not a single real buyer, but a set of disconnected anonymous sessions with no obvious link to each other.

The solution to this problem is a Customer Data Platform (CDP) and its key mechanism—Identity Stitching. This is the process of creating a deterministic graph where the nodes are various identifiers (cookie, device_id, email, phone number) and the edges are the facts of their joint use. The ultimate goal of the algorithm is to consolidate all identifiers into a single canonical_user_id. Historically, this task was handled by closed commercial SaaS platforms, but by 2026, the technological trend has shifted towards deploying modular architectures within companies’ own cloud environments.

Chapter 1. The Business Logic of Identity Stitching and Use Cases

Identity Stitching is not an abstract technical procedure, but the foundation for correctly calculating key financial metrics. Without understanding that a series of anonymous clicks and the final purchase belong to the same person, a business gets distorted data on Customer Acquisition Cost (CAC) and Lifetime Value (LTV). Marketing budgets are allocated blindly, and personalization systems offer users products they have already purchased.

The scope of this technology covers most modern digital markets. In e-commerce, stitching is necessary for the correct attribution of advertising channels and loyalty program management. In the financial sector, it provides a seamless transition for the client between a bank’s website and its mobile app. In the media industry, Identity Stitching algorithms control access to paid content by tracking the limits of free views before a user logs in.

Real Case: Optimizing LTV in the British Travel Sector

A large travel agency in the UK faced apparent inefficiency in mobile traffic. Analytical reports showed that advertising expensive safari tours on mobile social networks generated clicks but did not bring in transactions. After implementing an identity stitching system that linked authorizations on mobile devices with subsequent purchases on desktops, it turned out that 65% of clients chose tours from their smartphones and paid for them later from their home computers. Restoring the broken user journey allowed the company to avoid shutting down its most profitable traffic acquisition channel.

Chapter 2. Market Analysis of Commercial CDPs in 2026

For many years, off-the-shelf SaaS solutions (Packaged CDPs) remained the industry standard. They offer a quick start and user-friendly visual interfaces, but require transferring all raw data to a third-party vendor’s servers. As traffic volumes grow, many companies begin to face the strict limitations of commercial platforms.

Platform	Strengths	Weaknesses	Pricing Model	Optimal Use Case
Segment (Twilio)	Intuitive interface, hundreds of ready-made integrations (Destinations). Marketers can manage data flows without involving developers.	Billing is based on the MTU (Monthly Tracked Users) metric. The stitching logic is a closed system; its algorithms cannot be adjusted to the specifics of a particular business.	From $1,500/month, exponential growth with an increase in the share of anonymous traffic.	Fast-growing companies with sufficient venture funding and a lack of their own engineering expertise.
mParticle	Deep specialization in mobile platforms (iOS/Android). Powerful SDKs capable of processing events offline with subsequent synchronization.	Excessive architectural complexity for web-heavy projects. Closed source code and lack of transparency in internal data transformations.	Enterprise segment (estimated from $3,000/month).	Large mobile ecosystems: taxi aggregators, food delivery services, fitness apps.
Tealium	Broad real-time capabilities. Reliable integration with legacy corporate enterprise resource planning systems.	Extremely high entry barrier requiring lengthy staff training. One of the highest Total Costs of Ownership (TCO) on the market.	Enterprise contracts (from $5,000/month).	Financial corporations and insurance companies with complex legacy IT infrastructure.
RudderStack	Hybrid architecture. The platform collects and routes events, but physical data storage takes place in the client’s cloud data warehouse.	Despite having control over the warehouse, data collection and routing processes still depend on the vendor’s servers.	Payment for the volume of routed events (from $800/month for the cloud version).	Medium-sized businesses transitioning to data ownership but not ready to build a routing system from scratch.
Hightouch / Census	These are Reverse ETL platforms. They do not collect data or stitch profiles; they extract ready-made segments from the client’s warehouse and send them to marketing tools.	Complete lack of built-in Identity Stitching mechanisms. Require an already formed profile graph in the database.	Payment per number of connectors or active syncs (from $500/month).	Mature data teams that implement SQL logic independently and only need an integration layer with external APIs.

Real Case: The MTU Trap in the US Media Business

An American news platform with about 4 million unique monthly visitors integrated a commercial CDP. However, the number of authorized subscribers was only 60,000. The vendor’s platform billed all traffic based on the MTU model, issuing invoices exceeding $10,000 monthly. Paying for processing millions of anonymous users who read one article and left the site made the SaaS solution economically unviable, which triggered the transition to their own architecture.

Chapter 3. Designing a Custom CDP on the Google Cloud Ecosystem

The realization of the financial and architectural inefficiency of classic CDPs led to the popularization of the Composable CDP—a component-based approach where the data management center is moved to the company’s own cloud. The Google Cloud Platform (GCP) ecosystem provides a full stack of services to implement such a solution, covering stages from streaming data collection to its final activation.

Layer 1: Routing and Data Ingestion

The process starts with a complete refusal to send data to third-party analytics platform servers. Google Tag Manager Server-Side (GTM SS) is deployed as a single entry point. To ensure high availability and auto-scaling, GTM SS is hosted on Google Cloud Run. Events from the website or app flow into Cloud Run, where they are cleaned of junk parameters. Then, the data can be written directly to BigQuery (for batch analytics) or routed through a message broker, Google Cloud Pub/Sub, if the architecture requires near real-time event processing.

Layer 2: Storage and Transformation

Raw data lands in Google BigQuery, which acts as the fundamental single source of truth. It is important to understand that the raw event log is immutable. The transformation and the Identity Stitching process itself are implemented using Dataform, an orchestration tool natively integrated into GCP.

The algorithm’s workflow in Dataform is broken down into sequential SQL models:

1. Creating an identifier dictionary by finding pairs (for example, capturing a user_login event where cookie_id and crm_email are present simultaneously).
2. Resolving conflicts and assigning a unique canonical_user_id to the discovered clusters.
3. Generating analytical Views, where historical events of anonymous devices are enriched with the canonical identifier of the authorized user.

Layer 3: Security and Activation

Access to the collected graphs is strictly regulated through Cloud IAM (Identity and Access Management). Once profiles are stitched, they must be returned to the business environment. To allow marketers to activate segments, a BI platform like Looker can be connected. To push ready audiences to advertising networks (Google Ads, Meta), Google Cloud Functions are used. The logic of these functions, often written in C# (.NET) or Python, allows them to extract segments from BigQuery on a schedule and interact with external APIs, completely closing the data loop within a single cloud perimeter.

Real Case: Synchronizing the Deal Cycle in B2B

An American industrial equipment supplier used GCP to integrate web analytics with its CRM system. The company’s deal cycle took weeks: clients studied specifications on the website and placed orders through a call to a manager. Engineers set up the export of deal statuses from Salesforce to BigQuery via Cloud Functions. Dataform scripts linked the email addresses from the contracts with the session identifiers on the website. As a result, marketing obtained a deterministic picture of exactly which online catalogs generated multi-million-dollar offline contracts.

Chapter 4. Cloud Architecture Economics: Calculating the Total Cost of Ownership

Let’s look at the financial model of implementing a GCP architecture using the example of a US e-commerce retailer. The company manages a catalog of outdoor gear, generating about 2.5 million unique visitors and 50 million events per month. Using a commercial CDP cost the business about $90,000 per year. Moving the infrastructure to Google Cloud fundamentally changes the cost structure.

1. Storage (BigQuery Storage): 50 million events per month convert to roughly 60 gigabytes of raw data. The cost of active storage in BigQuery is minimal, sitting at about $1.50–$2.00 per month.
2. Compute (BigQuery Compute): This is the main expense item. It includes the daily execution of the Identity Stitching graph, dictionary recalculation, and updating incremental tables in Dataform. With optimized SQL queries, costs range from $200 to $400 per month.
3. Routing (Cloud Run & Pub/Sub): Maintaining servers for GTM Server-Side and event transit will cost the business about $100–$150 per month, scaling smoothly during peak loads.
4. Activation (Reverse ETL / Cloud Functions): Executing cloud functions to export audiences or using a third-party connector adds about $500 per month to the budget.

The total monthly cost of ownership for a custom CDP is around $1,000, which equals $12,000 per year. The transition to GCP frees up over $75,000 annually. The company can reinvest these funds into hiring specialized data analysts, gaining unlimited access to historical data without worrying about vendor pricing limits.

Chapter 5. Legal Compliance: Managing Personal Data (CCPA/GDPR)

Consolidating data into a single data warehouse requires strict compliance with privacy laws, such as CCPA in the US or GDPR in Europe. A key requirement is ensuring the “Right to be Forgotten”—the ability to completely delete user information upon request. In commercial CDPs, the deletion process is opaque: a company clicks a button in the interface but cannot guarantee the physical erasure of data from the provider’s servers.

In the Google Cloud architecture, this problem is solved using the Crypto-Shredding pattern. The logic involves a strict physical separation of behavioral data and Personally Identifiable Information (PII):

1. All personal data (email, phone number, full name) is stored in a separate, isolated BigQuery table, access to which is restricted by Cloud IAM policies and protected by encryption keys via Cloud KMS (Key Management Service).
2. The massive tables containing event logs store cryptographic hashes (like SHA-256) rather than plain-text email addresses.
3. When a legal deletion request is received from a user, engineers do not scan terabytes of logs. They delete a single row linking the specific hash to the personal data in the PII table and destroy the corresponding encryption key.
4. After this, trillions of behavioral event rows permanently lose their connection to a real person, turning into completely anonymous statistics safe for machine learning and analytics.

Real Case: Automating CCPA in a FinTech Startup

A financial app faced the need to process dozens of account deletion requests daily. Previously, executing DELETE queries across all historical tables heavily loaded the database and led to high compute costs. Implementing the Crypto-Shredding concept reduced the deletion procedure to erasing a single record in the master PII table. The process began to take fractions of a second, consumed zero warehouse computing resources, and guaranteed full compliance with regulatory requirements.

Chapter 6. Architectural Limitations and Trade-offs of a Custom Build

Developing your own platform on GCP is not a universal, flawless solution. Designing the system requires acknowledging serious architectural limitations; ignoring them will lead to data degradation.

1. Processing Latency (Batching vs. Streaming): BigQuery and Dataform are designed for batch processing. If business logic requires changing the website interface milliseconds after user authorization, a batch SQL graph will be useless. Implementing real-time scenarios requires complicating the architecture: introducing stream processing via Dataflow and storing hot profiles in in-memory databases (e.g., Redis).
2. Vulnerability to Super-Nodes: The stitching algorithm is vulnerable to frontend anomalies. If a technical error causes the system to assign the same default device_id to a thousand unique visitors, the deterministic graph will merge them into one giant profile. This will lead to an exponential increase in SQL query execution costs and the destruction of analytics. Dataform requires strict safeguards to filter out identifiers with an abnormally high number of edges before graph construction begins.
3. Maintaining Technical Debt: Owning the code means owning the problems. Any changes in the CRM database structure or event tracking formats from the frontend can cause Dataform pipelines to crash. Maintaining system uptime falls entirely on the shoulders of the internal data engineering team, making them a critical single point of failure.

Real Case: The Consequences of Probabilistic Modeling

An educational platform in the US tried to expand its stitched profile base by adding Probabilistic Stitching logic into the SQL graph—merging users based on matching IP addresses and browser versions. In the realities of 2026, using IP addresses is akin to random guessing. The algorithm linked hundreds of students connected to a single university campus Wi-Fi network into one super-user. Marketing triggers started sending students the contents of other people’s abandoned carts. The incident required an emergency rollback of the pipeline to strict deterministic logic based on direct authorizations.

Chapter 7. Engineering Standards of Implementation (Practical Guide)

For teams deciding to deploy an Identity Stitching architecture within Google Cloud, there are several mandatory technical standards that ensure system stability and cost-effectiveness:

• Partitioning and Clustering: Raw event tables in BigQuery must be partitioned by date (event_date) and clustered by the identification key (client_id or user_id). Executing a JOIN operation during graph traversal without partitioning will result in a Full Table Scan, multiplying the cost of every query.
• Incremental Computing: A full recalculation of the graph from scratch (Full Refresh) is acceptable only during the initial setup phase. In a production environment, Dataform models must be of the incremental type. The daily run should process only the events that entered the system in the last 24 hours, appending the existing graph rather than rewriting it.
• Isolating Raw Data: A fundamental rule of data engineering states that raw event logs are never updated directly. The output of the graph execution should be a separate flat mapping table (Mapping Dictionary) that links historical cookies to verified profiles. This table is applied to the logs exclusively during the creation of analytical views.
• Hardware Hypothesis Testing: The Dataform toolkit allows the use of assertions blocks. Before the final table build, the pipeline must enforce core business rules. For example, checking that one canonical_user_id is always unique and does not duplicate records in the transaction table. If the check fails, the build stops, preventing distorted data from reaching top-management dashboards.

Creating a custom CDP based on Google Cloud Platform requires high engineering discipline and a deep understanding of domain logic. However, this is exactly the path that allows companies to transition from renting infrastructure to fully owning their data, ensuring maximum flexibility, security, and economic efficiency in the long run.