Identity contract
Document source identifiers, match evidence, confidence, threshold, merge and split history, survivorship, reviewer action, and the identity version used downstream.
Identity to measured action
BluePi connects customer identity, consent and purpose controls, event history, derived features, decision logic, activation, and outcome measurement in one traceable path. Each intervention retains the customer state, rule or model version, eligibility decision, action, and resulting evidence.
Customer identity connected to a governed decision
A customer-intelligence system begins with one action the business can influence. Identity resolution, event history, profile freshness, consent and purpose controls, candidate logic, eligibility, activation, and measurement are designed for that decision.
The operating record keeps the customer state, identity version, rule or model version, control decision, intervention, and outcome connected.
Document source identifiers, match evidence, confidence, threshold, merge and split history, survivorship, reviewer action, and the identity version used downstream.
Separate candidate generation from eligibility, suppression, availability, frequency, risk, business constraints, ranking, fallback, and final reason codes.
Record assignment, exposure, action, outcome, attribution window, reporting source, comparison or holdout, incremental effect, uncertainty, and guardrails.
When this is the right starting point
Good fit
One operating workflow has a named owner, a measurable baseline, and users who can judge whether the result improves.
Poor fit
The request is capacity-only staffing, an unowned demonstration, or a broad transformation without a first decision and finish condition.
Evidence produced during delivery
Open the part you need. Each section expands into the full delivery scope for that step.
Define the decision before building a unified profile. The first contract records the customer action the system can influence, the user or system that acts, the required freshness, eligible and excluded populations, decision owner, error cost, and measurable outcome.
Source identifiers, match keys, confidence, merge and split behavior, survivorship, and manual review determine what the customer profile represents. A low-confidence or conflicting match enters review instead of silently joining two profiles.
The customer record separates raw events, resolved identity, source attributes, derived attributes, model features, segments, recommendations, actions, and outcomes. Each event retains event time, arrival time, source, schema version, and correction state so the system can reproduce the customer state known at the moment of a decision.
The system checks whether a source, attribute, model feature, segment, channel, and proposed action are permitted for the approved purpose. Candidate generation and final eligibility remain separate.
The result delivered to an application, service workflow, or approved channel contains the customer and decision identifiers, generation time, expiry, action, rank or priority, reason codes, rule or model version, control state, and exception status. The consumer can distinguish an eligible action, suppressed action, fallback, and system failure.
Measurement separates assignment, exposure, customer action, operational completion, and business outcome. The contract defines the eligible population, treatment or holdout assignment, exposure time, outcome event, attribution window, repeated exposure handling, reporting source, incremental effect, uncertainty, segment breakdown, and guardrails.
Monitoring covers source completeness, identity conflicts, profile and control freshness, feature drift, segment size, recommendation distribution, suppression, fallback, decision latency, delivery, exposure, action, and outcome. See it in production in the Ferns N Petals customer data platform, CaratLane personalization, dealer recommendations, and customer risk profiling case studies.
Start with one decision and its eligible population, action surface, freshness requirement, owner, error cost, and measurable outcome. Identity, profile, control, candidate, eligibility, and measurement design follow that bounded use.
The profile separates source events, resolved identity, source attributes, derived attributes, features, segments, recommendations, interventions, and outcomes. It retains event and arrival time, source and schema version, identity version, control state, and correction history.
Separate eligible population, assignment, exposure, customer action, operational completion, and business outcome. Define the comparison or holdout, attribution window, repeated exposure behavior, reporting source, incremental effect, uncertainty, segment breakdown, and guardrail measures.
We will review the owner, the baseline, the data path, the system boundary, and the route to go-live.
Discuss one workflow