Amperity builds customer context for identity, predictions and AI agents

Amperity addresses a problem that becomes more expensive when AI enters customer operations: different systems describe the same person differently. Its platform resolves identities, builds usable profiles and turns that context into predictions, audiences and actions. The attraction is a shared customer foundation; the hard question is whether its matching decisions reflect the people your business actually serves.

01 / ProductCustomer identity sits beneath the intelligence

Amperity describes its current offer as a customer context platform. The identity product builds graphs from first-party records and combines explicit matching rules with AI scoring for uncertain cases. This matters when purchase history, loyalty accounts and website activity have no reliable shared key. A graph supplied by a third-party identity broker is a different dependency from reconciling the records a brand already holds.

The platform then makes resolved profiles useful to analysts and marketers. Its intelligence and decisioning page describes predictions for value, purchase propensity and churn, plus recommended audiences and actions. Those are vendor-described capabilities, not evidence that any particular campaign will improve. A customer record can be more complete while a poorly specified objective still produces an unhelpful recommendation.

The current Pér documentation introduces an AI agent for customer data. It belongs within this wider foundation rather than replacing identity management. A conversational request is an interface to data and actions whose reliability still depends on ingestion, semantic definitions and permissions. This blueprint is a public-source assessment; we have not operated a production tenant or measured matching accuracy.

02 / AudienceA fit for brands with fragmented customer histories

The strongest reader situation is an established consumer business whose online, store and loyalty systems disagree about who bought what. A retailer may see several emails for one shopper, while a hospitality group may have guest records that span properties and booking systems. The proposed benefit is the ability to analyze or activate a consistent person-level history without writing another set of brittle joins for each question.

A marketing team with a clean, stable customer identifier may need less identity machinery. If the immediate task is sending warehouse-defined audiences into engagement tools, Hightouch offers a useful comparison around activation and decisioning. The evaluation should locate the actual bottleneck: identity resolution, audience design, destination delivery or the decisions made after delivery.

Amperity also intersects with an existing warehouse strategy. Snowflake is relevant when the warehouse is already the governed analytical home. A sensible architecture decision asks which system owns the customer key, where transformations run and how downstream teams discover corrections. Buying another customer platform does not automatically resolve conflicting ownership among marketing, analytics and operational systems.

03 / WorkflowProposed workflow: reconnect a loyalty purchase history

Consider a proposed workflow for a retailer whose loyalty members buy both in stores and online. Start with an agreed evaluation set that contains known same-person pairs and deliberately confusing pairs: household members, recycled phone numbers, shared email addresses and records with missing names. Keep the business definition of a person separate from the definition of a household. Neither should be silently substituted for the other.

The Stitch reference explains a sequence of semantic tagging, preprocessing, table union, blocking, scoring, pairwise comparison and stable ID assignment. Semantic tags tell the system that differently named columns represent the same kind of information. Blocking narrows candidate comparisons. Scoring then helps decide which records belong together. These stages explain why a high match count alone is insufficient: the wrong candidate grouping can make subsequent scoring look convincing.

For the evaluation, inspect both accepted and rejected links against the known pairs. Ask the operating team to trace a suspicious merged profile back to its source records. Retain the original source identifiers so that a later split can be reconciled in reporting. Check what happens after a changed address or an additional loyalty ID arrives; identity is an ongoing process, not just a one-time cleanup.

Only after that review, define a lapsed-customer audience and compare the resulting purchase history with the retailer’s own records. Use a small approved activation and a holdout to assess the campaign independently of the identity exercise. This example is a proposed evaluation, not an Amperity customer result. It separates three questions that otherwise get blurred: did the records match, did the segment mean what the team intended, and did the intervention help?

The hosted MCP server can expose Amperity operations to compatible assistants using existing credentials. Its documented operations extend beyond reading to building queries, segments and activations. A pilot should therefore begin with tightly scoped access and explicit review of actions. Natural-language convenience should not give an experimental assistant authority to activate a production audience by accident.

04 / Commercial modelAmps meter platform consumption

The pricing page publishes a usage model rather than a public currency tariff. Amps measure platform activities. Both editions list the full platform, while services and support differ. A useful forecast must therefore describe work performed, not merely the number of employees who will log in.

Build the quote around the actual refresh pattern: initial historical ingestion, subsequent updates, repeated segmentation and destination sends. A short proof of concept may understate steady-state activity if it omits routine reprocessing or campaign iteration. Ask for the consumption estimate alongside the assumptions so the organization can explain a higher bill when its operating pattern changes.

The public page describes dashboards and threshold alerts. These help observe spend; an alert is not a guaranteed spending cap. Confirm the contractual treatment of additional consumption and unused capacity rather than converting a usage unit into an invented per-customer price.

05 / DistinctionsThe matching explanation is unusually useful

One valuable distinction is that Stitch has public technical documentation explaining intermediate matching work. The description gives a buyer concrete review questions about preprocessing, candidate selection and stable identifiers. It does not reveal every proprietary detail or establish an independent accuracy advantage, but it is more useful than evaluating identity software solely from a headline match-rate claim.

Another distinction is the connection from the identity foundation to prediction and activation. It reduces the conceptual distance between the person an analyst studies and the audience a marketer reaches. That relationship is worth testing directly: select a profile in analysis, inspect the same person’s activation fields and confirm which changes arrive in the destination.

06 / Open questionsAccuracy and authority need different evidence

The main unresolved accuracy question is how matching behaves on your hardest records. A demonstration with obvious duplicates cannot establish performance on shared contact details, non-Latin names or sparse histories. Require separate error analysis for false merges and missed matches; their consequences differ. A false merge can contaminate preferences, while a missed match can leave a fragmented history.

The second question is how rapidly corrected identity reaches every consumer. A fixed profile in one screen is not a corrected campaign export or warehouse table. Include an intentional correction in the evaluation and follow it downstream. Ask how historical reports reconcile old and new identifiers when a customer graph changes.

Finally, confirm the precise Pér and MCP operations enabled for your tenant, the approval boundaries and the data sent to any model provider. The public platform description cannot substitute for tenant configuration or an executed agreement. Assess prediction quality against a time-separated baseline and actual outcome data before treating a generated recommendation as a business decision.

07 / DecisionChoose the next step around the identity problem