Якщо автоматизація, спричинена коментарем, повідомляє про активність status: "sent", але людина, яка залишила коментар, каже, що ніколи не отримала DM, це майже завжди пов’язано з налаштуваннями конфіденційності отримувача в Instagram — не з помилкою у вашій автоматизації чи в Ayrshare.
sent означає, що Instagram прийняв повідомлення, а не те, що воно було доставлене. Instagram не надає доставку повідомлень на жодному рівні API. Ayrshare позначає дію send_dm як sent у той момент, коли Instagram її прийме; чи справді вона дійде до отримувача, вирішують налаштування, які Ayrshare не може ані прочитати, ані змінити.
Параметр «Message requests» отримувача вирішує доставку
Кожен користувач Instagram контролює, хто може надсилати йому запит повідомлення, у розділі Settings and activity → Messages and story replies → Message requests. Опції приблизно такі: «Everyone», «Your followers» та «No one».
Коли ваша автоматизація надсилає DM тому, хто обмежив запити повідомлень, Meta приймає запит, повертає успішну відповідь з ID повідомлення, а потім тихо відкидає повідомлення. Немає ані помилки, ані webhook про невдачу, ані сигналу про доставку/прочитання — це відкидання невидиме на кожному рівні API. Meta знає, що повідомлення недоставне (його власний інтерфейс застосунку показує «This account can’t receive your message because they don’t allow new message requests from everyone»), але не надає цієї інформації в API.
Наявна розмова перекриває цей параметр
Якщо відправник і отримувач уже мають гілку повідомлень (наприклад, отримувач раніше писав акаунту в DM), ця наявна розмова перекриває параметр Message requests, і DM автоматизації доставляється в наявну гілку, а не як новий запит. Саме тому одна й та сама автоматизація може досягати одних коментаторів і не досягати інших, і чому отримувач, який пише акаунту першим, потім надійно отримуватиме DM автоматизації.
Як це розпізнати
- У рядку активності показано
status: “sent” без errorDetails. - Отримувач повідомляє про відсутність DM (і він не знаходиться в його теці message-requests).
- Це відбувається періодично серед отримувачів — одні отримують DM, інші ні — без закономірності у вашій конфігурації.
Це результат доставки, а не стан невдачі, тож він ніколи не з’явиться як failed. Рядок failed означає, що Instagram відхилив надсилання, і причина знаходиться в actionResults[].errorDetails — це інша ситуація (див. коди помилок).
Що ви можете зробити
Програмного обхідного шляху не існує — жоден API, scope чи форма надсилання не може обійти параметр Message requests отримувача. Що ви можете зробити:
- Одразу сформуйте очікування: DM, спричинений коментарем, досягає лише людей, чиї налаштування Instagram дозволяють запити повідомлень, або тих, хто вже має розмову з вашим акаунтом.
- Заохочуйте коментаторів писати DM вашому акаунту (або увімкнути запити повідомлень), якщо вони хочуть отримати подальшу відповідь — вхідне повідомлення відкриває гілку назавжди.
- Розгляньте публічну відповідь на коментар як резервний шлях для охоплення всіх.
Як надсилаються DM, спричинені коментарями (private replies)
Автоматизації, спричинені коментарями, доставляють DM через Instagram private replies, прив’язані до самого коментаря. Саме це дозволяє автоматизації надсилати повідомлення коментатору, з яким ви ніколи не листувалися. Механіку — та її обмеження — варто знати:
- 7-денне вікно, прив’язане до коментаря. Відповідь має бути надіслана протягом 7 днів з моменту коментаря. Після цього вікно закривається, і надсилання зазнає невдачі з
code: 484. - Одна відповідь на коментар, будь-коли. Instagram дозволяє лише одну private reply на коментар. Друга спроба зазнає невдачі з
code: 484 — Instagram повідомляє «already replied» через ту саму спільну помилку, яку використовує для закритого вікна, тож перевіряйте errorDetails, щоб дізнатися, яка причина. - Надходить як запит повідомлення. Навіть успішно доставлена private reply потрапляє в теку message-requests отримувача і має бути прийнята — якщо розмова вже не існує.
- Доставка все одно залежить від налаштувань отримувача. Private replies знімають вимогу «має спершу написати повідомлення», але вони не перекривають параметр Message requests отримувача, який і є обмеженням, описаним вище.
Пов’язане
