Why Game Events Matter for Marketing
Mobile game developers collect a wealth of telemetry data every day — session starts, level completions, purchases, and ad views. But most studios treat this data as a purely engineering concern: crash reporting, latency monitoring, server load. The marketing team gets a separate analytics tool (Firebase, Amplitude, Mixpanel) with limited overlap.
What if you could bridge the two? At CCFish, we built a cross-platform analytics pipeline that feeds raw game events directly into our marketing automation stack — and it changed how we think about user engagement.
The Architecture: From Game Server to Marketing Channel
CCFish runs on Cocos Creator 2.4.15 with a custom game server stack. Here's the data flow we implemented:
Layer 1: Event Collection (Game Side)
Every meaningful player action fires a structured event:
```json
{
"event": "level_complete",
"player_id": "p_abc123",
"data": {
"level": 7,
"score": 12500,
"time_played": 184,
"items_used": ["powerup_ice", "extra_life"]
},
"timestamp": "2026-05-07T14:30:00Z",
"session_id": "sess_xyz789"
}
```
These get batched and sent to a Cloudflare Worker endpoint every 60 seconds (or immediately on critical events like purchases). Batching reduces HTTP overhead while maintaining near-real-time awareness.
Layer 2: Processing (Cloudflare Workers + D1)
The Worker deduplicates events by `session_id + event + timestamp`, enriches them with player metadata (cohort, install source, days active), and writes to a D1 analytics table:
```sql
CREATE TABLE game_events (
id TEXT PRIMARY KEY,
player_id TEXT NOT NULL,
event_type TEXT NOT NULL,
event_data JSON,
session_id TEXT,
source TEXT DEFAULT 'game',
enrichments JSON,
created_at TEXT DEFAULT (datetime('now'))
);
CREATE INDEX idx_events_player ON game_events(player_id);
CREATE INDEX idx_events_type ON game_events(event_type);
```
Layer 3: Segmentation Engine
Every 15 minutes, a cron job runs a segmentation query:
```sql
SELECT
player_id,
COUNT(CASE WHEN event_type = 'purchase' THEN 1 END) as purchase_count,
COUNT(CASE WHEN event_type = 'level_complete' THEN 1 END) as levels_done,
MAX(CASE WHEN event_type = 'session_end' THEN json_extract(event_data, '$.duration') END) as max_session_time
FROM game_events
WHERE created_at > datetime('now', '-7 days')
GROUP BY player_id;
```
This produces segments like:
| Segment | Criteria | Marketing Action |
|---------|----------|-----------------|
| Whale | 3+ purchases in 7 days | VIP offer, no ads |
| Engaged F2P | 10+ sessions, 0 purchases | Offer wall, rewarded video prompt |
| Churn Risk | No session in 3+ days | Push notification + comeback bonus |
| Newbie | <5 sessions total | Tutorial tips, first-purchase discount |
Layer 4: Marketing Automation Triggers
Segments feed directly into Telegram bot campaigns. When a player enters the "Churn Risk" segment, an automated sequence fires:
1. Wait 24 hours (maybe they'll come back naturally)
2. If still churned → send personalized push notification: "🐟 Your fish are hungry! Come back for a bonus"
3. If still churned after 72 hours → trigger Telegram ad campaign targeting lookalike audience
All of this runs on Cloudflare Workers with Durable Objects for stateful sequences — no third-party marketing platform needed.
What This Unlocked for CCFish Marketing
1. Real-Time Offer Personalization
Before the pipeline, offers were server-timed ("day 3 offer", "day 7 offer"). Now offers fire based on actual behavior. A player who completes level 7 with 0 deaths gets a difficulty-scaled power-up offer immediately. Conversion rate on these triggered offers is 3.2x higher than scheduled ones.
2. Cross-Platform Attribution
CCFish has an iOS build (TestFlight), an Android APK, and a Telegram Mini App. Before the pipeline, we had no unified view of a player across platforms. Now every event carries a `player_id` that ties back to the install source, regardless of platform. We discovered that 22% of Telegram Mini App players eventually install the native iOS app — something Firebase's attribution couldn't capture.
3. Automated A/B Test Analysis
Game events include variant IDs from feature flags. When we A/B test a pricing change, the pipeline automatically segments revenue, retention, and engagement by variant — and fires a Telegram report when statistical significance is reached (p < 0.05). No manual dashboard checking.
The Cost
The entire pipeline runs on Cloudflare's free tier:
- Workers: 100k requests/day free (we use ~12k)
- D1: 5GB storage, 5M reads/month included
- Durable Objects: minimal for stateful sequences
Total monthly cost: $0. The only paid component is the Telegram bot server ($5/month on a VPS).
Key Lessons Learned
1. **Batch, don't stream.** Sending individual HTTP requests per event created too many Worker invocations. 60-second batching reduced our request count by 95% while keeping data fresh enough for segmentation.
2. **D1 eventual consistency is fine for analytics.** We don't need strong consistency for segmentation queries — a 1-2 second delay doesn't affect marketing decisions. This let us avoid Durable Objects for writes.
3. **Player IDs must be stable across platforms.** We use a combination of device fingerprint + account creation timestamp + random salt, hashed into a UUID. This survives reinstalls and platform switches.
4. **Events schema should be append-only.** We learned not to update old events. If enrichment data changes (e.g., we retroactively flag a player as VIP), we write a new enrichment record rather than mutating the original event.
Next Steps
We're building a real-time dashboard in the CCFish Telegram Mini App that surfaces these segments directly to players — showing them their own stats, achievements, and personalized offers without leaving Telegram. The game events pipeline is the backbone that makes this possible.