Source records
- CRM contacts and accounts
- Web and app events
- Point of sale and orders
- Support tickets and calls
Customer Analytics Development
Customer analytics and CDP development
When one customer shows up as four records, every segment, churn score and lifetime value figure is wrong. Agnotic Technologies builds the unified customer profile underneath your analytics: identity resolution, consent carried with each attribute, and outputs your CRM and marketing tools can use.
Identity resolutionConsent in the data modelSegments as codeYour own warehouse
Trusted by global innovators
Customer analytics
What is customer analytics development?
Customer analytics development is building the unified customer profile that every segment, churn score and lifetime value figure depends on: matching records from CRM, web, app and store systems, carrying consent with each attribute, and pushing results back to the tools that act on them. Agnotic Technologies builds this layer for the client, in the client's own cloud.
This page is about the customer data underneath the dashboards. Retail sales and inventory analytics, dashboard design and model building have their own pages, linked at the end.
Most customer analytics problems are identity problems. If one person appears as four customers, every rate built on top is wrong, so we settle the matching rules before any model.
Decision table
Which matching method should link two customer records?
Identity resolution usually combines several methods. We use this table to choose their order and to decide which matches need a person to confirm them.
| Matching method | Accuracy risk | Consent implication | When to use it |
|---|---|---|---|
| Login or customer ID | Lowest, when your own system issues the ID | Covered by the account terms the customer accepted | Linking app, web and loyalty activity for signed-in customers |
| Exact email or phone (deterministic) | Low, but shared family emails and recycled phone numbers can merge different people | Data the customer gave you directly; the purpose they were told still limits its use | First pass for every source that captures a verified email or phone |
| Hashed identifier sent to a partner | Low for the match; the risk is what the partner learns | Sending hashed emails to an ad platform can count as sharing for cross-context behavioral advertising under the CCPA | Audience matching, only for customers who have not opted out |
| Probabilistic name and address | Medium to high: typos, house moves and common names create false merges | An inferred link must not widen the purposes a record was collected for | Store and call center records with no email, with a confidence score and a review queue |
| Device or cookie graph | High, and it weakens as browsers limit identifiers | Usually needs consent or opt-out handling before collection | Anonymous web behavior, kept apart until the person signs in |
Every match is stored with its method and confidence, so a bad merge can be split again without rebuilding the profile.
Profile data model
What does a unified customer profile look like?
The profile model we build, from raw source records to the outputs your teams use.
Identity graph
- Match rules and confidence scores
- One golden record per person
- Merge and split history
- Household links kept separate
Profile attributes
- Source and timestamp on each attribute
- Consent and purpose flags
- Retention date per attribute
- Sensitive fields tagged
Features
- Recency, frequency and spend
- Engagement trends
- Churn signals
- Lifetime value inputs
Activation
- Segments synced to CRM
- Audiences to ad tools after opt-out checks
- Scores in support and sales screens
- Exports for analysts
Consent
How is consent carried with each attribute?
Consent belongs in the data model, not in a spreadsheet beside it. These are the rules we build in.
- Every attribute stores the purpose it was collected for, so a marketing job cannot read a field collected only for delivery
- Consent and opt-out changes are events that update every downstream segment, not a nightly overwrite
- Browser opt-out preference signals are recorded against the profile and respected by every activation job
- Audience syncs to ad platforms check opt-out status at send time, not only when the segment was built
- Deletion requests remove the person from the profile, the features and every synced audience we control
- Raw identifiers stay inside the identity service; analysts work with pseudonymous IDs
Outputs
Outputs built on a clean customer profile
Outputs we build once identity and consent are reliable.
Segment definitions as code
Segments written as versioned queries with an owner and a description, so marketing and analytics count the same customers.
Churn features
Signals such as falling visit frequency, unresolved support tickets and lapsed subscriptions, ready for your data science team or a simple rules score.
Customer lifetime value
Past spend, margin where you have it and expected repeat behavior, with the method written down so finance can check it.
Next best action inputs
Recent behavior and open issues shown in CRM and support screens, so the person talking to the customer sees the same picture.
Cohort and retention analysis
Cohorts by first purchase, channel or plan, built on resolved identities rather than raw accounts.
Customer analytics for startups
A smaller first version: one identity rule set, one profile table and a few segments, built so it can grow.
Failure points
Where do customer analytics projects go wrong?
Problems we find in existing customer data, and the fix we build.
Challenge
Two people merged because they share a household email.
Agnotic approach
Households are a separate relationship, and a merge on shared contact details needs a second matching field.
Challenge
A segment built in one quarter still targets people who opted out since.
Agnotic approach
Activation jobs check consent at send time and drop opted-out profiles before every sync.
Challenge
Marketing and finance report different customer counts.
Agnotic approach
One customer definition in code, with versioned identity rules named in every report.
Challenge
Churn scores look accurate in testing and fail in use.
Agnotic approach
Features use only data available at the moment of prediction, so future information does not leak into training.
Challenge
Raw emails copied into every analyst's notebook.
Agnotic approach
Identifiers stay in the identity service; everything downstream uses pseudonymous IDs.
Challenge
A bad probabilistic match cannot be undone.
Agnotic approach
Each merge keeps its method and confidence, and can be split without reloading the sources.
Should you build customer analytics or buy a packaged CDP?
Buy when your sources are standard, your marketing team will run the tool day to day and the vendor's identity rules fit your customers. A packaged customer data platform gets you running sooner.
Build when identity is unusual (households, business accounts with many contacts, store customers without emails), when the data must stay in your own warehouse, or when consent rules differ by region and product.
Many clients do both: the warehouse holds the profile and identity graph, and a packaged tool reads from it for activation. We build the warehouse side and connect it to the tool you choose; we do not resell or rank vendors.
Scope and cost
What drives the cost of customer analytics development?
We do not publish prices. These are the scope drivers we size on the scoping call.
Sources and their quality
How many systems hold customer records, and how clean their emails, phones and addresses are.
Identity rules
Deterministic matching only, or probabilistic matching with a review queue.
Consent model
The regions, purposes and opt-out signals the profile has to respect.
Outputs
Which segments, churn features and lifetime value measures the first release needs.
Activation targets
How many CRM, support and ad tools receive segments, and how often.
Warehouse and hosting
Whether you already run a warehouse on AWS, Microsoft Azure or Google Cloud, or need one set up.
Rules and standards
Privacy rules behind the customer profile
The privacy rules and practices behind the consent design above. Your counsel confirms which apply to you.
CCPA and CPRA11 CCR 7025GDPRGlobal Privacy ControlNIST Privacy FrameworkVersion control
Facts and sources
Facts behind customer analytics development
California privacy rules that shape how a customer profile is built and used, each linked to its primary source.
Under the CCPA, "sharing" means making a consumer's personal information available to a third party for cross-context behavioral advertising, whether or not money changes hands.
Source: Cal. Civ. Code 1798.140(ah) (California Privacy Protection Agency, statute text effective 1 January 2026)The CCPA regulations require a business's collection, use, retention and sharing of personal information to be reasonably necessary and proportionate to the purpose it was collected for, or to another disclosed, compatible purpose.
Source: 11 CCR 7002(a) (CCPA regulations effective 1 January 2026)The CCPA regulations require symmetry in choice: the path to a more privacy-protective option must not be longer or harder than the path to a less protective one.
Source: 11 CCR 7004(a)(2) (CCPA regulations effective 1 January 2026)A business that sells or shares personal information must process a qualifying opt-out preference signal, such as an HTTP header field or JavaScript object, as a valid request to opt out of sale and sharing.
Source: 11 CCR 7025(b) (CCPA regulations effective 1 January 2026)
Engagement
How does a customer analytics engagement work?
Three stages, each with a clear output.
1.
Scoping call and source review
We look at your customer sources, sample their identity fields and agree what the first release must produce.
Scope2.
Identity and profile first release
Match rules, the profile model and consent flags built and tested on your real data in your warehouse.
Build3.
Outputs and activation
Segments, churn and lifetime value features, then syncs to the tools that act on them.
ExtendFrequently Asked Questions
We do not publish prices. Cost depends on the number and quality of sources, whether you need probabilistic matching, the consent model, the outputs and how many tools receive segments. You get a written proposal after the scoping call.
It depends mostly on how clean the source records are. We agree a fixed first release on the scoping call, usually one identity rule set and a first set of segments, and plan the rest from what the source review finds.
No. A CRM is where sales and service teams work with customers. A customer data platform, or the profile layer we build in your warehouse, joins records from the CRM and every other source into one profile and feeds the results back to the CRM.
Yes. We read from the CRM, commerce, app and support systems you already run, build the profile in your existing warehouse where one exists, and sync segments and scores back through each tool's API.
Only where exact matching is not enough. Deterministic rules come first because they are explainable. Probabilistic matching is added for records without shared identifiers, with confidence scores and a review queue for borderline matches.
Yes. A typical first release is two or three sources, deterministic matching, the profile table with consent flags and a handful of segments synced to one tool. Churn and lifetime value features follow once the profile is trusted.
Engineers may use AI assistants to draft SQL and tests, but every query is reviewed and checked against known records before it reaches the profile. Customer data is never pasted into AI tools that sit outside your agreed environment.