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 снимается после включения сбора и при обнаружении поддерживаемых полей.
Две фазы доставки
- SDK отправляет компактный pulse с UUID события, сессией, хешем структуры, триггером, действием и кодами полей.
- Если серверу нужна структура, ответ содержит
202иX-TM-Need-Skeleton. - SDK передаёт skeleton и повторяет тот же pulse с тем же UUID. Известная структура и принятая либо идемпотентно повторённая запись дают
204без тела.
202 не означает готовое намерение. Повторы не должны создавать новые UUID для одного события. Очередь и попытки ограничены; гарантированной доставки при закрытии вкладки нет.
Как читать результат
Намерения формируются из достаточного числа близких допустимых наблюдений. Автоматическое сходство не подтверждает бизнес-смысл: команда проверяет группу, называет её и связывает с фичей. Разбираться во внутренних векторах для этого не требуется. Технические свойства модели описаны в границах интерпретации.
Сессии — не люди; продолжение — следующее наблюдаемое действие в сессии, не подтверждённая покупка. Текущий Web SDK автоматически не измеряет Dwell или Rage: отсутствие измерения должно читаться как «нет данных», а не ноль. Ограничения и интерпретация →