Search Knowledge Base Articles

Preview Tool

📢 Push Campaigns: Preview Tool

Summary:
The Preview Tool lets you test an app user against your campaign rules and see whether a push would actually be allowed into the queue before the automatic process runs.

Overview

The Preview Tool is one of the most important screens in the Push Campaigns module.

It is designed to help you test campaigns before relying on live automation.

This screen allows you to:

choose an app user
select a specific campaign or use automatic campaign matching
see the app user context used for rule checking
see whether a campaign matched
see whether the push would be allowed or blocked
manually queue a preview push where permitted

This makes it an essential troubleshooting and testing screen.

Section 1: What this screen is for

The Preview Tool helps answer questions such as:

Does this user match the campaign rules?
Which campaign would the system select for this user?
Is the push actually eligible to queue?
Has this user already been sent this campaign before?
Is the campaign blocked by cooldown, limits, or missing push capability?

It is particularly useful before setting a campaign live.

Section 2: How to use the Preview Tool

Step 1: Choose an app user

Select the app user you want to test.

The list is searchable and typically shows a combination of:

internal user number
email
first-party ID

Choose a user you believe should match, or one you want to investigate.

Step 2: Choose a campaign, or leave blank for auto-match

You have two ways to preview:

Auto-match highest priority campaign

Leave the campaign field blank.

This makes the system search for the best matching campaign for that user, based on campaign logic and priority.

This is the best option when you want to simulate real behaviour.

Choose a specific campaign

Select a campaign manually.

This is the best option when you want to test a single campaign in isolation.

Step 3: Click Run Preview

The module will then process the selected user and show the result.

Section 3: App User Context

Once a user has been selected, the screen shows an App User Context panel.

This is extremely important because it shows the actual values being checked by the campaign rules.

The context may include values such as:

app user ID
first party ID
OneSignal subscriber ID
has first party ID
has OneSignal subscriber ID
days since first seen
days since last seen
days since created
days since updated
device type
email
OS status
SMS status
aux fields

Why this matters

The Preview Tool is not based on guesswork. It uses the actual stored app-user data.

If a campaign does not match when you expected it to, the App User Context usually explains why.

For example:

the user may be older than expected
the user may not have a OneSignal subscriber ID
the device type may not match the rule
the first-party ID may be different from what you assumed

Always read the App User Context carefully when troubleshooting.

Section 4: Preview Result

The Preview Result area shows whether a campaign matched.

If a campaign matched

You will see:

the campaign name
the push title
the push message

This confirms that the campaign rules matched the selected user.

If no campaign matched

You will see a message explaining that no campaign matched this app user with the current selection.

This may mean:

the selected campaign rules do not match
the user does not meet the conditions
another campaign would normally win in auto-match mode
the campaign setup needs adjusting

Section 5: Queue Decision

Even if a campaign matches, the push may still be blocked.

That is why the Queue Decision section is so important.

This section tells you whether the push is:

Allowed
or Blocked

and also gives a reason.

Common reasons a queue decision may be allowed

the campaign matches
push sending is enabled
the user is eligible
limits and cooldown rules do not block it

Common reasons a queue decision may be blocked

push automation is disabled for the campaign
the campaign is manual only in a non-manual scenario
the user has no OneSignal subscriber ID
the campaign has already been queued or sent before
max pushes per user has been reached
the campaign is inside a cooldown period
the selected campaign rules do not match this app user

This makes the Preview Tool much more useful than simple matching alone, because it shows whether the campaign is truly ready to queue.

Section 6: Last Push State

If previous activity exists for that user and campaign, the screen shows Last Push State.

This can include:

Matched
Queued
Sent
Sent count

This helps you understand whether the user has already been through the campaign.

For example, if a user matches but the queue decision says blocked, the Last Push State may reveal that:

the campaign has already been queued once
the campaign has already been sent
the sent count has reached the limit
the cooldown period is still active

Section 7: Queue Preview Push

If the campaign matches and the queue decision is allowed, the screen displays a Queue Preview Push button.

This lets you manually place a test push into the queue for that user and campaign.

This is useful when you want to perform a controlled real-world test.

Use this carefully

A queued preview push is more than a visual test. It is an actual queue action.

Only use this when you are intentionally testing delivery and have selected the correct user.

Section 8: Recommended preview process

Before relying on any campaign, use this process:

Save the campaign
Open the Preview Tool
Select a user who should match
Run the preview
Read the App User Context carefully
Confirm the campaign matched
Confirm the Queue Decision is allowed
Review the Last Push State
Test a user who should not match
Only then rely on automatic sending

This reduces the risk of accidentally creating campaigns that are too broad, too narrow, or blocked by send rules.

Section 9: Example preview checks

Example: Welcome campaign

You expect a newly seen user to match a welcome campaign.

Check that:

days since first seen is within the expected range
has OneSignal subscriber ID is true if required
the campaign matches
the queue decision is allowed

Example: Re-engagement campaign

You expect an older inactive user to match a re-engagement campaign.