[{"data":1,"prerenderedAt":698},["ShallowReactive",2],{"blog-\u002Fblog\u002Fbitrix24-yandeks-metrika-oplachennye-sdelki":3},{"id":4,"title":5,"body":6,"category":686,"date":687,"description":688,"extension":689,"meta":690,"navigation":691,"path":692,"readingTime":693,"seo":694,"seoTitle":695,"stem":696,"__hash__":697},"blog\u002Fblog\u002Fbitrix24-yandeks-metrika-oplachennye-sdelki.md","Битрикс24 и Яндекс Метрика: как связать рекламу с оплаченными сделками",{"type":7,"value":8,"toc":665},"minimark",[9,13,16,19,24,27,30,108,123,130,134,137,164,179,195,198,201,205,220,223,226,253,261,264,268,271,383,410,413,417,420,423,444,457,474,481,485,491,502,512,515,519,522,534,537,557,560,567,570,574,579,582,586,589,593,596,600,603,607,610,614,617,624,628,631],[10,11,12],"p",{},"Реклама принесла сто заявок. В Битрикс24 менеджеры закрыли двадцать сделок, но деньги поступили только по двенадцати. Если смотреть лишь на отправки формы, все сто обращений выглядят результатом. Если передавать в аналитику успешную стадию, результатом станут двадцать сделок. Для оценки рекламы по оплатам нужны двенадцать подтверждённых продаж и их суммы.",[10,14,15],{},"Связка Битрикс24 с Яндекс Метрикой помогает проследить этот путь. Однако сама передача данных ещё не гарантирует правильный отчёт. Сначала нужно договориться, что считается оплатой, сохранить связь обращения с посетителем сайта и определить, как обновлять одну сделку без новых продаж при каждом изменении карточки.",[10,17,18],{},"Разберём это на учебном примере поставщика оборудования. Цифры и компания вымышлены; схема подходит и для услуг с оплатой после переговоров.",[20,21,23],"h2",{"id":22},"сначала-определите-какой-результат-считать-конверсией","Сначала определите, какой результат считать конверсией",[10,25,26],{},"У поставщика есть четыре разных события: заявка, подтверждённая потребность, согласованный заказ и полная оплата. Каждое полезно для своего вопроса. Заявки показывают входящий спрос, квалификация помогает оценить качество обращений, оплата связывает рекламу с деньгами.",[10,28,29],{},"Для начала составьте короткий словарь:",[31,32,33,49],"table",{},[34,35,36],"thead",{},[37,38,39,43,46],"tr",{},[40,41,42],"th",{},"Событие",[40,44,45],{},"Когда считаем состоявшимся",[40,47,48],{},"Что проверяем",[50,51,52,64,75,86,97],"tbody",{},[37,53,54,58,61],{},[55,56,57],"td",{},"Заявка",[55,59,60],{},"Создано обращение с контактными данными",[55,62,63],{},"Это реальный запрос, а не тест или спам",[37,65,66,69,72],{},[55,67,68],{},"Квалифицированный лид",[55,70,71],{},"Подтверждены потребность и возможность поставки",[55,73,74],{},"Менеджер заполнил согласованные признаки",[37,76,77,80,83],{},[55,78,79],{},"Первая оплата",[55,81,82],{},"Подтверждено первое поступление",[55,84,85],{},"Есть платёж, сумма и дата",[37,87,88,91,94],{},[55,89,90],{},"Полная оплата",[55,92,93],{},"Получена вся согласованная сумма",[55,95,96],{},"Учтены изменение заказа и частичные платежи",[37,98,99,102,105],{},[55,100,101],{},"Возврат",[55,103,104],{},"Деньги возвращены покупателю",[55,106,107],{},"Есть сумма и дата возврата",[10,109,110,114,115,122],{},[111,112,113],"strong",{},"Успешная стадия сделки и оплата должны проверяться отдельно."," Менеджер может закрывать сделку после подписания договора, а покупатель платить позднее. В Битрикс24 статус оплаты заказа отображается отдельно в таймлайне и канбане. Его нельзя подменять фактом просмотра страницы оплаты. ",[116,117,121],"a",{"href":118,"rel":119},"https:\u002F\u002Fhelpdesk.bitrix24.ru\u002Fopen\u002F18291172\u002F",[120],"nofollow","Как Битрикс24 показывает оплату",".",[10,124,125,126,122],{},"Источником подтверждения выберите платёжную систему, учётную систему или проверяемое поле CRM, которое заполняется по установленному правилу. Назначьте ответственного за расхождения. Логика стадий разбирается в статье про ",[116,127,129],{"href":128},"\u002Fblog\u002Fvoronki-prodazh-v-bitrix24","воронки продаж в Битрикс24",[20,131,133],{"id":132},"два-способа-передачи-событие-или-заказ-из-crm","Два способа передачи: событие или заказ из CRM",[10,135,136],{},"В документации Метрики есть разные механизмы. Их поля и поведение нельзя объединить в один условный «файл конверсий».",[10,138,139,142,143,147,148,147,151,154,155,158,159,122],{},[111,140,141],{},"Офлайн-конверсии"," передают отдельное достижение цели: например, подтверждённую оплату. В таком файле указывают идентификатор посетителя или покупки, цель и фактическое время события; дополнительно можно передать ценность и валюту. Поддерживаются ",[144,145,146],"code",{},"ClientID",", ",[144,149,150],{},"UserID",[144,152,153],{},"yclid"," и ",[144,156,157],{},"PurchaseId",". Это механизм дополнения визита событием, а не карточка заказа с изменяемыми стадиями. ",[116,160,163],{"href":161,"rel":162},"https:\u002F\u002Fyandex.ru\u002Fdev\u002Fmetrika\u002Fru\u002Fmanagement\u002Foffline-conv",[120],"Передача офлайн-конверсий",[10,165,166,169,170,173,174,122],{},[111,167,168],{},"Данные о клиентах и заказах из CRM"," описывают заказ с его постоянным номером, датой создания, статусом и денежными показателями. В Метрике появляются данные для анализа заказов и их оплаты. Для простого обмена есть упрощённый формат ",[144,171,172],{},"simple_orders","; для товаров и дополнительных атрибутов предусмотрена подробная передача. ",[116,175,178],{"href":176,"rel":177},"https:\u002F\u002Fyandex.ru\u002Fdev\u002Fmetrika\u002Fru\u002Fdata-import\u002Fcontacts",[120],"Возможности CRM-загрузки",[10,180,181,182,185,186,189,190,122],{},"Для стандартного сценария сначала проверьте ",[111,183,184],{},"официальное подключение Метрики к Битрикс24",". Его настраивают через раздел интеграций Метрики и приложение в Маркете Битрикс24. Затем сопоставляют статусы CRM с типами статусов Метрики. По текущей документации приложение доступно только для доменной зоны ",[144,187,188],{},"ru",", а дальнейшая передача данных выполняется каждый час. ",[116,191,194],{"href":192,"rel":193},"https:\u002F\u002Fyandex.ru\u002Fsupport\u002Fmetrica\u002Fru\u002Fcrm\u002Fbitrix",[120],"Инструкция штатного подключения",[10,196,197],{},"Этот путь подходит, когда согласованные стадии CRM действительно выражают нужный результат. Если подтверждение оплаты хранится отдельно, сначала нужно связать его с данными CRM. Когда сопоставления стадий недостаточно для частичных оплат или нескольких заказов внутри сделки, рассмотрите отдельный обмен с проверяемыми правилами. Не отправляйте одни продажи параллельно несколькими способами без схемы устранения дублей.",[10,199,200],{},"Далее разбираем упрощённую CRM-загрузку как учебную модель такого обмена. Она показывает, какие данные и проверки нужны; писать собственный API для каждой компании не требуется. Одна сделка Битрикс24 соответствует одному заказу Метрики. Если бизнес делит сделку на несколько самостоятельных заказов, это соответствие нужно изменить до запуска.",[20,202,204],{"id":203},"как-связать-обращение-с-визитом","Как связать обращение с визитом",[10,206,207,208,210,211,214,215,122],{},"Связь лучше сохранять в момент заявки, пока посетитель находится на сайте. Для выбранного CRM-формата используем ",[111,209,146],{},": идентификатор посетителя, который выдаёт Метрика. Его получают методом ",[144,212,213],{},"getClientID",", передают вместе с формой и сохраняют в CRM. Для звонков нужно проверить, передаёт ли его система коллтрекинга. ",[116,216,219],{"href":217,"rel":218},"https:\u002F\u002Fyandex.ru\u002Fdev\u002Fmetrika\u002Fru\u002Fdata-import\u002Fsimple-orders-prep",[120],"Подготовка CRM-данных",[10,221,222],{},"При превращении лида в сделку идентификатор должен дойти до сделки. При создании повторного заказа нельзя без проверки копировать последнюю рекламную метку из контакта: она может относиться к другому обращению. Храните исходные данные конкретной заявки и время их получения.",[10,224,225],{},"Соседние идентификаторы решают другие задачи:",[227,228,229,239,247],"ul",{},[230,231,232,234,235,238],"li",{},[111,233,150],{}," задаёт владелец сайта, например для личного кабинета. Для офлайн-конверсий его предварительно связывают с посетителем вызовом ",[144,236,237],{},"setUserID"," на сайте. Номер контакта Битрикс24 сам по себе такой связи не создаёт.",[230,240,241,243,244,246],{},[111,242,153],{}," обозначает клик по объявлению Яндекс Директа. Он подходит для поддерживающего его механизма офлайн-конверсий. Подставить его вместо ClientID в ",[144,245,172],{}," нельзя.",[230,248,249,252],{},[111,250,251],{},"UTM-метки"," описывают источник, кампанию и другие параметры перехода. Они нужны в CRM для разбора рекламы, но не идентифицируют посетителя: одна ссылка используется множеством людей.",[10,254,255,256,122],{},"Яндекс отдельно перечисляет поддержку идентификаторов: UserID и yclid доступны для офлайн-конверсий и звонков, а CRM-заказы связываются по ClientID, телефонам и почте, включая предусмотренные форматом хеши. ",[116,257,260],{"href":258,"rel":259},"https:\u002F\u002Fyandex.ru\u002Fsupport\u002Fmetrica\u002Fru\u002Fdata\u002Foffline-params",[120],"Идентификаторы офлайн-данных",[10,262,263],{},"Для нашего сценария достаточно ClientID. Не добавляйте в выгрузку весь контакт, комментарии менеджера и переписку. Если выбран другой способ сопоставления, передавайте только необходимые данные и соблюдайте его формат. Хеширование не заменяет правила работы с персональными данными. Токены Метрики и доступ к Битрикс24 должны храниться на сервере; в коде формы им места нет.",[20,265,267],{"id":266},"какие-данные-понадобятся-пример-одной-сделки","Какие данные понадобятся: пример одной сделки",[10,269,270],{},"Покупатель пришёл по рекламе 5 октября, оставил заявку на насос и получил предложение на 120 000 ₽. Через неделю внёс аванс, а 25 октября доплатил остаток. В CRM всё это время существует сделка № 8401.",[31,272,273,286],{},[34,274,275],{},[37,276,277,280,283],{},[40,278,279],{},"Данные",[40,281,282],{},"Учебное значение",[40,284,285],{},"Зачем нужны",[50,287,288,301,314,324,335,348,359,372],{},[37,289,290,293,298],{},[55,291,292],{},"Постоянный ID заказа",[55,294,295],{},[144,296,297],{},"b24_main_deal_8401",[55,299,300],{},"Обновлять тот же заказ; префикс различает источники",[37,302,303,306,311],{},[55,304,305],{},"Дата создания",[55,307,308],{},[144,309,310],{},"2026-10-05 10:20:00",[55,312,313],{},"Сохранить исходное время заказа в часовом поясе счётчика",[37,315,316,318,321],{},[55,317,146],{},[55,319,320],{},"Сохранённое значение из заявки",[55,322,323],{},"Найти посетителя; хранить без округления",[37,325,326,329,332],{},[55,327,328],{},"Статус",[55,330,331],{},"Сначала в работе, затем оплачен",[55,333,334],{},"Разделить заказ в работе и полностью оплаченный",[37,336,337,340,345],{},[55,338,339],{},"Выручка",[55,341,342],{},[144,343,344],{},"120000",[55,346,347],{},"Передать согласованную стоимость заказа",[37,349,350,353,356],{},[55,351,352],{},"Себестоимость",[55,354,355],{},"Только подтверждённая сумма, если учитывается",[55,357,358],{},"Рассчитать разницу выручки и себестоимости",[37,360,361,364,369],{},[55,362,363],{},"Валюта",[55,365,366],{},[144,367,368],{},"RUB",[55,370,371],{},"Правильно интерпретировать денежные значения",[37,373,374,377,380],{},[55,375,376],{},"Платежи и возвраты",[55,378,379],{},"Реестр в CRM или учётной системе",[55,381,382],{},"Проверять правило оплаты; это не отдельные строки этого заказа",[10,384,385,386,388,389,392,393,396,397,400,401,404,405,122],{},"В ",[144,387,172],{}," статус нужно передавать явно: если его пропустить, заказ считается оплаченным. Поле ",[144,390,391],{},"id"," позволяет обновлять заказ, а исходную дату создания после загрузки менять нельзя. Денежные поля также имеют точный смысл: ",[144,394,395],{},"revenue"," является выручкой; при переданной себестоимости ",[144,398,399],{},"cost"," доход целей рассчитывается как ",[144,402,403],{},"revenue − cost",". Не сравнивайте его с выручкой без поправки на эту разницу. ",[116,406,409],{"href":407,"rel":408},"https:\u002F\u002Fyandex.ru\u002Fdev\u002Fmetrika\u002Fru\u002Fdata-import\u002Fsimple-orders-data",[120],"Формат упрощённых CRM-данных",[10,411,412],{},"В этом примере 120 000 ₽ в карточке ещё не означают поступившие 120 000 ₽. До полной оплаты статус остаётся «в работе». Для отчёта по поступлениям нужен отдельный реестр платежей; сумма заказа его не заменяет.",[20,414,416],{"id":415},"повторные-изменения-одна-сделка-остаётся-одним-заказом","Повторные изменения: одна сделка остаётся одним заказом",[10,418,419],{},"После заявки менеджер меняет ответственного, уточняет комплектацию и исправляет телефон. Эти изменения не должны создавать новые продажи. Обмену нужен постоянный ID и журнал: какую версию заказа подготовили, куда отправили, какой ответ получили и что требуется повторить.",[10,421,422],{},"Рабочая последовательность выглядит так:",[424,425,426,432,435,438,441],"ol",{},[230,427,428,429,122],{},"При создании заказа отправить его с явным статусом ",[144,430,431],{},"IN_PROGRESS",[230,433,434],{},"При изменении значимых данных перечитать актуальную карточку и подтверждение оплаты.",[230,436,437],{},"Подготовить обновление с тем же ID и прежней датой создания.",[230,439,440],{},"Отправить его в выбранном режиме обновления, затем проверить обработку и привязку.",[230,442,443],{},"При сбое повторить подготовленную версию без нового ID и выдуманной даты события.",[10,445,446,447,147,452,122],{},"Для обмена полными снимками заказа предусмотрен режим полной замены данных записи. Учтите его поведение: ранее переданные поля обновляемой записи заменяются новым набором, а пропущенные значения могут очищаться. Есть также режимы обновления переданных полей и добавления информации. Режим нужно выбрать под состав выгрузки; одинаковые ID несколькими строками в одном файле создают неопределённый порядок применения. ",[116,448,451],{"href":449,"rel":450},"https:\u002F\u002Fyandex.ru\u002Fdev\u002Fmetrika\u002Fru\u002Fdata-import\u002Fmodes",[120],"Режимы CRM-загрузки",[116,453,456],{"href":454,"rel":455},"https:\u002F\u002Fyandex.ru\u002Fdev\u002Fmetrika\u002Fru\u002Fmanagement\u002Fopenapi\u002Fschema\u002FuploadSimpleOrders",[120],"параметры simple_orders",[10,458,459,460,463,464,469,470,122],{},"Разработчик может получать изменения через события Битрикс24 и проверять карточки по расписанию. В актуальном API сделки читаются и изменяются универсальными методами ",[144,461,462],{},"crm.item.*","; документы оплаты имеют отдельную группу методов. Технический способ зависит от того, где компания учитывает реальные поступления. ",[116,465,468],{"href":466,"rel":467},"https:\u002F\u002Fapidocs.bitrix24.ru\u002Fapi-reference\u002Fcrm\u002Fdeals\u002F",[120],"Обзор методов сделок Битрикс24",". Основные принципы доступа описаны в материале про ",[116,471,473],{"href":472},"\u002Fblog\u002Frest-api-bitrix24-vebhuki","REST API и вебхуки",[10,475,476,477,480],{},"При передаче отдельных офлайн-конверсий нужен свой журнал событий: например, «первая оплата сделки 8401». Повторное уведомление об одном платеже не должно создавать новую отправку. Не переносите сюда логику обновления CRM-заказа: изменение ",[144,478,479],{},"DateTime"," при повторе не является исправлением прежнего события.",[20,482,484],{"id":483},"авансы-возвраты-и-длинный-цикл-продаж","Авансы, возвраты и длинный цикл продаж",[10,486,487,490],{},[111,488,489],{},"Частичная оплата."," Если бизнес считает конверсией полную оплату, аванс не переводит заказ в статус оплаченного. Для первого поступления можно согласовать отдельную цель. Тогда в отчёте должны различаться количество оплаченных заказов, число платежей и общая сумма поступлений.",[10,492,493,496,497,122],{},[111,494,495],{},"Возврат."," Зафиксируйте его в своей системе и проверьте, какие изменения поддерживает выбранная интеграция. Возврат денег не равнозначен отмене ещё не оплаченного заказа. Простая смена статуса не гарантирует удаления прошлой конверсии: Яндекс предупреждает, что уже переданные цели CRM-заказа остаются в визитах. Поэтому чистые поступления после возвратов нужно сверять с платёжным реестром. ",[116,498,501],{"href":499,"rel":500},"https:\u002F\u002Fyandex.ru\u002Fsupport\u002Fmetrica\u002Fru\u002Fcrm\u002Fabout",[120],"Ограничения удаления CRM-данных",[10,503,504,507,508,122],{},[111,505,506],{},"Долгие переговоры."," Для первоначального дополнения визитов офлайн-данными действует период 21 день. Для CRM-заказа, который уже привязан к визиту, предусмотрено изменение данных в пределах 111 дней с начала этого визита. Это отдельное правило CRM-заказов, которое нельзя распространять на произвольные офлайн-цели. ",[116,509,511],{"href":258,"rel":510},[120],"Периоды дополнения визитов",[10,513,514],{},"Именно поэтому заказ отправляют ещё в работе. Если впервые выгрузить его после трёх месяцев переговоров, наличие ClientID не гарантирует привязки к давнему посещению. За пределами доступного периода храните историю в CRM и используйте собственный отчёт, указывая границы данных Метрики.",[20,516,518],{"id":517},"как-проверить-результат-и-оценивать-рекламу","Как проверить результат и оценивать рекламу",[10,520,521],{},"Начните с небольшой проверочной группы, которая проходит весь путь. Для экспериментов используйте отдельный счётчик: ошибочно загруженные цели могут сохраниться. Включите обычную оплату, аванс с доплатой, отмену, возврат, повторное уведомление и заявку без ClientID.",[10,523,524,525,528,529,122],{},"Проверяйте три разных результата: ",[111,526,527],{},"данные приняты, заказ привязан, суммы интерпретированы верно",". Успешный ответ на загрузку подтверждает лишь часть пути. Метрика указывает срок появления загруженных данных в отчётах до трёх часов. ",[116,530,533],{"href":531,"rel":532},"https:\u002F\u002Fyandex.ru\u002Fsupport\u002Fmetrica\u002Fru\u002Fdata\u002Foffline-conversion-data",[120],"Обработка офлайн-данных",[10,535,536],{},"Критерии приёмки можно записать заранее:",[227,538,539,542,545,548,551,554],{},[230,540,541],{},"десять разных ID дают десять заказов; повтор той же выгрузки не увеличивает число;",[230,543,544],{},"изменение ответственного не создаёт оплату;",[230,546,547],{},"аванс не достигает цель полной оплаты, а доплата меняет тот же заказ;",[230,549,550],{},"суммы, валюты и статусы совпадают с выбранными карточками CRM;",[230,552,553],{},"непривязанные заказы выделены отдельно и имеют понятную причину;",[230,555,556],{},"возврат отражён в контрольном отчёте, а сохранённые достижения целей учтены при его чтении.",[10,558,559],{},"В рабочем отчёте сопоставляйте расходы, качественные обращения, оплаченные заказы и выручку по одинаковым правилам. Не делите расходы октября на все оплаты октября, если значимая часть денег относится к сентябрьским заявкам. Сравнивайте группы обращений одного периода после сопоставимого срока ожидания оплаты.",[10,561,562,563,122],{},"Показывайте долю заказов с сохранённым идентификатором и долю привязанных заказов. Иначе канал с потерянными ClientID будет выглядеть хуже канала, где сбор работает исправно. Порядок построения управленческих отчётов описан в статье ",[116,564,566],{"href":565},"\u002Fblog\u002Fotchety-i-analitika-v-bitrix24","«Отчёты и аналитика в Битрикс24»",[10,568,569],{},"Если рассчитываете окупаемость рекламы, заранее определите, какую прибыль используете и какие затраты включаете. Отношение выручки к рекламным расходам само по себе не показывает окупаемость: у оборудования есть закупочная стоимость, доставка и другие расходы.",[20,571,573],{"id":572},"частые-вопросы","Частые вопросы",[575,576,578],"h3",{"id":577},"можно-ли-обойтись-utm-метками-в-сделке","Можно ли обойтись UTM-метками в сделке?",[10,580,581],{},"Они помогут группировать обращения в CRM, но не заменят идентификатор для привязки к визиту Метрики. В выбранном здесь CRM-формате сохраняйте ClientID вместе с заявкой; UTM храните рядом как сведения об источнике.",[575,583,585],{"id":584},"достаточно-ли-отправлять-стадию-успешно-завершена","Достаточно ли отправлять стадию «Успешно завершена»?",[10,587,588],{},"Только если она по принятому и проверяемому правилу означает нужный факт оплаты. Если стадия обозначает подписанный договор, её следует анализировать как договор, а подтверждение денег получать отдельно.",[575,590,592],{"id":591},"почему-метрика-приняла-заказ-но-реклама-не-получила-конверсию","Почему Метрика приняла заказ, но реклама не получила конверсию?",[10,594,595],{},"Принятие файла не гарантирует привязки. Проверьте идентификатор, счётчик, даты и допустимый период. Отдельно смотрите статус обработки загрузки и результат сопоставления, затем проверяйте отчёт.",[575,597,599],{"id":598},"можно-ли-после-возврата-убрать-прошлую-оплату-из-всех-отчётов","Можно ли после возврата убрать прошлую оплату из всех отчётов?",[10,601,602],{},"Рассчитывать на это нельзя. Изменение состояния CRM-заказа и история достигнутых целей имеют разное поведение. До запуска проверьте возврат на тестовом заказе и согласуйте, какой отчёт показывает продажи за вычетом возвратов.",[575,604,606],{"id":605},"что-делать-если-продажа-занимает-больше-трёх-месяцев","Что делать, если продажа занимает больше трёх месяцев?",[10,608,609],{},"Передавать заказ в работе сразу после создания, отслеживать доступный период обновления и хранить полную историю у себя. Метрика дополняет анализ в пределах своих ограничений; давние сделки необходимо учитывать в отдельной сверке.",[20,611,613],{"id":612},"как-поставить-задачу-на-интеграцию","Как поставить задачу на интеграцию",[10,615,616],{},"Подготовьте несколько обезличенных сделок: обычную оплату, рассрочку, возврат и долгие переговоры. Для каждой укажите источник заявки, подтверждение денег и ожидаемый результат в отчёте. Такой набор помогает проверить будущую связку до массовой выгрузки.",[10,618,619,623],{},[116,620,622],{"href":621},"\u002Fcontacts#project-form","Опишите задачу Aventra",": какие каналы приводят обращения, где фиксируются оплаты и по каким показателям вы оцениваете рекламу. На этой основе можно определить состав данных, способ передачи и критерии проверки.",[20,625,627],{"id":626},"источники-и-документация","Источники и документация",[10,629,630],{},"Материал проверен по документации 25 октября 2026 года. Перед настройкой обмена следует повторно сверить выбранный формат и доступные возможности конкретного портала.",[227,632,633,644,654],{},[230,634,635,636,147,640,122],{},"Яндекс Метрика: ",[116,637,639],{"href":176,"rel":638},[120],"CRM-заказы и их привязка",[116,641,643],{"href":407,"rel":642},[120],"формат simple_orders",[230,645,635,646,147,650,122],{},[116,647,649],{"href":161,"rel":648},[120],"офлайн-конверсии",[116,651,653],{"href":258,"rel":652},[120],"идентификаторы и периоды дополнения визитов",[230,655,656,657,147,661,122],{},"Битрикс24: ",[116,658,660],{"href":118,"rel":659},[120],"информация об оплате",[116,662,664],{"href":466,"rel":663},[120],"обзор REST-методов сделок",{"title":666,"searchDepth":667,"depth":667,"links":668},"",3,[669,671,672,673,674,675,676,677,684,685],{"id":22,"depth":670,"text":23},2,{"id":132,"depth":670,"text":133},{"id":203,"depth":670,"text":204},{"id":266,"depth":670,"text":267},{"id":415,"depth":670,"text":416},{"id":483,"depth":670,"text":484},{"id":517,"depth":670,"text":518},{"id":572,"depth":670,"text":573,"children":678},[679,680,681,682,683],{"id":577,"depth":667,"text":578},{"id":584,"depth":667,"text":585},{"id":591,"depth":667,"text":592},{"id":598,"depth":667,"text":599},{"id":605,"depth":667,"text":606},{"id":612,"depth":670,"text":613},{"id":626,"depth":670,"text":627},"Интеграции","2026-10-25","Как передавать оплаты из Битрикс24 в Яндекс Метрику: связать сделки с визитами, выбрать конверсии, учесть повторные изменения и проверить результат без дублей.","md",{},true,"\u002Fblog\u002Fbitrix24-yandeks-metrika-oplachennye-sdelki","11 мин",{"title":5,"description":688},"Битрикс24 и Метрика: реклама и оплаченные сделки","blog\u002Fbitrix24-yandeks-metrika-oplachennye-sdelki","MLs8FkSCVbKmPrtbURegYIdXmIRTKXIgG8Ucv8Nhac0",1792925211344]