Відстеження кліків по посиланнях у Salesforce: кліки в записі Contact

Salesforce записує клік лише тоді, коли посилання надіслав сам Salesforce. Account Engagement переписує URL у власних листах і прив'язує клік до prospect, а custom redirects поширюють це на посилання, які ви вставляєте деінде. Це вся нативна історія.

Усе інше, що надсилає ваша компанія, не створює жодного кліку в CRM. Наступний лист менеджера з продажу з власної поштової скриньки, SMS-розсилка, QR-код на стенді конференції, платна реклама, партнерська розсилка - усе це невидиме. Щоб закрити цей розрив, потрібне власне відстежуване посилання і webhook, що пише в Salesforce, а цікаві рішення стосуються того, що саме записувати, а не як надсилати. Для тієї самої проблеми в іншій CRM кліки HubSpot у таймлайні контакту розглядає форму такої інтеграції.

Що охоплюють нативні інструменти

Два механізми, і обидва обмежені повідомленнями, які надіслав сам Salesforce.

Відстеження кліків по посиланнях у листах в Account Engagement переписує кожне посилання через піддомен трекера, тому клік записується на prospect, якому надіслали лист. Це працює добре, і працює лише там.

Custom redirects йдуть на крок далі: ви генеруєте відстежуваний URL і використовуєте його в банері, публікації в соцмережі чи документі, і кліки з'являються як activity у prospect. Два обмеження визначають, наскільки це корисно. Повторні кліки того самого prospect обмежуються в межах вікна, тому лічильник свідомо не є сирим підсумком. А прив'язка до конкретного prospect залежить від того, чи вже ідентифікований відвідувач, що для холодного трафіку означає: клік записується без прив'язаної людини.

У Marketing Cloud є власна модель відстежуваних посилань з тим самим принципом: вона вимірює те, що сама надіслала.

Це не критика. Це межі охоплення, і знання цих меж точно підказує, для чого потрібен третій шлях.

Розрив і як його закрити

Схема коротка. Ваш сервіс коротких посилань надсилає webhook на кожен клік. Ендпоінт отримує його, перевіряє і перетворює на запис.

Три рішення в реалізації визначають, чи буде це роботою на вихідні, чи повторюваним інцидентом.

Публікуйте platform event замість того, щоб писати напряму. Це platform event відділяє прийом даних від рішення про те, що означає клік. Інтеграція публікує Link_Click__e; підписники самі вирішують, чи оновити campaign member, чи створити task, чи взагалі нічого не робити для цієї кампанії. Коли маркетинг змінює думку про те, що має запускати клік, ви редагуєте Flow, а не споживача webhook.

Перевіряйте підпис, перш ніж довіряти payload. Ендпоінт за визначенням публічний. Звіряйте HMAC зі спільним секретом, відхиляйте при розбіжності і ніколи не беріть ідентифікатор contact із тіла запиту без перевірки проти чогось, що видали ви самі.

Усувайте дублікати за ідентифікатором кліку. Доставка webhook повторюється після тайм-ауту, а це означає, що той самий клік може прийти двічі. Зберігайте ідентифікатор і робіть запис ідемпотентним; інакше - contact із чотирма однаковими записами кліку від одного дотику. Ліміти та ідемпотентність в API посилань розглядає ту саму дисципліну з боку вихідних запитів.

Чесне зіставлення кліку з людиною

Саме тут інтеграції часто тихо брешуть, тож варто сказати прямо.

Клік несе те саме, що ніс сам лінк. Якщо ви згенерували окреме коротке посилання для кожного отримувача, payload ідентифікує отримувача, і ви можете впевнено писати в його запис. Якщо те саме посилання отримали чотириста людей, у вас чотириста кліків без жодних імен, і жодне хитре з'єднання таблиць їх не відновить.

Тож вирішуйте окремо для кожного випадку. Вихідні послідовності і персональні follow-up виправдовують окреме посилання на отримувача, згенероване через API під час постановки повідомлення в чергу. Масові кампанії - ні, і чесним результатом тут є лічильники на рівні кампанії: кліки на кампанію, на канал, на посилання, прив'язані до об'єкта campaign, а не до конкретних людей. Скорочувачі URL для B2B-команд продажів розглядає, де варіант "посилання на кожного отримувача" себе виправдовує.

Єдине, чого не варто робити, - вгадувати особу за IP-адресою чи збігом у часі. Це помиляється достатньо часто, щоб зіпсувати звіт по воронці продажів, а в Європі це рішення про обробку даних, яке краще не доводиться захищати.

Налаштовуєте це зараз? Webhooks Elido підписують кожну доставку і повторюють спроби з backoff, а довідник webhooks у документації перелічує поля payload кліку, які вам доведеться маппити.

Що записувати і куди

Чотири цілі, у порядку зростання того, скільки роздумів вони потребують.

• Custom object для кліків. Click__c з lookup-полями на Contact і Campaign, плюс посилання, параметри кампанії, країна, пристрій і часова мітка. Це довговічний вибір: звітність залишається швидкою, а activity feed - читабельним.
• Статус campaign member. Переведення учасника зі статусу Sent у Responded при першому кліку - найкорисніша автоматизація тут, бо вона живить кожен наявний у вас звіт по кампанії.
• Task, обережно. Корисно для цінних посилань, де менеджер з продажу має побачити дотик у своїй стрічці. Жахливо як варіант за замовчуванням, бо кілька тисяч task на тиждень ховають усе інше.
• Rollup-поле на contact. Дата останнього кліку і поточний лічильник дешеві в підтримці і відповідають на більшість питань менеджера з продажу без відкриття пов'язаного списку.

Маппіть параметри кампанії в поля одразу, а не парсіть їх пізніше. Саме utm_campaign у записі кліку дозволяє звіту sales ops групувати за кампанією без жодних з'єднань таблиць.

Обсяг - обмеження, яке ніхто не планує

Кліки приходять сплесками. Розсилка на п'ятдесят тисяч людей створює тисячі кліків за перші десять хвилин, і наївна інтеграція перетворює кожен на виклик API.

Org у Salesforce мають денні квоти API, а публікація platform event має власні ліміти. Цю арифметику варто зробити до запуску, а не під час нього: пікові кліки на хвилину проти вашої квоти, і відповідь зазвичай одна - запис на кожен клік просто не влазить.

Три виходи, у порядку переваги. Публікуйте лише порогові події, щоб CRM дізнавалась, наприклад, про третій клік, а не про кожен. Агрегуйте на своєму боці і записуйте погодинні підсумки для звітності на рівні кампанії. Або групуйте: тримайте події короткий час і вставляйте масово. Webhooks проти polling для відстеження кліків розглядає компроміс, коли обсяг взагалі підказує протилежний напрямок.

Я бачив, як це ламалося рівно один раз, о 9 ранку в день запуску, і виправлення під тиском завжди грубіше за те, що продумане заздалегідь.

Тестування перед тим, як довіритись

П'ять перевірок. Надішліть підписаний тестовий клік і переконайтесь, що він стає записом з прив'язаною кампанією. Надішліть той самий клік двічі і переконайтесь, що вийшов один запис. Надішліть клік для невідомого contact і переконайтесь, що він потрапляє як рядок без атрибуції, а не викликає помилку. Повторно надішліть payload з неправильним підписом і переконайтесь у відхиленні. Потім запустіть реальну кампанію з невеликим обсягом і звірте лічильник сервісу коротких посилань з кількістю записів за те саме вікно; розбіжність у кілька відсотків - це усталення повторних доставок, розбіжність у тридцять відсотків - це баг.

Читайте базову серію статей

Ця стаття входить до кластеру інтеграцій. Скорочувачі URL для маркетологів - базова стаття для сторони звітності, а webhooks для подій посилань детально розглядає форми payload.

Схожі статті в блозі

• Кліки HubSpot у таймлайні контакту
• Події угод Pipedrive з кліків по посиланнях
• Webhooks проти polling для відстеження кліків
• Скорочувачі URL для B2B-команд продажів
• Ліміти та ідемпотентність в API посилань