SAP CDP

What is SAP Customer Data Platform?

SAP Customer Data Platform is SAP’s real-time customer data platform: it ingests data from commerce, service, marketing, and ERP sources, resolves identities across anonymous and known touchpoints, and activates unified, consent-compliant profiles across every connected channel. The official product page and the SAP Help Portal documentation are the canonical references.

Spadoom designs the data models, ingestion pipelines, and activation flows behind SAP CDP for clients in Switzerland, Germany, Austria, and Italy. Below: what we deliver, how CDP differs from Customer Identity (CIAM), and where the value of a CDP typically comes from.

What Spadoom delivers

A Customer Data Platform is only valuable if the data inside it is trustworthy. Most CDP projects fail at the data layer: poor source mapping, inconsistent identifiers, incomplete consent capture.

Every Spadoom CDP project starts with a data audit. We sit with your engineering and marketing teams and map every customer touchpoint: what data it generates, how it is structured, where identifiers exist, and what needs transforming before ingestion. We document gaps. We flag consent blind spots. Only then do we configure the platform.

This approach is slower up front and significantly faster overall. It eliminates the rework cycles that plague CDP rollouts where teams skip the audit and start connecting sources on day one.

As an SAP Gold Partner with offices in Zug (headquarters) and Wädenswil, plus Cornate d’Adda near Monza (Italy), Vienna and Tallinn, we deliver CDP projects across the DACH region, Italy, and broader Europe. Our delivery follows the SAP Activate methodology across five phases (discovery, preparation, exploration, realisation, and deployment), adapted specifically for CDP scope and complexity.

We are not a platform reseller. We build the data model, the ingestion pipelines, the identity rules, and the activation flows. Then we train your team to run it.

The ERP side of the customer profile

A unified profile is only as good as the ERP data behind it: customer master records, orders, invoices, credit status, delivery addresses. When the CDP and the ERP sit with two different vendors, mismatched customer numbers and missing order history turn into tickets that bounce between them. Spadoom delivers SAP S/4HANA Public Cloud and the SAP CX products with one team, so the ERP side of the data model is mapped in the same audit as the CX side instead of being someone else’s problem. Where a flow needs custom logic, we build it on SAP BTP. If your ERP is itself about to move, our ERP and CX transformation guide shows how the two tracks fit together.

CDP vs Customer Data Cloud: which is which?

CDP and Customer Identity (CIAM, formerly part of SAP Customer Data Cloud) sound similar and are often confused. They solve different problems and most enterprises end up needing both.

Think of Customer Identity (CIAM) as the front door. It answers “who is this person, how do they prove it, and what did they consent to?” That covers registration, login, social sign-in, password reset, consent capture, and preference management. It owns the moment a stranger becomes a known customer.

Think of Customer Data Platform (CDP) as the engine room. It answers “what has this person ever done with us, what do they look like as a unified profile, and which audiences should we activate?” That covers ingestion from commerce, service, marketing, ERP and third parties; identity resolution across anonymous and known touchpoints; segment building; and pushing to channels in real time.

Historically SAP grouped both capabilities under the SAP Customer Data Cloud (SAP CDC) umbrella. Since then SAP has split the offering into discrete products (Customer Identity for the CIAM job, Customer Data Platform for the unification and activation job), so you can buy, scope, and scale each one on its own terms. In a typical SAP CX architecture, CIAM feeds registration and consent events into CDP, and CDP feeds enriched profiles back to Sales, Service, Commerce, and SAP Engagement Cloud (formerly Emarsys).

Where the value comes from

CDP projects should pay for themselves. If yours does not, something went wrong in scoping or execution. This is where the value of a CDP typically comes from:

• Less campaign waste. When you suppress recently converted customers and deduplicate audiences, you stop paying to advertise to people who already bought. The saving shows up in media spend, so it is straightforward to measure.
• Personalisation based on real behaviour. Unified profiles mean SAP Engagement Cloud and your commerce engine see real behaviour, not partial snapshots. Customers who were previously split across systems become addressable as one person.
• Segment activation in minutes, not days. Marketers build and push segments from the CDP interface without filing a ticket. The step from business idea to live campaign no longer waits for an engineering queue.
• Fewer duplicate customer records. Identity resolution merges fragmented profiles. Your CRM, service desk, and marketing platform stop treating one customer as three separate people.

Want to model the numbers for your business? Use our ROI calculator to estimate the impact before the project starts.

SAP CDP in the SAP CX context

SAP Customer Data Platform is the connective tissue of the SAP CX suite. When it is properly implemented, every connected product gets better.

SAP Engagement Cloud receives richer segmentation data. Campaigns target audiences built from unified profiles, not siloed email lists. Suppression works because SAP Engagement Cloud knows what happened in commerce and service, not just in past email sends. Read more in our deep dive on Engagement Cloud and CDP integration.

SAP Sales Cloud V2 agents see customer lifetime value, recent support tickets, and marketing engagement alongside pipeline opportunities. They walk into calls with context instead of guessing.

SAP Service Cloud V2 agents see a customer’s full purchase history, loyalty tier, open marketing offers, and past interactions, in one screen. Resolution times drop because agents stop asking customers to repeat themselves.

SAP Commerce Cloud uses CDP segments for on-site personalisation. Product recommendations, pricing rules, and content blocks respond to the unified profile, not just the current session cookie.

SAP Customer Identity (CIAM) provides the authentication and consent layer that feeds CDP. Registration events, consent updates, and preference changes flow into CDP in real time. For detail on how these two systems divide responsibility, read our CDP vs CDC comparison.

SAP Loyalty Management shares points balances, tier status, and reward redemptions with CDP. This data enriches profiles and enables loyalty-aware segmentation across all channels.

If you are running multiple SAP CX products, a CDP implementation multiplies the value of each one. If you are only on one product today, CDP is the foundation that makes the next one fast to deploy.

Identity resolution

Identity resolution is the hardest part of a CDP implementation. It is also the part that delivers the most value. Get it wrong and your unified profiles are fiction. Get it right and every downstream system benefits.

SAP CDP supports two approaches:

Deterministic matching links records that share an exact identifier: email address, phone number, loyalty ID, CRM account number. This produces high-confidence merges. It is the backbone of identity resolution and handles most matches in a typical deployment.

Probabilistic matching fills the gaps. It uses behavioural signals, device fingerprints, and fuzzy attribute matching to link records that likely belong to the same person. Confidence scores determine whether a merge happens automatically or gets flagged for review.

Spadoom configures merge policies that define which source wins when two records conflict. Your CRM says the customer is in Zurich; your commerce platform says Basel. Merge policies resolve this based on source trustworthiness and recency, not random chance.

The practical impact: fewer duplicate profiles once identity resolution is live, measured against the baseline from the data audit. That means fewer wasted marketing impressions, more accurate lifetime value calculations, and service agents who see the real history.

Real-time activation

Batch data loads are necessary but not sufficient. The highest-value CDP use cases depend on real-time event processing.

SAP CDP ingests streaming events (page views, cart additions, form submissions, service interactions, app events) and updates the unified profile within seconds. This powers three categories of use case:

Cart abandonment and browse recovery. A customer adds a product to their cart on your commerce site and leaves. Within seconds, CDP updates the profile and pushes the event to SAP Engagement Cloud. The abandonment email fires while the intent is still warm, not 24 hours later from a batch sync.

Real-time lead scoring. A prospect visits your pricing page, downloads a whitepaper, and opens a recent email. Each event updates the lead score in CDP. When the score crosses a threshold, CDP pushes the enriched profile to Sales Cloud V2 as a hot lead. The sales rep sees it in their queue within minutes.

Service context enrichment. A customer contacts support after placing an order and browsing the returns page. The CDP profile, updated in real time, tells the Service Cloud V2 agent what happened before the customer explains. Resolution is faster. The customer feels understood.

Spadoom configures the event pipeline architecture during the discovery phase. We define which events matter, how they map to the data model, and what activation rules trigger downstream actions.

What non-SAP data looks like

Many of our clients have customer data spread across non-SAP systems. SAP CDP handles these through standard API ingestion, pre-built connectors, and streaming integrations.

Salesforce CRM. Accounts, contacts, opportunities, and activities sync into CDP via API connectors. We map Salesforce fields to the CDP data model and configure bidirectional sync where needed.

Shopify and other commerce platforms. Orders, customer records, and browsing events flow into CDP. This is common for clients running SAP for B2B and Shopify for B2C, and CDP unifies the customer across both.

Custom APIs and mobile apps. Any system with a REST or webhook endpoint can push events to CDP. Mobile app SDKs capture in-app behaviour (screen views, feature usage, in-app purchases) and stream it to the unified profile.

Data lakes and warehouses. BigQuery, Snowflake, Azure Synapse, Amazon Redshift: CDP ingests batch exports from any of these. This handles historical data loads and periodic enrichment from analytics systems.

We scope every non-SAP integration as part of the project plan. Data format mapping, authentication, rate limits, error handling, and monitoring are all defined before development starts. There are no surprises at go-live about what can and cannot be connected.

Connecting non-SAP sources raises a follow-up question: does this data belong in CDP or CDC? Our guide to SAP CDP vs CDC helps you draw that line before the project starts.

The integration advantage

A CDP is not a standalone product. Its value compounds with every system connected to it.

One data source in CDP gives you a clean profile store. Two sources give you identity resolution. Three sources give you segments that actually reflect customer behaviour. Four or more sources give you a single customer view that no individual system can produce on its own.

This compounding effect is why we treat CDP as infrastructure, not as an application. It sits between your operational systems and your activation channels. It does not replace your CRM, your marketing platform, or your commerce engine. It makes all of them better by feeding them unified, consent-compliant, real-time customer data.

The practical implication for project planning: CDP value scales with the number of connected sources. Start with your two or three highest-value sources, typically CRM, commerce, and marketing. Prove the ROI. Then expand. Each additional source is faster to connect because the data model and identity rules already exist.

For a detailed look at how CDP fits into the broader SAP CX architecture, read our SAP CDP deep dive.

What good looks like

At project start we agree targets for four dimensions and measure them six months after go-live:

Data quality. Duplicate profiles are down against the audit baseline. Consent coverage for active customers is known and tracked. Data freshness targets are met: real-time events land within seconds, batch sources sync within their defined windows.

Marketing efficiency. Campaign audience overlap drops because segments are built from unified profiles, not siloed lists. Suppression rules work across channels. Cost-per-acquisition falls because you stop spending on already-converted customers.

Sales and service context. CRM users in Sales Cloud V2 and Service Cloud V2 see the unified profile without switching systems. Agents reference purchase history, marketing engagement, and loyalty status from one screen. Customers stop hearing “Can you tell me your order number again?”

Operational independence. Marketing teams build and activate segments without filing engineering tickets. Getting from “we need this audience” to “it’s live in SAP Engagement Cloud” no longer depends on a developer. New data source onboarding follows a documented, repeatable process, not a custom project every time.

If your current setup does not deliver these outcomes, the gap is either in your data architecture or your implementation approach. Wondering whether a CDP belongs in your roadmap now or later? Our planning guide lays out the decision framework we use with clients. Or estimate the financial impact before the project starts.