With summer in full swing, Faraday’s product team and developers have been working hard to create some incredibly exciting updates to the Faraday platform. The _why_ behind these changes is rooted in two of our core product pillars:

1. **AI for all**. The benefits of machine learning should not be reserved solely for the Fortune 500 or those with advanced degrees. The promise of easy AI, scalable cloud-based infrastructure, and a good UI should unlock the benefits of consumer behavior predictions for all brands.
2. **Making data science fun**. Using Faraday should be intuitive and easy. You should feel empowered to ideate, experiment, and deploy, all on your own.

We're thrilled to announce that as of today, four major updates are live. In this blog, we'll walk you through how each one works—here's what we'll cover:

- **Build your own predictions in Outcomes**: Describe the business outcomes you want predictions for, and Faraday will build and maintain predictive models for that outcome, with models getting more accurate over time as they learn from your data.
- **Deploy your predictions with ease in Pipelines**: Choose your likely-to-buy outcomes, your personas, and more; pick a specific population of customers; and target a destination for your deployment, like your data warehouse, cloud bucket, CRM, ESP, etc.
- **Plug into Faraday with Connections**: Plugging in your data is now a simpler process with fewer steps required. Plus, Connections paves the way for a future update where we'll implement true bi-directionality for your data and predictions in the Faraday platform.
- **Create more powerful Cohorts**: Cohort building now features the ability to specify certain trait requirements from your data or the Faraday Identity Graph in order for a customer to enter a cohort, adding an extra layer of depth to your predictions.

Let’s dive in.

## Build your own predictions in Outcomes

Back in December, we released an update that enabled Faraday users to build their own predictive personas within a cohort of their choosing based on various attributes from the [Faraday Identity Graph](/features/data).

That update had been the first major in-platform step toward user autonomy, and, more importantly, toward making AI accessible for all. Continuing on that path, Faraday users can now access an additional self-serve interface, this one for defining propensity (likelihood) predictions: **Outcomes**.

Outcomes allows you to easily describe the business outcomes you’re trying to predict in just a few clicks. Likely to buy? Sure. Likely to churn? You bet. Likely to buy _again_? That, too. Behind the scenes, Faraday takes over from here, applying dozens of strategies to build a range of candidate models, then selecting the one that most accurately predicts your outcome. Over time, Faraday automatically builds and rebuilds progressively more accurate models as you accumulate more data.

Our new Outcomes interface puts the power of experimentation in your hands, allowing you to easily try out different outcomes and view how effective the model will be across your use cases—all without needing a data scientist at your shoulder.

## Deploy your predictions with ease in Pipelines

Once you’ve defined your own prediction objectives, make them actionable with **Pipelines**.

Pipelines completely streamlines the prediction deployment process in Faraday. Previously, you may have used some combination of Reach, Monitor, and Inform to deploy predictions on-demand, on a scheduled basis, and in real-time via API. These three products have been unified into Pipelines for a more accessible and intuitive user experience.

Jump into Pipelines and choose your:

- **Payload:** a combination of your desired propensity outcomes, your personas, and more.
- **Population:** the people you want the predictions on.
- **Targets:** where you want your predictions deployed, including your data warehouse, cloud bucket, or anywhere else in your stack (CRM, ESP, etc).

Faraday takes over from here, keeping your predictions constantly up to date by refreshing scores and persona assignments when new data comes in, ensuring you’re never left wrong-footed when delivering personalized experiences to your most likely-to-buy customers.

With Pipelines, for the first time ever, you’re able to both describe and deploy your own predictions completely autonomously—without a data science degree.

## Plug into Faraday with Connections

Starting today, you’ll notice the Sources and Destinations areas of the Faraday platform have been combined into a single **Connections** view.

With Connections, you’re able to plug Faraday right into your data warehouse or cloud bucket by entering your location-specific details. Once done, it’ll be ready for selection as a deployment target in Pipelines. Dropping the number of setting screens required to complete your end-to-end connection from two to one should save you some clicks, and get your first predictions deployed that much faster.

Keep an eye out for more news here, because Connections is a major building block for a future update that will enable every Connection to be bi-directional—your predictions, wherever you want them, whenever you want them.

## Create more powerful Cohorts

Previously, **Cohorts** in Faraday were defined by event streams, or an event that each person in a cohort has experienced. This included the type of event (such as an order), when the person experienced the event (all orders, last X days, etc), the frequency of the event (such as number of times an order was placed), and finally, the value of the order.

We introduced the Segments console last year to allow users to define a group of people based solely on the Faraday Identity Graph (FIG)-based traits, like geography or income. While this was a great step for offering flexibility in terms of the types of population you could define in the Faraday platform, it was cumbersome having to navigate through both Cohorts and Segments to do so.

With today’s update, Segments and its functionality has been folded into Cohorts. Now, in one console, users can define their cohorts by selecting specific traits from either their customer data, or exclusively from FIG. Event streams are no longer required to build a cohort.

Prior to today, your "Recent bulk purchasers" cohort might’ve been simply based on the number of orders in the last 30 days. You can now refine this cohort further to say "Recent bulk purchasers in CA" or "Recent bulk purchasers with income >\$100k." On the flip side, you might also build a cohort without an event stream, such as "Dog owners in CA with an income >\$100k."

We hope that by allowing you to define your preferred population of people—whether that be based on an event stream like orders, FIG traits, or a combination of the two—gives you another building block upon which you can easily experiment with predictions through Outcomes, Personas, and Pipelines.

## What's next?

Coming up, we’ll be revamping data ingress to make it easier to map your data into Faraday. We see this as a critical step towards democratizing data science and empower you to create and maintain a powerful predictive layer atop your martech stack.

---

\*Explore our [product documentation](/docs/) or [talk to sales](/talk-to-sales) to learn more.

Introducing four major updates that empower users to build and deploy their own predictions in the Faraday platform—no data science degree required.

August 2022 product updates: Outcomes, Pipelines, Connections, Cohorts

Headlines abound on the [opportunities](https://www.techrepublic.com/article/companies-are-doubling-down-on-artificial-intelligence-and-machine-learning-due-to-pandemic/) and [dangers](https://www.propublica.org/article/machine-bias-risk-assessments-in-criminal-sentencing) of machine learning. Now armed with [plenty](https://www.propublica.org/article/breaking-the-black-box-when-algorithms-decide-what-you-pay) of [examples](https://www.nytimes.com/2019/08/20/upshot/housing-discrimination-algorithms-hud.html), the Data Science community is at least aware that our data lakes and algorithms can make life more difficult for real people if not properly used. But the root problem can be summed up in pretty simple terms:

> An algorithm contains the biases of its builder.

Examples of bias include:

- **Reporting bias** _(at the source)_ — Maybe the folks who filled out your online survey were mostly young, male, and computer-literate.
- **Implicit bias** _(the call is coming from inside the building)_ — Perhaps your image of an ideal job candidate fits into a mental archetype of which you're only semi-aware, and that image excludes those who don't match the archetype.

At Faraday, we have a handful of approaches we use to minimize these effects.

## Data sourcing

It's possible to get your hands on a pretty broad range of data points these days. Everything from the basics of home value, age, and income to the more esoteric pet ownership and liklihood to buy high-end men's apparel. **Faraday actively excludes data points relating to protected classes**. Race, ethnicity, primary language, and religion are excised from our database entirely and therefore excluded from our predictive models and audience definitions.

Of course, seemingly-harmless demographic variables can often act as proxies for these features, but our stance begins with the most effective levers we have available to pull. And further on in the pipeline we do check _results_ against features like race, but we do it at an aggregated level using standardized census data (more on that below).

## Model priors

We investigate the examples in our training data before they become machine-actionable profiles. In particular, we look at how well they're balanced by age, gender, and geography against the population at large. If there's a significant skew versus the baseline, we know there's a chance the resulting predictive model will show bias, so we rework the inputs.

## Model predictions

When a predictive model is fully-built and ready to be put into action, we typically assign a predictive score to everyone in the country as a matter of efficiency. But this also allows us to check whole populations against statistics that reflect the inclusion or exclusion of protected groups at a census block group level.

If we see - for example - that the lowest scores are concentrated in the block groups with the highest proportions of particular racial or ethnic groups, we'll know that _some_ bias has made it into the model, and we'll revise it.

The bottom line is that these strategies are only a start, and **the best defense against unfair algorithms is multi-pronged and in for the long haul.** If you have questions about how your own applications might be veering away from fairness, I suggest checking out:

- Google's [Marketers' guide to ML fairness](https://www.thinkwithgoogle.com/feature/ml-fairness-for-marketers) or [ML bias crash course](https://developers.google.com/machine-learning/crash-course/fairness/video-lecture)
- ["Abolish big data"](https://d4bl.org/videos/19-abolish-big-data) from [Data for Black Lives](https://d4bl.org/)
- The machine bias case studies at [diversity.ai](http://diversity.ai/#case)

How to reduce the effects of implicit bias in machine learning, from data sourcing to model predictions.

Product

August 2022 product updates: Outcomes, Pipelines, Connections, Cohorts

Mitigating implicit bias in machine learning