MB-260 cheat sheet

Customer Insights - Data is a standalone customer data platform (CDP); it unifies, enriches, and activates data but does not store transactional system-of-record data.

Core object hierarchy: data sources feed tables; tables feed the unification process; unified profiles feed segments, measures, and predictions; outputs leave through exports and connections.

Environment roles include Administrator, Contributor, Viewer, and (where configured) DataSourceReader; the admin controls data sources, connections, and environment settings.

Unification rules can be configured in two ways: the guided rule builder (graphical match/merge rules) or the JSON-based advanced configuration for complex scenarios.

Segments and measures are environment-scoped; a segment built on unified profiles cannot be exported unless an export destination (e.g., a connection) is configured.

Customer Insights - Data integrates natively with Dynamics 365 apps via the Customer Insights connector; activation to other systems requires a configured connection or export.

Audiences and outputs are governed by consent and data residency settings; the environment's region is chosen at provisioning and cannot be changed afterward.

Data volume and refresh cadence are constrained by the environment's capacity (e.g., unified profile counts); exceeding capacity surfaces as refresh or processing failures.

Supported ingestion methods: Power Query connectors (Dynamics 365, Dataverse, Azure Data Lake, SQL, etc.), CSV file upload, and the REST API / data ingestion endpoints.

A data source is the container; a table within it maps to a source entity. Each table needs a primary key and a defined data type per column.

Power Query transformations run at ingestion time; they can rename, filter, and shape columns before the data lands in the unified store.

Incremental refresh requires a watermark or modified-date column; full refresh reloads the entire table and is costlier for large sources.

Data profiling surfaces column quality (null percentage, distinct counts, type mismatches) before unification; fix type issues at the source table, not in the unified profile.

Common ingestion failure causes: duplicate primary keys, unsupported data types, schema drift (column renamed/removed), and expired credentials on the connection.

Tables can be marked as 'semantic' (used for measures/segments) or excluded; a table not included in unification still appears in the data source list.

File uploads (CSV) are limited in size and row count per upload; larger volumes should use a connector or the API rather than manual upload.

Unification matches records across tables using match rules; each rule pairs a source table with a match column and a normalization (e.g., exact, fuzzy, email/phone normalization).

Match rules define 'who is the same person'; merge rules define which field value wins when matched records disagree (e.g., source priority, most recent, most frequent).

Every unified profile has a CustomerId (system-generated) plus a set of unified fields; source-specific values remain visible in the profile's source records.

Deduplication happens during the unification run; duplicates are grouped, and the merge policy selects the surviving value per field.

Fuzzy matching tolerates typos and formatting differences but increases false positives; exact matching on normalized keys is more precise and cheaper.

The unification report shows matched vs. unmatched record counts, match rate per rule, and duplicate clusters; use it to tune thresholds before go-live.

Unification must be rerun after any change to match/merge rules or after a data source refresh; results are not retroactive until the next run.

A profile's activity/relationship timeline is built from activity tables linked via the profile's key; linking requires a common key column across tables.

Enrichment options include Microsoft's brand/interest data, partner enrichments, and custom enrichments (bring your own data) joined on a key such as email or address.

Enrichment is optional and cost-bearing; it is applied to unified profiles and can be scoped to a subset via a filter before enrichment runs.

Segments come in two types: rule-based (builder UI, conditions on unified fields/measures) and code-based (SQL-like query over the unified profile entity).

Rule-based segment conditions support AND/OR grouping, set operations (include/exclude), and references to measures; nested groups are allowed but deep nesting hurts performance.

Code-based segments require a query that returns the CustomerId column; the segment definition is validated before it can be activated.

Segments can be refreshed on a schedule or on demand; a segment's membership is a snapshot as of the last successful refresh.

Segment activation requires an export or connection; without one, the segment exists but cannot be delivered to a destination.

Segment size and refresh time depend on the underlying unified profile volume; test with a filtered subset before running at full scale.

Measures are calculations over unified profiles and their related tables (e.g., average revenue per customer); they are defined with a builder or a SQL-like expression.

A measure definition requires a name, a source entity, an aggregation (sum, average, count, min, max), and a filter/group-by as needed.

Predictions use machine learning models (e.g., churn, customer lifetime value) trained on historical unified data; they require a labeled training set and a target outcome.

Prediction outputs are written back as fields on the unified profile and can be used in segments and measures after the model run completes.

Exports push data out to a destination (e.g., Azure Blob, Dataverse, a connection); each export defines the entity, the fields, and the destination.

Export scheduling can be recurring or on demand; a failed export retains its error detail in the export run history for troubleshooting.

Measures and predictions consume capacity; model training and large exports are the most resource-intensive operations and should be scheduled off-peak.

A prediction model must be retrained when the underlying data distribution shifts; stale models degrade accuracy and should be monitored via the model's performance report.