Начнем с ознакомительной части в софте.
В софте есть 2 метода для инвайта, это инвайт по username и инвайт по id пользователя.
Я пользуюсь инвайтом по username. Почему? В этом методе есть функция принудительное количество приглашенных пользователей. За что она отвечает? Она считает только успешные инвайты (Done). Все посторонние, такие как конфиденциальность пользователя, пользователь уже в группе и т.д он не засчитывает за успешный инвайт. Так как я стараюсь каждый аккаунт использовать по максимуму, мне необходима эта функция.
Добавляем базу данных, которую мы спарсили, вводим username группы куда хотим добавить участников, дальше переходим к задержкам.
1 поле означает min [ ] users max [ ] users количество участников которое будет задано аккаунту на добавление.
Например в графе min укажем 30, в графе max укажем 40, то каждый аккаунт возьмет рандомное количество участников от 30 до 40.
Так как я стараюсь, чтобы аккаунт отработал по максимум я ставлю min [48] users max [48] users либо min [49] users max [49] users.
Лимиты Telegram на добавление участников с 1 аккаунта составляют 50 человек. Почему я ставлю 49 участников? По моим неоднократным тестам я замечал, что примерно на 50 добавление участника, телеграм выдает спам на 3 суток. Если остановить на 49, то аккаунт с большей вероятностью останется свободным от ограничений.
Задержка min [ ] sec max [ ] sec. Это задержка аккаунта между добавлениями пользователя.
Это поле достаточно важно для инвайта. Если не правильно указать задержку между запросами аккаунта на добавление участника можно получить либо бан, либо спам, флудвайт или аккаунт будет гонять впустую пользователей (В софте будет успешно добавлять, а счетчик в группе стоять на одном месте). По моим тестам я использую задежку min [15] sec max [35] sec. Либо min [25] sec max [50] sec.
Примерно на 6 аккаунтов у меня выходит от 250 до 280 успешных инвайтов. (Успешные считаю по счетчику в Telegram).
Почему такой большой разброс 250-280 человек с 6 аккаунтов? Ну во первых одному Дурову и его команде известны все лимиты и защита телеграм, а по моим тестам я заметил, что хорошие прокси влияют и на количество успешных инвайтов в том числе.
Минус ротационных прокси, что кто то их тоже использует. Вы можете с одной партии 6 аккаунтов добавить 280 человек, тут же запустить новый поток в 6 аккаунтов и добавить на тех же самых настройках 250 человек, а то и меньше.
Проблема в инвайте в том, что нет 100% правильно рабочего варианта, слишком много факторов влияет на работу (прокси, сам аккаунт, гео аккаунта, задержки, группа куда добавляете, какую аудиторию добавляете и т.д.) Но в этой статье я расскажу, то что знаю, и как работаю я.
Максимальное время ожидания: На сколько я понял работает это так. Если вы указали допустим 600 секунд, если аккаунт получил FloodWait на 300 секунд, то софт остановит работу аккаунта на 300 секунд, после чего попробует снова продолжить работу, если аккаунт получит FloodWait или любое другое ограничение больше 600 секунд, то софт остановит работу с этим аккаунтом.
Ставлю всегда 600 секунд.
Выбор аккаунтов. Выбираем аккаунты которые будут работать при инвайте и добавлять новых людей. Обычно в начале работы с какой либо группой я использую 1 аккаунт для теста. Если 1 аккаунт успешно добавляет +- 40-49 человек, то я продолжаю инвайтить в нее.
Пример: У меня стоит задача в группу залить 500 человек. Я примерно понимаю, чтобы залить 500 человек мне потребуется 11-12 аккаунтов.
Тут есть 2 пути как залить 500 человек с 11-12 аккаунтов. Либо разделить в 2 партии по 6 аккаунтов, либо сразу выбрать 12 аккаунтов в работу, а уже через опцию управления потоками выбрать количество аккаунтов которые будут работать сразу (Чуть ниже объясню подробней про работу с потоками).
Принудительное количество приглашенных пользователей. Считает только успешные инвайты (Done).
Покинуть основную группу. После добавления участников аккаунт покинет группу в которую добавлял этих участников.
Защита от ботов. Насколько я понимаю эта функция защищает и не приглашает ботов в чат.
Управление потоками. Это количество одновременно работающих аккаунтов. Это после очень важное при инвайте. От количества потоков также влияет качество успешных инвайтов, и защита аккаунтов от спама, флудвайта, бана и т.д.
Обычно после 1 теста с 1 аккаунтом я запускаю в работу 6 потоков. Рекомендую использовать не больше 8 потоков.
Также использую задержку между потоков 1 - 40 секунд. Это нужно для того, чтобы сразу 6 аккаунтов не приступили к работе. А рандомно по очереди 1-40 секунд начали работать.
Так как я выше написал, что можно выбрать сразу 11-12 аккаунтов, чтобы добавить +- 500 человек, но я не хочу, чтобы сразу 11-12 аккаунтов приступило к работе, а по очереди выполнили свою работу, в количестве потоков я указываю 6. При такой настройке софт возьмет 11-12 аккаунтов, но одновременно в работу запустит только 6, после завершения одного из работающих аккаунтов он сразу запустит в работу следующий. И так проведет 11-12 аккаунтов или любое другое количество аккаунтов через 6 потоков одновременной работы.
Автоматическая остановка. В случае бана, спама на аккаунт или flood wait остановит работу софта. Обычно ставлю только на Статус Ban и Спам блок по 1.
Для безопасности аккаунтов также ставлю галочку экстренное закрытие программы.
Максимальное количество инвайтов с аккаунта - 50 человек в сутки. Обычно если аккаунт без ограничений на следующий день я использую его в работу.
Отлежка. Для ГЕО России достаточно 3+ дней отлежки для инвайта. (На данный момент после регистрации нового аккаунта вы можете получать спам в виде TempSpamBlock(GeoNumber) при отлежке 3+ дня на новом аккаунте этот спамблок снимается. При нем на 1 инвайте вы получите ограничение и не сможете добавить больше).
Не советую вообще какие либо действия проводить с аккаунтами, пока не отлежится 3+ дня.
Не забываем поставить бота который будет удалять системные сообщения в чате (пользователь пригласил пользователя в чат). А то будет куча уведомлений, пользователи начнут кидать спам, аккаунты начнут улетать в спам блок, короче возникнет много трудностей.
PeerFloodError - спамблок.
UserBannedInChannelError - вечный спамблок.
FloodWaitError - ошибка, когда слишком много запросов с аккаунта в телеграм. Она выдается рандомно Telegram от 60 секунд до 80 тысяч секунд.
UserKickedError - пользователь удален или забанен в группе.
UserPrivacyRestrictedError - пользователь закрыл свой аккаунт конфиденциальностью.
UserNotMutualContactError - невозможно добавить вышедшего участника.
UserChannelsTooMuchError - у пользователя слишком много чатов.
UserIdInvalidError - информация о пользователе недействительна.
Возможные проблемы при инвайте.
Тут я постараюсь рассказать проблемы, которые встречались мне при инвайте.
Отлежка группы.
Отлежка группы важна, но и важно правильно инвайтить в группу. По моим тестам, да и вообще сам лично себе заливал несколько групп с отлежкой 7+ дней.
Но лучше конечно купить группу с отлежкой побольше.
Сейчас с нынешними обновленями Telegram, можно убить группу с любой отлежкой. Тут скорей всего зависит от правильного инвайта, а не от отлежки.
Как убить группу?
По моим тестам и практике, я убивал разные группы, группы где были боты, группы где не было ботов, новые группы, группые с 5 000 + участниками и т.д
По тестам могу сказать следующее, без разницы сколько ботов у вас изначально в группе, для инвайта. Если в ней не будет активности, а новые пользователи при инвайте превысят порог по жалобам, то вы получите мут на группу. Как проявляется этот мут? При инвайте ваши аккаунты на 1-5 добавлениях будут получать FloodWait от телеграм. На данный момент неизвестно на сколько этот мут ложится на группу.
Пример: У вас в группе 5000 участников, из них 4500 тысячи ботов. 500 участников еле живые, активности мало, онлайн маленький. Тут вы добавляете 1000 новых пользователей, из этой тысячи какой то % пользователей подает жалобу, если лимит жалоб превысит, вы получите мут на группу.
Совет: не спешите сразу добавлять большое количество участников за раз. Лучше потихоньку, понемногу поднять активность в группе и количество живой аудитории. Так же не советую сразу добавлять только активную аудиторию (писавших в чат). Парсите всех подряд, добавляйте живых людей, ботов... Чтобы уменьшить количество жалоб на группу.
Как делаю я? От 0 до 1000 человек в день я добавляю 200-300 человек. От 1000 до 2000 тысяч 250 - 350 человек. От 2000 до 3000 350 - 450 человек. От 3000 до 5000 тысяч 500-600 человек. От 5000 до 8000 тысяч 600-800 человек. Свыше 8000 человек уже добавляю 1000+ человек в день.
Смотрите активность, смотрите онлайн, количество участников. Чем больше активности к вашим участникам, тем больше можете добавлять людей в день.
На 25000 участников я смело заливал до 3 тысяч людей за день и группа стабильно живет для инвайта. При таких лимитах я еще никогда не получал мут в группе.
Как еще можно получить мут группы? Недавно я тестил аккаунты Индии.
Решил попробовать такой метод. 50 аккаунтов в 10 потоков по 10 человек. После завершения работы, снова запускал инвайт, чтобы по максимальному отработать аккаунты.
Дня 3-4 аккаунты успешно отрабатывали, +- неплохо, в таком режиме успешные инвайты для Индии хоть как то отрабатывали. До одного момента, запустил я партию, все аккаунты которые учувствовали в работе улетели в бан, а на группу наложили мут.
Еще существуют проблемы группы.
Проблемными группами я называю те группу, где тяжелая аудитория.
Как правила после парсинга тяжелой аудиторию при инвайте у большого количества людей стоит конфиденциальность. Будете получать в консоли вот такие сообщения UserPrivacyRestrictedError частенько.
При большом количестве UserPrivacyRestrictedError аккаунт будет получать FloodWait. К примеру... 30 аккаунтов он попытался добавить, из них 17 с приватностью, 13 смог добавить и поймал FloodWait. Хотя должен был 48-49 инвайтов сделать. Не удивляйтесь сильно этому, что аккаунты уходят во флудвайт. Попробуйте найти другую группу для парсинга.
Наткнулся для себя на интересную вещь. Так как софт при инвайте не отслеживает пользователей, которые уже в группе, он их добавляет и в софте они идут, как Done.
Но по факту человек, который был в группе уже в группе софт засчитывает за Done. Обсудил это со Стриксом, сказал, что скоро будет реализовано исключение таких юзеров.
А пока что придется парсить другую группу, которая ранее не участвовала в инвайте.
В софте есть 2 метода для инвайта, это инвайт по username и инвайт по id пользователя.
Я пользуюсь инвайтом по username. Почему? В этом методе есть функция принудительное количество приглашенных пользователей. За что она отвечает? Она считает только успешные инвайты (Done). Все посторонние, такие как конфиденциальность пользователя, пользователь уже в группе и т.д он не засчитывает за успешный инвайт. Так как я стараюсь каждый аккаунт использовать по максимуму, мне необходима эта функция.
Добавляем базу данных, которую мы спарсили, вводим username группы куда хотим добавить участников, дальше переходим к задержкам.
1 поле означает min [ ] users max [ ] users количество участников которое будет задано аккаунту на добавление.
Например в графе min укажем 30, в графе max укажем 40, то каждый аккаунт возьмет рандомное количество участников от 30 до 40.
Так как я стараюсь, чтобы аккаунт отработал по максимум я ставлю min [48] users max [48] users либо min [49] users max [49] users.
Лимиты Telegram на добавление участников с 1 аккаунта составляют 50 человек. Почему я ставлю 49 участников? По моим неоднократным тестам я замечал, что примерно на 50 добавление участника, телеграм выдает спам на 3 суток. Если остановить на 49, то аккаунт с большей вероятностью останется свободным от ограничений.
Задержка min [ ] sec max [ ] sec. Это задержка аккаунта между добавлениями пользователя.
Это поле достаточно важно для инвайта. Если не правильно указать задержку между запросами аккаунта на добавление участника можно получить либо бан, либо спам, флудвайт или аккаунт будет гонять впустую пользователей (В софте будет успешно добавлять, а счетчик в группе стоять на одном месте). По моим тестам я использую задежку min [15] sec max [35] sec. Либо min [25] sec max [50] sec.
Примерно на 6 аккаунтов у меня выходит от 250 до 280 успешных инвайтов. (Успешные считаю по счетчику в Telegram).
Почему такой большой разброс 250-280 человек с 6 аккаунтов? Ну во первых одному Дурову и его команде известны все лимиты и защита телеграм, а по моим тестам я заметил, что хорошие прокси влияют и на количество успешных инвайтов в том числе.
Минус ротационных прокси, что кто то их тоже использует. Вы можете с одной партии 6 аккаунтов добавить 280 человек, тут же запустить новый поток в 6 аккаунтов и добавить на тех же самых настройках 250 человек, а то и меньше.
Проблема в инвайте в том, что нет 100% правильно рабочего варианта, слишком много факторов влияет на работу (прокси, сам аккаунт, гео аккаунта, задержки, группа куда добавляете, какую аудиторию добавляете и т.д.) Но в этой статье я расскажу, то что знаю, и как работаю я.
Максимальное время ожидания: На сколько я понял работает это так. Если вы указали допустим 600 секунд, если аккаунт получил FloodWait на 300 секунд, то софт остановит работу аккаунта на 300 секунд, после чего попробует снова продолжить работу, если аккаунт получит FloodWait или любое другое ограничение больше 600 секунд, то софт остановит работу с этим аккаунтом.
Ставлю всегда 600 секунд.
Выбор аккаунтов. Выбираем аккаунты которые будут работать при инвайте и добавлять новых людей. Обычно в начале работы с какой либо группой я использую 1 аккаунт для теста. Если 1 аккаунт успешно добавляет +- 40-49 человек, то я продолжаю инвайтить в нее.
Пример: У меня стоит задача в группу залить 500 человек. Я примерно понимаю, чтобы залить 500 человек мне потребуется 11-12 аккаунтов.
Тут есть 2 пути как залить 500 человек с 11-12 аккаунтов. Либо разделить в 2 партии по 6 аккаунтов, либо сразу выбрать 12 аккаунтов в работу, а уже через опцию управления потоками выбрать количество аккаунтов которые будут работать сразу (Чуть ниже объясню подробней про работу с потоками).
Принудительное количество приглашенных пользователей. Считает только успешные инвайты (Done).
Покинуть основную группу. После добавления участников аккаунт покинет группу в которую добавлял этих участников.
Защита от ботов. Насколько я понимаю эта функция защищает и не приглашает ботов в чат.
Управление потоками. Это количество одновременно работающих аккаунтов. Это после очень важное при инвайте. От количества потоков также влияет качество успешных инвайтов, и защита аккаунтов от спама, флудвайта, бана и т.д.
Обычно после 1 теста с 1 аккаунтом я запускаю в работу 6 потоков. Рекомендую использовать не больше 8 потоков.
Также использую задержку между потоков 1 - 40 секунд. Это нужно для того, чтобы сразу 6 аккаунтов не приступили к работе. А рандомно по очереди 1-40 секунд начали работать.
Так как я выше написал, что можно выбрать сразу 11-12 аккаунтов, чтобы добавить +- 500 человек, но я не хочу, чтобы сразу 11-12 аккаунтов приступило к работе, а по очереди выполнили свою работу, в количестве потоков я указываю 6. При такой настройке софт возьмет 11-12 аккаунтов, но одновременно в работу запустит только 6, после завершения одного из работающих аккаунтов он сразу запустит в работу следующий. И так проведет 11-12 аккаунтов или любое другое количество аккаунтов через 6 потоков одновременной работы.
Автоматическая остановка. В случае бана, спама на аккаунт или flood wait остановит работу софта. Обычно ставлю только на Статус Ban и Спам блок по 1.
Для безопасности аккаунтов также ставлю галочку экстренное закрытие программы.
Максимальное количество инвайтов с аккаунта - 50 человек в сутки. Обычно если аккаунт без ограничений на следующий день я использую его в работу.
Отлежка. Для ГЕО России достаточно 3+ дней отлежки для инвайта. (На данный момент после регистрации нового аккаунта вы можете получать спам в виде TempSpamBlock(GeoNumber) при отлежке 3+ дня на новом аккаунте этот спамблок снимается. При нем на 1 инвайте вы получите ограничение и не сможете добавить больше).
Не советую вообще какие либо действия проводить с аккаунтами, пока не отлежится 3+ дня.
Не забываем поставить бота который будет удалять системные сообщения в чате (пользователь пригласил пользователя в чат). А то будет куча уведомлений, пользователи начнут кидать спам, аккаунты начнут улетать в спам блок, короче возникнет много трудностей.
PeerFloodError - спамблок.
UserBannedInChannelError - вечный спамблок.
FloodWaitError - ошибка, когда слишком много запросов с аккаунта в телеграм. Она выдается рандомно Telegram от 60 секунд до 80 тысяч секунд.
UserKickedError - пользователь удален или забанен в группе.
UserPrivacyRestrictedError - пользователь закрыл свой аккаунт конфиденциальностью.
UserNotMutualContactError - невозможно добавить вышедшего участника.
UserChannelsTooMuchError - у пользователя слишком много чатов.
UserIdInvalidError - информация о пользователе недействительна.
Возможные проблемы при инвайте.
Тут я постараюсь рассказать проблемы, которые встречались мне при инвайте.
Отлежка группы.
Отлежка группы важна, но и важно правильно инвайтить в группу. По моим тестам, да и вообще сам лично себе заливал несколько групп с отлежкой 7+ дней.
Но лучше конечно купить группу с отлежкой побольше.
Сейчас с нынешними обновленями Telegram, можно убить группу с любой отлежкой. Тут скорей всего зависит от правильного инвайта, а не от отлежки.
Как убить группу?
По моим тестам и практике, я убивал разные группы, группы где были боты, группы где не было ботов, новые группы, группые с 5 000 + участниками и т.дПо тестам могу сказать следующее, без разницы сколько ботов у вас изначально в группе, для инвайта. Если в ней не будет активности, а новые пользователи при инвайте превысят порог по жалобам, то вы получите мут на группу. Как проявляется этот мут? При инвайте ваши аккаунты на 1-5 добавлениях будут получать FloodWait от телеграм. На данный момент неизвестно на сколько этот мут ложится на группу.
Пример: У вас в группе 5000 участников, из них 4500 тысячи ботов. 500 участников еле живые, активности мало, онлайн маленький. Тут вы добавляете 1000 новых пользователей, из этой тысячи какой то % пользователей подает жалобу, если лимит жалоб превысит, вы получите мут на группу.
Совет: не спешите сразу добавлять большое количество участников за раз. Лучше потихоньку, понемногу поднять активность в группе и количество живой аудитории. Так же не советую сразу добавлять только активную аудиторию (писавших в чат). Парсите всех подряд, добавляйте живых людей, ботов... Чтобы уменьшить количество жалоб на группу.
Как делаю я? От 0 до 1000 человек в день я добавляю 200-300 человек. От 1000 до 2000 тысяч 250 - 350 человек. От 2000 до 3000 350 - 450 человек. От 3000 до 5000 тысяч 500-600 человек. От 5000 до 8000 тысяч 600-800 человек. Свыше 8000 человек уже добавляю 1000+ человек в день.
Смотрите активность, смотрите онлайн, количество участников. Чем больше активности к вашим участникам, тем больше можете добавлять людей в день.
На 25000 участников я смело заливал до 3 тысяч людей за день и группа стабильно живет для инвайта. При таких лимитах я еще никогда не получал мут в группе.
Как еще можно получить мут группы? Недавно я тестил аккаунты Индии.
Решил попробовать такой метод. 50 аккаунтов в 10 потоков по 10 человек. После завершения работы, снова запускал инвайт, чтобы по максимальному отработать аккаунты.
Дня 3-4 аккаунты успешно отрабатывали, +- неплохо, в таком режиме успешные инвайты для Индии хоть как то отрабатывали. До одного момента, запустил я партию, все аккаунты которые учувствовали в работе улетели в бан, а на группу наложили мут.
Еще существуют проблемы группы.
Проблемными группами я называю те группу, где тяжелая аудитория.
Как правила после парсинга тяжелой аудиторию при инвайте у большого количества людей стоит конфиденциальность. Будете получать в консоли вот такие сообщения UserPrivacyRestrictedError частенько.
При большом количестве UserPrivacyRestrictedError аккаунт будет получать FloodWait. К примеру... 30 аккаунтов он попытался добавить, из них 17 с приватностью, 13 смог добавить и поймал FloodWait. Хотя должен был 48-49 инвайтов сделать. Не удивляйтесь сильно этому, что аккаунты уходят во флудвайт. Попробуйте найти другую группу для парсинга.
Наткнулся для себя на интересную вещь. Так как софт при инвайте не отслеживает пользователей, которые уже в группе, он их добавляет и в софте они идут, как Done.
Но по факту человек, который был в группе уже в группе софт засчитывает за Done. Обсудил это со Стриксом, сказал, что скоро будет реализовано исключение таких юзеров.
А пока что придется парсить другую группу, которая ранее не участвовала в инвайте.
