Changelog

Pipelines that carry a Nearest Location column can now report the distance in miles. Pick Reported distance unit under the payload's Advanced settings; meters remains the default, and every existing pipeline keeps reporting meters until you change it.

The bounds you set are unchanged: a maximum distance is still entered in miles in the dashboard and in meters through the API, whichever unit the pipeline reports.

Deployments with human friendly column headers now name the unit: the distance column is fdy_location_distance_m for meters or fdy_location_distance_mi for miles, where it was fdy_location_distance. A deployment that already delivers this column picks up the new header on its next build, so update anything downstream that reads it by name. Machine friendly headers are unaffected.

Via the API, set "distance_output_units": "miles" on the pipeline's payload.location. See Atlases for the full configuration.

We've added Amazon Athena as a new connection type. Faraday can read Glue-catalogued tables as datasets and write predictions back as tables in the same lake — no extracts, no separate warehouse.

Athena runs in your AWS account, so you keep the data and pay for the query compute. Faraday generates a unique IAM role per connection and assumes a role you create in your account to submit queries; there are no IAM user access keys involved. To set one up you'll need an AWS account ID, a region, the Glue database Faraday should read from and write to, and an S3 prefix for staging.

Targets always fully replace the destination table: Faraday writes CSV to a new prefix under your output location, then updates the Glue table in place, so the table name never disappears. Append and upsert aren't supported.

Via the API, use POST /connections with "type": "athena". To get started, see the new connection guide.

You can now manage location data — stores, branches, dealers, service areas — as a first-class resource with Atlases, and output each person's nearest location directly in a Pipeline payload.

Previously, proximity required stitching together a Dataset and a Place. Atlases follow the Dataset pattern instead: create one from a hosted CSV or an existing connection, map your locator columns (address + postcode, lat/lon, or GeoJSON/WKT geometry), and define properties you can filter on later.

In the Pipeline configuration page, a new Nearest location control under Payload adds Location name, Location reference key, and Location distance (m) to your deployment. Advanced settings let you restrict to specific Atlases, filter by location properties, and choose between the nearest location or every location that qualifies. Radius cohorts and market opportunity analyses can now be built from Atlases as well.

Via the API, use POST /atlases with output_to_locations, and the new location property on a Pipeline's payload. If you use select: all, you must supply a max_distance — otherwise every location is returned for every person. See the Atlas API reference to get started.

Faraday Pro is a new self-serve way to buy Faraday context. Pick data from the catalog; enrich your contacts by CSV, API, MCP, or database integration; and pay per matched element at $0.05 a credit. No contract or call required.

The original Faraday dashboard is now Faraday Enterprise. Existing accounts and app.faraday.ai are unchanged; public signups now go to Pro.

If you'd like to read more, check out our blog post about the release, or take a look at the docs to learn more about what Pro is and who it's for and how projects work in the platform. And if you're still not sure self-serve is the right motion for you, read a little more about what Enterprise is and who that's for.

And if you're ready to get the data, just create an account. All you need to get started is a credit card and an ID.

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.

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.