We had a requirement to implement SSO using Microsoft Entra ID. Here I'll explain the step-by-step process to implement that.

References

What I’ve Learned Designing CDP the Right Way

When teams implement Sitecore CDP, the focus usually goes to personalization use cases, dashboards, and decision models. But in real projects, I’ve seen something different. If your event model and identity strategy are weak, nothing else works properly. Personalization behaves inconsistently. Reports don’t add up. Profiles get duplicated. Consent becomes messy.

So in this post, I want to walk through what actually matters when designing Sitecore CDP — based on what I’ve seen in real implementations.

1. Event Taxonomy Design for Sitecore CDP

Your event taxonomy is your foundation.

If you don’t define it early and clearly, every team will send data differently — and you’ll spend months fixing it later.

Start With Business Intent, Not Pages

A common mistake is modeling events around pages:

• home_page_click
• product_page_click
• checkout_page_click

This ties your data to the UI.

Instead, model around user intent:

• product_viewed
• product_added_to_cart
• checkout_started
• checkout_completed

Now your model works across:

• Web
• Mobile apps
• Email journeys
• Future channels

That’s how you future-proof it.

Naming Conventions

Keep it simple and consistent.

I recommend:

lowercase + underscores + business action

Examples:

• product_viewed
• cart_updated
• form_submitted
• account_logged_in

Avoid:

• Environment prefixes (dev_, prod_)
• Version numbers in event names
• Brand-specific naming unless absolutely required

Let schema versioning handle evolution — not the event name.

Versioning Strategy

Events will evolve. That’s normal.

The mistake is changing them without a plan.

What works well:

• Add a schema_version field inside the payload
• Only add new optional fields
• Avoid deleting existing properties suddenly

If a field must be removed, deprecate it first.
Remember: decision models might still be using it.

Future-Proofing Your Event Model

Before finalizing your taxonomy, ask:

• Will this work across brands?
• Will this work in mobile apps?
• Will this work in offline or call center scenarios?
• Will this still make sense 3 years from now?

For example:

Instead of web_banner_clicked use promotion_clicked

Now it works everywhere.

That small decision saves major rework later.

2. Designing Identity Resolution in Complex Ecosystems

Identity is where most CDP projects struggle.

In reality, one user can have:

• Anonymous browser ID
• CRM ID
• Email
• Mobile app ID
• Loyalty ID

If you don’t define how these connect, you’ll end up with duplicate or broken profiles.

Anonymous → Known Transitions

This is a critical moment.

A user browses anonymously. Then they log in or submit their email.

What should happen?

You must:

• Link anonymous history to the known profile
• Merge safely
• Avoid losing past behavioral data

Best practice:

• Send both identifiers during the transition
• Merge using strong identifiers (email, customer ID)
• Never merge using weak signals like name only

If this is not designed carefully, you’ll see:

• Fragmented journeys
• Reset personalization
• Inconsistent reporting

Multi-Device and Multi-Brand Scenarios

In enterprise setups, things get more complex.

A customer might:

• Browse Brand A on desktop
• Use Brand B mobile app
• Purchase through call center

Now you must decide:

• Are profiles shared across brands?
• Is identity enterprise-wide or brand-level?
• What about regional data boundaries?

Define clearly:

Identity Scope

• Brand-level
• Region-level
• Enterprise-level

Identifier Priority

For example:

• Customer ID
• Email
• Loyalty ID
• Device ID

Document this. Socialize it. Govern it.

Identity chaos usually comes from unclear ownership — not technical limitations.

3. Data Modeling Mistakes I See Often

Over-Collection

Some teams send everything:

• Every click
• Every scroll
• Every hover

More data does not mean better personalization.

It usually means:

• Higher storage cost
• Slower processing
• Noisy segments
• Harder debugging

Before sending any event, ask:

Will this drive a business decision?

If not, don’t send it.

Poor Event Normalization

Across brands, I’ve seen this:

Brand A sends:
productId

Brand B sends:
product_id

Brand C sends:
sku (Stock Keeping Unit)

Now try building a unified segment.

Standardize:

• Attribute names
• Data types
• Value formats

Create a shared event contract and enforce it.

Identity Chaos

This is the hardest to fix later.

Symptoms:

• Duplicate profiles
• Conflicting attributes
• Random merges
• Personalization behaving unpredictably

Root cause:
No documented identity strategy.

Identity resolution is not just configuration.
It’s enterprise data architecture.

4. GDPR and Consent Architecture with CDP

Consent must be part of your data model from day one.

Not something added later.

What Data to Send

Send:

• Behavioral interaction data
• Pseudonymous identifiers
• Business events
• Consent status

Be cautious with:

• Sensitive personal data
• Financial information
• Health data

Minimize data collection wherever possible.

What Data to Suppress

Do not send:

• Events before required consent (based on region)
• Users who have opted out
• Internal test traffic

Consent logic should sit before data flows into CDP.

Modeling Consent Events

Treat consent as its own event.

For example:

consent_updated

• consent_type
• consent_status
• timestamp
• source

This gives you:

• Full audit history
• Clean compliance reporting
• Better suppression logic
• Dynamic personalization based on consent state

And most importantly — transparency.

Practical Architecture Diagram Outline

Real Enterprise Case Study Example

Final Thoughts

Sitecore CDP is not just about connecting data sources. It’s about designing a clean, scalable event and identity foundation.

If you rush taxonomy and identity design, you’ll spend years fixing personalization issues.

If you invest time upfront, you unlock:

• Reliable personalization
• Accurate reporting
• Predictable decision models
• Cleaner compliance

In my experience, CDP success has very little to do with features — and everything to do with architecture discipline.

References

• Sitecore CDP Documentation
• Sitecore Personalize Documentation
• GDPR Official Portal
• GA4 Event Model Documentation

Sitecore’s SaaS products — Sitecore AI with XM Cloud, Content Hub, CDP, Personalize, Sitecore Search, and Sitecore Connect — gives architects all the building blocks for a modern composable DXP. The challenge is not what to buy, but how to place each capability without overlap, duplication, or architectural drift.

This post breaks down where each Sitecore SaaS product fits, where it explicitly does not, and the most common misconceptions that derail composable implementations.

The Core Principle of Composable DXP

Composable architecture is based on clearly separating responsibilities:

• Content Authoring intelligence resides in upstream systems and is decoupled from runtime delivery.
• The experience delivery layer is intentionally lightweight, stateless, and deterministic, focused purely on rendering and orchestration.
• Decisioning, personalization, experimentation, and optimization are executed within dedicated engines (e.g., CDP, Personalization) rather than embedded in the presentation tier.
• Integration follows an event-driven architecture (EDA) pattern using APIs, webhooks, and message streams instead of tightly coupled, point-to-point integrations.

Sitecore AI with XM Cloud: Content Backbone, Authoring Intelligence

Where Sitecore AI Fits:

Sitecore CDP: The Customer Information

Sitecore CDP is the system where we store customer data and behavior. It helps to understand the customer, based on everything we know?

Where CDP Fits

Where CDP Does Not Fit

Sitecore Personalize: The Decisioning Engine