Сьогодні хотілося б підняти питання технічної реалізації автоворонок. І приділити більше уваги прикладу зв'язки декількох сервісів. Наприклад, CRM і вирви. У цій статті пропоную розглянути кілька рішень, втілених у життя.
Щоб не перевантажувати текст вступною інформацією, пропоную залишити її за дужкою. Якщо ви ще не знайомі з терміном і хотіли б почати вивчення теми з самого початку, то рекомендую стартувати, наприклад, з цієї посади. Також нещодавно опублікували концепт, як автоматичні вирви продажів можуть вирішувати завдання запуску продажів у нових філіях. Він ілюструє варіант застосування автоворонок у житті.
Інтеграція сервісів один з одним - типове завдання при розробці автоматичних маркетингових вирв. У ряді випадків можна обійтися без програмування: є сервіси на зразок zapier.com, який може пов'язати між собою кілька інструментів, які за замовчуванням не передбачають інтеграцію один з одним.
Наприклад, ми хочемо збирати контакти в Facebook Lead Ads і відразу передавати їх в сервіс розсилки Mailchimp, Unisender або GetResponse. Інший варіант - організація опитувань за допомогою Google Ones, збереження даних і відправка поштової скриньки в сервіс підписки.
Організація збору та обміну даними за допомогою сервісів дозволяє значно підвищити швидкість втілення нових ідей у життя. І, в буквальному сенсі слова, покращувати їх кожен день.
Коли над проектом працює команда з декількох фахівців і керівника проекту з області маркетингу, все в курсі того, що відбувається. Як тільки виявляється помилка або очевидне поліпшення, кожен може просто зайти і поправити. Без стандартного ланцюжка «поставити завдання програмісту - > призначити пріоритет - > дочекатися внесення». Це радує і розробників, які можуть зосередитися на нових завданнях, і команду, яка оперативно впливає на показники автоворонки.
Подібне рішення працює, коли необхідно створити просту зв'язку з прямою логікою «тут забери - туди збережи». Давайте тепер розглянемо приклад, коли ми реалізуємо логіку спільно з розробниками.
В одній з вирв у нас була закладена наступна логіка. Після того, як передплатник отримує матеріали, що його цікавлять, ми відправляємо йому першу персоналізовану пропозицію. Воно має діяти протягом 7 днів, а потім ставати недоступним.
CRM: Бітрікс24.
Сервіс email-розсилок: Unisender.
Перші елементи вирви
Як вирішити таке завдання, і що потрібно передбачити?
Логіка роботи скрипту для пропозиції-стартеру
Завдання ми вирішували разом з партнерами-розробниками з Manao. Окремо по кожному пункту:
1. Створення Ліда в Бітрікс24. Механізм простий - у посиланнях у листі, який надсилає Unisender, вставляємо два параметри: {Email}}} - email отримувача і {{SendDate}}} - дата надсилання листа. Повний список параметрів, які можна використовувати, знаходиться тут.
З використанням цих параметрів, при переході за посиланням ми потрапляємо на сторінку з пропозицією, де знаходиться наш скрипт. Його завдання - через API створити в Бітрікс24.
Зауважте, ми передаємо дату надсилання листа. Таким чином, якщо зацікавлена особа перейде за посиланням не відразу, а, скажімо, через 2 дні, то збережеться все правильно. І у нього залишиться всього 5 днів, як було написано в листі.
Ліди, зроблені описаним чином, створюються з певною назвою і статусом. Для того, щоб їх було легко відфільтрувати
2. Захищаємося від спаму. Наше посилання має вигляд: http://site.ru/offer1/?email=ya@ya.ru&date=01.08.2017&type=hello
Очевидно, є ризик, що зловмисник може зайнятися перебором різних Email-адрес у відповідній GET-змінній. І тоді наша CRM заповниться великою кількістю безглуздої інформації.
Варіантів захисту може бути кілька. Ми вибрали зустрічну перевірку по API Unisender. Коли користувач переходить за наведеним посиланням, ми надсилаємо зворотний запит до Unisender і перевіряємо: чи є насправді користувач серед тих, хто підтвердив бажання отримувати наші листи.
3. Фіксація дати та типу речення. Тип пропозиції і дата, коли вона була зроблена, заносяться у властивості Ліда.
У кожного Ліда автоматично записується пара властивостей: тип речення та термін його дії
Всю інформацію, що передається в Бітрікс24, далі можуть використовувати не тільки роботи, але і живі люди. Варіацій багато.
Перш ніж створювати новий скрипт здійснює пошук в Бітрікс24 Ліда з відповідним Email, звіряється з типом пропозиції і датою, коли воно було зроблено. Якщо ^ вже був створений і пройшло більше 7 днів - видаємо повідомлення «шкодуємо, ви запізнилися». І пропозиція більш не дійсно.
Якщо ж термін речення не закінчився, то скрипт відображає сторінку зі спеціальною пропозицією.
Подібне рішення можна зробити практично для будь-якої CRM з підтримкою API. І для будь-якого сервісу розсилки.
Аналогічно, «нижче» по вирві ми можемо йти від зворотного: від змін до CRM. Наприклад, за допомогою Бізнес-процесів, коли змінився статус у Ліда або Угоди, переводити користувача в інший Email-сегмент. Або запускати відповідний ланцюжок листів. А коли здійснена перша операція - переносити в іншу гілку автоматичної вирви продажів.
Ще один приклад рішення, який можна розглянути в рамках цієї статті - редагування посадкової сторінки. З описаних вище причин, зручно робити посадкові сторінки для спецпропозицій у конструкторі. Це швидко, дешево, просто і красиво. Ми любимо Tilda.
Було б дуже чудово, якщо за описаною вище логікою, при актуальності пропозиції відображати сторінку на Tilda. І тут з'являється деяка складність.
Нехай реальна адреса сторінки буде виглядати як offer1.site.ru і розташовуватися на серверах Tilda.cc. Однак нам потрібно, щоб користувачі не знали про нього. Нагадаю, спецпропозиція завжди індивідуальна, з персональним посиланням і обмеженим терміном придатності. Якщо будь-яка людина, без будь-якої вирви і персонального посилання, в будь-який момент зможе відкрити сторінку, то весь сенс пропаде.
Звідси висновок - потрібно приховувати адресу і зробити так, щоб у разі актуальності пропозиції завантажувалася сторінка з конструктора, але зберігався початковий вид адреси (http://site.ru/offer1/?email=ya@ya.ru&date=01.08.2017&type=hello). А це можливо тільки в одному випадку: коли сторінка розташована на нашому хостингу.
Для цього ми реалізували ще одну інтеграцію. Тепер з Tilda.cc. За допомогою її API ми експортуємо код сторінки до себе на сервер. Після натискання кнопки «Опублікувати» на наш скрипт відправляється Webhook і повідомляє, що сторінка тільки що була змінена. Дані від Tilda приходять в JSON-форматі. Оскільки кількість запитів до сервісу обмежена, ми кешуємо відповіді. При зміні проекту Tilda шле запит (Webhook) на наш сервер, при отриманні якого вилучаємо файли кешу. При відкритті сторінки заново кешуємо відповіді і показуємо сторінку користувачеві.
Це рішення також дуже полегшує подальшу роботу з «підкрутки» автоворонки. Якщо ми хочемо повністю замінити одну спецпропозицію на іншу або поміняти її опис - питання вирішується від декількох годин до одного дня. Ми просто вбудовуємо в автоматичну систему нову сторінку натисканням кнопки «Опублікувати».
Звичайно, автоматичні вирви в першу чергу - це маркетинг. А зазвичай, коли пишуть про маркетингові технології, найчастіше міркування зводяться до ROI, кейсів «до» і «після», порівняно з іншими каналами. Однак автоворонки - це також логіка, алгоритми і (як, сподіваюся, вдалося показати) велику кількість інтеграцій. Тому і захотілося в даній статті продемонструвати хоча б найпростіші приклади технічних реалізацій.
При цьому варто ще раз зазначити: замість розглянутих Бітрікс24 і Unisender може бути практично будь-яка CRM або сервіс розсилки. Головна умова - наявність API.
Також автоматичні маркетингові вирви - це потужний контент-маркетинг. Від контент-стратегії в автоворонках залежить дуже багато. Тому одну з наступних статей плануємо присвятити цьому питанню.
COM_SPPAGEBUILDER_NO_ITEMS_FOUND