Want to know the difference between Meta’s Datasets, Data Sources, Integrations, and their relationship with the Ads Account in reasonably simple terms without getting too technical? 

You’re in the right place!

Data Sources & Integrations

A business might sell its products at various locations - an e-commerce website, an app, or a physical store, just to name a few. At each of these locations, users interact with the business. 

For example, a user visiting the business’s e-commerce website and adding a product to their cart is an interaction. Another user who purchases a product using the company’s app is another example of an interaction. 

In this context, the e-commerce website and the app are data sources. Each user interaction, whether adding a product to a shopping cart or purchasing it, triggers an event that each data source sends to Meta using various software. 

This software is called an Integration. It is a mechanism the data source uses to send event data to Meta for further processing and analysis. 

For example, an e-commerce website might use two types of software (read “Integrations”) to track and log user events that happen on the website: 

• Pixel
• Conversions API

In the above example, the e-commerce website is a data source, and Pixel and Conversions API are Integrations.

The same business might also use an app (again, a data source) to sell its products. Conversions API or Facebook SDK are different Integrations that can transfer user data to the Meta servers.

To sum up, it is two different data sources we are talking about here: 

• E-commerce Website
• The App

Imagine that the app events are tracked using Facebook SDK Integration. As such, our ecosystem consists of three Integrations: 

• Conversions API (website)
• Pixel (website)
• Facebook SDK (app)

An integration is software a data source uses to transfer users' event data to the Meta servers. Different integrations serve different purposes; for example, the Pixel primarily collects data through browser-based interactions, while the Conversions API enables server-to-server communication. Data sources are client-facing entities where users interact (e.g., explore, and purchase products) with the business.

Pixel & Conversions API Integrations for a single website

It is common and considered a best practice to use both Pixel and Conversions API integrations simultaneously to collect event data occurring on the same website. Pixel sends event data to the Meta servers using browser network requests (browser-to-server reporting). 

These requests may get lost along the way or could be affected by ad-blocking extensions and plugins, which could mean that not all event data is being received. Not collecting all user data could lead to smaller audience sizes and potentially unattributed conversions. 

To remedy these tracking inconsistencies, Meta came up with server-to-server reporting. Event data sharing with the Conversions API no longer relies on the browser. Events are stored on the company’s server and then sent directly to Meta’s server for parsing. 

As such, whenever a user adds a product to their shopping cart, the same AddToCart event is sent to the Meta servers by Pixel (browser-to-server) and Conversions API (server-to-server). 

Both events have the same hashed parameter, which Meta uses to deduplicate the same event coming from various Integrations. 

Therefore, it is not uncommon for two integrations to track data occurring on a single data source.

Most businesses have just one data source

That said, things rarely become as complicated as in the above scenario. Most businesses have just one data source (most commonly a website), where events are tracked using a single Integration (generally Pixel). 

What’s the deal with the datasets, you ask? Here goes.

Datasets

To keep things organized, Meta came up with another event-related resource type: a dataset. A dataset is like a container that groups related data sources and their Integrations. 

A business might have multiple datasets, depending on how big and complex its structure and business operations are. However, when it comes to SMB business, they usually need a single dataset.

Here is a sample scenario where more than a single dataset might be needed. Imagine a large company that sells products in Europe and the US. 

To make our example more vivid, the company's name is ShopMaster, and they have separate websites and apps for each region:

For the US:

• shopmaster.com - e-commerce website
• ShopMaster US - an iOS app

For Europe:

• shopmaster.eu - e-commerce website
• ShopMaster EU - an iOS app

These are four different data sources, each using a separate Integration to send event data to Meta. 

One of Meta’s products is Events Manager. It is a user interface element that parses and displays events from whichever dataset we feed into it. 

Each dataset has a unique ID. Let’s say ShopMaster’s dataset ID is “397772057472495.” When we open this dataset in the Events Manager, its ID gets appended to the URL (https://business.facebook.com/events_manager2/list/dataset/397772057472495/), and whatever event data is part of this dataset gets parsed and displayed in a human-readable format.

If ShopMaster had a single dataset for all 4 data sources, the Events Manager would load events from all four data sources, making it difficult to segment events to a specific source for further analysis and troubleshooting should there be any issues. 

With two datasets instead of one (e.g., Dataset—EU and Dataset—US), ShopMaster could host EU-related data sources in Dataset—EU and US-related ones in Dataset—US. Opening each dataset in the Events Manager would only include event data related to each region. Things would become less cluttered and more straightforward.

Again, based on my experience, most businesses have a much flatter setup with just one dataset—a website as a single data source and Pixel as its Integration. Some have an extra Conversions API Integration for the website to improve the match rate quality, but that’s pretty much it.

Datasets primarily exist to manage event data across different sources and ensure organization in complex multi-region setups.

We can add new integrations from related data sources directly within the Events Manager. 

So, if you only had a website but ended up building an app, you can create a new integration to import the app’s event data into the same dataset used to collect your website data:

Again, datasets are purely for organizational reasons. If you had a website and an app for the same business targeting the same audience, you could create two separate datasets and use one to hold website event data and the other to store app event data. The choice is yours.

Flexibility and freedom with tools like Meta’s tracking systems (or any marketing tech, really) give you a lot of power, but they can also lead to a bit of a "complex maze." 

You get to shape things to fit your business needs, but that also means you're responsible for making sense of how everything interacts.

It’s all about balancing the freedom to customize and the clarity to manage it smoothly.

Ad Accounts

When setting up a new campaign in Ads Manager, the first step is to select the campaign objective to determine the available Conversion Locations at the ad set level. 

In the Conversion Location section, you'll choose an Integration (such as Pixel or SDK), which implicitly defines the data source (like a website or app) where event data is collected. 

While the ad account itself doesn’t directly interact with the dataset, it works through the selected Integration within that dataset to optimize and track your campaign's performance.