Отслеживание кликов по ссылкам в Salesforce: клики в записи Contact

Salesforce записывает клик, только когда ссылку отправил сам Salesforce. Account Engagement переписывает URL в своих же письмах и приписывает клик prospect, а custom redirects распространяют это на ссылки, которые вы вставляете где угодно ещё. Это вся нативная история целиком.

Всё остальное, что отправляет ваша компания, не даёт клика в CRM. Follow-up менеджера из личного почтового ящика, SMS-цепочка, QR-код на стенде конференции, платная реклама, партнёрская рассылка - всё это невидимо. Чтобы закрыть этот разрыв, нужна отслеживаемая ссылка, которой владеете вы сами, и webhook, который пишет в Salesforce, а интересные решения касаются того, что писать, а не как отправлять. Для той же задачи в другой CRM клики по ссылкам в таймлайне контакта HubSpot разбирает форму интеграции.

Что покрывают нативные инструменты

Два механизма, и оба ограничены сообщениями, которые отправил сам Salesforce.

Отслеживание кликов по ссылкам в письмах Account Engagement переписывает каждую ссылку через поддомен-трекер, поэтому клик записывается на того prospect, кому отправили письмо. Работает хорошо, но только там.

Custom redirects идут на шаг дальше: вы создаёте отслеживаемый URL и используете его в баннере, посте в соцсети или документе, и клики появляются как активность prospect. Есть два ограничения, которые определяют полезность этого механизма. Повторные клики одного и того же prospect дросселируются в течение окна, поэтому счётчик сознательно не отражает сырое количество. А привязка к конкретному prospect зависит от того, идентифицирован ли посетитель уже, что для холодного трафика означает: клик записывается без привязки к человеку.

У Marketing Cloud своя модель отслеживаемых ссылок с тем же принципом: она измеряет то, что отправила сама.

Ничего из этого не критика. Это просто область охвата, и понимание этой области точно подсказывает, для чего нужен третий путь.

Разрыв и как его закрыть

Схема короткая. Ваш сервис коротких ссылок отправляет webhook на каждый клик. Эндпоинт принимает его, проверяет и превращает в запись.

Три решения по реализации определяют, будет ли это работой на выходные или повторяющимся инцидентом.

Публикуйте Platform Event вместо прямой записи. Platform Event отделяет приём данных от решения о том, что означает клик. Интеграция публикует Link_Click__e; подписчики сами решают, обновить ли Campaign Member, создать задачу или вообще ничего не делать для этой кампании. Когда маркетинг меняет мнение о том, что должен запускать клик, вы правите Flow, а не потребителя webhook.

Проверяйте подпись, прежде чем доверять payload. Эндпоинт по определению публичный. Сверяйте HMAC с общим секретом, отклоняйте при несовпадении и никогда не берите идентификатор Contact из тела запроса без проверки против чего-то, что вы сами выдали.

Дедуплицируйте по идентификатору клика. Доставка webhook повторяется после таймаута, а значит один и тот же клик может прийти дважды. Сохраняйте идентификатор и делайте запись идемпотентной; альтернатива - Contact с четырьмя одинаковыми записями о клике от одного касания. Лимиты запросов и идемпотентность в API ссылок разбирает ту же дисциплину на исходящей стороне.

Честно сопоставляем клик с человеком

Именно здесь интеграции незаметно лгут, поэтому стоит сказать прямо.

Клик несёт ровно то, что несла ссылка. Если вы сгенерировали отдельную короткую ссылку на каждого получателя, payload идентифицирует получателя, и вы можете уверенно писать в его запись. Если одну и ту же ссылку получили четыреста человек, у вас четыреста кликов без имён, и никакой хитрый join их не восстановит.

Поэтому решайте по сценарию использования. Исходящие цепочки и персональные follow-up оправдывают ссылку на каждого получателя, сгенерированную через API в момент постановки сообщения в очередь. Широкие кампании этого не оправдывают, и честный результат здесь - счётчики на уровне кампании: клики по кампании, по каналу, по ссылке, привязанные к объекту Campaign, а не к отдельным людям. URL-сокращатели для B2B-команд продаж разбирает, где версия "ссылка на получателя" себя окупает.

Единственное, чего точно не стоит делать - вычислять личность по IP-адресу или совпадению по времени. Это ошибается достаточно часто, чтобы испортить отчёт по воронке, а в Европе это ещё и решение об обработке данных, которое лучше не защищать перед регулятором.

Настраиваете это прямо сейчас? Webhooks Elido подписывают каждую доставку и повторяют попытки с задержкой (backoff), а справочник по webhook в документации перечисляет поля payload клика, которые вам предстоит маппить.

Что писать и куда

Четыре варианта, в порядке возрастания того, насколько тщательно нужно думать.

• Кастомный объект клика. Click__c с lookup на Contact и Campaign, плюс ссылка, параметры кампании, страна, устройство и временная метка. Это долговечный выбор: отчётность остаётся быстрой, а лента активности - читаемой.
• Статус Campaign Member. Перевод участника из Sent в Responded при первом клике - самая полезная автоматизация здесь, потому что она подпитывает каждый отчёт по кампании, который у вас уже есть.
• Задача (task), но экономно. Полезна для ценных ссылок, где менеджер должен увидеть касание в своей ленте. Ужасна как вариант по умолчанию, потому что несколько тысяч задач в неделю хоронят всё остальное.
• Свёрнутое (rollup) поле на Contact. Дата последнего клика и текущий счётчик дёшевы в поддержке и отвечают на большинство вопросов менеджера без открытия связанного списка.

Маппьте параметры кампании в поля, а не разбирайте их потом. utm_campaign в записи о клике - это то, что позволяет отчёту sales ops группировать по кампании, ничего не джойня.

Объём - это ограничение, которое никто не планирует

Клики приходят пачками. Рассылка на пятьдесят тысяч человек даёт тысячи кликов за первые десять минут, а наивная интеграция превращает каждый в вызов API.

У организаций Salesforce есть дневные квоты API, и у публикации Platform Event свои лимиты. Арифметику стоит проделать до запуска, а не во время него: пиковое число кликов в минуту против вашей квоты, и ответ обычно один - запись на каждый клик просто не помещается.

Три способа выйти из положения, в порядке предпочтения. Публикуйте только пороговые события, чтобы CRM узнавала о третьем клике, а не о каждом. Агрегируйте данные на своей стороне и пишите почасовые сводки для отчётности на уровне кампании. Или группируйте запросы, ненадолго удерживая события и вставляя их пакетом. Webhooks против polling для отслеживания кликов разбирает этот компромисс, когда объём аргументирует в пользу совсем другого направления.

Я видел, как это ломалось ровно один раз - в 9 утра в день запуска, и починка под давлением всегда грубее, чем починка, спроектированная заранее.

Тестируем, прежде чем доверять

Пять проверок. Отправьте подписанный тестовый клик и убедитесь, что он становится записью с привязанной кампанией. Отправьте один и тот же клик дважды и убедитесь, что запись одна. Отправьте клик для неизвестного Contact и убедитесь, что он попадает как неатрибутированная строка, а не вызывает ошибку. Повторите payload с неверной подписью и убедитесь, что получаете отказ. Затем проведите реальную кампанию с небольшим объёмом и сверьте счётчик сервиса коротких ссылок со счётчиком записей за то же окно; расхождение в несколько процентов - это оседающие повторные доставки, расхождение в тридцать процентов - это баг.

Читайте серию опорных статей

Этот пост входит в кластер интеграций. URL-сокращатели для маркетологов - опорная статья по стороне отчётности, а webhooks для событий по ссылкам подробно разбирает форму payload.

Похожие материалы в блоге

• Клики по ссылкам в таймлайне контакта HubSpot
• События сделок Pipedrive из кликов по ссылкам
• Webhooks против polling для отслеживания кликов
• URL-сокращатели для B2B-команд продаж
• Лимиты запросов и идемпотентность в API ссылок