Push Metrics: What Counts and How to Read

How Push Notifications Work in Adset.Pro

Push notifications are a free retargeting tool for your subscriber base.

Mechanics:

1. The user installed the PWA and allowed push notifications → they are in the subscriber base (FCM token + click_id + country + behavior flags)

2. You create a push notification with a title, text, image, and link

3. Adset.Pro sends it via Firebase Cloud Messaging (FCM) — individually to the FCM token

4. The user sees the notification on their phone screen → clicks → lands on the landing page/offer

5. The Service Worker on the client records the display (VIEW) and click (CLICK)

Business Value: This is a free channel for re-engagement. Once you have collected a subscriber base — you can send push notifications on a schedule or based on triggers (registration, deposit).

---

Types of Push Events

Each interaction with the push is recorded as a separate event in the events_push table:

Server Events (recorded by the tracker immediately)

Client Events (recorded by the Service Worker on the device)

Key Difference: SEND ≠ VIEW. A push can be sent (SEND) but not displayed: the user is in Do Not Disturb mode, the device is off, the browser is closed, or notifications are blocked at the OS level.

Subscription Events (in the main events table)

---

Key Metrics of Push Campaigns

All metrics are available in the statistics (table events_push):

Post-Click Attribution (table events_push_attributed)

Interpreting Metrics

• push_ctr: 2-5% — typical for gambling/betting. Above 5% — excellent creative. Below 1% — check the title, image, relevance

• push_delivery_rate: 60-80% — normal for a fresh base. Below 50% — the base has "aged", many dead tokens

• push_fail_rate: The flip side of delivery_rate. If > 40% — it's time to "clean" the base or update subscribers

• push_view_rate: Usually 50-70% of SEND. The rest are Do Not Disturb, turned off devices

---

Push Statistics in the Interface

Main Analytics (Statistics Section)

In the statistics, you can group data by pushes:

How to Select Push Data:

• Use metrics from the Push group: push_sends, push_views, push_clicks, push_ctr, etc.

• Add group by event_push_id to see which push performed better

• Push metrics work with the events_push table — it connects automatically when querying push metrics

Post-Click Attribution (Push Analytics Section)

Post-Click Attribution tracks conversions that occurred after clicking on the push, within a specified attribution window.

How it Works:

1. The user clicks on the push → event_click_id of the push click is recorded

2. Within N hours, the user registers or makes a deposit

3. The conversion is attributed to this push click via JOIN events_push_attributed

Important Nuances:

• Attribution to the push does not replace attribution to the ad click — one deposit can be attributed to both (the ad click in the main statistics + the push in Post-Click Attribution)

• Recommended attribution window for gambling: 48-72 hours. Shorter — you lose delayed conversions. Longer — too much "noise"

• Post-Click Attribution shows the contribution of pushes to the overall conversion picture, rather than replacing the main statistics

---

Types of Push Notifications

Regular Pushes (REGULAR / ONE_TIME)

Sent on a schedule via PushPlannerService:

• The push calendar (PushGroup) determines the days and times of sending

• Hourly scheduling is supported according to the user's timezone (tz_GMTp3, etc.)

• FCM condition: 'team_X' in topics AND 'country_UA' in topics [AND 'tz_GMTp3' in topics]

Application: Promotions, bonuses, content, regular reminders.

Event Pushes (EVENT)

Sent when an event occurs via PushEventScheduler:

• Triggers: REGISTRATION, DEPOSIT, and others

• Delayed sending with customizable delay is supported (via eventSchedule)

• Waiting for subscription: if there is no subscription yet, the scheduler waits up to 2 hours with backoff (5s → 15s → 1m → 5m → 10m)

Application:

• Welcome push after registration (after N minutes/hours)

• Push reminder in case of no deposit

• Re-engagement upon redeposit

---

Targeting Subscribers

Before sending, targeting is set based on behavioral flags and subscription parameters:

Behavioral Filters (push.targets)

Default Behavior: For most presets redeposit = not_redeposited (do not send pushes to those who have already redeposited). The preset "Reg+ Dep+ Redep+" is the only one where redeposit = redeposited.

Subscription Filters

Practical Cases

Case 1: "Bonus for Registered but Not Deposited Users from UA"

targets:
  registrations: registered
  deposit: not_deposited
  redeposit: all
Filter: campaign ∈ [UA-campaigns]

Case 2: "Trigger Push After Registration (after 1 hour)"

Type: EVENT
Trigger: REGISTRATION
Delay: 1 hour
Content: "Your bonus is waiting! Claim it right now"

Case 3: "Reactivation — Not Deposited in 3 Days"

Type: EVENT
Trigger: REGISTRATION
Delay: 72 hours
targets:
  deposit: not_deposited
Content: "Don't miss your bonus — it expires in 24 hours!"

---

Macros in Push Text

In the title and body of the notification, you can use macros for personalization:

Examples:

Title:

Bonus {offer.value} only today!

Body:

{random: Hurry to claim your bonus!, Your bonus is waiting!, Special offer for you!}

Tip: Randomization through {random} reduces "banner blindness" — when a user sees the same text every day and stops clicking. Change the text each time to maintain CTR.

---

Reasons for Low Delivery

Low Delivery Rate (< 60%)

FAIL vs SKIP — What’s the Difference

If push_fail_rate > 40% — the base is significantly outdated. Solution:

1. Launch new campaigns to gather fresh subscribers

2. Focus on push metrics of fresh cohorts (last 30 days)

---

Push Groups and Campaigns

Campaigns are tied to Push Groups (PushGroup). This determines:

• Which subscribers receive pushes from this group of campaigns

• The calendar for sending regular pushes

• General settings for all pushes in the group

FCM Topics: Subscribers are automatically subscribed to FCM topics:

• team_{teamId} — for filtering by team

• country_{ISO2} — for filtering by country (UA, KZ, UZ, etc.)

• tz_GMTp{N} — for filtering by timezone

---

Frequently Asked Questions

Q: I sent 10,000 pushes, but only 3,000 VIEW — where did the rest go?

Total: SEND + FAIL + SKIP = total number of processed subscribers.

• FAIL — outdated tokens, FCM errors (usually 10-30% for a base older than a month)

• SKIP — targeting did not match (user already deposited, etc.)

• Of the remaining SEND: not all became VIEW — Do Not Disturb, turned off devices, blocked notifications

Q: push_ctr is low (< 2%) — what to do?

1. A/B test titles — create two pushes with different text, compare CTR

2. Check sending time — push at 3 AM in the user's timezone = low CTR

3. Personalize using macros — {offer.value} and {random} increase relevance

4. Add/change image — pushes with images usually have higher CTR

5. Check segmentation — a push "for everyone" is always less relevant than targeted

Q: How to track which specific push led to a deposit?

1. Open Push Analytics → Post-Click Attribution

2. Select metrics: push_postclick_accepts, push_postclick_redeps

3. Group by: event_push_id (or event_push_id_name)

4. You will see how many FTDs and redeposits are attributed to each push

In the main statistics: add metrics push_clicks and group by event_push_id — you will see how many clicks each push received. The ratio of clicks to conversions = effectiveness.

Q: Can I send pushes to users who installed the PWA but did not subscribe to notifications?

No. Pushes are sent only to subscribers (FCM token in the base). Installing the PWA ≠ subscribing to pushes:

• PWA_INSTALL — PWA installed

• NOTIFICATION_SUBSCRIBE — user agreed to receive pushes (this is a separate event)

• NOTIFICATION_DECLINE — user declined

Usually, 40-70% of those who installed the PWA subscribe to pushes. To increase subscriptions: optimize the design of the request, show it at the right moment (not immediately upon opening).

Q: How does sending pushes via FCM condition vs tokens work?

Adset.Pro supports two modes:

• Condition (bulk): FCM condition of the form 'team_X' in topics AND 'country_UA' in topics — sent in one request to all suitable devices. Fast, scalable

• Token (individual): Sending to a specific FCM token — used for event pushes (EVENT) where personalization is needed