// INSIGHTS
Push Notifications During a Live Event, Done Properly
6 min read
A push notification is an interruption you are borrowing against a delegate's patience, and the account has a limit. Across a two-day conference you get roughly eight to twelve sends before people mute the app or delete it. Spend that budget on messages that change what somebody does in the next fifteen minutes. Everything else belongs in the in-app feed, on WhatsApp, or nowhere at all.
Treat sends as a fixed budget
Start by sorting every proposed message into four categories. Operational messages change physical behaviour immediately: the hall has moved, the bus leaves in ten minutes, lunch has opened on level two. Personal time-critical messages affect one delegate: your meeting starts in fifteen minutes at table nine. Programme messages are useful but low urgency: the afternoon keynote begins shortly. Promotional messages benefit somebody other than the delegate. The first two categories deserve push. The third deserves push only when tightly targeted. The fourth almost never does.
Segmentation is what separates a useful notification system from an irritating one. A hall change affects the 300 people who bookmarked that session, not all 2,000 delegates. You already have the data to work that out, from personal agendas, QR scan history and cohort membership. Building the segment should be a required step in the send console, not an optional one, because a console with a send-to-all button in easy reach will be used to send to all at 8am on day two.
Rate limiting has to live on the server. One push per delegate per hour as a hard ceiling, with an override reserved for genuine operational emergencies and logged when used. Add quiet hours that respect the agenda, so nothing fires during a keynote unless the building is on fire. These constraints look restrictive on a spec document and they are the reason delegates still have the app installed on day two.
A sane sending policy
Controls worth building
Category-level opt-outs
Delegates can mute promotional and programme messages while keeping operational ones. Given that choice, most people mute a category instead of muting the app.
A segment builder in the console
Target by cohort, bookmarked session, scan history or matchmaking status before composing the message. Choosing the audience first changes what people write.
Scheduled and triggered sends
Agenda reminders fire from the schedule and meeting reminders fire from the booking. Anything that can be automated is one fewer thing for a tired ops team to send at the wrong moment.
An in-app inbox as the fallback
Every message lands in a feed inside the app whether or not it was pushed. That gives the ops team somewhere to put the low-urgency announcements without spending the push budget.
Sending one notification properly
Define the segment first
Work out who is affected before writing a word. If the segment is everyone, question whether the message is really operational.
Write to sixty characters
Lock screens truncate, and a delegate decides whether to act from the first line alone. Lead with the change, not with the greeting.
Deep-link to the exact screen
A hall change opens that session's detail page, not the app home. Every extra tap between notification and action loses a share of the audience.
Check delivery, then stop
Review delivery and open rates after each send, and resist the urge to resend to non-openers. A second identical push is the most reliable way to earn a mute.
What usually goes wrong
Sponsor pressure destroys more notification strategies than bad engineering does. Sponsorship decks sell push notifications because they are easy to price, and three sponsors with two sends each consumes half the entire budget on messages that benefit nobody in the audience. Sell something better instead: prominent placement in the in-app feed, points value in the booth trail, and one geo-targeted or segment-targeted push per headline sponsor at most. Have that conversation while the sponsorship deck is being written, not on the morning of day one.
The second failure is the permission prompt. Many apps ask for notification permission on first launch, before the delegate has seen anything worth being notified about, and on iOS a denial is effectively permanent for the duration of the event. Ask after the delegate has bookmarked their first session, with one line explaining what they will receive. The third is treating push as a delivery guarantee, which it is not. Devices are off, permissions are denied, and networks fail. Anything safety-critical or genuinely time-critical goes out on push, the public address system, printed signage and WhatsApp at the same time, because WhatsApp reaches the delegates who never installed the app in the first place.
Common questions
Push or WhatsApp?
Both, for different jobs. Push is instant, free, deep-links into the app and only reaches people who installed it and granted permission. WhatsApp reaches essentially everyone in India, carries a per-message cost in INR, and is better for pre-event logistics, joining instructions and post-event follow-up. Use push for in-venue moments and WhatsApp for the days either side.
When should we ask for notification permission?
After the delegate has done something that implies they want reminders, such as bookmarking a session or accepting a meeting. Pair it with a single sentence explaining what will be sent. Asking at first launch, before any value has been demonstrated, produces a much higher denial rate and those denials are hard to reverse mid-event.
What about delegates who never install the app?
Plan for a meaningful share of them, especially at events with a broad age range or a lot of first-time attendees. Keep a WhatsApp and SMS path for critical operational messages, and make sure the printed programme and the signage carry anything the app was going to tell people. The app should improve the event, not be a prerequisite for attending it.
A notification plan before the sponsorship deck
Bring us your event comms plan and we will help set the budget and the segments.
