While data security has always been an important part of doing business, in recent years it’s become an increasingly urgent consideration. Public scandals, like those of [Facebook and Cambridge Analytica](https://www.wired.com/story/cambridge-analytica-facebook-privacy-awakening/), and growing government regulations, to the tune of GDPR and CCPA, have consumers on high alert about how their data is being used.

If you find yourself among the many brands looking for ways to build trust with your audience, you’ll need to consider not only how you manage data security at your organization, but also how you communicate with your clients. Transparency is an important part of security—clients and collaborators alike should be able to quickly and easily understand what you’re doing to protect their data. The more effectively you achieve that, the more trust you’ll be able to build.

Read on to explore the three most common questions our customers ask us (and might ask you!) about data security, and how we answer them. Feel free to use these as a blueprint to guide your own practices, though the particulars will vary from industry to industry.

## “How is your company audited for data security?”

_Our answer: Check out our [SOC 2 audit](/security)!_

If you offer a cloud-based product or service, and want potential customers and collaborators to see you as a trusted partner, a clean SOC 2 audit should be your gold standard. SOC 2 audits are exhaustive reviews performed by certified public accountants to ensure that SaaS companies meet strict security requirements and provide a safe operating environment for managing sensitive data. In order to retain a clean SOC 2 audit, companies must renew their audit annually.

The existence of SOC 2 as a process reassures clients, but it also benefits the company. As Seamus Abshere, Faraday co-founder and Chief Technology Officer, puts it, “SOC 2 audits provide a chain of trust going from the client all the way to Faraday and to our vendors (like cloud hosting providers). At every level, auditors are involved to ensure that policies and procedures are followed.”

## “How is my data transferred and stored?”

_Our answer: All data is stored with trusted cloud vendors (Amazon, Google Cloud), encrypted in transit and at rest, and access is controlled using multifactor authentication._

Simply put, encryption is a no-brainer. When customers share data with brands, they’re trusting them to protect it from bad actors, and encryption is the standard practice for doing so. “At this point, using unencrypted data is like a surgeon not washing their hands before surgery,” asserts Abshere. “If you are not encrypting everything, it's just malpractice.”

It's standard practice for clients and vendors to ask about encryption, but at this point, the answer should always be "yes."

## “What data do you actually use, and how?”

_Our answer: We live by the _[_“If we don’t need it, we don’t collect, store, or transmit it”_](https://faraday.ai/blog/using-ethical-data/)_ mentality._

It’s essential for brands to understand what data they have access to in order for them to put the proper safeguards in place. Here at Faraday, where we handle the data of hundreds of leading brands, we’re extremely clear with clients about what we use—and what we don’t.

**“We don’t want your account numbers, social security numbers, health records — any of that,” Abshere says.  “All we need are known identifiers (like billing information) and transaction information. We do not require or accept account numbers, so we don't affect our client's PCI DSS scope.”** In our case, we leverage this personally identifiable information (PII) to match consumers with our identity graph and train machine learning algorithms to make predictions about a brand’s current or potential customers.

Another important step is to prevent any co-mingling of your clients’ data, particularly if your clients are competitors. At Faraday, we understand this is a serious concern, and we’re careful to prevent it. “Data is logically separated, and everyone’s predictions are based only on their own data plus Faraday's identity graph,” explains Abshere. "Mixing client data would be a huge risk."

## Security is always a priority

No matter your role at a given company, you’re always a steward of your customers’ data. Various teams, from security to engineering to marketing, may operate on very different datasets and roadmaps, but it’s crucial that everyone contributes to a trusted relationship with clients and collaborators, working together to efficiently and transparently implement best practices.

Transparency is an important part of your security practices—clients and collaborators alike should be able to quickly and easily understand what you’re doing to protect their data.

Building trust: How brands can answer common data security questions

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

Building trust: How brands can answer common data security questions

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

Mitigating implicit bias in machine learning