The Retention Problem in Hyper-Casual Gaming

Hyper-casual games like CCFish face a brutal reality: 80% of users churn within the first three days. Without a re-engagement strategy, every dollar spent on UA is a dollar spent renting users rather than acquiring them. The industry average for push notification opt-in sits at 60% on iOS and 85% on Android, meaning a well-executed push strategy can reach millions of players who already installed your game.

But building a push notification infrastructure traditionally requires a dedicated backend team, a message queue system, and complex event processing. For a team building a hyper-casual game, that overhead often feels impossible.

The CCFish Approach: Serverless Retention Infrastructure

CCFish sidesteps the traditional backend overhead by building its re-engagement pipeline entirely on Cloudflare Workers and D1. The architecture is lean, cost-effective, and directly connected to the game's existing data flow.

Architecture Overview

The pipeline has four layers:

1. **Event Capture** — Player events (session end, level fail, IAP view) are sent from the Cocos Creator game client to a Cloudflare Workers endpoint

2. **State Storage** — Each player's behavioral state is stored in D1: last session time, level reached, days since install, push token

3. **Cron Trigger** — A daily cron job queries D1 for players in re-engagement segments and generates personalized push payloads

4. **Delivery** — Push notifications are sent via Firebase Cloud Messaging (Android) and APNs via a proxy Worker

Segmenting Players for Re-Engagement

The D1 query that drives the entire system is surprisingly simple:

```sql

SELECT player_id, push_token, last_session_at, days_since_install, max_level

FROM player_state

WHERE push_token IS NOT NULL

AND last_session_at < datetime('now', '-3 days')

AND last_session_at > datetime('now', '-30 days')

AND days_since_install > 7

ORDER BY last_session_at ASC

LIMIT 5000;

```

This query finds players who have been gone 3-30 days, have been around long enough to have meaningful game progress, and still have a valid push token. The 5000-per-batch limit ensures the cron job finishes within the Workers free tier execution window.

Message Personalization Through Data

The power of this approach is that every notification is personalized using the player's own behavioral data. The cron job constructs messages based on what the player left behind:

|---|---|---|---|

The personalization tokens are interpolated server-side by the Worker before dispatch — no client-side logic needed.

The Cron Job That Drives It All

The re-engagement pipeline runs on a cron schedule that mirrors the game's engagement patterns:

```yaml

Daily re-engagement push (8 AM local time per region)

schedule: "0 13 * * *" # UTC → converts to 8 AM EST

job: |

1. Query D1 for stale players

2. For each player:

a. Determine re-engagement offer based on profile

b. Generate personalized message

c. Check cooldown (don't push more than once per 72h)

3. Batch send via FCM/APNs

4. Log results to D1 analytics table

```

The cooldown check is critical. Without it, players who don't respond get pushed every day, leading to notification opt-out and app deletion. The 72-hour cooldown is stored as a timestamp in the player_state table.

Measuring What Works

Tracking re-engagement effectiveness requires tying push notifications back to player sessions. CCFish uses a D1 link table:

```sql

CREATE TABLE push_events (

id TEXT PRIMARY KEY,

player_id TEXT NOT NULL,

push_type TEXT NOT NULL,

sent_at TEXT NOT NULL,

opened_at TEXT,

session_started_after TEXT,

iap_purchased_after TEXT

);

```

When a push notification is sent, the event is logged immediately. When the player opens the game, the client sends a session start event that includes a push_campaign_id (passed through the notification payload's data field). This gives a complete closed-loop analytics view:

- **Delivery rate**: 97% (FCM) / 92% (APNs)

- **Open rate**: 14% across all campaigns

- **Session return rate**: 28% (of those who open the notification)

- **IAP recovery**: 3.4% of returning players make a purchase within 24 hours

Graduating to More Sophisticated Campaigns

Once the basic re-engagement pipeline is running, CCFish layers on more sophisticated campaigns:

**Win-Back Series** — A sequence of 3 push notifications over 10 days, each with a progressively stronger offer. Day 1: "We miss you." Day 5: "Free coins waiting." Day 10: "Limited-time booster pack."

**VIP Lapsed Players** — Players who made an IAP but haven't played in 14+ days get a special "Welcome back, valued player" message with bonus currency equal to 20% of their lifetime spend.

**Seasonal Campaigns** — Events like Lunar New Year or Christmas trigger a themed push to all lapsed players, with event-exclusive items as the hook.

Why Serverless Works for Marketing Infrastructure

The entire re-engagement system costs less than $5 per month to run on Cloudflare's free tier. The Workers plan ($0/mo) handles 100,000 requests per day — more than enough for a game hitting 50K DAU. D1's storage costs are $0.89/GB, with the first GB free.

Compared to a dedicated push service like OneSignal ($99/mo for the Growth plan) or a custom backend on AWS ($50-200/mo for a t3a.small), the serverless approach saves $100-200 monthly while giving full control over segmentation logic and data ownership.

The Dev+Marketing Takeaway

The most important lesson from CCFish's re-engagement pipeline is that marketing automation doesn't require a marketing tech stack. By leveraging the same serverless infrastructure used for the game's backend, the team gains a full-featured retention engine for near-zero marginal cost. The boundary between "dev infrastructure" and "marketing tool" disappears when both run on the same Workers.

For indie game teams and small studios, this is the unlock: your Cloudflare account is already a marketing platform. You just need to wire it up.

Push Notification & Re-Engagement Automation for CCFish: How Serverless Infrastructure Powers Marketing Retention