Changelog

Persona sets can now cluster on your own data — first-party traits defined on your account and properties from any event stream used to define the cohort — not just Faraday Identity Graph attributes.

Previously, clustering was restricted to a curated set of FIG attributes. That restriction keeps a persona set universally applicable: because we have those attributes on everyone, anyone can be assigned to a persona. But if you're personalizing after a first purchase, the restriction is overkill — and it can suppress model quality. Which product line someone bought first, or whether they used a discount code, is often far more useful clustering signal than their FIG demographics.

In the Dashboard, new controls under Advanced on the persona set form let you pick clustering attributes, clustering traits, and clustering stream properties. Note that persona sets built on custom traits or stream properties only apply to people present in the underlying first-party data — anyone outside it can't be assigned a persona.

Via the API, use the new clustering_dimensions property on create and update persona set. The modeling_* properties are now deprecated — if both are supplied, clustering_dimensions takes precedence. See the persona set documentation for full details.

Faraday now has a public status page at status.faraday.ai, showing real-time uptime and incident history for the platform and API.

Bookmark it to check current system status or subscribe to updates during an incident, instead of waiting on a support reply.

You can now get an Insights Report, a custom analysis built around the two or three questions that matter most to your team. Common ones are who your best customers are, why some leads convert and others don’t, and how much of a market you’ve already reached.

Each report combines persona analysis and market opportunity analysis. We match your customer records to the Faraday Identity Graph and build the report with the same data and systems that power the rest of the platform. Once your data is in, the analysis can come together in days.

Insights Reports are available to everyone: Enterprise customers, Pro customers, and teams that aren’t on Faraday yet. To see how teams use them, read our blog post, or talk to a context consultant to scope yours.

The Persona Flow feature has been deprecated. The Flow tab has been retired from persona sets in the app, and the corresponding getPersonaSetAnalysisFlow API endpoint is deprecated and no longer maintained.

Persona definitions, analysis, and recommendations remain fully supported. See the API reference for persona sets for the current set of persona capabilities.

Pipeline populations now support address-level exclusion — suppressing everyone at a given address, not just specific individuals.

Previously, exclusion cohorts operated at the individual level only. For direct mail use cases, this meant there was no way to prevent other residents at a previously-mailed address from appearing in a new deployment. The new Exclude at address level control solves this: any cohorts you add will suppress all individuals who share an address with anyone in those cohorts.

The existing exclusion behavior is unchanged and now labeled Exclude at individual level for clarity. Both controls are available under the Need to exclude/suppress? disclosure in the Pipeline population settings, and via the exclusion_address_level_cohort_ids field on the Scopes API. See population exclusion for full details.

The Faraday MCP server is out of beta and now generally available as the Configuration MCP — covering both full account configuration and real-time per-person context retrieval in a single server.

The Configuration MCP lets any AI agent configure and operate a Faraday account in natural language — connecting data sources, defining populations, training models, and deploying predictions — without writing HTTP requests against the REST API. It covers the full account lifecycle, from connections and datasets through cohorts, outcomes, scopes, targets, and more.

See the Configuration MCP docs to get connected.

Attribute imputation in target payloads is now opt-in. Previously, Faraday would automatically use data from cohabitants and neighbors to estimate missing attribute values — this now defaults to off, giving you explicit control over whether imputed data appears in your output.

To enable imputation for a target in API, set impute_payload: ["attributes"] in the target's representation, or if you're working in the Dashboard, check Impute missing attribute values when possible in the new target wizard. Learn more in our documentation.

Existing targets have been automatically updated to preserve their current behavior.

This feature is available for FIG v2 accounts only (all new accounts are FIG v2 by default). It applies to Traits only — imputation for modeled scores continues to run by default and cannot be disabled.

For more background, see our blog post on payload fallbacks.

A new Analysis tab on every Pipeline surfaces insights about your scope before you build a Deployment — no usage required.

Counts shows the size of your Pipeline's population, individuals and residences, broken down by state and by zip code (when the population spans 250 zip codes or fewer). Use it to size addressable markets and understand cohort distribution at a glance.

Prediction distribution shows how your scope is distributed across probability bins for each outcome and recommender, with cumulative individual and residence counts. Use it to pick deployment cutoffs (e.g. "top 20% by predicted likelihood") before exporting.

Both are also available via the scope analysis API. The existing Efficacy, Diagnostics, and Market opportunity views have moved from the Pipeline overview into the new Analysis tab.

The Talk to your Personas feature has been deprecated. The MCP server — now in beta — is a more flexible and powerful way to bring your Faraday data and predictions into AI-powered workflows.

Rather than a fixed chat interface, the MCP gives any LLM agent real-time access to your personas, cohorts, and predictions via a standard protocol, making it easy to build dynamic, context-aware applications on top of your Faraday data.

You can now see exactly how each row of your data matched (or didn't) every time a dataset ingests. A new ingress log gives you a full matching waterfall for every ingestion event — from total rows received all the way through to which rows were eligible for enrichment.

Each ingress log entry captures:

• Row counts at every stage — from total rows received through processable, valid, allowed, recognized, and enrichable
• Recognition rate — what share of your allowed rows matched known identities in the Faraday Identity Graph
• Enrichability — how many rows and unique people were eligible for enrichment

The most recent log entry is shown by default with the matching waterfall already open, so you get an at-a-glance read on your data quality every time you visit a dataset.

Logs are also accessible via the API at GET /datasets/{dataset_id}/logs/ingress. See the dataset documentation for details.