How to Increase Web Push Impressions

"The push was sent, but impressions are far below expectations" is one of the most common questions from Web Push integrators. Impressions are not an isolated metric; they are the result of losses accumulated across subscription, sending, delivery, and other stages. This article helps you locate the cause of low impressions layer by layer along the funnel, provides optimization measures for each type of cause, and closes with a sustainable, comprehensive approach.

Align on Definitions First: Where Impressions Sit in the Funnel

EngageLab records each push by the following stages. See Push Statistics and the Statistics API for the definition of each stage:

flowchart LR
    plan["Planned targets"]
    targets["Valid targets<br/>devices active in the last 365 days"]
    sent["Sent<br/>send task created by the server"]
    delivered["Delivered<br/>actually delivered to the Web client"]
    impressions["Impressions<br/>successfully displayed on the device"]
    clicks["Clicks"]

    plan --> targets --> sent --> delivered --> impressions --> clicks

Three points about "impressions" must be clarified first; otherwise it is easy to mistake a statistics-definition issue for a push issue:

1. Impressions are reported by the SDK. In the Callback API, the Impression status is defined as "Web Push notifications and in-app messages reported as successfully displayed by the SDK"; see Callback API. Displays that are not reported through the SDK are not counted as impressions.
2. Custom messages are not counted as impressions by default. The message (custom message) in the Create Push API is not displayed in the browser; it is passed through to your web page. To count impressions, you must call customDisplayReport from your page; see Web SDK API.
3. The statistics window is 5 days. Deliveries and impressions that occur more than 5 days after a successful send are not counted and no longer trigger callbacks.

Therefore, when investigating low impressions, first distinguish between "low impression rate" (delivered but not displayed) and "low impression count with a normal impression rate" (the problem lies upstream in subscription, sending, or delivery). The causes and solutions for these two cases are completely different.

Part 1: How to Investigate the Cause of Low Impressions

Work through the funnel from upstream to downstream, checking the data at each layer before locating the cause.

1.1 Is the Subscriber Pool Large Enough?

The ceiling on impressions is set by the size of your subscriber base. If there are few subscribers to begin with, even excellent delivery and impression rates cannot produce meaningful impression volume.

Where to look:

• User Overview: compare "subscribed users" with "active users". Subscribed users are the number of unique user devices that have subscribed and agreed to receive notifications. If subscribed users are far below active users, many visitors never completed authorization.
• Overview: check the device notification permission enable rate and the number of users who have turned off notifications.
• Data Query: spot-check the online status and last online time of specific Registration IDs to confirm the subscription is still valid.

Common causes (see FAQ and Basic Settings):

• The "direct request" mode shows the browser's native permission prompt. Once a user clicks Block / Don't Allow, permission cannot be requested again unless the user changes the browser settings.
• The site does not use HTTPS or the domain is not configured in the console, so the native permission prompt cannot appear and subscription is impossible.
• The Service Worker is not placed in the site root, or its scope conflicts with an existing PWA Service Worker, causing subscription to fail.
• iOS users have not added the site to the home screen, or the permission request is not triggered by a user gesture.
• Users are in incognito, private browsing, or guest mode, which do not support Web Push.
• When the same user_str subscribes on multiple browsers or devices, the new subscription replaces the old one, and only the last subscribed device receives messages.

1.2 Are There Heavy Losses from Valid Targets to Sent?

Where to look:

• Push History: compare valid targets with sent for a single push, and check the failure reasons in the message details.
• The push lifecycle query in the Statistics API: the target_invalid and sent_failed statuses locate the loss stage for specific devices.

Common causes:

• Valid targets are defined as "active in the past 365 days"; long-inactive subscriptions do not become valid targets.
• Per-device hourly / daily / weekly push limits or an allowed push time window are configured in Advanced Settings; messages exceeding the limit or outside the window are discarded directly.

1.3 Are There Heavy Losses from Sent to Delivered?

This is the layer most easily mistaken for "low impressions". If delivered is low, impressions will be low, but the impression rate may be perfectly normal.

Where to look:

• The delivery rate of a single push in Push History; delivery data split by browser (Chrome, Safari, Firefox, Edge, EngageLab channel, etc.) in Push Statistics.
• The sub field returned by the Statistics API shows delivered and impressions separately for notification and message; fields such as engageLab_web, chrome, safari, firefox, and edge split the data by channel.

Common causes (see Create Push API and FAQ):

• time_to_live is set to 0: offline messages are not retained, and only users currently online receive them. The default is 86400 seconds (1 day), and the maximum is 15 days.
• Channel differences: the EngageLab channel requires the user to have your site page open; system channels (Chrome, Edge, Firefox, etc.) deliver as long as the browser process exists in the operating system, but not once the browser has fully exited; the Safari system channel does not require the browser to be running.
• The user cleared browser cookies / cache, and the vendor channel subscription was lost with it. If notification permission is still "allow", the SDK re-subscribes automatically when the user returns to the site and a new Registration ID is issued; if permission has changed to "ask" or "block", no automatic re-subscription occurs.
• The third_party_channel.w3push.distribution strategy does not match your users' behavior, for example forcing mtpush (EngageLab channel only) when users rarely stay on the site.
• The browser vendor channel is unstable; the FAQ recommends switching to EngageLab-channel-first delivery in this case.

1.4 Are There Losses from Delivered to Impressions (Low Impression Rate)?

Only when delivered is normal but impressions are clearly low do you have a genuine "impression rate" problem.

Where to look:

• "Delivered / Impressions" and the ratio shown per platform in the Push History details.
• The Impression and impression_failed events of the Callback API.

Common causes:

1.5 Troubleshooting Checklist

Work through the items in the order below, ruling out definition and upstream issues before examining impressions themselves:

Part 2: How to Optimize Once the Cause Is Found

2.1 Grow the Subscriber Pool

• Switch to guided request (soft prompt). Under notification permission in Basic Settings, select "guided request": first explain the value of notifications with a custom prompt, and trigger the native permission prompt only after the user shows intent. This prevents users from clicking Block before understanding the value, which would make permission permanently unavailable. The soft prompt supports an initial prompt interval (default 3 days) and a follow-up interval (default 7 days) until the user subscribes.
• Make sure the prerequisites are complete. Use HTTPS and configure your domains under [Integration Settings] - [Website Domain] (up to 100). Place the Service Worker file in the site root for maximum scope. If the site already has a PWA Service Worker, merge the two or make sure their scopes do not overlap; see the Web SDK Integration Guide and FAQ.
• Guide iOS users. Safari on iOS / iPadOS 16.4 and later requires the user to add the site to the home screen and open it from there, and permission must then be triggered by a user gesture (such as tapping a subscribe button). A banner on the page to guide users is recommended.
• Avoid devices displacing each other. If you identify users with user_str, note that when the same user_str subscribes on multiple browsers / devices, only the last subscribed device receives messages. To cover all of a user's devices, do not reuse the same user_str across devices.
• Do not lose subscriptions during migration. When migrating from another provider to EngageLab, handle the old Service Worker as described in How to Prevent Subscriber Loss During Web Push Migration; users who have already granted permission will not be prompted again after initialization.

2.2 Reduce Losses from Valid Targets to Sent

• Configure per-device push limits and the allowed push time window in Advanced Settings according to business needs. Frequency control protects the user experience, but overly strict settings discard messages outright; evaluate them together with your push plan.
• Periodically use the Delete User API to remove subscriptions confirmed to be inactive, so that valid targets more accurately reflect reachable users and statistics are not diluted by invalid subscriptions. Deletion is irreversible; proceed with care.

2.3 Improve Delivery

• Set time_to_live appropriately. Do not use 0; keep the default of 1 day or extend it according to content timeliness, up to 15 days. For content that is not time-sensitive, a longer offline retention period lets offline users still receive it after reopening the browser.

• Choose a matching distribution strategy. In third_party_channel.w3push.distribution:

  • first_ospush (default): system channel first, falling back to the EngageLab channel if unavailable;
  • secondary_push: EngageLab channel first, falling back to the system channel when the user is offline; the Create Push API recommends this option;
  • mtpush: EngageLab channel only, suitable only when users stay on the site for long periods;
  • ospush: system channel only.

  When the browser vendor channel is unstable, you can temporarily switch to EngageLab-channel-first delivery.

• Use override_msg_id with care. Overriding a previous notification that has not been cleared means the user only sees the latest one. This suits content-update scenarios, not scenarios where you want multiple notifications to remain visible.

• Use rate-limited push for campaigns or large batches. Use big_push_duration to spread the push evenly over a specified number of minutes (up to 1440) and avoid instantaneous peaks.

2.4 Improve Impressions

• Prefer notifications. For content that must be displayed in the notification area and counted as impressions, use notification rather than message. If your business truly requires custom messages, call customDisplayReport('msg_id') after displaying them on the page and customClickReport('msg_id') on click.
• Avoid sending several notifications to the same user in quick succession. On Chrome, Edge, and Firefox, the later notification replaces the earlier one, so the user ends up seeing only the last one and only one impression is counted. Combine multiple items into a single notification or space out the sends.
• Mind browser compatibility of assets and copy. icon should be 192×192 and no larger than 1 MB; custom icons are supported only on Chrome and Firefox, while Safari and Edge use the system default icon. image should be 360×180 and no larger than 1 MB; it is supported only on Chrome and Edge, not on Firefox or Safari. System channels limit title length (fewer than 20 Chinese characters or 40 English characters); overly long titles may affect how the notification is displayed.
• Set a reasonable display validity period for in-app messages. Once the validity period has passed, the message is not displayed when the user returns to the page and impression_failed is triggered. Extend the validity period for content that is not time-sensitive and keep image sizes under control to avoid download failures.
• Push during users' active hours. Use intelligent delivery in Scheduled Tasks or the active-time matching data in Push Statistics to send when users are more likely to have the browser open, reducing offline expiry.
• Interpret Safari data correctly. The Safari system channel cannot return impression or click callbacks, so low impressions on that channel reflect a statistics limitation rather than notifications not being displayed. Evaluate Safari separately from other channels when assessing the impression rate.

Part 3: A Comprehensive Approach to Systematically Increasing Impressions

Point fixes solve only one layer at a time. To keep increasing impressions, run "subscriber growth, delivery assurance, and impression monitoring" as an ongoing routine.

3.1 Build a Per-Channel Monitoring View

• Check the push conversion funnel, delivery / impression / click rate trends, and the number of users with notifications enabled / disabled in the Overview every day.
• Split delivered and impressions by browser in Push Statistics, focusing on Chrome and the EngageLab channel; evaluate Safari separately.
• Receive delivered, Impression, impression_failed, click, and other events through the Callback API and store them for finer-grained analysis per user and per message than the console provides (per-message statistics are kept on the EngageLab side for at most one month).
• Set separate baselines for delivery rate and impression rate: when the delivery rate drops abnormally, check time_to_live, the distribution strategy, and vendor channels first; when the impression rate drops abnormally, check message type, overrides from multiple notifications, and user-side permissions first.

3.2 Action Checklist by Phase

Onboarding phase (around launch)

• Use HTTPS, configure domains, place the Service Worker in the root, and confirm there is no scope conflict;
• Select "guided request" for notification permission and configure the soft prompt copy and intervals;
• Prepare add-to-home-screen guidance for iOS users;
• Use notifications (notification) rather than custom messages (message) as the primary reach method;
• During integration testing, use Push History and Data Query to confirm that target devices' online status, delivery, and impressions are counted correctly.

Growth phase (day-to-day operations)

• Compare subscribed and active user growth weekly; when subscription conversion is poor, adjust the soft prompt copy and trigger timing;
• Keep time_to_live at 1 day or more and use secondary_push or the default strategy for distribution;
• Control push frequency to the same user to avoid impression loss from overrides, while configuring frequency control to protect the experience;
• Choose send times based on intelligent delivery or active-time matching data;
• Periodically clean up long-inactive subscriptions.

Campaign phase (peak pushes)

• Use rate-limited push to smooth peaks;
• Shorten time_to_live for time-sensitive content and extend offline retention for content that can be delivered later;
• Combine multiple marketing notifications into one, or send in staggered batches by user segment;
• After the push, review delivery and impression rates by channel and feed lessons from abnormal channels back into the next push configuration.

3.3 In One Sentence

Impressions = subscribed users × valid-target ratio × delivery rate × impression rate. Use funnel data to determine which layer the loss occurs in, then optimize that layer. For the "impression" layer itself, the key is to use notifications and ensure SDK reporting, avoid overrides from multiple notifications, and interpret data per channel.

Reference Documents

• Web SDK Integration Guide
• Web SDK API
• Basic Settings
• Advanced Settings
• Create Push API
• Callback API
• Statistics API
• Push Statistics
• Push History
• FAQ
• How to Prevent Subscriber Loss During Web Push Migration