Changelog

The Prediction distribution table on a Pipeline's Analysis tab can now suggest where to set your deployment cutoff.

Enter what it costs to reach one contact and the most you would pay for one conversion. The table then adds the spend and expected cost per conversion for each probability bin, and highlights the lowest bin that still converts for less than your target. Above the table, it gives you the probability to filter on when you deploy, and the average cost per conversion of everyone above that cutoff.

The table also shows the conversion rate the model expects across your pipeline's population. If that rate is far from what you actually see, treat the probabilities and any cutoff based on them with caution. A toggle switches the counts, and the calculation, between individuals and residences.

Faraday doesn't store your cost figures. They are only used to calculate the table on your screen.

Faraday now shows which US households just moved into your service area, and flags your own customers who look likely to move soon. A move resets where a household shops, so reaching new movers while they're still picking providers gives you the best chance of winning them.

You can get weekly lists of the movers landing in your ZIP codes, ranked by how likely each one is to buy from you and sent to your ads, CRM, or mail house. Existing customers can also add mover data through the API, real-time lookups, or recurring deliveries.

To see how many people moved into your area, paste your ZIP codes into the free report on the New mover data page. To get started, contact your account team or talk to sales.

Visitor Context identifies people who visit your website without filling out a form, then adds Faraday's consumer context to each one. Identified visitors become known contacts in Faraday, so you can score them, assign personas, suppress your existing customers, and send the visitors worth reaching to your mail vendor, CRM, or ad platform.

To set it up, create a Faraday Pixel dataset and add the tag from its Definition tab to your site, usually through your tag manager. There are no databases or credentials to connect. Faraday can also create a website_event event stream and a cohort of your site's visitors for you. Visitors arrive in batches, not in real time, and Visitor Context works on websites only.

The tag runs only where your consent tools allow it. Visitors who can't be identified stay anonymous and are never delivered, and each brand's visitor data stays in its own Faraday account.

Visitor Context is available now. To get access, contact your account team or talk to sales. To get started, read the Visitor Context docs and see how to install the Faraday Pixel.

Ask Faraday lets you ask plain-language questions about U.S. consumers from Claude, ChatGPT, Gemini, or another AI assistant. Answers come from the Faraday Identity Graph, which covers 1,400+ attributes on 240 million U.S. adults and their households.

Ask about a market, then ask the same question about your own customers, and Ask Faraday shows where the two differ. Because it runs in your own assistant, it works alongside the other tools you’ve connected there. One conversation can pull records from your CRM, compare them in Faraday, and turn what you find into lists and campaigns.

Every answer has to be backed by at least 50 distinct people, and the database itself refuses requests for records about individual people.

Ask Faraday is in beta for current Enterprise customers. To get access, contact your account team. For now, read the launch announcement. See the Ask Faraday docs.

Explore is no longer available. We removed the Explore page and the Explore switches on the cohort and persona set lists from the Faraday dashboard. Faraday no longer builds Explore data when a cohort or a persona set updates.

The explore field on cohorts and persona sets is deprecated in the API. The field has no effect. Requests that set it still succeed, and responses still include the stored value. You can remove the field from your requests and Terraform configurations at any time.

Looking for a way to understand who your customers are? Try an Insights Report, or, for Enterprise customers, Ask Faraday.

Outcome predictions now include a lift score alongside probability and percentile. Lift score tells you how many times as likely a person is to convert as average: 1.0 is average, 2.0 is twice as likely, and 0.5 is half as likely. That makes scores easier to read and share with people outside your data team: instead of "Jane has a 6% chance of converting," you can say "Jane is 3x as likely to convert as average." It's calculated from the model itself, so it stays accurate when your models refresh, and it costs nothing extra. Use it to send your best leads to top reps, prioritize calls, adjust bids, or show results in your own dashboards. It's the same ratio as the Lift column in an outcome's lift table, which reports it for groups of top scorers. The lift curve and Average lift over random on the metrics tab show lift over random, which is lift score minus 1.

Lift score is available on identified, referenced, and aggregated deployments. Hashed deployments don't include it. The column is fdy_outcome_{outcome_id}_propensity_lift, and aggregated deployments also get count_ and avg_ versions of it. The Lookup API returns the same key.

New deployments show lift score under Structure. If a deployment created before September 23 doesn't include lift score, recreate it once the pipeline has rebuilt. Editing its structure won't add it. Some structure formats pick up lift score on their next build; formats that only send identity columns don't include it. See the lift score docs for details.

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.

Faraday’s MCP server now also supports ChatGPT. You can connect it through OpenAI’s app directory, alongside Claude and other MCP-compatible assistants. See our MCP blog post to get connected.

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.