Most of what you say to testers happens one to one, in tickets. Announcements are the other half of the conversation: one message to the whole beta, or to some slice of it, when something has changed that everybody needs to hear about.
They're also the antidote to the way betas usually fail. Testers sign up, hear nothing for two weeks, and quietly stop showing up.
In this article
- When announcements become available
- Write and send an announcement
- Target a slice of your testers
- See who received it and who read it
- Announcement, ticket, or triggered email?
When announcements become available
The Announcements tab sits inside your beta, but it stays quiet until two things are true: the project is published, and at least one tester has accepted their invitation. Before that there's nobody to announce anything to, so the tab says so instead of letting you write into the void.
It's also where Stomio sends you after you publish changes to a running beta. You'll get a Notify testers shortcut in the confirmation, and it's worth taking, because nothing tells testers that a task changed unless you do.
Write and send an announcement
There are three parts to an announcement:
- To, which is who gets it. More on that below.
- Body, your message, up to 300 characters. It's short on purpose, since this arrives as a notification rather than a newsletter.
- An attachment, optional, and useful when a screenshot or a build note saves you a paragraph.
Then hit Send it.
Staring at an empty box? There's a list of ready-made suggestions further down the page under Some ideas you can use. Tap one and it drops into the message box, where you can rewrite it however you like.
Target a slice of your testers
The To field takes tags, individual testers, or a mix of both. Tags send to everyone carrying that tester tag; individual testers you just pick by name.
Tags are what keep announcements from becoming noise. If only your iOS testers care that a new build is up, sending it to everyone teaches the Android half to skim past your messages, and you'll pay for that the next time you send something they genuinely need to read.
See who received it and who read it
Previous announcements gives you a timeline of everything you've sent. Each entry shows who sent it, when, which tags it went to, and two counts: recipients and viewers.
Click either count and you get the actual names, under Announcement sent to or Announcement view by, so you're not just looking at a percentage.
Read the view list in one direction only
Open tracking is best effort, and it's worth knowing why before you draw conclusions from it. Registering an open depends on the tester's email client loading a small tracking image, and plenty of clients block that by default, or hide it behind a privacy setting the tester may not even know is switched on.
Which means the signal only works one way:
- A name in the viewed list did open it. That part is solid.
- A name missing from the list tells you nothing at all. They may have read every word on a client that never phoned home.
So use the viewed list to confirm who you can count on, not to build a list of people who ignored you. Chasing a tester for not reading something they did read is a quick way to lose a good one.
The same goes for engagement generally. Someone who never registers an open but completes every task is doing fine, and has probably just got images turned off. It's the tester with no opens and no completed tasks who's worth a direct message.
Announcement, ticket, or triggered email?
Three ways to reach a tester, and picking the wrong one is usually why a message goes unread.
Use an announcement for news that affects everyone: new tasks, a new build, a change of dates, a thank you when the beta wraps up. Use a ticket when it's a conversation with one person, like a bug they reported or a question about their setup (Use Tickets to Capture Qualitative Tester Feedback covers those). And a triggered email fires by itself when a tester reaches a particular step, which is more about routing their feedback to the right colleague than talking to the tester at all, covered in Make Sure Your Emails Reach Your Testers.
Rough rule: if you find yourself typing the same message a second time, it should have been an announcement. If you're announcing something only one tester cares about, it should have been a ticket.