Intelligence & Services → Identity & Profile Service

Relationships

Models the connections between customer records themselves — households, corporate accounts, referrals — beyond identity resolution's single-person linking.

High-Level Design

Relationships link customer records to each other, not just identifiers to a customer.

Data Source
Business Systems
CRM account hierarchies, loyalty referral records
→
Ingestion
Ingestion Layer
Business system connectors
→
Processing
Data Modeling
Transformation & Processing's dbt models
→
Foundation
curated.customer_relationships
Relationship edges as an Iceberg table
→
Intelligence
Relationships
.NET Core Analytics/AI API relationship endpoint
→
Activation
Household & Account Views
Powers account-level personalization and B2B activation

💼 Business Context

  • Lets the business reason at the household or corporate-account level, not just the individual — essential for B2B customers and family/household marketing
  • Improves referral-program accuracy by linking a new sign-up back to the referring customer's own profile
  • Owned by Data Engineering, with relationship types sourced from CRM/Loyalty business rules

🔌 Technical Overview

A dbt model in Transformation & Processing derives relationship edges — household (shared address/payment method), corporate account (CRM hierarchy), and referral (loyalty program referral codes) — into curated.customer_relationships. The Analytics/AI API, deployed as a Docker container on Azure Container Apps, exposes a relationship-traversal endpoint so a query for one customer can return their household or corporate-account peers in a single call.

Relationship Types

Household Corporate account Referral Family plan member

💾 Relationship Record

{
  "customer_key": "cust_004821",
  "relationship_type": "household",
  "related_keys": ["cust_004822", "cust_004823"],
  "source": "shared_payment_method"
}

🔗 Integration Points

  • Business Systems (CRM, Loyalty) — source of account hierarchy and referral data
  • Data Modeling (Transformation & Processing) — the dbt model producing relationship edges
  • Unified Customer Profile — household/account context is attached to profile reads on request
  • Real-time Activation — household-level suppression rules (e.g., one offer email per household) read from this endpoint

🧰 Services Consumed

  • Owning microservice — Cxos.Profile.Api (see the Full Application Service Map)
  • Database — Azure Cosmos DB (Core API + Gremlin API) + Azure Cache for Redis

⚠️ Non-Functional Considerations

  • Scale: relationship edges are a small fraction of total customer count, so the table stays compact even at enterprise scale
  • Latency: relationship lookups are cached alongside profile lookups and return in single-digit milliseconds
  • Reliability: relationship inference rules are versioned in dbt and tested, since a bad rule could incorrectly merge unrelated households
  • Security/Privacy: a household view of another member's data respects that member's own consent state — visibility is not an implicit override of individual privacy

🎯 Enterprise Example

A marketing campaign wants to send one offer per household rather than one per family member. The Relationships endpoint collapses four individually-profiled family members into a single household, cutting redundant sends and the complaint rate that comes with them.

← Back to Identity & Profile Service