A gym manager created a group «Promo: discounted memberships» and added 150 numbers from website leads. Clients saw they were added to a stranger's chat without consent, were angry their numbers were exposed to strangers, and mass-left. Number banned in 12 minutes. Not a text mistake - a format mistake. How groups differ from broadcast lists and why confusing them is almost always expensive.
Groups and Broadcast Lists solve different jobs. A group is a shared chat - everyone sees each other's messages and phone numbers. A broadcast list delivers one message as separate private chats with no recipient visibility - see manual label funnel where Broadcast is a separate tool.
| Parameter | Group | Broadcast list |
|---|---|---|
| Members visible to each other | Yes - numbers and messages [✓] | No [✓] |
| Where replies go | Group chat | Sender's private chat [✓] |
| Size limit | Up to 1024 per group [✓] | Up to 256 per list [✓] |
| Delivery condition | To all added [~] | Only if recipient saved your number [✓] |
| Admins-only mode | Hides posting, not member numbers [~] | N/A |
| Main risk | Number leak, invite without consent | Zero delivery on cold base |
Before (implicit): Both limits ~256.
After: Different numbers. Broadcast list - 256 per list, unlimited lists per account. Group - up to 1024. Old 256 for groups is outdated.
Before: Broadcast guarantees delivery to all listed.
After: No. Message reaches device only if company number is saved in recipient's contacts - same logic as cold vs warm lists. Cold base = broadcast effectively dead.
Saving your number = opt-in; Meta treats list sends as lower software spam risk. But on cold/dormant base where nobody saved you, real device delivery often 5–15% - see inbound opt-in collection.
Group delivers regardless of saved contact - great for live community, fatal for blast use: every member sees all numbers; forced cold invites get crushed by the system.
Unknown adder → prominent Report and Leave buttons - gym ban in 12 minutes - see mass mailing ban mechanics.
Admins-only stops flood, not privacy - member list and numbers still visible.
Yoga studio asked reception clients to save studio number for schedule. 500 loyal clients across two broadcast lists; weekly schedule in private chats - 92% delivery, 0 complaints - similar to local business service notifications.
Shows: broadcast + prior opt-in works for regular personal notices. Doesn't prove: 92% is universal - result of consent collection, not format alone.
Gym group + forced invite - opposite. Difference: format and consent, not niche.
Group: community where peer interaction has value - client clubs, course chats, peer support, resident communities.
Broadcast list: personal offers, promos, booking/order notices - no recipient visibility needed.
No official Meta «support = group, promo = list» rule - practical conclusion from product design.
Meta Communities bundle groups with announcement channel hiding numbers from outsiders. Practitioners split: partial group replacement for privacy vs harder admin for micro-business. No universal proof - team readiness decides.
«In broadcast list = sure delivery» - False. Saved number required.
«Admins-only = hidden safe channel» - False. Numbers still visible.
«Group works for any mass send - easy to add people» - False. Unconsented add = number leak + complaints - behavioral antispam.
«Many 256 lists = free cold spam» - False. Unsaved = ~zero delivery - like first cold message without prior contact.
Before next campaign: do recipients need to see each other? If no - broadcast list + confirm saved numbers. If yes - group only with explicit add consent.
Practical rule:
Groups unite people. Broadcast lists speak to each alone. Swap the goal - number leak or zero delivery.
