Building event creation, geospatial discovery, and engagement tracking in a campaign operations platform.
Context
Alongside campaigns and adverts, the creator marketing platform included an events module. Organisations could create listings with dates, tags, venue data, and platform associations, then expose approved events through token-protected delivery APIs. The same data also powered an internal map view and list workflows in the web app.
This module had to work as a full path, not a single screen: create event data, keep media organized, filter discoverable events by context, and capture engagement signals for later ranking and reporting.
Challenge
Event systems get complex quickly because each listing carries mixed structures. One event can include multiple dates, many tags, optional images, and platform targeting constraints. If create and update flows are not transactional enough, editors end up with half-saved records and inconsistent presentation.
Discovery adds another layer. Consumers need to filter by location radius, date windows, and tags while only receiving approved and eligible content. At the same time, the delivery API should capture impressions and clicks without making integration heavy for client apps.
There was also a privacy and trust angle. Venue contact details are useful, but not every organisation wants full details exposed publicly in every context.
Approach
On the GraphQL side, event creation was handled with a transaction that writes the core event record and related dates, tag mappings, and platform links together. Updates follow the same model and support a map-oriented query surface with filters for bounds, tags, and date ranges.
Map discovery behaviour was mirrored in the frontend. The Event Map page consumes mapEvents, renders markers with Mapbox, syncs selected items between map and list, and gracefully handles missing map tokens. That gave teams a practical planning surface without custom tooling.
For external delivery, Express routes under /api/delivery/events apply token auth and platform scoping, then return approved, non-deleted events with venue, dates, images, tags, and organisation metadata. Optional query filters support radius, tags, and date windows so clients can request only relevant event payloads.
Engagement tracking is built into the read path. Event detail requests write an impression entry, and click endpoints record interaction events. Media management also got explicit safeguards, including a transaction-backed hero-image switch that first clears existing hero flags then sets the target image as hero.
Sensitive venue fields are treated selectively, for example only exposing phone data when visibility settings allow it.
Outcome
The module became a coherent operational workflow rather than a set of disconnected features. Content teams could create richer event records, field teams could scan activity on a live map, and partner clients could pull eligible events through a consistent API contract.
Data quality improved because related event entities were handled together, not as fragile sequential writes. Discovery quality improved because filters were available in both internal and external contexts. Engagement tracking improved because view and click behaviour was captured as part of normal event consumption.
From an operations perspective, the main gain was reduced coordination overhead. Teams spent less time reconciling mismatched event details and more time using the workflow as intended.
Key takeaway
Event discovery features work best when creation, filtering, and tracking are designed as one continuous system. Transactional writes plus token-scoped delivery and map-friendly queries gave this workflow the consistency it needed.