OneSignal for Gig Economy Marketplaces

Why Lifecycle Optimization in Gig Marketplaces Is Different

Gig economy marketplaces have two customers, not one. Every message you send either goes to a worker (driver, freelancer, cleaner, courier) or a buyer (rider, client, homeowner, business). Get that confused and you will frustrate both sides of your marketplace simultaneously.

OneSignal gives you the infrastructure to manage both audiences with precision — but only if you set it up correctly from day one. Most platforms treat push notifications as a broadcast channel. The teams that win use it as a behavioral response system.

This guide covers exactly how to do that.

---

Setting Up OneSignal for a Two-Sided Marketplace

Separate Your User Bases From the Start

Do not put workers and buyers in the same OneSignal app. Create two separate OneSignal applications — one for each side of your marketplace. This keeps your user segments, data tags, and notification templates clean and avoids the risk of sending a "Your ride is arriving" message to a driver.

Your OneSignal SDK initialization should pass a `user_type` value immediately on registration. Tag every user at the moment of account creation.

Minimum required data tags for workers:

• `user_type` = `worker`
• `onboarding_step` (e.g., `background_check`, `id_verified`, `first_job_completed`)
• `job_category` (e.g., `delivery`, `cleaning`, `freelance_writing`)
• `active_status` = `active` / `idle` / `churned`
• `lifetime_jobs_completed`
• `last_active_date`

Minimum required data tags for buyers:

• `user_type` = `buyer`
• `account_age_days`
• `total_orders`
• `last_order_date`
• `preferred_category`
• `payment_method_on_file` = `true` / `false`

Connect OneSignal to Your Event Pipeline

OneSignal's API works best when it receives real-time signals from your backend. Connect it to your event tracking system — whether that is Segment, Amplitude, or a custom webhook setup — so that behavioral triggers fire automatically.

The core events to pipe into OneSignal for a gig marketplace:

Worker-side events:

• `worker_registered`
• `background_check_submitted`
• `background_check_passed`
• `first_job_accepted`
• `first_job_completed`
• `payment_received`
• `rating_below_threshold` (e.g., drops below 4.2 stars)
• `30_days_no_job`

Buyer-side events:

• `buyer_registered`
• `first_booking_started`
• `first_booking_abandoned` (session ended without confirmation)
• `first_booking_completed`
• `second_booking_completed`
• `30_days_no_booking`
• `high_value_order_placed` (above your defined threshold)

---

Segments to Build in OneSignal

Segments are where most teams underinvest. OneSignal's segment builder can filter on data tags, session count, first session date, and last session date. Use all of it.

High-priority segments to create:

1. Worker: Stuck in Onboarding — `onboarding_step` is not `first_job_completed` AND `worker_registered` date is more than 7 days ago. These users cleared signup but never activated. This is your biggest supply-side leak.

1. Worker: At-Risk Active — `lifetime_jobs_completed` is greater than 5 AND `last_active_date` is more than 21 days ago. These are experienced workers going cold. Reactivating them costs far less than recruiting new ones.

1. Buyer: First Booking Abandonments — `first_booking_started` = `true` AND `total_orders` = 0 AND account created more than 48 hours ago.

1. Buyer: One-and-Done — `total_orders` = 1 AND `last_order_date` is more than 14 days ago. Converting these buyers to a second purchase is the single highest-ROI action on the demand side.

1. Buyer: High-Value Repeat — `total_orders` is greater than 10 AND `last_order_date` within 30 days. Protect this segment. They get first access to new features and proactive service updates.

---

Automations to Build First

Worker Onboarding Sequence

Most gig platforms lose 40-60% of registered workers before they complete their first job. A structured push sequence recovers a meaningful portion of that drop-off.

Build a 5-step drip triggered by `worker_registered`:

• Day 1 (if background check not submitted): "Your profile is 60% complete — submit your background check to start earning."
• Day 3 (if still no submission): Reminder with specific earnings data from your market ("Drivers in [city] averaged $847 last week").
• Day 7 (if check submitted but not passed): Status update to prevent ghosting.
• Day 10 (if check passed but no first job): "You're approved — here's how to accept your first job."
• Day 14 (if no first job): Final push with an incentive offer if your economics allow it.

Stop the sequence the moment the user completes the relevant step.

Buyer Re-Engagement After First Order

The window between a buyer's first and second order is where retention is won or lost. A buyer who completes two orders retains at roughly 3x the rate of a one-time buyer.

Trigger this sequence 5 days after `first_booking_completed`:

• Day 5: "How did it go? Book again and your second [service] is prioritized to the same worker."
• Day 12 (if no second booking): Category-specific prompt ("Your home was last cleaned 12 days ago").
• Day 20 (if still no booking): Introduce a secondary use case or category they have not tried.

Real-Time Transactional Notifications

These are not optional — they are the baseline expectation. Buyers expect to know when a worker is assigned, when they are en route, and when the job is confirmed. Workers expect instant job alerts, payment confirmations, and rating notifications.

Set these up as API-triggered notifications, not scheduled campaigns. Latency above 90 seconds on a job-match notification meaningfully reduces acceptance rates.

---

Industry-Specific Challenges With OneSignal

Opt-out pressure is high. Gig platforms send a lot of transactional notifications, which trains users to tune out or disable push entirely. Separate your transactional and marketing notification channels using OneSignal's category-based notification grouping. Let users mute marketing pings without losing job alerts.

Worker availability windows are irregular. A standard "best time to send" setting does not work for gig workers. Use OneSignal's Intelligent Delivery feature, but override it for time-sensitive job availability windows. A cleaning platform with morning demand should push supply-activation messages between 6:30 and 7:30 AM, not whenever the algorithm decides.

Geographic variation is significant. A driver in Dallas and a driver in Boston operate in different market conditions. Use location-based data tags to segment by metro area and customize message content — including real earnings data — by market.

Duplicate devices are a real problem. Workers who reinstall your app or use multiple devices can end up with multiple OneSignal player IDs. Implement external user ID mapping through OneSignal's API from day one to avoid sending duplicate job alerts that confuse workers.

---

Frequently Asked Questions

How many OneSignal apps should a two-sided marketplace create?

At minimum, two — one for workers and one for buyers. Some platforms with multiple service categories (e.g., delivery and home services) create additional apps per category if the messaging logic is fundamentally different. Start with two and only add complexity when you have a clear operational reason.

What is a realistic opt-in rate for push notifications on a gig marketplace platform?

For worker apps, opt-in rates typically run 70-85% because workers need job alerts to earn — the value is obvious. For buyer apps, expect 40-60% without a prompt strategy and 55-70% with a well-timed permission ask after the first positive experience. Ask for push permission after the first successful order completion, not on first app open.

Can OneSignal handle the volume of real-time transactional messages a gig marketplace sends?

Yes, but your architecture needs to be set up correctly. Use OneSignal's REST API for all transactional sends rather than the dashboard. Batch job-match notifications are not appropriate — each one must fire individually and immediately when a match occurs. OneSignal's delivery infrastructure handles millions of messages per minute, so volume is not the constraint. Your backend triggering logic is.

How should gig platforms handle notification fatigue without hurting worker activation rates?

Segment aggressively by worker state. An active worker completing three jobs a day needs fewer prompts than a worker who has been idle for two weeks. Build a frequency cap by segment — active workers get transactional notifications only, idle workers get one re-engagement push every four days. Use OneSignal's global frequency capping as a floor, not a ceiling, and layer your own logic on top through the API.