Перейти к содержимому

TopoMetrika · документация SDK

Как SDK собирает события и состояния

Клики, submit, канонический скелет, коды полей и двухфазная доставка без передачи введённых значений.

Обновлено

Когда это нужно: вы хотите понять, что именно появляется в отчёте и почему число кликов не равно числу намерений. Результат: вы отличаете взаимодействие, состояние поля и наблюдаемое продолжение от подтверждённого бизнес-результата.

Пример на языке продукта

Посетитель нажал «Оформить заказ», а выбор доставки остался пустым. TopoMetrika может сохранить факт допустимого действия и код пустого состояния, не само значение поля. После накопления подходящих наблюдений команда может увидеть группу таких взаимодействий и проверить её связь с фичей оформления заказа.

Для продакта следующий шаг — спросить, ожидаемо ли пустое поле в этом сценарии, и запросить проверку у коллеги. Это ещё не доказательство дефекта: поле могло быть необязательным, а реальный заказ мог завершиться иначе. Разработчику разделы ниже объясняют, как этот контекст попадает в наблюдение.

SDK наблюдает поддерживаемые кнопки, ссылки и формы в отрисованном DOM. Он не превращает каждый клик в доказанную покупку и не знает бизнес-смысл операции без проверки команды.

Как взаимодействие получает действие

После click или submit SDK ищет разрешённое действие в ближайшем временном окне 250 мс: same-origin fetch/XHR, изменение адреса через History API либо переход ссылки. Для формы учитываются метод и action. Отправка формы не записывается второй раз как отдельный клик её submit-кнопки.

Запросы на другой origin автоматическая корреляция игнорирует. Метод и путь сопоставляются с шаблонами из проекта. В пакет попадает разрешённый шаблон, например POST /api/checkout/:id, а не фактический URL конкретного заказа. Временная близость не доказывает причинность и успешное выполнение запроса: SDK не удостоверяет оплату по бизнес-системе.

Если действие начинается позднее этого окна или через внешний API, разработчик может явно вызвать capture для поддерживаемой кнопки и заранее разрешённого шаблона. Не добавляйте ручной capture поверх уже работающего автосбора без проверки дублей. См. API клиента.

Канонический скелет

Вокруг триггера выделяется ближайший смысловой контейнер: form, fieldset, article, section, элемент с role dialog/group или data-tm-container. Обычные layout-обёртки не становятся самостоятельными смысловыми узлами.

Канонические типы: CONTAINER, STATIC_TEXT, INPUT_ENUM, INPUT_BOOL, INPUT_NUM, INPUT_TEXT, TRIGGER. Идентификаторы вроде n0.2 позиционные — это не DOM id, имя поля и не постоянный бизнес-идентификатор. После изменения структуры позиции могут измениться.

SVG, canvas, iframe и содержимое scripts/styles не анализируются как интерфейсные узлы. Скрытые, aria-hidden и data-tm-ignore поддеревья исключаются. Обычные нативные controls поддерживаются; сложный рисованный виджет не становится автоматически эквивалентом select.

Коды состояния перед действием

КодЗначение
0 · UNCHANGED_DEFAULTПоддерживаемое поле не изменилось относительно локального исходного состояния.
1 · MODIFIED_NUMИзменилось числовое поле.
2 · MODIFIED_BOOL_TRUEБулево поле изменилось в true.
3 · MODIFIED_BOOL_FALSEБулево поле изменилось в false.
4 · MODIFIED_ENUMИзменился выбор в select.
5 · MODIFIED_TEXTИзменилось текстовое поле.
6 · UNCHANGED_EMPTYПоле осталось пустым относительно исходного состояния.

Это наблюдение о состоянии перед взаимодействием, а не содержимое ввода и не автоматическое доказательство ошибки формы. Baseline снимается после включения сбора и при обнаружении поддерживаемых полей.

Две фазы доставки

  1. SDK отправляет компактный pulse с UUID события, сессией, хешем структуры, триггером, действием и кодами полей.
  2. Если серверу нужна структура, ответ содержит 202 и X-TM-Need-Skeleton.
  3. SDK передаёт skeleton и повторяет тот же pulse с тем же UUID. Известная структура и принятая либо идемпотентно повторённая запись дают 204 без тела.

202 не означает готовое намерение. Повторы не должны создавать новые UUID для одного события. Очередь и попытки ограничены; гарантированной доставки при закрытии вкладки нет.

Как читать результат

Намерения формируются из достаточного числа близких допустимых наблюдений. Автоматическое сходство не подтверждает бизнес-смысл: команда проверяет группу, называет её и связывает с фичей. Разбираться во внутренних векторах для этого не требуется. Технические свойства модели описаны в границах интерпретации.

Сессии — не люди; продолжение — следующее наблюдаемое действие в сессии, не подтверждённая покупка. Текущий Web SDK автоматически не измеряет Dwell или Rage: отсутствие измерения должно читаться как «нет данных», а не ноль. Ограничения и интерпретация →