📢 Push Campaigns: Create or Edit a Campaign
Summary:
This is the main setup screen for building a push campaign. Here you define the campaign name, status, rules, push settings, message content, image, URL, and internal notes.
Overview
The Create/Edit Campaign screen is where the real campaign setup takes place.
This is the most important page in the Push Campaigns module. It allows you to define:
-
what the campaign is called
-
whether it is active
-
which app users it should apply to
-
whether the push should be sent automatically
-
what the push message should say
-
where the push should take the user when clicked
If you are new to Push Campaigns, this is the page you will use most often.
Section 1: Basic campaign details
Campaign Name
This is the internal name of the campaign.
It is only for your team’s reference, so it should clearly describe the purpose of the campaign.
Examples:
-
New User Welcome
-
7 Day Follow-Up
-
Lapsed User Reminder
-
App Discount Reminder
-
Default Fallback Push
Status
The available statuses are:
-
active
-
inactive
-
draft
Use them as follows:
-
Draft when you are still building or testing a campaign
-
Active when the campaign is ready to be used
-
Inactive when you want to keep a campaign saved but prevent it from being used
A good habit is to keep new campaigns in draft until you have previewed them properly.
Priority
Priority controls the order in which campaigns are considered.
A higher number means a campaign is considered earlier.
This is especially important when multiple campaigns could match the same user.
For example:
-
Welcome campaign = 100
-
Re-engagement campaign = 50
-
Default campaign = 1
Use as default fallback campaign
Tick this option if the campaign should act as a fallback.
A default campaign is used when no more specific rule-based campaign applies.
Only use this if you genuinely want a catch-all campaign.
Section 2: Rules
What the rules do
Rules determine which app users match the campaign.
When a user matches the rules, the campaign becomes a possible campaign for that user.
How rules are structured
Each rule line includes:
-
Group
-
Field
-
Operator
-
Value 1
-
Value 2
The module uses grouped rule logic:
-
rules in the same group are treated as AND
-
rules in different groups are treated as OR
This means:
-
all rules in one group must pass together
-
but a different group can provide an alternative path to match
Rule help in plain English
If two rules both have Group 1, the user must satisfy both of them.
If one rule is in Group 1 and another is in Group 2, the campaign can match either group.
Available rule fields
The module includes these fields:
-
Days since first seen
-
Days since last seen
-
Days since created
-
Days since updated
-
Has OneSignal subscriber ID
-
Has first party ID
-
First party ID
-
OneSignal subscriber ID
-
Device type
-
Email
-
OS status
-
SMS status
-
Aux one
-
Aux two
-
Aux three
Available operators
The module supports:
-
Equals
-
Does not equal
-
Greater than
-
Greater than or equal
-
Less than
-
Less than or equal
-
Between
-
Contains
-
Does not contain
-
Is empty
-
Is not empty
-
In list
-
Not in list
Section 3: How to build rules
Group
Use the same group number when several rules must all be true together.
Use a different group number when you want to create an alternative matching path.
Field
Choose the app-user data field you want to test.
Operator
Choose how the value should be checked.
Value 1
This is the main value for the rule.
Value 2
This is usually only used when the operator is Between.
Section 4: Rule examples
Example 1: New users within 7 days
-
Group: 1
-
Field: Days since first seen
-
Operator: Between
-
Value 1: 0
-
Value 2: 7
This matches users first seen between 0 and 7 days ago.
Example 2: User must have push capability
-
Group: 1
-
Field: Has OneSignal subscriber ID
-
Operator: =
-
Value 1: 1
This helps ensure the user has a stored OneSignal subscriber ID.
Example 3: Re-engagement campaign
-
Group: 1
-
Field: Days since last seen
-
Operator: >=
-
Value 1: 30
This targets users who have not been seen for at least 30 days.
Example 4: Specific user
-
Group: 1
-
Field: First party ID
-
Operator: =
-
Value 1: ABC123
This targets one specific user.
Example 5: Alternative groups
Group 1:
-
Days since first seen between 0 and 7
Group 2:
-
Device type = ios
This means the campaign can match either new users or iOS users.
Section 5: Push Configuration
This section controls whether the campaign can queue and send pushes.
Enable automatic push sending for this campaign
Tick this if the campaign should be able to queue pushes automatically.
If this is unticked, the campaign will not operate as an automatic push campaign.
Only queue push when the app user has a OneSignal subscriber ID
Tick this if the system should only queue the push for users who have a OneSignal subscriber ID.
This is recommended in most cases, because push notifications generally require a valid OneSignal subscriber record.
Push Send Mode
The available options are:
-
disabled
-
on_first_match
-
manual_only
Disabled
The campaign will not automatically queue pushes.
On first match
The campaign will queue a push when the user matches for the first time.
This is a very common setting for lifecycle campaigns such as welcome or milestone pushes.
Manual only
The campaign can be tested and manually queued, but it is not meant to auto-queue during the normal automated process.
This is useful for controlled testing.
Max Pushes Per User
This controls how many times the same user can receive pushes from this campaign.
Examples:
-
1 = one-time campaign
-
2 = user can receive it twice
-
higher numbers = repeat campaigns
For most welcome or milestone campaigns, 1 is usually the best choice.
Push Delay (Days)
This adds a delay between the match and the queue timing.
For example, if a user matches today and the push delay is 2, the campaign can be delayed by 2 days.
This is helpful if you want to avoid messaging a user immediately.
Cooldown Days
Cooldown prevents the campaign from being queued again too soon after a previous push.
If the same campaign has already been queued or sent recently, the cooldown period blocks another send until enough days have passed.
This is especially useful if a campaign can match the same user more than once.
Section 6: Push content
Push Title
This is the headline of the push notification.
Keep it short and direct.
Push Message
This is the body text of the push.
Try to keep it clear, relevant, and action-focused.
Push Image
You can optionally upload an image for the push.
Supported file types include common image formats such as PNG, JPG, JPEG, GIF, and WEBP.
If an image already exists, the screen shows:
-
the current file name
-
a preview image
-
a remove button
You can remove the existing image if needed.
Push URL
This is the page the user should be taken to when they tap the push.
Examples include:
-
a discount page
-
a landing page
-
a collection page
-
a feature page
-
a booking page
Always make sure the URL is correct and relevant to the message.
Internal Notes
This is for your own internal reference.
Use it to record:
-
campaign purpose
-
rule logic
-
testing notes
-
review dates
-
any special instructions for your team
Section 7: Recommended campaign setup process
A good setup process is:
-
Enter a clear campaign name
-
Set the status to draft or active
-
Choose a sensible priority
-
Decide whether it is a default fallback
-
Add your rule lines carefully
-
Configure push sending settings
-
Add the title, message, optional image, and URL
-
Save the campaign
-
Open the Preview Tool
-
Test matching and queue eligibility before relying on live sending
Section 8: Best practice
-
start with simple rules
-
avoid too many overlapping campaigns
-
use clear priorities
-
keep one-time campaigns limited to one push per user where appropriate
-
use cooldowns when repeat matches are possible
-
always test in the Preview Tool
-
use internal notes so your team understands why the campaign exists