What Are Salesforce Marketing Cloud Data Views?

Data Views are one of the most useful and underused features in Salesforce Marketing Cloud. They give you direct SQL access to your engagement data: opens, clicks, bounces, unsubscribes, journey activity, without needing to export anything or wait for a report to generate.

If you are using Automation Studio* to build audiences, suppression lists, or engagement-based segments, Data Views are the source you will query most often.

What Are Data Views?

Data Views are system-generated tables in SFMC that store subscriber engagement and send data. Unlike data extensions*, you cannot create, edit, or delete Data Views. SFMC populates them automatically after each send and journey activity.

You access Data Views through SQL Query Activity* in Automation Studio. The syntax is the same as querying a data extension. You select from the view name using an underscore prefix, for example SELECT * FROM _Open.

Data Views are scoped to the Business Unit* you are querying from. If you are in a parent Business Unit, you will see data for that BU only, not for child BUs.

Available Data Views

Engagement Data Views

These views store subscriber-level engagement events for email sends:

• _Sent: one record per email sent per subscriber, including JobID, ListID, BatchID, SubscriberID, and send date
• _Open: records for email open events, including unique and total opens, browser, operating system, and whether the open was from a mobile device
• _Click: records for link click events, including the URL clicked, subscriber key, and click date
• _Bounce: records for bounce events, including bounce category (hard or soft), bounce type code, and SMTP reason
• _Unsubscribe: records for unsubscribe events, triggered by subscriber action or list unsubscribe
• _Complaint: records for spam complaint events reported by ISPs or email clients

Send and Job Data Views

• _Job: metadata for each send job, including send definition details, send date, email name, and subject line. Useful for joining engagement views to human-readable send information
• _SentNoSends: records for subscribers who were excluded from a send due to suppression or list membership rules

Subscriber Data Views

• _Subscribers: subscriber status, created date, and email address for all contacts in the All Subscribers list. No retention limit applies to this view
• _ListMembership: subscriber membership across all lists in the account

Journey Data Views

• _Journey: metadata for journeys, including journey name, version, and status
• _JourneyActivity: individual activity-level data for journey participants, including entry date, activity name, and outcome

(Salesforce Help: Data Views)

Data Retention in Data Views

Data retention is one of the most important things to understand before building any workflow that depends on Data Views.

Engagement Data Views (_Sent, _Open, _Click, _Bounce, _Unsubscribe, _Complaint, _Job): data is retained for 6 months only. Records older than 6 months are not accessible via SQL query, regardless of broader platform retention settings.

This is a common source of confusion: Salesforce updated its broader Marketing Cloud Engagement retention policy to 730 days (2 years) from June 16, 2025, but that policy applies to tracking reports and SOAP API access, not to Data Views. The retention period for engagement data in Data Views remains 6 months.

_Subscribers and _ListMembership: no retention limit. These views reflect current subscriber state rather than historical event data.

_Journey and _JourneyActivity: retained for 6 months.

Practical implication: if you need engagement data beyond 6 months (for annual suppression lists, long-term re-engagement logic, or historical reporting), you need to export from Data Views into a data extension on a regular schedule before the data ages out.

How to Query Data Views in Automation Studio

Data Views are queried using SQL Query Activity in Automation Studio. The query runs in the context of your current Business Unit and writes results to a target data extension.

Basic syntax:

SELECT
    s.SubscriberKey,
    s.EmailAddress,
    o.EventDate AS OpenDate
FROM _Sent s
INNER JOIN _Open o
    ON s.JobID = o.JobID
    AND s.SubscriberID = o.SubscriberID
    AND s.ListID = o.ListID
    AND s.BatchID = o.BatchID
WHERE o.EventDate >= DATEADD(DAY, -30, GETDATE())

Key points:

• Always filter by date range when querying engagement views. Unfiltered queries across 6 months of data are slow and risk hitting the 30-minute SQL timeout
• Join _Sent to _Open or _Click using JobID, SubscriberID, ListID, and BatchID together. Joining on JobID alone can return incorrect results
• _Open records multiple opens per subscriber per send; use IsUnique = 1 to filter for the first open event per subscriber per send. Note: the IsUnique field can return misleading results in some cases. For a more reliable unique open count, apply aggregation over SubscriberKey using COUNT(DISTINCT SubscriberKey) instead

Common Use Cases

• Re-engagement audiences: query _Open and _Click to identify subscribers who have not engaged in 60 to 90 days, then feed the output into a re-engagement journey or suppression logic
• Bounce suppression: query _Bounce filtered by BounceCategory = ‘Hard’ to build a suppression list updated on a daily or weekly schedule
• Spam complaint suppression: query _Complaint to identify and suppress contacts who have marked emails as spam, protecting sender reputation
• Engagement scoring: count opens and clicks per subscriber over a rolling 90-day window, write scores to a data extension, and use those scores in Journey Builder* decision splits
• Deliverability monitoring: query _Bounce daily and write aggregate bounce rates to a reporting data extension for tracking trends over time
• Journey QA: query _JourneyActivity to confirm contacts are flowing through journey steps as expected, particularly useful during testing and post-launch monitoring

Common Mistakes

• Querying without a date filter: querying _Open or _Sent without a WHERE clause on EventDate forces SFMC to scan 6 months of data; for large sending volumes this causes slow queries and can hit the 30-minute SQL execution timeout
• Joining on JobID alone: _Open and _Click can have multiple records for the same JobID across different list segments; always join on JobID, SubscriberID, ListID, and BatchID together
• Not accounting for the 6-month retention window: building logic that assumes data older than 6 months is available via Data Views will return incomplete results
• Confusing unique and total opens: _Open stores one record per open event, not one per subscriber. Filtering IsUnique = 1 targets the first open event per subscriber per send, but this field can return misleading results; using COUNT(DISTINCT SubscriberKey) aggregation is more reliable for unique open counts
• Not scheduling regular exports: if your use case requires data beyond 6 months, set up a recurring automation to export and append Data View records to a data extension before they age out

Going Deeper

• What Is Salesforce Marketing Cloud Automation Studio?
• Using SQL in SFMC (With Examples)
• What Is a Data Extension in Salesforce Marketing Cloud?
• 10 Signs Your Marketing Automation Needs an Audit

Need help building Data View queries or setting up engagement-based automation workflows? Talk to our team.

Glossary

Automation Studio: a workflow tool in SFMC used to schedule and sequence backend data activities, including SQL queries, file transfers, and data imports. Data Views are queried via SQL Query Activity inside Automation Studio.

Business Unit: a subdivision of an SFMC account used to separate data, sending, and user access across teams, brands, or regions. Data Views are scoped to the Business Unit in which the query runs.

Data extension: a table in SFMC used to store subscriber data or campaign-related information. Data Views are read-only system tables; query results are written to a data extension for further use.

Data View: a system-generated, read-only table in SFMC that stores subscriber engagement and send event data. Accessible via SQL Query Activity in Automation Studio. Most engagement Data Views retain data for 6 months.

Hard bounce: a permanent delivery failure caused by an invalid or non-existent email address. Hard bounces are stored in _Bounce with BounceCategory = ‘Hard’ and should be suppressed immediately.

IsUnique: a field in the _Open and _Click Data Views that flags whether a given event is the first occurrence for that subscriber for that send (value = 1) or a subsequent event (value = 0). Can return misleading results in some accounts. For reliable unique open or click counts, applying COUNT(DISTINCT SubscriberKey) aggregation is more dependable than filtering on IsUnique alone.

SQL Query Activity: an Automation Studio activity that queries one or more data extensions or Data Views using SQL and writes the output to a target data extension.

Soft bounce: a temporary delivery failure caused by a full mailbox, server timeout, or other transient issue. Soft bounces are stored in _Bounce with BounceCategory = ‘Soft’ and require monitoring before suppression.