Segment for Gig Economy Marketplaces

Why Lifecycle Optimization Matters for Gig Marketplaces

Gig economy platforms operate with two distinct customer populations simultaneously — supply (workers, drivers, freelancers) and demand (buyers, riders, clients). Most CDPs are configured for single-sided businesses. That mismatch is where growth teams lose the most ground.

Segment gives you the infrastructure to track, segment, and activate both sides of your marketplace in a unified system. But the default setup won't get you there. You need to instrument it specifically for the dual-sided, high-churn, activation-dependent reality of gig platforms.

This guide covers exactly how to do that.

---

Setting Up Segment for a Two-Sided Marketplace

Separate Your User Identity Model

Your first architectural decision determines everything downstream. Most gig platforms have users who exist on both sides — a person might be both a driver and a passenger on certain platforms, or both a buyer and a seller.

Do not flatten these into a single profile. Use Segment's identify call with distinct `userType` traits:

• `userType: "provider"` for gig workers
• `userType: "consumer"` for demand-side users
• `userType: "dual"` for accounts with both roles active

Pair this with a `platformSide` property on every event so your downstream tools always know which journey is in motion.

Use Group Calls for Marketplace Entities

Beyond individual users, your marketplace has entities that matter to activation — a restaurant on a food delivery app, a service category on a home services platform, a project type on a freelance marketplace.

Use Segment's group call to model these. Attach providers to their service category group. This unlocks cohort-level analysis: "providers in the home cleaning category who completed fewer than 3 jobs in their first 30 days" is a segment you can build and act on.

---

Key Events to Track by Lifecycle Stage

Provider (Supply-Side) Events

The provider funnel has more friction than the consumer funnel. Instrument every step.

Acquisition and Onboarding

• `Provider Application Started`
• `Background Check Submitted`
• `Background Check Passed` / `Background Check Failed`
• `Profile Completed` — include a `completionScore` property (0–100) so you can segment by profile quality
• `First Job Accepted`
• `First Job Completed`

Activation and Engagement

• `Availability Set` — providers who never set availability never activate
• `Earnings Milestone Reached` — track at $50, $250, $1,000 increments
• `Negative Review Received`
• `Job Cancellation` — include `cancellationReason` as a property
• `App Session During Peak Hours`

Churn Signals

• `Last Login` — calculated trait, not a raw event, but critical to expose in Segment Personas
• `Job Acceptance Rate Drop` — a computed trait comparing 7-day vs. 30-day rates
• `Account Deactivation Requested`

Consumer (Demand-Side) Events

Acquisition and First Transaction

• `Signup Completed`
• `First Search Performed` — include `categorySearched` and `locationEnabled` as properties
• `Service Requested`
• `First Booking Completed`
• `Payment Method Added`

Retention Signals

• `Repeat Booking` — flag when `bookingCount` crosses 2, 5, and 10
• `Preferred Provider Saved`
• `Review Submitted` — high-intent engagement signal
• `Subscription Activated` (if applicable)

Drop-Off Events

• `Checkout Abandoned` — include the `abandonmentStep` property
• `Search With No Results`
• `Booking Cancelled` — with `initiatedBy: "consumer"` vs. `"provider"` distinction

---

Segments to Build in Segment Personas

These are the audiences your growth team should be using every week.

Provider Segments

| Segment Name | Logic |

|---|---|

| At-Risk Providers | No job accepted in 14 days + previously completed 3+ jobs |

| High-Quality New Providers | Completed onboarding + profile score ≥ 80 + first job in ≤7 days |

| Churned Providers | No login in 30 days + last job completed 30–90 days ago |

| Power Providers | ≥10 jobs completed in last 30 days + rating ≥ 4.7 |

Consumer Segments

| Segment Name | Logic |

|---|---|

| One-and-Done Buyers | Completed exactly 1 booking + no activity in 21 days |

| High-LTV Prospects | 3+ bookings + no subscription + used service ≥2 categories |

| Lapsed High-Value Users | Previously booked ≥5 times + no booking in 45 days |

| Referral Candidates | NPS score ≥ 9 (if tracked) + ≥3 completed bookings |

---

Automations to Build With Segment Destinations

Provider Win-Back Sequence

Connect Segment to your email or SMS tool (Braze, Klaviyo, Twilio) and trigger a three-step sequence when a provider enters the At-Risk Providers segment:

1. Day 1 — Push notification: "Jobs are available in your area this week"
2. Day 3 — Email: Earnings recap showing what similar providers made last week
3. Day 7 — SMS: Incentive offer tied to completing 2 jobs within 5 days

The earnings comparison message consistently outperforms generic re-engagement. Specificity moves providers back into activity.

Supply-Demand Imbalance Alerts

This is an automation most gig platforms don't build but should. Use Segment's event-triggered destination connections to fire a workflow when:

• Consumer bookings in a specific category exceed a threshold AND
• Active provider sessions in that category are below a second threshold

Route this signal to your operations Slack channel and to your at-risk provider re-engagement queue simultaneously. Real-time supply-demand data sitting in Segment unused is a direct revenue leak.

New Consumer Activation Campaign

Trigger immediately after `First Booking Completed`:

1. Within 1 hour — Confirmation + "what to expect" content
2. Day 3 — Education on platform features they haven't used (scheduling, preferred providers)
3. Day 10 — Prompt toward second booking with a time-limited discount if `bookingCount` is still 1

---

Industry-Specific Challenges With Segment

Contractor status and data sensitivity. Gig workers are contractors, not employees. In some jurisdictions, how granularly you track and segment worker behavior has legal implications. Work with your legal team before building any segment that uses income-level or hours-worked data for adverse actions.

Event volume and MTU costs. High-frequency platforms — delivery apps, ride-share — generate enormous event volumes. Audit which events actually power decisions before tracking everything. Unused events inflate your Monthly Tracked User count without adding value. Start with the events listed above and expand deliberately.

Attribution across two funnels. Standard attribution models assume one conversion goal. Your platform has two — provider activation and consumer booking. Build separate attribution tracking for each side using Segment's `context.campaign` properties, and resist combining them into a single ROAS or CAC number.

---

Frequently Asked Questions

How should we handle providers who are also consumers on the same platform?

Create a `dual` user type as a trait on their profile, and use the `platformSide` event property to tag each action. This way the behavior is cleanly separated at the event level even though the identity is unified. Most analytics destinations and email tools can filter on event properties, so your provider re-engagement campaigns won't fire on consumer-side activity.

What's the right approach for tracking earnings and payout data in Segment?

Track earnings milestones as events rather than passing raw earnings figures as traits. An event like `Earnings Milestone Reached` with a `milestoneAmount` property of `250` gives you the behavioral signal you need for segmentation without storing sensitive financial data in your CDP. For detailed payroll data, keep that in your financial system and use a secure integration rather than routing it through Segment.

How do we prevent our provider segments from degrading as the workforce scales?

Build your segments on behavioral thresholds, not absolute counts. "No job accepted in 14 days" stays accurate whether you have 500 providers or 50,000. Segments built on relative percentiles ("bottom 20% by job acceptance rate") require recalculation as population size changes and are harder to maintain. Stick with time-based behavioral logic as your primary segmentation approach.

Can Segment handle real-time supply-demand matching signals?

Segment is a data routing and identity layer, not a real-time matching engine. What it does well is detecting behavioral signals — like a drop in provider availability events — and routing those to your downstream systems quickly. For sub-second matching logic, that processing happens outside Segment. Use Segment to detect and activate on supply-demand trends at the minute or hour resolution, and keep your matching infrastructure separate.