Overview Architecture Flexible data model Real-time engine Security & data control
All features Missions Recurring missions Streaks Collections Rules engine Points & loyalty Rewards & catalog Marketplace Segmentation
All solutions Customer activation Customer retention Customer reactivation Loyalty programs VIP engagement Personalized campaigns
All industries iGaming E-commerce Crypto Games Fintech Food Delivery Fitness Streaming Travel Mobility EdTech Telecom
About Contact FAQ Use cases
Why us Easy integration
Developers
Talk to sales
Industries · Mobility

Build the commute habit, and fill the quiet hours

A rider's weekdays repeat almost exactly: the same two trips, at the same two times. That regularity is useful, but paying for it is wasted, because those trips were happening anyway. The value is in moving the undecided trips into the hours you have spare capacity.

See recurring missions
The shape of a rider's week

The same person commutes on Tuesday and explores on Saturday

The commute barely varies from Monday to Friday, so it needs no encouragement. Leisure trips follow no pattern at all, so a daily mission would sit unmet. One programme has to handle both, with a different mechanic on each.

The commute is reach, not a target

Ten trips a week is a habit that already exists. Paying for it changes nothing. Spend the incentive on undecided trips.

Rare trips break daily missions

A daily mission for something a rider does twice a month sits unmet 28 days out of 30. Use a Week or Month recurrence.

Where and when a trip happens

Send mode, time_band and origin_zone as properties. A city team can retarget a zone with no new key and no release.

one rider · one weekday
One weekday, hour by hour, for a single rider. Twenty-four bars, one per hour of a weekday. There are two tall clusters, one around eight in the morning and one around six in the evening, which are the commute. The hours in between are almost empty. A band from ten in the morning to four in the afternoon marks the hours this operator labels off-peak on the trip itself. trips started that hour off-peak hours 00 06 08 12 16 18 20 The commute happens anyway. These are the trips worth moving.

Reading the chart: each bar is one hour of a weekday. Two tall clusters, around eight in the morning and six in the evening, are the commute, and those trips happen whether you reward them or not. The band covers the hours this operator labels off-peak, and the mission counts only trips carrying that label.

The rule you would build

You label the quiet hours, and the mission counts only those trips

We know nothing about your timetable, and we do not need to. You decide what off-peak means for your city, stamp that label on the trip when you send it, and the rule simply asks for trips carrying that label. Change the definition and no code changes.

how this is set up
Match all of the 2 rules below
Count of trips · filter time band = off-peak >= 2 this occurrence
Count of trips · filter origin zone in z north quay, z riverside >= 1 this occurrence
Then: objective satisfied · grant 120 points to the rider's balance
KeyKindWhat it carries
trips Metric · Number One completed trip.
ride spend Metric · Currency Fare paid, in your base currency.
mode Property · String bike, scooter, bus, rail, car. One metric covers every mode.
time band Property · String peak, off-peak, night. Your definition, sent as a label.
pass tier Attribute · String Read directly by eligibility rules.

Send us one trip event

Send us the shape of one completed-trip event. We will build the off-peak mission in a test account, then send the event while you watch it settle.

Read the ingest API