Home / How it works / Industry playbooks
Playbooks

Industry playbooks

ContentFlow's building blocks are the same in every industry: blocks to show, campaigns and journeys to reach, profiles and segments to target, analytics and sensors to measure. What changes is the vocabulary, the regulator, and the moments that matter. Each playbook below is built only from capabilities that work today, and lists the calls in the order you make them.

In short
  • Every industry uses the same building blocks: blocks, campaigns and journeys, profiles and segments, analytics and sensors.
  • Each playbook starts from its consent preset (for example banking_ksa), fetched with GET /sdk/v1/consent/config/{preset}, then its profile schema and event helper.
  • Each scenario gives the goal, the products, the one-time setup and the calls. Use the switcher to show one industry.
Format

How to read a playbook

Every industry starts with its consent preset (fetch it with GET /sdk/v1/consent/config/{preset}), its profile schema (industryType plus typed fields), and its event helper. Each scenario then gives the goal, the products, the one-time setup, and the calls. Use the switcher to focus on one industry.

Banking

Banking

Consent preset banking_ksa (SAMA + PDPL): push required for security alerts; topics transaction alerts, statement ready, offers and rewards, card updatesProfile industryType: banking: KYC level, account and card types, income band, products heldEvents trackBanking: transfer initiated / completed / failed, bill payment, card activated / blocked / limit changed, statement download

1. Personal-finance offer for salaried customers

Goal: raise applications from customers who earn enough to qualify. Products: enrichment, segments, blocks, push campaign, analytics.

Salary-based personal finance offer
  1. Nightly, stored on each profile: monthly_salary and has_personal_finance per customer, source erp_sync or csv_upload.
  2. Daily update frequency; used by the campaign and the journey.

    If this step is skipped: Enrichment rules aren't evaluated on the in-app delivery path. For the in-app card, also send the salary band as an identify trait (traits.salary feeds a workspace segment on the salary trait).

  3. The in-app offer card targets a workspace segment on the salary trait (fed by the trait the app sends on identify).
  4. The Management API dispatches a push campaign to the enrichment segment, Arabic and English, deferred around prayer times, to people with push consent.
  5. ContentFlow hands each push to the provider, which delivers it to the device.
  6. Events reach analytics through the SDK API within seconds. Tap on the card; conversion when the application is submitted. Compare variants if the card runs an A/B test.

2. Card activation onboarding

Goal: get new customers to activate their card in the first week. Products: journeys, push, in-app, traits.

  1. A journey triggered by the Signs up app event (eventType SIGN_UP) → wait 1 hour → push "Activate your card in two taps" → condition Card active → no branch: in-app step (shown as journey_message) after 2 days.
  2. Segment Card active: customAttributes.card_active is_true.
  3. App: trackSignUp({ username: userId }) on registration; on activation trackBanking('card_activated', { cardType }) and identify({ traits: { card_active: true } }).

3. "Eligible but didn't apply" win-back

Goal: follow up with people who saw they were eligible but never applied. Products: sensors, rules, segments, WhatsApp.

  1. Enable sensors on offer.eligible (the eligibility message) and offer.apply_cta (the Apply button).
  2. Relationship absence: impression of offer.eligible without interaction with offer.apply_cta within 24 hours. Rule: add to segment Eligibility drop-offs, remove on recovery.
  3. Journey with trigger segment_entry on that segment → WhatsApp template with a link back to the offer.
  4. App: render both strings with client.t(); trackString('offer.apply_cta', 'interaction') on tap.

4. Security and transaction alerts

Goal: reliable alerts that survive marketing opt-outs. Products: consent presets, push, one-off notifications API.

  1. Build the consent screen from banking_ksa: security alerts are required, marketing topics optional.
  2. App: registerPush after OS permission; setChannelConsent({ push: true }).
  3. Your backend: POST /api/v1/notifications for the person when your core banking system raises an alert. Note that PDPL opt-out blocks every channel.
Fintech

Fintech and wallets

Consent preset fintech_ksa (SAMA + PDPL): security alerts required; transaction alerts, payment reminders, product updatesProfile industryType: fintech: KYC, wallet, transactions, credit scoreEvents trackBanking plus custom events (there's no fintech helper yet)

1. Low-balance top-up nudge

  1. App: client.track('wallet_low_balance', {}, { balance: 12 }) when the balance drops below your threshold.
  2. Journey trigger event = wallet_low_balance → push "Top up in one tap" with a deep link (https universal link) → wait 1 day → in-app reminder.
  3. Measure with trackBanking('transfer_completed', …) or a custom wallet_top_up conversion.

2. Finish your verification

  1. App: on each verification step send a trait, for example identify({ traits: { kyc_level: 'basic' } }).
  2. Segment customAttributes.kyc_level in ['none', 'basic'] → a home block explaining the benefits of full verification, and a journey reminder.
  3. Verification itself stays in your KYC provider; ContentFlow's KYC records are server-side only and not exposed to the SDK.

3. Referral programme A/B test

  1. One referral_card instance with an A/B test: "Give 50, get 50" vs "Invite friends, earn rewards".
  2. Each device sticks to its variant; trackTap and trackConversion carry variantId.
  3. Read results per variant, conclude the test, and the winner is served to everyone.
Insurance

Insurance

Consent preset insurance_ksa (CCHI + PDPL): policy updates, claim statusProfile industryType: insurance: policies (motor, health, home, travel, life), claims history, no-claims level, dependents, vehiclesEvents trackInsurance: quote, policy renewal, claim started, document uploaded, claim submitted, claim status viewed

1. Claim status updates

From claim submitted to status updates
  1. With the claim reference as a property.
  2. The SDK API accepts the event and analytics records it.
  3. The journey's event trigger enrols the person into the Claim follow-up journey.

    If this step is skipped: Without analytics consent there's no profile, so the person can't be enrolled. Make claim notifications part of your required service consent.

  4. An approved template; the claim reference fills a variable.
  5. Then an in-app reminder to upload missing documents.

2. Renewal reminders

  1. Upload policy_end_date and policy_type from your policy system as enrichment (typed date).
  2. Segment on the end date with a date rule, updated daily; a push and SMS campaign 30 days ahead, and a renewal block in the app for the same segment through a trait such as renewal_due: true.

3. Motor cross-sell

  1. Segment: has a vehicle (industryProfile.vehicles exists) and no motor policy.
  2. Blocks and campaigns with a quote CTA; trackInsurance('quote_requested') as the conversion.
Healthcare

Healthcare

Consent preset healthcare_ksa (CBAHI + PDPL): appointment and medication reminders, lab resultsProfile industryType: healthcare: patient, care, insurance, wellnessEvents trackHealthcare: appointment booked / cancelled / rescheduled / checked in, lab results viewed, prescription refill, video consult
i Keep health data out of messagesWrite reminders that don't reveal a condition ("You have an appointment tomorrow"), and target on operational facts (an upcoming appointment) rather than diagnoses.

1. Appointment reminders

  1. App: trackHealthcare('appointment_booked', { clinic, slot }).
  2. Your scheduling system uploads next_appointment as enrichment; a daily segment "appointment tomorrow" feeds a push and SMS campaign with a check-in link.
  3. Measure attendance with trackHealthcare('appointment_checked_in').

2. Lab results ready

  1. Your lab system calls POST /api/v1/notifications for the patient with a neutral message and a deep link into the results screen.
  2. The app records trackHealthcare('lab_results_viewed').

3. Seasonal wellness content

  1. A wellness_tip block with Ramadan fasting and hydration guidance on a custom schedule, Arabic and English, for all users.
  2. Sensors on the tip's title and read-more link to see engagement.
Travel

Travel and airlines

Consent preset travel_ksa (PDPL): booking updates, flight status, gate changes, travel deals, loyalty updatesProfile industryType: travel: loyalty tier, seat and meal preferences, history, passport expiry, companionsEvents trackTravel: search, booking, check-in, boarding pass, miles redeemed, upgrade

1. Check-in reminder and upgrade offer

  1. Upload upcoming flights (next_departure) as enrichment; segment "departs in the next 48 hours", updated hourly.
  2. Push "Check-in is open" to that segment; the app's home block (trait upgrade_eligible: true) shows a paid upgrade.
  3. trackTravel('checkin_completed') and trackTravel('upgrade_requested') as conversions.

2. Airport presence

  1. The app registers a geofence around each airport: registerGeofence({ fence: { type: 'circle', id: 'ruh-airport', … }, triggers: { onEnter: true, onDwell: true } }).
  2. Enter and dwell events appear in Analytics → Location; use the local onEnter callback to show the boarding pass. A journey can start when someone enters, leaves or dwells in a geofence (GEOFENCE_ENTER / GEOFENCE_EXIT / GEOFENCE_DWELL, optionally filtered by fence).

3. Loyalty tier upgrade

  1. Segment on industryProfile.loyalty.tier; a celebratory block and push when people enter the Gold segment (journey trigger segment_entry).
Retail

Retail and e-commerce

Consent preset retail_ksa (PDPL): order updates, delivery status, promotions, back in stock, loyalty rewardsProfile industryType: retail: purchases, cart, loyalty, preferencesEvents trackRetail: product viewed, search, wishlist, cart add / remove / abandon, checkout, purchase

1. Cart recovery

Abandoned cart → reminder → purchase
  1. When the cart is left with items, with cart value and item count.
  2. The SDK API accepts the event and analytics records it.
  3. The journey's event trigger enrols the person into Cart recovery; each person enters once, so design it as a long-running programme.
  4. Give them time to come back on their own.
  5. Branch on a segment built from a purchase trait.

    If this step is skipped: Without a purchase segment the reminder goes to people who already bought. Keep a trait like last_purchase_at current on identify.

  6. Only on the no branch, to people with push consent.
  7. The conversion, sent through the SDK API to analytics, which measures the journey.

2. Seasonal collections

  1. A collection block (carousel) of product cards for White Friday or Ramadan, each card its own instance with its own segment, on a custom schedule (Riyadh time by default).
  2. Impressions and taps per card show which products pull.

3. Back in stock

  1. The person opts into the back in stock topic; your inventory system calls POST /api/v1/notifications for each subscriber when the item returns.
Food delivery

Food delivery

Consent preset food_delivery_ksa (PDPL): order status required; driver location, deals and discounts, recommendationsProfile industryType: food_delivery: ordering, preferences, behaviourEvents trackFoodDelivery: order placed through delivered, or cancelled

1. Iftar-time offers in Ramadan

Ramadan starts → wait until iftar → offer
  1. The journey checks the Hijri calendar each day; its Hijri trigger enrols people on the first day of Ramadan.
  2. Waits until maghrib for the day (prayer-time aware).
  3. Branch: regulars get a loyalty offer, others a first-order discount.
  4. Arabic and English, to people with push consent.
  5. ContentFlow hands the push to the provider for delivery.
  6. The conversion.

2. Win back lapsed customers

  1. Journey trigger inactivity, 30 days → push with a voucher → wait 3 days → SMS if still inactive (condition on a recent-order segment).

3. Order status

  1. Order status is a required topic. Your order system calls POST /api/v1/notifications at each stage; the app records trackFoodDelivery('order_delivered').
Any app

Any app, including government and media

1. Kill switch and feature flags

  1. Give a feature's entry point a block with an #enabled boolean field. Pausing the instance or disabling the type hides it on the next sync, with no release.

2. Service announcements

  1. An announcement block on the home screen for outages, holidays and new services, with Arabic and English copy and a custom schedule; publish goes through approval.

3. Measure your copy

  1. Turn the strings on your key screens into sensors; a surface tracker shows what people see and tap, before and after a copy change.

4. Ask for feedback

  1. An NPS card block for engaged users (lifecycle engaged), recorded with track('nps_submitted', {}, { score }); detractors enter a follow-up journey through a trait.
Back to How it works Get started