Understanding Usage and Billing Metrics

The Usage and Billing page provides comprehensive insights into your organization's Iterable usage. This transparency helps you proactively manage your usage and avoid unexpected overages. This article explains the differences between the metrics presented on the Usage and Billing page and other Iterable reports.

To learn more about the Usage and Billing page and the metrics it displays, see Usage and Billing.

# In this article

# Why other Iterable reports don't match Usage and Billing

The Usage and Billing screen uses daily snapshots based on Pacific Time (PT) for Users, Custom Events, and Catalog metrics, and includes deleted data during their retention periods, providing organization-wide metrics with project-level breakdowns.

Other Iterable reports use real-time calculations based on current data and exclude deleted users and events, typically focusing on project-specific or campaign-level data. Because these reports cover different scopes and timeframes, they may not always match the metrics displayed on the Usage and Billing screen.

# Core differences

Timing and Time Zones

• Usage and Billing: Calculated exclusively in Pacific Time (PT) using fixed 24-hour periods (most specifically, at 12:00:00.000 AM PT to 11:59:59.999 PM PT).
• Other reports: Based on actual send time and user-specified timezone settings.

Data Scope

• Usage and Billing: Organization-wide totals with project-level breakdowns available.
• Other reports: Project-specific or selected campaigns only.

Data Lifecycle

• Usage and Billing: Includes deleted users and events in high water mark metrics (for Users metrics only) based on daily snapshots.
• Other reports: Exclude deleted users, deleted events, and archived campaigns.

Calculation Methods

• Usage and Billing: Immutable snapshots taken once daily (typically between 1:05 AM and 1:30 AM PT) for Users, Custom Events, and Catalog metrics; other events captured as they happen.
• Other reports: Real-time calculations based on current data (actual send time).

# When discrepancies are most significant

• End of billing periods: Activities such as sending on the last day of a billing period may result in a metric being partially reported in the next billing period, depending on the timing of the activity and impacts such as time zone sends, quiet hours, and other factors that intentionally delay delivery, as well as occasional SMS processing delays.

• Time zones:

  • Cross-timezone campaigns: Campaigns using non-PT timezone settings may appear in billing on different dates when compared to other reports. Activities in time zones far from PT (Asia-Pacific, Europe) are most pronounced when comparing reports.
  • PT midnight boundary: Campaigns spanning across PT midnight.

• Rate limiting and quiet hours: Rate limiting and quiet hours may cause campaign sends to finish sending the next business day. If this occurs at the end of a billing period, the metrics may be partially reported in the next billing period.

• User and event deletions: Users and events deleted during or after the billing period will still count in billing high water mark metrics during their retention periods (30 days for archived projects, configurable for custom events), but deleted events and users will not be reflected in other reports.

• SMS campaign metrics: SMS campaigns have additional nuances with sending and receiving that are not present in other reports. See SMS campaign metrics vs Usage and Billing metrics below for more details.

# Campaign performance metrics vs Usage and Billing metrics

Metrics from campaign performance reports, including Campaign Analytics, Messaging Insights, Audience Insights, and Dashboard, are calculated differently than Usage and Billing metrics.

Here are some reasons these metrics vary:

• Scope – Campaign metrics reflect campaign performance details for a project or selected campaigns in a project. The Usage and Billing page reflects data usage for an entire organization, but does also provides project-level breakdowns.

• Deleted users – Campaign metrics include events that are associated with existing users. If a user is deleted during the time range being reported on, their usage is not included in campaign metrics. Conversely, Usage and Billing metrics preserve messaging-related events as immutable records, so these metrics count users and events that were deleted during and/or after the billing period.

• Unknown users - Anonymous users aren't added to your Iterable project, so they aren't counted in user volume for billing purposes. Unknown users (users who are added to your Iterable project after satisfying profile creation criteria) and their associated custom events do count towards your contracted allotment of subscribers and custom events.

• Archived projects – When a project is archived, no additional data usage is calculated for it, however, data used from the beginning of the current billing period (first of the month) to the archival date (inclusive) is considered for billing purposes. For example, if you send a campaign, and then archive the project associated with the campaign, the number of messages sent (or, for SMS, message segments sent) is included for billing purposes.

# Time zone and send count discrepancies

Usage and Billing metrics are calculated exclusively in Pacific Time (PT). Campaign metrics are calculated based on the campaign's actual send time, so campaign date ranges and billing periods may not align perfectly.

• Billing data collection timing - Iterable collects usage data for billing purposes during a fixed 24-hour period from 12:00 AM to 11:59 PM PT. This data is reported in Iterable during the next day once it is processed (which takes several hours).

• Campaign metrics timing - Campaign-related metrics are calculated on-the-fly when reports are requested, using the campaign's actual send time and the user's specified timezone settings.

Differences between campaign and billing metrics are more pronounced when:

• Campaigns are sent from time zones that are many hours away from PT (such as Asia-Pacific, Europe).
• Rate limiting and/or quiet hours are active during campaign sends.
• Campaigns use user-specific timezone settings.
• Campaigns span across the PT midnight boundary.

Example scenario:

A campaign sent at 8:00 AM Central European Time (CET), which is 11:00 PM PT the previous day, may appear in billing metrics for a different date than shown in campaign analytics. This is because the data processing is based on the PT midnight cutoff, so activities in time zones far from PT can cross date boundaries between campaign analytics and billing reports.

# SMS campaign metrics vs Usage and Billing metrics

SMS metrics calculate and report the number of segments sent and consider whether a message is SMS or MMS. Billing for SMS services is based on actual data usage, not campaign performance.

# SMS sent vs SMS segments sent

One SMS campaign may correlate with multiple SMS segments. Segmentation occurs when the SMS message exceeds a predetermined character limit.

The number of SMS campaign messages sent may not be equal to the number of SMS segments sent. The campaign count is always less than or equal to the number of SMS segments sent.

Additionally, campaigns may have variations in message length due to factors like personalizations, shortlinks that vary in length, character encoding, special characters, and other dynamic content types. These differences can result in a different number of SMS segments sent for each user receiving the same campaign. This means that the number of SMS segments sent does not always align with the number of SMS campaigns sent (or a multiple thereof).

To learn more about SMS segments, character encoding, and size limits, read Creating SMS Templates.

# SMS processing delays

After Iterable sends a message request to your SMS provider, there can be a
delay before receiving the final delivery status of the message back from the provider. The timing of the final delivery status determines when an SMS is billed. This may cause SMS messages sent on one day to be charged on the next day (in rare cases, the delay may be up to five days).

You'll most likely notice this impact for SMS messages sent on or near the last day of a billing period.

# Examples of SMS campaign metrics vs SMS Usage and Billing metrics

These examples illustrate why SMS campaign metrics can differ from SMS billing usage metrics:

Single SMS segment

For an SMS campaign with a single segment, the number of SMS sent equals the number of segments sent (assuming all SMS were successfully delivered by the SMS provider). You'd see metrics such as:

• 363,657 total SMS sent (campaign metric)
• 363,657 SMS sent (Usage and Billing metric)
• 363,657 SMS segments sent (Usage and Billing metric)

Multiple SMS segments

For an SMS campaign with 3 segments, metrics may look like this:

• 363,657 total SMS sent (campaign metric)
• 363,657 SMS sent (Usage and Billing metric)
• 1,090,971 SMS segments sent (Usage and Billing metric)

Variable SMS segments

If an SMS campaign sends messages that vary in length from one user to the next (because of dynamic data), metrics may look like this:

• 363,657 total SMS sent (campaign metric)
• 363,657 SMS sent (Usage and Billing metric)
• 581,851 SMS segments sent (Usage and Billing metric)

MMS campaign

For an SMS campaign that sends MMS messages, total SMS sent equals MMS sent, and metrics may look like this:

• 363,657 total SMS sent (campaign metric)
• 363,657 MMS sent (Usage and Billing metric)

Delayed SMS

If your SMS campaign was partially delayed, and its campaign sends or delivery notifications were delayed from the SMS provider, that may impact billing metrics by changing the date a message is billed.

Reasons for delayed SMS campaign sends or delivery notifications include (but aren't limited to):

• Campaign rate limiting
• Sending in the recipient's time zone
• Send time optimization
• Quiet hours
• Processing delays

Here is an example of that scenario:

• Campaign metric: 369,046 total SMS sent
• Usage and Billing metrics:
  • 290,925 SMS sent on January 18th (billing period 1)
  • 72,732 SMS sent on January 19th (billing period 2)
  • 5,389 SMS sent on January 20th (billing period 2)

In this scenario, a campaign was activated on January 18th, and some of its campaign sends or delivery notifications were delayed for some reason, which impacted billing metrics by changing the date a message is billed. As a result, the campaign was billed across two different billing periods.

# Custom event volume vs Usage and Billing metrics

Data Schema Management event volume counts are sums of events that are currently stored in Iterable. Usage and Billing metrics reflect snapshot data as of yesterday's date (or the previous day, if yesterday's data is not yet available), and a high water mark metric for the current billing period.

# Event storage by status

Custom events are stored in Iterable based on the event status. There are some nuances to the event volume counts presented in the Data Schema Management screen:

• Saved events are events that are currently stored in Iterable whenever a new event is tracked for a user.

  These events are included in the event volume counts for billing purposes, during the period they are stored.

• Discarded events are events that are currently stored in Iterable but are discarded when a new event is tracked for a user. This event status is generally used to trigger automation workflows but prevent event storage.

• Deactivated events are events that are not currently stored in Iterable and are not actively triggering workflows. These events may still have historical events stored, and these events are included in the event volume counts for billing purposes.

# Historical events (discarded, deactivated, and deleted events)

There can be instances where a custom event was previously saved, and some events were stored, but then later the event was changed to a different status (discarded or deactivated). In this scenario, all stored events are included in the total events stored for billing purposes until they are deleted from Iterable by directly deleting the event or by event retention policies.

Deleting events will reduce Data Schema Management event volume counts and the current volume of events stored, but they are included in the high water mark event volume counts until the end of the current billing period.

For information about viewing event usage details, see Monitoring Custom Event Usage.

To learn more about custom event data retention, see Managing Custom Event Retention.

# Segmentation vs Usage and Billing metrics

Segmentation is the primary way to query user data in Iterable. Things to know when looking at user counts from segmentation vs Usage and Billing metrics:

• Segmentation counts are real-time information based on currently stored data, while Usage and Billing metrics are based on daily snapshots of data stored during each billing period.
• Segmentation counts cannot account for deleted users or deleted events, while Usage and Billing metrics do.
• Segmentation queries data for one project at a time, while Usage and Billing metrics are based on the entire organization. Remember to view the project breakdown when reviewing metrics for a specific project.

For example, if you delete a large group of users, they will not be included in segmentation counts when you run a query after the deletion. However, these users were already counted during daily snapshots for billing purposes and they're included in the high water mark metric until the end of the current billing period.