Event push notifications

Push notification permission is the only asset in an event app you can spend down permanently. An attendee who turns them off on day one is unreachable for the rest of the event, and you will not know which attendees those are until the moment you need them.

Everything below follows from treating permission as a budget.

The rule that matters most

Every notification opens the exact thing it is about. Not the app. Not the home screen. The session that moved, the announcement that was posted, the thread that was replied to.

This one rule matters more than volume, timing and copy combined. A notification that says “Keynote moved to the Windsor Suite” and then dumps the attendee on a home screen has made them do the work twice, and they will remember. Two or three of those and notifications become something to dismiss rather than read.

In event67 announcements and messages deep-link to the exact post or thread. If you are evaluating another product, this is the specific behaviour to test in the demo, not to ask about.

How many, and when

For a full-programme conference:

When	What	Send to
07:45	Today at a glance, with the one thing not to miss	Everyone
Mid-morning	Only if something changed	Affected attendees
12:15	Lunch, and the topic tables	Everyone, day one only
Mid-afternoon	Only if something changed	Affected attendees
17:30	Tonight, and tomorrow’s first session	Everyone

Three scheduled, two conditional. That is the shape. On a single-day event, halve it.

Two timing rules that are worth being strict about. Nothing before 7:30am, because attendees are in different hotels and some arrived last night from a different time zone. Nothing after the last programmed item, because an evening notification is a notification you will pay for tomorrow.

Schedule the fixed ones the night before. A notification composed live is where a typo reaches four hundred phones.

The first one sets the terms

The first notification an attendee receives teaches them what these are for. Waste it on “Welcome to the conference!” and you have taught them that notifications carry nothing.

Send something genuinely useful on the first morning: the room the opening is in, the one workshop still with space, the thing that is different from the printed programme. Then permission is worth having when you need it at 14:20 on day two.

Writing them

Notifications are read in a glance on a lock screen. Front-load the information.

Do not send	Send
“Don’t miss today’s exciting sessions!”	“Opening keynote, Windsor Suite, 09:15”
“Important update”	“Track B moved to Room 4 for the rest of today”
“Check out the app for the latest”	“Three workshop places left: Kubernetes at 14:00”
“Thanks for a great day one!”	“Tomorrow starts at 08:45, not 09:00”

Rules that hold:

• Under ten words where possible. The lock screen truncates.
• Lead with the noun. “Keynote moved” not “Please note that the keynote has moved”.
• No exclamation marks. They read as marketing, and marketing is what people turn off.
• No emoji in the first three words. They displace the information in the truncation.
• Say the room, not the room ID. The Windsor Suite, because that is what the door says.

Segment before you broadcast

The default should be the smallest group for whom the message is true.

• A room change goes to attendees who saved that session.
• A workshop with places left goes to people who did not get in.
• A track-specific announcement goes to that track.
• Only genuinely event-wide news goes to everyone.

Sending everything to everyone is how a five-a-day budget becomes fifteen. If your tool cannot segment, that is a real constraint and it should lower your volume, not raise it.

Scheduled versus live

Schedule the predictable ones: the morning summary, lunch, the evening wrap. Write them the night before, when you have judgement and a keyboard.

Send live only when something has actually changed. That is the whole list. If you find yourself composing a live notification because the afternoon feels quiet, you are spending permission on a mood.

event67 supports both: announcements publish now or schedule to push at a set time, and both deep-link.

Read the delivery report

Sent is not delivered. After the first send, look at the numbers.

• A large gap between sent and delivered usually means permissions declined at first run, or stale device tokens from attendees who reinstalled. Some of this is fixable on day one by asking at the registration desk.
• A gap that grows across the event usually means people are turning notifications off, which is a volume problem and the only honest response is to send fewer.
• Zero delivered on one platform is a certificate or configuration problem, and it is the one thing on this page you should test before the event rather than discover during it.

Notifications and sponsors

A sponsored notification is the highest-value digital asset in most event apps, and the one most likely to be misused.

• One per event, maximum.
• You write it, or you approve every word.
• It has to be useful to the attendee first. “Coffee is on Acme in the atrium until 11” works. “Acme is revolutionising the industry, visit stand 4” does not.
• Price it properly. It reaches every attendee and it is genuinely scarce. There is more on this in sponsor package ideas.

A sponsor who is allowed to write their own copy will spend permission you built over a week. That is not a reason to refuse; it is a reason to hold the pen.

The failure modes

The 6:45am send. Someone tests a notification early on day one and forgets it goes to everyone. Restrict who can send, and rehearse to a test group.

The apology chain. A notification goes out wrong, then a correction, then an apology. Three interruptions for one mistake. Send the correction, skip the apology.

Silence, then crisis. The first notification of the event is a fire-alarm message. Nobody has them on, because nothing ever came through. This is the argument for sending something useful on the first morning.

The link that goes nowhere. A deep link to a session that was deleted opens an error. Check links after any schedule change.

Notification as a substitute for signage. If people cannot find the room, print a sign. A notification reaches the people who have the app, have notifications on, and are looking at their phone. A sign reaches everyone.

What to do when notifications are the wrong tool

A notification reaches attendees who have the app, have permission on, and are looking at their phone. That is a large share of a room and it is never all of it, so some messages need a different channel.

A room change five minutes before a session is a person standing at the old door, not a notification. Send the notification as well, but the person is what works.

Anything safety-related goes through the venue’s own systems first. A public address announcement reaches everyone in the building including the people who never installed anything.

A message for one attendee is a conversation, not a broadcast. Segmenting to a single person still costs the same permission and reads as strange.

Something people need after the event is an email. Notifications are ephemeral by design and the app’s half-life is short once everyone has gone home.

Detail that will not fit on a lock screen goes in an announcement inside the app, with a short notification pointing at it. That is what deep-linking is for: the notification carries the fact, the announcement carries the detail.

The judgement is worth making explicitly rather than by habit, because the default at most events is to send everything through the newest channel and then wonder why permission erodes across two days.

A workable default

If you take one thing: three a day, all deep-linked, the first one useful, segmented wherever the message is not true for everyone, and written the night before. That covers most conferences and leaves permission intact for the day something actually goes wrong.