Iterable for Gig Economy Marketplaces

Why Lifecycle Optimization in Gig Marketplaces Requires a Different Playbook

You're managing two audiences simultaneously. Every message you send either serves a worker (driver, freelancer, tasker) or a buyer (rider, client, requester). Get the sequencing wrong, and you create supply-demand imbalances that kill marketplace liquidity. Iterable gives you the infrastructure to run both sides of this equation with precision — but only if you configure it around the dual-sided nature of your platform from the start.

This guide covers exactly how to do that.

---

Structuring Your Iterable Setup for a Two-Sided Marketplace

Most teams make the same mistake: they treat workers and buyers as one user base and use a single project. You should separate them.

Use two Iterable projects — one for your supply side (workers), one for your demand side (buyers). This keeps data schemas clean, prevents cross-contamination of journeys, and lets your growth team move independently on each side without stepping on each other's campaigns.

Within each project, your user schema should reflect the lifecycle state of that user type:

• For workers: `onboarding_step`, `first_job_completed`, `jobs_last_30_days`, `earnings_last_30_days`, `churn_risk_score`, `preferred_job_category`
• For buyers: `first_booking_completed`, `bookings_last_30_days`, `average_order_value`, `repeat_buyer_status`, `preferred_service_category`

These fields power every segment and automation you'll build.

---

Key Events to Track

Iterable runs on events. The quality of your event taxonomy determines how precisely you can target users. For gig marketplaces, track these events at minimum.

Supply-Side (Worker) Events

• `worker_signed_up` — captures acquisition source, device, and referral code
• `background_check_initiated` and `background_check_passed` — onboarding is a major drop-off point; you need to see where workers stall
• `first_job_accepted`
• `first_job_completed` — this is your activation event; workers who complete a first job have dramatically higher 90-day retention
• `job_completed` — fired after every job, with properties: `earnings_amount`, `job_category`, `rating_received`
• `app_session_started` — frequency signals engagement health
• `payout_processed`
• `worker_referred_worker` — referrals from active workers produce your highest-LTV supply

Demand-Side (Buyer) Events

• `buyer_signed_up`
• `first_booking_initiated` and `first_booking_completed` — track both; the gap shows friction in checkout
• `booking_completed` — with properties: `order_value`, `service_category`, `worker_id`, `rating_given`
• `booking_cancelled` — include `cancellation_reason` as a property
• `promo_code_redeemed`
• `repeat_booking_created` — when a buyer books the same worker again, that signals high satisfaction

---

Segments to Build

Segments are the foundation of every automation. Build these before touching a single workflow.

Worker Segments

• New + Stuck in Onboarding: Signed up more than 3 days ago, background check not passed, zero jobs completed. This group needs intervention, not nurture.
• Activated Workers: First job completed within last 60 days, at least 3 jobs total.
• At-Risk Workers: Had 5+ jobs in the previous 30 days, but fewer than 2 jobs in the current 30 days. This is early churn — catch it here, not after they're gone.
• High-Frequency Workers: 15+ jobs in the last 30 days. These are your super-suppliers. Treat them differently.
• Churned Workers: Zero jobs in 60+ days, previously active.

Buyer Segments

• Never Converted: Signed up but never completed a booking. Separate by how long ago they signed up — day 1-7, day 8-30, 30+ days need different messaging.
• One-and-Done Buyers: Exactly one completed booking, no activity in 30 days. This is the highest-leverage segment on the demand side.
• Repeat Buyers: Two or more bookings in the last 60 days.
• High-Value Churning Buyers: AOV above your top quartile threshold, but no booking in 45+ days.

---

Automations to Build

Worker Onboarding Journey

This is the most operationally sensitive automation you'll run. Every day a worker doesn't complete onboarding is a day of lost supply.

1. Day 0: Confirmation email immediately after signup. Include exactly what to expect in onboarding — steps, timeline, what the background check covers.
2. Day 2: Push notification if background check hasn't been initiated. Direct link to the app screen, not the home screen.
3. Day 5: SMS to workers who have passed background check but haven't accepted a job. Include earnings data — "Workers in your area earned an average of $847 last week" performs better than generic encouragement.
4. Day 7: Email with a first-job tip based on the worker's selected job category. Personalize this using the `preferred_job_category` field.

Worker Re-Engagement (At-Risk Segment)

When a previously active worker drops below their normal job frequency, trigger a Winback Journey immediately — not after 60 days.

• Day 1 of segment entry: Push with current demand data in their area. "34 open jobs near you this weekend" beats "We miss you."
• Day 4: Email with earnings comparison — what they earned in their best recent month versus the current trajectory.
• Day 10: SMS with a surge incentive if available, or a referral bonus to keep them engaged even if they're not actively taking jobs.

Buyer First-Booking Conversion

The window between signup and first booking determines long-term retention. Buyers who book within 48 hours of signing up retain at 2-3x the rate of those who wait a week.

• Hour 1: Email with social proof specific to their selected service category.
• Hour 6: Push notification if no booking initiated.
• Day 2: Email with a first-booking offer if conversion hasn't happened.
• Day 5: SMS. Keep it short — one offer, one CTA.

Post-Booking Satisfaction and Repeat Booking

Your highest-ROI automation is the one that converts a first-time buyer into a repeat buyer.

• 1 hour post-job: Rating request via push. Fast rating requests get higher completion rates and better scores.
• 24 hours post-job: Email with a "Book Again" prompt if rating was 4 stars or higher. Include the specific worker they used if they rated them 5 stars.
• Day 7: Email to non-repeaters with a personalized prompt based on `service_category` and time of last booking.

---

Industry-Specific Challenges in Iterable

Real-time supply signaling is hard. Iterable isn't a real-time data warehouse. If you're trying to fire messages based on live supply availability (e.g., "Workers near you right now"), you'll need to push that data into Iterable via API on a scheduled basis — every 15-30 minutes — and use it as a user field rather than a live query.

Dual identity management. Some users are both workers and buyers on the same platform. Keep them in separate projects with separate profiles. Don't try to build a unified profile across both sides inside Iterable — it creates segmentation conflicts and message collisions.

Regulatory variance by geography. Gig platforms operating in multiple markets face different worker classification rules. Segment by `geo_region` from the start so you can suppress or modify messaging in regulated markets without rebuilding entire journeys.

---

Frequently Asked Questions

What's the single most important event to track in Iterable for a gig marketplace?

For supply side, it's `first_job_completed`. For demand side, it's `first_booking_completed`. Both of these activation events are the strongest predictors of long-term retention on their respective sides. Build every early-lifecycle automation around accelerating users to these events.

How should we handle push notification fatigue for workers who receive operational alerts from the app itself?

Use Iterable's channel frequency capping and tag operational messages separately from marketing messages. Workers tolerate high message volume when it's relevant to earning — but they churn fast when it feels like noise. Keep lifecycle marketing pushes to no more than one per day, and suppress them entirely on days when the platform has already sent 2+ operational alerts.

Can Iterable handle the real-time demand-supply matching communications that gig platforms need?

No — and you shouldn't try to use it for that. Iterable is built for lifecycle marketing, not real-time operational dispatch. Use your core platform infrastructure for immediate job matching and availability alerts. Iterable's role is the broader relationship: onboarding, retention, re-engagement, and revenue expansion.

How do we measure whether our Iterable journeys are actually improving marketplace liquidity, not just email metrics?

Map every journey to a marketplace metric, not just an email metric. Onboarding journeys should be measured by first job completion rate, not open rate. Re-engagement journeys should be measured by jobs completed in the 14 days following re-entry. Buyer journeys should map to second booking rate within 30 days. Build these as conversion goals directly inside each Iterable workflow so you're optimizing for the metric that matters.