Articles in this section

See more

Email Open Tracking

Email open tracking helps you understand how recipients engage with the messages you send. This article explains when Iterable records an emailOpen event, when it doesn't, where you can view email open event data, how open tracking affects metrics, and how to monitor tracking-pixel consent per recipient.

NOTE

If you have questions about pixel tracking consent or regulatory requirements related to email open tracking, see Compliance considerations. To learn how to assess the impact of pixel consent on your messaging, see Control open tracking with user-level consent.

# In this article

# How email open tracking works

When Iterable sends a standard HTML email, it adds a hidden 1x1 tracking pixel at the start of the email's <body> element during send-time processing. The pixel is not part of your template. Iterable injects it automatically unless the project has open tracking disabled, or the project is set to respect user-level tracking-pixel consent and the recipient didn't consent or is missing the consent field. See Compliance considerations.

When an email client displays images in a message, it downloads the tiny tracking image from Iterable's servers. Iterable treats that image request as an open and records an emailOpen system event. An inbox provider or proxy can also download the image, sometimes before or without a recipient viewing the message.

Iterable evaluates properties of the image request against known automated-open patterns and records the result in the isBot field in the email open event. This is a heuristic and does not confirm whether a human viewed the message.

Open metrics are useful directional and trend data, but they do not always reflect recipient behavior. Their completeness can be affected by image blocking, privacy proxies, bot prefetching, and other factors.

# When Iterable records an email open event (emailOpen)

Iterable records an email open event (with event name emailOpen) when all of the following are true:

  • Open tracking is enabled for the project (tracking is enabled by default).
  • The rendered email included the tracking pixel.
  • The recipient's email client, inbox provider, or a proxy loads the image.
  • The pixel request reaches Iterable.

If the project is set to respect user-level tracking-pixel consent, Iterable includes the pixel in marketing emails (and therefore only records an emailOpen event) when emailTrackingPixelConsent is true. Transactional emails aren't subject to that check. See Control open tracking with user-level consent.

An email open event doesn't always mean a human recipient intentionally opened and read the message. Privacy proxies, inbox providers, and security scanners can load the tracking pixel automatically, causing an emailOpen event to be recorded in Iterable.

# When Iterable doesn't record an open

An open is not recorded when the tracking pixel doesn't load or when Iterable intentionally avoids recording an open. For some email use cases, Iterable doesn't include a tracking pixel in the email HTML. External factors can also prevent the tracking pixel from loading.

Common scenarios where opens are not tracked, which can make reported open rates appear lower than they may actually be, include:

  • Images are blocked — Some email clients or user settings block images from loading. If images are blocked, the pixel doesn't load, and an open is not recorded.
  • Open tracking is disabled — When open tracking is disabled for a project, Iterable doesn't add its open tracking pixel to email HTML for messages sent from that project.
  • The recipient didn't consent for tracking-pixel use — When the project is set to respect user-level tracking-pixel consent, Iterable doesn't add the pixel to marketing emails if emailTrackingPixelConsent is false or missing. No pixel means no emailOpen.
  • A recipient views the message using the View in browser feature — View-in-browser email views don't record opens. This prevents shared or revisited page hits in browser views from inflating open metrics.
  • The message is a proof send — Proof sends use the same consent policy as live sends. They may include an open pixel, but the pixel URL routes to a test endpoint that doesn't record an emailOpen event.

# Other conditional behavior

Some email clients and message formats handle open tracking differently:

  • Privacy proxies — Email clients such as Gmail and Apple Mail can request images through a proxy. As a result, an open event might not reflect a recipient's device, location, or whether they viewed the message.
  • Bot prefetching — Security scanning tools and mail preprocessing services can load images automatically, producing open events that are not the result of a human opening the email.
  • AMP email — AMP email uses an AMP-compatible tracking element instead of a standard HTML pixel when the send includes open tracking. AMP uses the same send-time decision as standard HTML email.

If you need to honor tracking-pixel consent per recipient, you can turn on user-level consent for the project. Iterable then checks the emailTrackingPixelConsent field on the user's profile when it renders a marketing email, and adds the tracking pixel only when that field is true.

This control is off by default. Until you enable it, Iterable doesn't evaluate emailTrackingPixelConsent, and pixel behavior follows the project's existing open-tracking setting.

  1. Go to Settings > Project Settings.
  2. In the Email section, turn on Use consent-based open tracking.

IMPORTANT

Turn this setting on only after you've stored consent values on user profiles. If you enable it first, marketing emails omit the tracking pixel for every user whose emailTrackingPixelConsent field is false or missing. Your organization is responsible for collecting and updating users' consent for email tracking pixels in your own systems.

If your CSM previously disabled open tracking for all users in this project, that project-wide restriction conflicts with user-level consent. Before you enable Use consent-based open tracking, contact your CSM to disable the project-wide restriction. After they disable it and you turn on user-level consent, Iterable tracks opens for users who have consented. Users who haven't consented or are missing the consent field continue to have the tracking pixel omitted.

# The emailTrackingPixelConsent field

emailTrackingPixelConsent is a system-defined boolean on the user profile. Use this field rather than a custom field with a similar name. For this field, the following values are handled as follows, depending on the message type:

Value Marketing email Transactional email
true Tracking pixel added Tracking pixel added
false Tracking pixel omitted Tracking pixel added
Missing or not a boolean true Tracking pixel omitted Tracking pixel added

Iterable treats only an exact boolean true as consent. Iterable doesn't treat the string "true" as consent.

Iterable doesn't check emailTrackingPixelConsent for transactional emails, so those sends always include the tracking pixel. Iterable classifies a send as marketing or transactional by the message channel, not by campaign name or template. If you send marketing content through a transactional channel, Iterable includes the tracking pixel regardless of the user’s consent value, but applicable regulations may still require consent for that send. Your organization is responsible for ensuring that channel classification in Iterable reflects the regulatory treatment of your messages.

Iterable doesn't collect tracking-pixel consent from recipients and doesn't backfill existing profiles. You collect consent in your own systems, then write the boolean to Iterable using existing profile-update paths:

NOTE

If you need to capture tracking-pixel consent in Iterable, you can use a Journey to set emailTrackingPixelConsent when:

  • A recipient clicks a tracking opt-out link in an email.
  • A user matches profile attributes you use to apply a consent policy.

Iterable doesn't provide a built-in tracking opt-out link. Contact your Iterable Customer Success Manager for help setting this up.

To withdraw consent, set the field to false. Blank values in a CSV import don't change the stored value.

Tracking-pixel consent is separate from consent to receive marketing email. Channels, message types, and preference centers don't set emailTrackingPixelConsent.

Iterable decides whether to include the pixel when it renders the email. Later changes don't rewrite messages that were already sent.

  • Future marketing emails use the current field value and project setting.
  • Previously sent emails keep the HTML that was rendered at send time. If a pixel was included, it can still record an emailOpen if the image loads.
  • Click tracking isn't affected.

If you use Stored Messages to store email send payloads, you can review the stored HTML to see whether the send included the tracking pixel. System webhook emailSend payloads can also include pixelInjectionOutcome (InjectTracking or Omit) and pixelInjectionReason.

# Compliance considerations

IMPORTANT

This information is subject to change and does not constitute legal advice or a compliance determination.

You are responsible for evaluating how email open-tracking requirements apply to your organization, including:

  • How you collect, manage, and store user consent
  • How you provide notice about tracking-pixel use
  • Whether the tracking pixel needs to be turned off

Consult with your compliance and privacy teams to determine how these requirements apply to your organization. Iterable cannot provide advice on how to comply with these requirements.

In some regions, privacy regulators have issued guidance that treats email tracking pixels similarly to non-essential cookies. For example, CNIL in France and Garante in Italy have issued guidance that distinguishes consent to receive marketing emails from consent to use tracking pixels. Under this guidance, organizations may need separate consent for tracking pixels.

Marketing subscription consent in Iterable is currently managed through channels, message types, and preference centers. Marketing subscription consent is separate from any tracking-pixel consent that may be required under applicable regulations.

Iterable stores each user's current tracking-pixel consent on their profile. It doesn't maintain a complete history of consent changes. If your organization needs to demonstrate consent as of a specific date, such as when a particular email was sent, maintain a timestamped consent log in your own systems.

If you determine that you are subject to open tracking regulations, you can honor tracking-pixel consent per recipient or disable open tracking for the project. To disable open tracking for an entire project, contact your Iterable Customer Success Manager.

NOTE

You can honor tracking-pixel consent per recipient with emailTrackingPixelConsent, or disable open tracking for the whole project. Iterable doesn't determine which approach applies to your organization.

# Viewing email open events

You can view emailOpen events in Iterable, export them with APIs, or send them to external systems with webhooks and Snowflake.

# Viewing email open events for a user

To view email open events associated with a user:

  1. Go to Audience > Contact Lookup and search for the user.
  2. Go to Events > History to view the Events History page.
  3. Use filters or search to locate emailOpen events.

# Exporting email open events with Iterable APIs

Use Iterable's Export APIs to retrieve historical emailOpen event payloads for your project.

# Sharing email open events with external systems

You can send email open events to external systems in several ways, based on what your vendor preferences are and how you need to access the data:

  • System webhooks — Send an emailOpen payload to your endpoint when Iterable records an open.
  • mParticle — Forward email opens as mParticle custom events named emailOpen when you configure and enable the mParticle system webhook.
  • Segment — Forward email opens to Segment as Email Opened Track events.
  • Snowflake Data Share — Access email open records incrementally in your data warehouse.
  • Data Sync — Send email open records incrementally to a supported data destination.

# Email open event data

When the tracking pixel loads, Iterable can record an emailOpen system event. The event includes identifying information about the send and contextual data captured from the pixel request.

Because email open events are highly variable in their data fields, Iterable doesn't provide complete schema documentation in this article. However, the event can include data captured from the HTTP request that loads the tracking pixel.

# Data collected from the tracking pixel request

Field Description
ip IP address included with the pixel request. This can be the address of an email client or proxy.
userAgent User agent string reported by the email client or proxy that requested the pixel
userAgentDevice Client or device classification derived from the user agent that requested the pixel
proxySource Identifies the proxy if the open came through one, for example Gmail
createdAt Timestamp of when the pixel request was received
isBot Indicates that Iterable identified the request as most likely performed by a non-human user agent. This is a heuristic, not confirmation that a request was automated.

This signal is used to calculate filtered open metrics.
city*, region*, country*, timeZone* Location data derived from the IP address.

* These fields are available when GeoIP lookup is enabled, except for Gmail-proxied opens.

# Data retention

Open events are classified as Iterable system events, which are retained in Iterable's data storage for 2 years by default, unless your contract specifies otherwise. See Events Overview for more information about Iterable system events and their retention.

# How open tracking affects metrics and reporting

Open tracking data feeds several email metrics in Iterable. Some metrics are calculated directly from emailOpen events, while others include assumed opens, which count a click as an open when a recipient almost certainly opened an email by clicking a link even if the pixel did not load.

When a project respects user-level tracking-pixel consent, marketing emails to users with emailTrackingPixelConsent set to false or missing don't include a pixel and don't produce emailOpen events. Open counts decrease for those sends. A missing emailOpen doesn't always mean the recipient didn't open the message—the pixel might not have been included. Metrics that include assumed opens can still count a click as an open.

If you turn the setting on during an active campaign, or only some recipients provide consent for pixel tracking, campaign reporting can include both tracked and untracked messages.

# Metrics that directly reflect open tracking

The following metrics depend on emailOpen events. If open tracking is disabled, some recipients don't consent or are missing the consent field, or opens are incomplete, these metrics decrease or become unavailable:

NOTE

Nova features like Send Time Optimization and Brand Affinity use open history to make recommendations. They work best when open tracking is on. If tracking is off, or if some recipients haven't consented, you'll have less open data, which may impact Nova performance and recommendations.

# Metrics that include assumed opens

These metrics count a click as an open to account for when a recipient clicks a link but the tracking pixel did not load:

Email open data is used by several Iterable features. If open tracking is disabled, some recipients didn't consent or are missing the consent field, or email open data is incomplete, these features may be affected:

# Disabling open tracking

If your organization has consent requirements that prevent you from using open tracking for every recipient, you can honor consent per user or disable it at the project level.

To disable open tracking for an entire project, ask your Iterable Customer Success Manager to disable it for your project.

Enabling user-level tracking-pixel consent turns off project-level open-tracking disablement for that project.

# What changes when open tracking is disabled

When open tracking is disabled for a project, Iterable doesn't add its tracking pixel to the email HTML for messages sent from that project. As a result, new emailOpen events and open-based metrics are not recorded for those messages.

After your CSM disables open tracking, future emails from that project no longer include the tracking pixel. This includes future sends from active and recurring campaigns, as well as scheduled campaigns that have not started. Emails that Iterable has already rendered for sending or previously sent are not affected.

NOTE

Iterable does not record whether open tracking was enabled for an individual send. If you change this setting during an active campaign, campaign reporting can include both tracked and untracked messages.

If you use Stored Messages to store email send payloads, you can review your stored messages data to determine whether the email HTML that was sent included the tracking pixel.

Open-based metrics stop receiving data for emails rendered after tracking is disabled. This includes total opens, unique opens, and open rate. Delivery and bounce metrics are not affected because they do not depend on open events.

The following features are also affected:

  • Experiments — Experiments that use email opens as a winning criterion stop receiving new open-conversion events. Experiments that use other conversion events continue to collect those events.
  • Journeys — Journeys that start or branch when a recipient opens an email stop receiving new qualifying activity.
  • Segmentation and Audience Insights — Queries based on emailOpen stop receiving new qualifying activity.
  • Data out features - When disabled, any data out features that use email open data will stop receiving new data.

# What doesn't change when open tracking is disabled

Historical email open data before the change is not affected.

Click tracking is not affected by disabling open tracking. Open tracking and click tracking use separate mechanisms. Disabling open tracking removes Iterable's tracking pixel from email sends, but click tracking continues to work through link rewriting. Accordingly, metrics that include assumed opens can still reflect assumed opens for clicks that are tracked.

# Resuming open tracking

When you ask your Iterable Customer Success Manager to resume open tracking, Iterable will resume adding the tracking pixel to future emails from that project.

Resuming tracking does not provide retroactive open data.

# Want to learn more?

To learn more about related email behavior and event data, see these articles:

Related articles