Postback status optimization rules are part of the Optimization Tool in Swaarm. For a general overview of how optimization rules work, including rule types, scope, and priority, see the Optimization Tool Overview.
Postback Status vs Postback Decision
Postback status defines the state of the conversion (Approved, Pending, Rejected).
Postback decision defines whether the postback is sent to the publisher or not (Passed / Failed).
For example, if a conversion occurs after a cap is reached, it may have status Pending, while the postback decision is Failed, meaning the postback will not be sent to the publisher.
Where to Configure Postback Status Optimization Rules
Navigation path: Automation → Optimizations → Create → Rule Type: Postback Status
Rules
Status Assignment Rules
These rules explicitly define which status a conversion should receive based on predefined conditions or advertiser logic.
Default Status Rule - allows you to define a default conversion status (Approved, Pending, or Rejected) for postbacks matching a specific scope. The rule can be applied to: a specific Advertiser, Offer, Publisher, or any combination of the above.
Conversions matching the selected criteria will be assigned the configured status by default, unless overridden by a more specific postback status rule.
Duplicate & Integrity Validation Rules
These rules handle duplicate events and invalid identifiers.
Alternate Duplicate Detection - If a duplicate event is detected, the conversion status is set to Pending. Duplicate detection is based on the
uqpostback parameter used to match repeated events. Learn more about supported postback parameters here.Duplicated Click - if a conversion is received with a duplicated Swaarm click ID, the conversion status is set to Rejected.
Advertiser & MMP Validation Rules
These rules reflect validation performed by the advertiser or Mobile Measurement Partner (MMP).
Rejected by Advertiser - if a conversion is received with status=rejected from the advertiser, the conversion status is set to Rejected.
AppsFlyer Retargeting - for conversions coming from Appsflyer with the macro retargeting={is-retargeting}:
if retargeting=1 or true, the conversion status is Approved
if retargeting=0 or false, the conversion status is Rejected
This rule applies only when the corresponding Swaarm parameter is present.
Invalid Adjust / Appsflyer / Singular IP - if a conversion is received from an IP claiming to belong to Adjust, Appsflyer, Singular, but is not validated as a legitimate MMP IP, the conversion status is set to Rejected.
Invalid Purchase - if a conversion is received from an app with an invalid purchase, the conversion status is set to Rejected. This rule is specific to Swaarm MMP flows and is not applicable to standard performance campaign setups.
Budget & Delivery Rules
These rules adjust conversion status when budget or delivery constraints are reached.
Budget Reached - if a conversion is received after the daily or monthly offer budget has been reached, the conversion status is set to Pending.
Disabled VTA - If a conversion is received for a VTA campaign where VTA is not enabled, the conversion status is set to Pending.
Offer & Publisher Eligibility Rules
These rules ensure conversions match current offer and publisher configuration.
Inactive Offer - if a conversion is received for an offer that is no longer active, the conversion status is set to Pending.
Publisher Not Approved - if a conversion is received from the publisher who is not approved on the offer, the conversion status is set to Pending.
Event & Mapping Validation Rules
These rules ensure correct event and offer mapping.
Invalid Advertiser Offer - if the advertiser_offer_id received in the postback does not match the Advertiser Offer ID configured in the offer settings, the conversion status is set to Rejected.
Invalid Event Type - if a conversion is received with an invalid event ID, the conversion status is set to Rejected.
Security & Authenticity Rules
These rules protect against spoofed or unauthorized postbacks.
Invalid Security Token - if a conversion is received with a Security Token that does not match the current Postback Security Token, the conversion status is set to Rejected.
Invalid Server IP - If a postback is received from an IP that is not on the allowed list, the conversion status is set to Rejected.
SKAdNetwork Validation Rules
These rules handle SKAdNetwork-specific validation.
Invalid SKAd by MMP - if a SKAdNetwork postback is not validated by the respective MMP, the conversion status is set to Rejected.
Invalid SKAd Signature - if a conversion is received with an incorrect SKAdNetwork signature, the conversion status is set to Rejected.
Reporting & Monitoring
If conversion statuses are being changed due to postback status optimization rules, their impact can be reviewed directly in reports.
Where to Check
You can analyse postback statuses in the following reports:
Conversion Report
Custom Report
Explorer
What to Look For
In reports, pay attention to the following metrics and dimensions:
Evaluation Status / Postback Status - shows whether a conversion is Approved, Pending, or Rejected.
Evaluation Status Active Rules - shows the names of the optimization rules which are affecting the conversion status
Evaluation Status Failed Rules / Status Failed Rules - shows which postback status rule(s) caused the postback not to have status Approved (for example, Duplicated Click, Invalid Event Type, etc.).
Evaluation Status Failed Sub Rules - shows the subrule, which caused the status set as Pending or Rejected (for example, Budget Reached Event Daily Hard Offer)
Example: Investigating Rejected Conversions
Let’s say you are reviewing reports and notice that some conversions for offer 29308 are marked as Rejected, while others are Approved. You want to understand why certain conversions were rejected.
Step 1: Start with a high-level overview
Go to Reports → Custom Report or Explorer.
Apply a filter for
Offer ID = 29308
Add the following dimension:
Postback Status (in Custom report) / Status (in Explorer)
This gives you a high-level split of conversions by status:
At this stage, you can already see how many conversions are rejected, but not yet why.
Step 2: Break down rejected conversions by reason
Next, extend the same report by adding:
Status Failed Rules - Now you can see why conversions were rejected.
For example, rejected conversions may be split between:
Invalid Event Type
Duplicated Click
This helps you identify which rejection reasons are most common and worth investigating further.
Step 3: Focus on a specific rejection reason
Let’s say you see that several conversions were rejected due to Invalid Event Type.
At this point, you know: the conversions reached Swaarm, but failed validation because the event mapping did not match the offer configuration.
To investigate this in detail, you need to look at the advertiser postback itself.
Step 4: Inspect advertiser postbacks in the Conversion Report
Go to Reports → Conversion Report. Apply the following filters:
Offer ID = 29308
Status Failed Rules = Invalid Event Type
This allows you to see the exact parameters the advertiser is sending, including: event_id, or our_event_type_id
Step 5: Compare postback values with offer event setup
Conversions are rejected due to Invalid Event Type when:
the value passed in event_id parameter does not match the Adv. EventType ID configured on the offer event, or
the value passed in our_event_type_id parameter does not match the Swaarm event ID.
In case of offer 29308 the advertiser fired the postback with event_id=level_6:
whereas in the offer event setting Adv.EventType ID is level6 (without underscore):
Step 6: Resolve the issue
To fix this, you can either:
ask the advertiser to send the needed event value, or
update Adv. EventType ID at your side
💡 Install Event Mapping
In some cases an advertiser might fire a conversion for install event with event_id=install. However, even though the default event in Swaarm is Install, the expected event_id value for default event must be:
event_id=0,
or event_id=1,
or event_id=Default
If the advertiser cannot change the event value on their side, you can create an additional event on the offer and set the corresponding Adv. EventType ID to match the value they are sending (for example, install).
Advanced Analysis (Superset)
Conversion-level data can also be analysed in Superset (Reports → Studio) using SQL queries. Utilising Superset is optional and typically required only for advanced or custom analysis. In most cases, Conversion Report, Custom Report, or Explorer provide sufficient visibility into postback decision behaviour.
