Community-Led App Distribution Without Getting Banned

Because the tactic that scales — one message, many strangers — is the exact behaviour every one of these platforms defines as spam, and each of them says so in writing before you start. The ban is not arbitrary enforcement catching you out. It is the published rule doing what it says.

The pattern is consistent across the teams we are called in to rescue. Someone builds a list of forty relevant servers, groups or subreddits. They write one good post. They send it to all forty over two days from one account. Within a week the account can no longer message strangers, half the posts are removed, and the team concludes that community marketing does not work.

Community marketing works. Bulk identical outreach from a fresh account is a different activity that happens to use the same buttons, and the platforms distinguish between them explicitly.

The third is the one teams underweight, because it does not feel like a platform risk at all. Asking a Telegram group of loyal users to go and rate the app is a community activity with an app store consequence, and the app store consequence is far more severe than anything Telegram will do to you.

Across the 300+ apps we have managed since 2013, the launches that survive community distribution share one unglamorous property: someone read the rules of each platform first and wrote the plan against them. That is the whole method. What follows is what those rules say, quoted from the pages themselves, and one platform where we cannot quote them at all.

Discord prohibits unsolicited bulk messages, prohibits self-bots outright, and prohibits artificially inflating server membership — which removes automation, mass DMs and bought members in three separate rules. Read together, they leave you with participation and nothing else.

The Discord Community Guidelines state it plainly. Rule 13: “Do not send unsolicited bulk messages (or spam) to others. Also, do not facilitate this activity, such as by selling spambots, server ‘raid’ tools, account-creation tools, token generators, CAPTCHA-solving services, or other spam tools.” Rule 14: “Do not use self-bots or user-bots. Each account must be associated with a human, not a bot.” Rule 15: “Do not engage with our service in an inauthentic way. This includes artificially inflating server membership, manipulating engagement metrics, and selling artificial engagement services.”

Rule 14 is the one that quietly ends most growth-hacking plans. A script that posts your launch announcement into thirty servers from your own user account is a self-bot, regardless of how careful the script is, because the account it drives is not being driven by a human at that moment.

Discord’s Terms of Service add a separate restriction that catches the research half of the same plan. Section 9 prohibits “scraping our services without our written consent, including by using any robot, spider, crawler, scraper, or other automatic device, process, or software”. Harvesting member lists from a server you joined is not a grey area under that wording.

What is left is unrestricted and considerably more effective: join as a person, post where the server’s own rules permit it, and ask the moderators before you post anything promotional. Server rules are set per server and vary enormously, and they are the layer that will actually remove you long before Discord does.

For sending unwanted messages to strangers or posting spam in groups — and the restriction that follows is precisely shaped: a limited account can still message people who have your number saved as a contact, and can always reply to anyone who messaged first. That shape tells you exactly which half of your plan Telegram considers legitimate.

Telegram’s Terms of Service list the prohibited activities directly, including “Use our service to send spam or scam users”, and state that failure to comply “may result in a temporary or permanent ban from Telegram or some of its services”. The mechanism behind that is documented separately on Telegram’s Spam FAQ: when users press the report button in a chat, those messages go to moderators, and accounts are limited when moderators determine that the user has been sending unwanted messages to random strangers or posting spam in groups.

The consequence is worth quoting because it is unusually specific. Limited accounts can send messages to people who have their number saved as a contact, and you can always reply to anyone who messages you first. Telegram also documents an appeal route for accounts it has limited in error, through its @SpamBot.

Read that as a design brief rather than a punishment. Telegram’s restriction leaves inbound conversation and existing relationships completely intact while removing cold outbound. A distribution plan built on people messaging you, or on a public channel people choose to join, is untouched by the limit even if you are wrongly reported.

• A public channel is not outbound messaging. People subscribe; you broadcast to subscribers. Nothing in the spam mechanism above applies to that relationship.
• Being added to groups is not permission to advertise in them. Group admins remove promotional posts, and enough removals is what generates the reports in the first place.
• Never mass-add users to a group. It generates the exact report pattern the moderators are looking for, from people who did not ask to be there.

We have seen this work well for regional apps in India, where a Telegram channel becomes the release-notes surface for the users who care most. That audience is small and disproportionately valuable, which is a pattern our guide to getting your first 100 app users covers in more depth.

Two things, both mandatory: the person must have given you their phone number, and they must have opted in to receiving messages from you. WhatsApp is the strictest of the four platforms here, and the requirement is stated as a condition, not a recommendation.

The WhatsApp Business Messaging Policy sets the bar: “You may only contact people on WhatsApp if: (a) they have given you their mobile phone number; and (b) you have received opt-in permission from the recipient confirming that they wish to receive subsequent messages or calls from you.” The same policy tells businesses not to “confuse, deceive, defraud, mislead, spam, or surprise people with your communications”, to respect opt-out requests, and to provide clear instructions for how people can opt out.

Note what condition (a) rules out. A number you scraped, bought, matched from another platform or found in a group member list was not given to you, so it fails the first test before opt-in is even considered. Both conditions have to hold.

For Indian consumer apps this is often the difference between a channel that compounds and one that gets the business number blocked within a fortnight. The workable version is unexciting: collect the number and the permission together, at a moment when the user wants something from you, and treat the opt-out as a real product feature rather than a line of small print.

The other reason to be careful here is that WhatsApp is the channel where growth teams most often reach for a purchased list. Our note on where paid install sources cross the line makes the same argument in a different channel: the shortcut and the enforcement action are usually the same event, separated by a few weeks.

Because we could not open them. Reddit’s help centre returned HTTP 403 to our tooling, and its main site and corporate policy site were not reachable either, so we have no verified text to quote — and this publication does not paraphrase policy from memory.

That refusal is the point of the section rather than an apology for it. Platform rules change, and a confidently recalled version of a self-promotion policy is worse than no version, because a reader will act on it. Every other rule in this article is a quotation from a page we opened and read. Reddit’s is not available to us on the same terms, so it is not here.

What you should do instead is straightforward, and it is what we do for clients:

The general principle survives the missing citation intact. On every platform we could verify, the prohibited pattern is the same one — high-volume, low-relationship, automated or unsolicited broadcast — and there is no reason to expect a community platform we could not open to be more permissive about it than Discord, Telegram and WhatsApp are.

If you need certainty on a specific subreddit before spending a launch on it, that is a research task with a person doing the reading, not a policy you can generalise. We would rather tell you that than print a rule number we cannot verify.

Severely, and independently of anything the community platform does — Apple states that manipulating reviews may include expelling you from the Apple Developer Program. This is the risk that turns a bad week into a lost business, and it is created by a message you send outside the store entirely.

The App Review Guidelines put it in the introduction, before any numbered rule: “If we find that you have attempted to manipulate reviews, inflate your chart rankings with paid, incentivized, filtered, or fake feedback, or engage with third-party services to do so on your behalf, we will take steps to preserve the integrity of the App Store, which may include expelling you from the Apple Developer Program.”

Google is equally direct. Its policy on user ratings, reviews and installs prohibits inflating product ratings, reviews or install counts by illegitimate means such as fraudulent or incentivized reviews, and states that “Developers must not attempt to manipulate the placement of any apps on Google Play.” The same policy bars reviews containing inappropriate content, “including affiliates, coupons, game codes, email addresses, or links to websites or other apps”.

Apple draws one line inside the app as well. Guideline 3.2.2(x) states that apps “must not force users to rate the app, review the app, download other apps, or other store-related actions in order to access functionality, content, or use of the app”, while apps “may otherwise incentivize users to take specific actions within apps (e.g. completing a level, watching an ad)”. The permitted incentives are for in-app actions; store actions are the excluded category.

Telling a community your app exists is not manipulation. Attaching a reward, a rating target or a star count to it is where the language above starts to apply. Our guide to getting ratings and reviews within the rules covers the compliant mechanisms, and what a Play enforcement action looks like covers the recovery path if you are already past this point.

Slow at the top, permission-based in the middle, and completely uncoupled from your store ratings at the bottom. Every rule quoted above points in the same direction, which makes the plan easier to write than it looks.

The uncomfortable part is the second step, because it does not fit a launch date. A community you joined last week will not carry your launch. A community you have been useful in since January will, and the people in it will defend the post when someone calls it spam.

In our portfolio the apps that get real distribution from communities are almost always the ones where a founder or a product person is genuinely present in them, not a marketing account. That is not a moral point. It is that presence is the only input the moderators can see, and moderators are the enforcement layer that matters day to day. Where communities need to compound into something larger, the mechanics in our referral programme guide are the natural next step.

On Android, with the Play Install Referrer API, which returns the referrer string your link carried along with click and install timestamps. Without that, community work is invisible in your dashboards and gets cut at the first budget review despite being the cheapest channel you have.

The Play Install Referrer Library documentation describes what you get back. The ReferrerDetails object exposes the install referrer URL, the referrer click timestamp in seconds, the app install begin timestamp in seconds, and a Google Play Instant parameter. Google states that the install referrer information will be available for 90 days and will not change unless the application is reinstalled, and advises invoking the API only once, during the first execution after install, to avoid unnecessary calls.

Two timestamps rather than one is more useful than it first appears for this channel. Community-sourced installs often have a long gap between click and install — someone reads a post at work and installs that evening — and a gap that would look like fraud in a paid campaign is entirely normal here. Knowing both timestamps is what lets you tell those apart instead of writing off the channel.

Give every community a distinct referrer value: one per server, per channel, per subreddit, per campaign. The cost is a few minutes at link-building time and the benefit is being able to say which of your five communities is worth the next month of somebody’s attention. Our deeper walkthrough of the install referrer and what it can and cannot tell you covers the implementation detail, and our attribution guide places it against the rest of the measurement stack.

We are not printing an iOS equivalent here because we could not open a current Apple page documenting one, and an attribution mechanism quoted from memory is exactly the kind of claim that wastes an engineering sprint. Verify the current iOS path in your own console before you plan around it.

When you need volume on a deadline, when no community exists for your category, or when nobody on the team can commit months of genuine presence. Community distribution is cheap in money and expensive in attention, and teams choose it for the first property while ignoring the second.

The honest test is a staffing question rather than a marketing one. If your plan requires a named person to spend real hours in five communities every week for a quarter, and you cannot name that person, the plan is not funded. It will decay into exactly the broadcast pattern the rules above prohibit, because broadcasting is what an unfunded community plan turns into.

• Deadline-driven launches. A community you have not built cannot be conjured in the fortnight before a launch. Paid acquisition can be turned on in a day; this cannot.
• Categories with no natural gathering place. Some products have passionate forums. A utility app frequently has none, and the answer is search demand rather than community.
• Anything requiring predictable weekly volume. Community output is lumpy by nature. It will not hit a number every week, and holding it to one produces the spam behaviour.

Where it does fit, it fits unusually well: early validation, high-intent niches, and any product where the first users need to trust you personally before they will trust the app. Those users tend to be your best retention cohort, which is worth more than the install count suggests. Our note on reaching the first 10,000 installs sets out how that stacks against the paid channels.

Run it alongside a channel that does produce predictable volume, rather than instead of one. That is the structure we generally recommend in our user acquisition work, and if you want a second opinion on whether your category has a community worth the quarter, tell us what the product is and we will tell you honestly if it does not.