Welcome Journey Documentation

Use Case Description

A Welcome Journey is a critical player onboarding experience that activates immediately when a new player registers with your brand. This automated customer journey is designed to transform first-time registrants into engaged, depositing players. Messages can be personalised by name, sign-up offer and acquisition source, so the first experience matches why the player joined.

To take full advantage of the Welcome Journey, please review the technical requirements for this use case.

Deploying Your Use Case

Understanding The Flow

The Welcome Journey is structured as a multi-step, time-based marketing automation workflow that responds to player behaviour and profile attributes.

Players enter the journey on the customer_registration event. Operators send their own event names, so yours may differ. The screenshot below shows one example of how a welcome journey can be built. Your own can differ in channels, timings and number of steps. Treat it as inspiration, not a template.

Every path must finish at an endpoint. See Ending Journeys and Analysing Results.

Build it in Journey Builder: Journey Builder overview · Time delays · Decision branches · Adding channels

Adjusting the Use Case

The Welcome Journey can be adapted to your player base, regulatory requirements and marketing strategy. Key areas to consider:

Timing and cadence

• The example waits 12 hours before checking for a deposit. Use your own FTD data to set this. If most depositors convert sooner or later, move the check to match. This can be variant tested too.

• Use Engagement Categories to cap how many welcome messages a player receives and to avoid overlap with other live campaigns. For setup, see Setting Engagement Rules and Categories.

Content personalisation

• Use dynamic fields such as first_name and currency_symbol, with a fallback for missing values. See Personalisation and dynamic programmable content.

• Tailor content by sign-up offer (signup_offer) and acquisition source (acquisition_source_code). For example, a player acquired via a football campaign should see football fixtures and markets, not a generic sportsbook banner.

Channels

• The example uses email and inbox. You can add or swap SMS, push or other channels on any branch, provided players have consented and your project supports them.

Regulatory compliance

• Include the responsible gaming messaging and terms your licence requires in every message. Requirements vary by jurisdiction, so check with your compliance team.

• Include an unsubscribe route in every email. Consent Manager is an optional feature, enabled on request. See Managing User Consent. If you don't use it, make sure channel marketing permission is held elsewhere in your project.

• Make sure self-excluded, blocked and bonus-abuse-flagged players do not enter the journey, using entry criteria or your project's global include conditions.

Use Case Requirements

Before deploying this use case, ensure your data infrastructure supports the technical requirements outlined below. This use case relies on real-time event triggers and profile attributes to deliver personalised, timely messaging to the right players.

The following tables specify which event data and profile attributes are required, recommended, or optional for optimal performance. Proper data foundation is the difference between a high-performing automated journey and one that underdelivers on its potential.

Event

The customer_registration event is required. Each event must include a user_id and a timestamp in ISO 8601 format. For payload structure, see Event Payloads: The Engagement Engine.

The example also includes an FTD check, so the journey needs a deposit signal. This can be a deposit event or an attribute such as deposit_count.

{
  "event": "customer_registration",
  "timestamp": "2025-01-06T09:22:27Z",
  "user_id": "user123",
  "user_attributes": {
    "first_name": "John",
    "last_name": "Smith",
    "username": "jsmith123",
    "birth_date": "1990-01-01",
    "registration_date": "2025-01-06T09:22:27Z",
    "country_name": "United Kingdom",
    "state": "England",
    "city": "London",
    "postal_code": "SW1A 1AA",
    "signup_language": "en",
    "acquisition_source_code": "PPC_GOOGLE_01",
    "currency_code": "GBP",
    "currency_symbol": "£",
    "account_status": "active",
    "customer_segment": "new_player",
    "reward_tier": "bronze",
    "kyc_status": "pending",
    "is_blocked": false,
    "is_abuser": false,
    "is_self_excluded": false
  },
  "value": {
    "promo_code": "WELCOME2025",
    "referrer_url": "https://google.com/search",
    "balance_cash": 10,
    "balance_bonus": 50,
    "balance_total": 60
  }
}

📝 How user attributes work
Anything you send in user_attributes is written to the player's Xtremepush profile, so it's available for segmentation, personalisation and exclusions in every journey, not just this one. Data about the event itself, such as promo_code, goes in value.

• Send only what has changed. Standard events such as kyc_verification and player_update update a few attributes at a time.

• Custom attributes must exist in your project before you send them. See Data Ingestion.

Profile Attributes

These player profile attributes are used for segmentation, personalisation, and targeting throughout the Welcome Journey.

Optimising Your Welcome Journey for Maximum Conversion

The first hours after registration are your best chance to convert a sign-up into a depositing player. When executed with strong data, segmentation, multi-channel delivery, and personalisation, it significantly impacts first-deposit conversion. Keep improving the journey with your own performance data.

Measure

• Track FTD conversion at each check point. In the example, that's 12 hours and one day later.

• Also watch time to FTD, message engagement and unsubscribe rate.

• Keep a control group so you can see what the journey adds beyond organic deposits.

Test one variable at a time

• Compare first-wait lengths, such as 6, 12 and 24 hours.

• Compare offer versus no offer in the reminder.

• Compare email only versus adding SMS or push on the "no deposit" path.

• Run these with decision branches.

Related use cases

Once a player has deposited, Deposit No Bet can encourage them to place their first bet.